12-19-2024, 08:06 AM
(12-18-2024, 09:46 PM)Ofnuts Wrote:(12-18-2024, 11:08 AM)ken Wrote:(12-18-2024, 09:43 AM)Ofnuts Wrote: Two explanations:
- There is a bug, in which case you can report it (but with the actual image and palette)
- Your expectation of "closest color" is not the same as Gimp's. This wouldn't be surprising since looking at the comments in the source code (see here around line 31) Gimp doesn't match colors in RGB but in CIE L*a*b space (and the comment at line 22 hints that in Gimp3 this will be done using the linear and not gamma-encoded values).
I think this is a bug, so I would like it to be fixed.
By the way, I am using LinuxMint and Windows11
and the same issue occurs on Gimp 2.10 and 3.0.0RC1.
Here is the image that actually had the problem.
How can I add palette information (gpl)?
You can put the GPL in a ZIP and attach it here. But as far as I can see you don't even need a palette to show the problem:
- Color > Info > Color cube analysis shows 229 distinct colors in the image, so that 's less than 256 and you can use these to make a palette for color-indexing
- Importing a palette from the image indeed yields a 229-colors palette
- You can convert your image to indexed using this new palette. You would expect the conversion to be perfect....
- If you copy-paste the color-indexed image back over the original image and compare them (top in "difference" mode) you indeed find that there are pixels that are different, the worst offender being pixels with color (0,0,64) being indexed to the color (0,0,60).
- Problem appears worse in 2.10 than in 3.0
- Just reported here.
Thank you for looking into this issue.
For now, I guess I'll have to wait for a Gimp update to fix this issue.
I hope it will be fixed in the official version of 3.0.