Gimp-Forum.net

Full Version: Indexed PNG palette is randomised?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I'm making wallpapers for my Kindle 3, and in Photoshop, when I export a PNG using the Kindle palette, the image displays correctly on the Kindle.

But when I export an indexed PNG from GIMP, the colours in the image are all wrong. Opening the resulting PNG in Aseprite shows the palette colours to be in a completely random order than the palette I provided.


I can then correct this in Aseprite by converting to RGB, sorting the pallete in decending luminance, converting back to Indexed mode and then exporting the PNG.

But I was wondering if I could save myself these extra steps in an external program and just have GIMP respect the original palette when saving the PNG?
I do not think it is possible.

You can sort a colormap by H S V but not luminance. Right click in the colormap for a menu.

A quick animation of that: https://i.imgur.com/XNrywIq.mp4

You can always ask the developers for an enhancement gitlab.gnome.org/GNOME/gimp/-/issues
I have a script to reorder a colormap (without changing the image of course) using any criteria that you can compute using the RGB values, but before it is useful here I would have to know how they compute Luminance.
Thanks for the reply guys - actually none of that would solve the problem, because the colourmap I created already has the colours carefully sorted into the correct order by hand. The problem is GIMP is not respecting that colour order after exporting to PNG.

The Kindle only reads images in a 16 colour indexed format. That's the really old image format which stores a colour palette in each image (so you can have 8 colours, or 256 colours, etc.), and each pixel value is a single integer index into that colour palette.

GIMP supports exporting to this format in the PNG export dialogue (when choosing the option "automatic pixelformat") but does not retain the order of the colours in the colour map. It keeps the same colours, but randomises the order they're stored in the palette in the file.  This seems unnecessary.

The Kindle expects the colour palette in a specific order, so the colours are all garbled when viewed on the device.
No easy solution, but only 16 colors. You can click and drag the colors in the colormap to re-arrange. At least it cuts out using another editor and saves a little time.
(11-30-2021, 03:38 AM)Domarius Wrote: [ -> ]Thanks for the reply guys - actually none of that would solve the problem, because the colourmap I created already has the colours carefully sorted into the correct order by hand. The problem is GIMP is not respecting that colour order after exporting to PNG.

This is not what I see:

  1. Create Color indexed image
  2. Open ColorMap dialog
  3. Duplicate image
  4. When switching images the colormap doesn't change
  5. Export the initial image to PNG, and close it
  6. Check on disk that it is indeed indexed
  7. Reload the saved PNG, still the same colormap (switching images with the initial duplicate doesn't change the colormap display)
So as far as I can tell, there is no randomization of the colormap when exporting (which, by the way would require additional CPU, because you would have to change all the image bytes to match).
A little bit of a hunt around Wink Is it related to this post

https://www.lemkesoft.info/forum/viewtopic.php?t=3936

editied out this part 16 grayscales that those models of Kindle can display correspond to: #ffffff or, 255 255 255 #eeeeee or, 238 238 238 #dddddd or, 221 221 221 #cccccc or, 204 204 204 #bbbbbb or, 187 187 187 #aaaaaa or, 170 170 170 #999999 or, 153 153 153 #888888 or, 136 136 136 #777777 or, 119 119 119 #666666 or, 102 102 102 #555555 or, 85 85 85 #444444 or, 68 58 68 #333333 or, 51 51 51 #222222 or, 34 34 34 #111111 or, 17 17 17 #000000 or, 0 0 0 The final image needs to be saved in a 4 bit (16 color) PNG-8 format with the above exact indexed values.

I can make a Gimp palette easy enough, it is a text file

Code:
GIMP Palette
Name: 4-Bit Grayscale-reversed
Columns: 16
#
255 255 255
238 238 238
221 221 221
204 204 204
187 187 187
170 170 170
153 153 153
136 136 136
119 119 119
102 102 102
85 85 85
68 68 68
51 51 51
34 34 34
17 17 17
0 0 0

If I take an image and convert to indexed mode using that palette

[attachment=7146]

The colormap keeps that order

[attachment=7147]

and checking the properties with Imagemagick it looks consistent. Nothing scrambled.  
I do think there might be a bug in the png export, Use automatic rather than 4 bit otherwise the result is not indexed.

[attachment=7148]

..but then I have nothing kindle to try it on.
OK! rich2005's screenshot exposed what the problem was;

In the dialogue for converting to Indexed colour mode, I noticed a checkbox for the first time - "Remove unused colours", which is checked by default.  In rich's screenshot, it's unchecked.

If this is checked, I noticed when converting to indexed mode, the order of the colours is changed, due to the removal algorithm of course (even though it never ended up removing anything). Ofnuts, this is the "extra CPU" that would be required!

That is the point where the colours are being randomised!  Not on export like I thought.


Leaving this unchecked, the palette order is maintained during conversion.  Whew!!!

Now I can stay within GIMP Smile Thanks guys!