[continued from previous message]   
      
   ends up needing palettes or encoding schemes that are slightly irregular.   
      
      
      
   For color-cell, there are different approaches depending on how fast it   
   needs to be:   
      Faster: Simply select minimum and maximum luma;   
        Selector encoding is often via comparing against thresholds.   
          Except on x86, where multiply+bias+shift is faster.   
      Medium: Calculate along 4 axes in parallel;   
        Select axis which gives highest contrast;   
          Usually: Luma, Cyan, Magenta, Yellow.   
        Adjust endpoints to better reflect standard deviation.   
          Vs simply min/max.   
      Slower:   
        Calculate centroid and mass distribution and similar;   
        Better quality, more for offline / batch encoding.   
      
      
   As noted, early on, I was mostly using real-time color-cell encoders for   
   Doom and Quake and similar (hence part of why they were modified to use   
   RGB555).   
      
   Some of this is also related to the existence of a lot of RGB555 related   
   helper ops. Though, early on, had also used YUV655 as well, but RGB555   
   mostly won out over YUV655 (even if it is easier to get a luma from   
   YUV655 vs RGB555).   
      
   ...   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)