GNOME Bugzilla – Bug 421751
Indexization using a custom palette doesn't quantize accurately
Last modified: 2018-05-24 12:10:20 UTC
Steps to reproduce: 1. Create a new RGB image of 256x256 pixels 2. Generate a grayscale sinus pattern onto it using filters->render->patterns->sinus 3. Check the number of colors using Colorcube Analysis(255) 4. Palette map the image using the attached palette of 192 colors. 5. Check the number of colors (190) 6. Indexize to the attached palette. 7. Check the number of colors (101) In this case, 90% of the colors in the non-indexized picture aren't being used despite all of the colors in the picture matching palette entries exactly. Compare with this: (starting after step 5) 6. Indexize the image to 256 colors, optimal palette 7. Check the number of colors (still 190) See the attachments.
Created attachment 85150 [details] palette-mapped sine pattern
Created attachment 85151 [details] palette-mapped sine pattern after indexization to specified custom palette This error occurs regardless of the palette -- Erroneous matching occurs when two or more 'candidate' colors from the palette are too 'close' to each other, but only when indexizing to a custom palette. It seems to treat some entries of the palette as simply not available to quantize to. Choice of dithering algorithym is irrelevant, except to note that dithering is done even when it is not needed, like in this case.
Created attachment 85152 [details] custom palette
All you have shown here is that the RGB->Indexed algorithm and Colorcube Analysis plug-in use different algorithms to determine the number of colors. The RGB->Indexed conversions works in CIE-LAB space so it is not surprising that it selects a different number of colors. In my opinion this is not a bug. I'll give you a chance to show us that it is one by not closing this report yet but setting it to NEEDINFO.
What you said is completely unrelated. The fact is, that when I start with an image where all the pixels are of colors exactly the same as palette entries, and indexize that to the palette, colors disappear; In the original image, 190 of the palette entries are used; after indexization, 101 are used. Colorcube analysis is irrelevant, it's just an easy way to verify the error. You could just as easily convert to indexed with an optimal palette of 256 colors and then take note of the highest entry. Can't you see the data loss between the two images, that shows clearly that colors from the palette that match EXACTLY are not being used, and other colors that match less well *are* being used?
Is the human eye able to differentiate the lost colors from the ones that are used? The algorithm is based on human perception. It doesn't aim to create a perfectly matching image, it aims to create one that looks the same and it tries to use as few colors as possible.
Okay; Yes, the difference is perceptible to the naked eye (at least mine). Aside from the differences in the colors used for individual pixels (which would need to be at least 50% closer to the original color to be unnoticable), the overall contrast is increased, and the image is roughened. Anyway, let's say that's okay. The other issue remains -- indexizing to an optimal palette of 256 colors produces *no* degradation, and picks all the appropriate colors, whereas indexizing to a premade palette does degrade the image, though the exact same colors are being indexized. From a user's point of view, I find this inexplicable -- Isn't the point of custom palettes to control more precisely the result you get, rather than less precisely?
Then probably there is a bug. I doubt however that we will find time to debug Adam's indexing algorithm. We would very much appreciate a patch though that improves it.
*** Bug 602632 has been marked as a duplicate of this bug. ***
David, does this still happen in master? Tho the indexed conversion is mostly the same, everything else regarding colors has changed, so maybe...
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/238.