GNOME Bugzilla – Bug 602632
Sloppy colour index number assignment in RGB -> indexed mode function
Last modified: 2009-11-23 14:11:03 UTC
Sorry if this is known, I didn't get any hits on it in open bugs, and it's not listed in bug fixes from 2.6.5 (where I found it) onward. I would describe this as a "backslide", in that gimp 2.0 and 2.2 did not have this problem. Best way to explain is to try it, and I have visual aids, but I'll try to describe it as well. If you have an image in RGB mode, and you create it with only one colour R,B or G, but with 256 levels, such as this one: http://i35.photobucket.com/albums/d177/PV1/BoB/doverLSRTMTest.png and you create a palette file with all 256 levels of that colour, such as in this zip: http://www3.telus.net/v1ncent/bob/GreenPalettes.zip then if you do a mode RGB -> indexed on that image, specifying use of that palette, gimp should find an exact colour match on the palette for each colour on the image, and thus the indexed output image should be identical in appearance to the input image. As I say, gimp 2.0 and 2.2 did this pretty well - maybe not exactly perfect, but close enough that no error could be seen on visual inspection. However, with 2.6.5, which I used for this recently, the output looked like this: http://i35.photobucket.com/albums/d177/PV1/BoB/doverLSRTMgimpBadIndex.gif You should be able to see the problem quite clearly. The indexing routine is using roughly every 4th entry in the palette when assigning the pixels, so the smooth transitions of the original become steps. Even irfanView does a better job, though not as well as gimp used to do: http://i35.photobucket.com/albums/d177/PV1/BoB/doverLSRTMirfanBadIndex.gif
Upon getting more familiar with the bug search function, I have found a similar looking report, #421751. I like to think my description of the problem is clearer, but it appears he's describing the same problem. Drifting through some discussions in other indexing bug reports, it seems there's not a lot of interest in the indexing code. To elucidate the reason why this might matter, the images shown here are used for terrain height (DEM) data translation. Each palette entry represents a height of one metre, so if only every 3rd or 4th entry is being used, the original 1 metre height resolution is being degraded to 3 or 4m, which in some cases makes the file unuseable. Yes, it may be possible to locate some dedicated geo-tool that might have the required function, with an associated learning curve, but when all the other aspects of the work I'm doing are image work using gimp, it doesn't seem unreasonable to hope it could be fixed to do this as well.
Indexed mode is scheduled to be removed in future versions of GIMP. It will become an export option, and most likely the focus will be people who just need indexed colors. If you need more precise control, then I'd suggest that you contribute to whatever changes will be done. *** This bug has been marked as a duplicate of bug 421751 ***