Index8 Profile with auto-generated CLUT does not show white or gray variations

Question

Hello, I've autogenerated the CLUT file by using the EmWi recommended method. Everything looks good except for variations of white and gray that are essential to the look and feel of our application on Index8. I saw that only 191 entries had been created, so I manually entered the gray and white variations into the CLUT file, and that helped with the white variation but that didn't make much of a difference unfortunately for the gray variation. Here are the values that I added (the last 2 are the ones that are not working right):

  #F2F2F2FF, // 192: RGBA( 242, 242, 242, 255 )
  #DDDDDDFF, // 193: RGBA( 221, 221, 221, 255 )
  #3F3F3FFF, // 194: RGBA(  63,  63,  63, 255 )
  #3A3A3AFF  // 195: RGBA(  58,  58,  58, 255 )

Answer 1

The color granularity for Index8 color format is limited. This means, all gradients and all dynamically calculated colors have a limited variation.
Allthough you fill many similar colors into the CLUT, the resulting color gradients will have noticeable color steps.

Let me try to explain: For all dynamically calculated colors the resulting index has to be determined during runtime. This means, for all drawing operations (line, rectangle,...), for all text drawings and for all bitmap transfers with blend mode the resulting color (= index) needs to be mapped to the CLUT.
For this purpose, an internal color mapping table is used: For each color, there are only taken the most significant bits (RGBA 4:4:4:2) to find the index.
Therefore, it makes no sence to have too much similar colors, since they won't be found during runtime.

However, there is one difference: Bitmap resources are already mapped pixel by pixel to the global CLUT during compile time!
Since this procedure is not time critical on PC, all pixels of a bitmap are mapped exactly to the best fitting color.
If a color is not found, the nearest color is taken and the resulting error is equalized by dithering.
This all means, that a bitmap (Views::Image), which is drawn by using the copy mode, is mapped exactly to all colors, even they are similar.

What is the background for this implementation:
For all bitmaps, the Resource Converter take care on the real colors and uses dithering to get nearest results. By using this approach it is possible to work with images including color gradients. For all dynamically calculated colors (which happens always in 32 bit resolution) a good fitting color is found very fast only by using the color mapping table.
Of course, it would be possible to find a better color in the CLUT by comparing all CLUT entries. But this never happens within an acceptable time.

Thus, the Index8 color format is a good compromise between low memory consumption and fast graphics performance. Of course, there are limitations and the color space is not as rich as true color formats...