Select Image → Mode → Indexed → Generate optimum palette
GIMP mangles the perfectly white (#ffffff) background into a green-tint (#fbfdfa).
It’s not as if there are too many (>255) colors to represent accurately. If you look at the Colormap, color index 254 is white (#ffffff) so no reason it couldn’t have used that. I don’t have dithering enabled. I see no reason it should mangle the white background into off-white.
GIMP versions quite a number of years old, as well as new, exhibit this issue for me.
Seems there is an open GIMP bugreport with no activity for the past 4 years, too:
I can go into the Colormap and pick and fix the background color, but it’s cumbersome and really shouldn’t be necessary.
What does everyone else do? Just tolerate discolored images? Keep their images 5X larger than necessary for no reason? Convert to indexed color with a 3rd party tool like pngcrush/pngquant/optipng/oxipng?
The last time i worked with manual prepared indexed color maps was for the web in the 1990s For that (and modem connections), tools like GraphicConverter or the legendary Debabelizer at high cost were my first choices.
Little edit: I tried with Gimp 2.10.38 the conversion from rgb to a indexed palette of 256 color (without dithering) and got a white with #FFFFFF. After saving as png and loading in GIMP again the white was still #FFFFFF.
Provided I understood the source problem correctly
I don’t have 2.10.38 conveniently available, but I just reproduced the problem exists with 2.8.22, and a newer beta version, but perhaps I need to try an even more recent beta. I can’t imagine why the project would have quietly fixed this issue but not closed the multiple (confirmed) bugreports about it.
I’ve found pngquant works well for me, doesn’t mangle colors and happens to produce even smaller files. e.g.:
pngquant -f --nofs --strip --speed 1 256 file.png
It’s got some more advanced features to specify size/quality I’ll have to try out in the future, but for now it’s easy to change 256 to 32 or similar for even smaller files that still look better than GIMP’s sad attempts.
Hi! It’s likely because it was fixed as part of solving another problem, and we didn’t notice. Improving indexed mode is one of our goals after 3.0, but the majority of developers work with RGB/Grayscale images in their daily work.
If I understand you correctly and the issue is fixed in the newer 2.99 development releases, it’d be really helpful if you could post to confirm in those issue reports. Then they can be closed. Thanks!
Mode → Indexed → Generate optimum palette
GIMP mangles the perfectly white (#ffffff) background into a green-tint (#fbfdfa).
Using kubuntu 24.04 here, Gimp 2.10.38 and 2.8.22 (portable) and I can not reproduce that, no green tint. I do appreciate that Generate optimum palette will give an off-white background. Maybe for that sort of image using a defined palette is a better option.
This using a print-safe palette with 224 colours, enough for the anti-aliasing in the original png and it reduces to a sensible 32 colours, only a single white for the background. I really advise upgrading to the latest Gimp if possible, however this using Gimp 2.8.22
For that (and modem connections), tools like GraphicConverter or the legendary Debabelizer at high cost were my first choices. 