Converting from RGB to indexed changes colors
Submitted by Raphaël Quinet
Description
When the Gimp converts an image to indexed mode using "Generate Optimal Palette" and there are more colors in the RGB image than the palette can hold, then all colors in the image are changed. This is not a problem in some cases (and it is even desirable most of the time because the averaged colors give better results) but in other cases this can lead to bad results if some of the colors had to keep a precise value.
For example, if an image contains some web-safe colors (6x6x6 color cube) together with some other colors from which an "optimal palette" should be generated, then all web-safe colors will be shifted to another value (another option would be to force all colors to be mapped to the web-safe palette instead of generating an new palette, but this implies some losses for the other colors). Another example is the images used in games like Doom or Quake that have a range of 20 or so "fullbright" colors in their palette, which get a special treatment during the rendering. Or some programs relying on a special color such as blue or magenta for generating a transparency mask from a flat bitmap. In all these cases, the exact value of the colors is important and they are modified when converting the RGB image to indexed mode. This is also annoying if an image contains a corporate logo that has to keep some precise RGB values requested by the corporate visual identity.
How to reproduce: 1 - Create an image containing the 216 web-safe colors (this can be done by taking a screenshot of the palette editing window when you select the "Web" palette) 2a - Add some other colors to the image (for example, add a gradient on the side of the image) so that the total number of unique colors is greater than 256, then convert the image to indexed mode without dithering. 2b - Alternatively, use the image with 216 colors and generate an optimal palette that is limited to 215 colors or less. Select no dithering. 3 - Open the Indexed Palette dialog and look at the values. All colors will have been shifted to a different value. This is particularly visible for black (#000000) and white (#ffffff), which get different values (for example, #020202 and #fefefe). If you display the resulting image in a web browser that can only use a 256-colors display, you will see a lot of dithering on the image.
Even if this should probably not be the default (for the reasons mentioned above), there should be a way for the user to ensure that the "optimal palette" generated by the Gimp will only use some colors from the original image without trying to shift their values. This could be done by adding a checkbox in the Indexed Color Conversion window saying "average colors" (checked by default).
Current workarounds:
- After converting to indexed mode, open the Indexed Palette dialog and edit the important colors one by one (those that must have a precise value, such as pure black, pure white or web-safe colors).
- Do the conversion in two separate images: From the original RGB image, extract all parts containing the colors that have to keep a precise value and put them in a new image (other parts are transparent). Create a second image containing the parts that are not in the first one (all parts using colors that are not so important). Convert the first one to indexed mode using exactly the N colors that have to be preserved. Convert the second one to indexed mode using 256 - N colors (so some colors will have to be merged, but this is not a problem for these parts of the image). Paste both images in a new RGB image and flatten it. Now convert this to indexed mode and the result will have exactly 256 colors, while still preserving the colors that are important.
- If the same operations have to be done with a large number of images and all of them have more or less the same colors, then the best workaround is to create a new palette by hand, containing all important colors plus a good selection of non-important ones. Then convert all images to that palette instead of generating an "optimal" one. All of these workarounds are rather tedious.
Version: 1.x