After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 331198 - Suboptimal RGB->Indexed conversion
Suboptimal RGB->Indexed conversion
Status: RESOLVED DUPLICATE of bug 66257
Product: GIMP
Classification: Other
Component: Tools
2.2.x
Other All
: Normal minor
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2006-02-14 21:51 UTC by Max Gilead
Modified: 2008-01-15 13:05 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test image (16.76 KB, image/gif)
2006-02-14 21:52 UTC, Max Gilead
Details

Description Max Gilead 2006-02-14 21:51:41 UTC
Please describe the problem:
When performing RGB->Indexed conversion some colors are converted imprecisely.

Namely, the black color in attached animation is converted to color (4,7,2)
regardless of the fact that black background is vast majority of the pixels in
this image and the rest of image is almost monochromatic (red-orange). I would
expect that conversion of such image yielded almost perfect result.

Steps to reproduce:
1. Open tiger_eyes_128.gif
2. Convert to RGB (Image->Mode->RGB)
3. Scale image to 176x66 (Image->Scale Image)
4. Convert to Indexed color (Image->Mode->Indexed, Optimum palette, no dithering)


Actual results:
Black color is replaced with color (4,7,2).

Expected results:
Black color is kept precisely at (0,0,0).

Does this happen every time?
Yes.

Other information:
This work is based on photo taken 2005 by Bernard Landgraf:
http://commons.wikimedia.org/wiki/Image:Panthera_tigris_2.jpg
(http://upload.wikimedia.org/wikipedia/commons/c/c0/Panthera_tigris_2.jpg)

Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation; with no
Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of
the license is included in the section entitled "GNU Free Documentation
License."
Comment 1 Max Gilead 2006-02-14 21:52:44 UTC
Created attachment 59372 [details]
test image
Comment 2 Max Gilead 2006-02-14 21:55:18 UTC
Sorry, forgot: workaround is to convert image back to RGB, fix the color in all layers and convert to indexed color again. This time conversion retains black color correctly (no idea why).
Comment 3 Sven Neumann 2006-02-15 08:06:28 UTC
This is a duplicate of bug #66257, isn't it?
Comment 4 Raphaël Quinet 2006-02-15 10:31:00 UTC
Yes, this is a duplicate of bug #66257.  Marking as such.

Regarding comment #2, the reason why the second conversion from RGB to indexed
does not change the colors is that the first conversion has already reduced
the number of unique colors in the image.  If all colors fit into the colormap
for the indexed image (i.e., 256 colors or less), then the conversion algorithm
does not have to modify some of them in order to minimize the total color shift
of the image.

By the way, you do not have to go back to RGB, fix the colors and then convert
again to indexed mode.  You could simply convert to indexed mode once, then
open the colormap dialog and simply fix the colors there before saving your
image.


*** This bug has been marked as a duplicate of 66257 ***