#35 The color palette order is changed when a PNG file is exported

[SD Snatcher]

When a PNG file is exported, the palette color order is changed.

Ideally, the original palette order should be preserved, to allow post processing of the images and re-conversion to be done without worries.

I attached here a reference image, the exported PNG and the palette order inside the PNG file.

[Grim]

This is because the way recoil works the image is converted to RGB and the palette gets discarded. The new palette comes from reducing the number of colors again, which will also cause any unused color to get lost in the process. See bug #28.

[Grim]

Properly fixing this requires a lot of small changes all over the code. This patch demonstrates how to do it gradually (with only a moderate risk of breaking things in the process). It currently only preserves the palette for MSX formats (including SC2) and some others. Once the changes are done i guess ContentPalette can be removed, possibly also the RGB to indexed color conversion code, maybe even the color counting code? It is also an open question if both the RGB version and index version of the image needs to be stored at the same time or if the same memory can be used for both (there doesn't seem to be unions in Ć though).

I volunteer to make all the changes if this approach gets approved.

[Piotr Fusik]

This ticket is a subset of [#28]. Let's discuss the palette preservation here and leave [#28] for the pixel geometry.

It's not clear what the "original palette" means. If processing a 4-color image from a C64, should the palette be 4 colors or 16 colors that the hardware has?
Some formats support different palettes in different lines, e.g. Atari 8-bit G2F and various "multi-palette" flavors of ILBM. Do we want to preserve these palettes? That could easily cross the limit of 256 colors in PNG.
What about flickering images?
What about sprites with colors controlled independently from the bitmap?

Thanks for the patch!
Lack of unions in Ć is not an issue. RECOIL should switch to dynamic allocation for the pixels in order to support some really huge images (mostly IFF and GEM IMG). I'd like to work on this first.

[SD Snatcher]

It's not clear what the "original palette" means. If processing a 4-color image from a C64, should the palette be 4 colors or 16 colors that the hardware has?

For example: In MSX and PC-98 image files the "original palette" will be the palette with the colors ordered in the exact same sequence it had on the original file.

The correct order of the colors for many aplications. For example:

• On MSX1 and C64, there are many different "flavours" of the hardware palette out there.. Depending on the complementary tool you're going to use, it will require a specific palette flavour to work correcly (i.e.: Pixel Polizei). With the colors in the correct sequence, it's possible to use the GIMP Color->Map->Set Colormap funcion to easily change between all the palette flavours for the MSX1 and C64 required by other tools

• On the MSX2, the correct color sequence is very important because, otherwise it will ruin the Sprites "OR color" feature. This is important for game development, i.e.

[Grim]

In my opinion an image for the C64 should generally have all 16 colors in the palette, even if the image only contains a subset. Perhaps if the format has a concept of a palette with fewer colors, only those colors should be included. Does such formats exist?
For multi palette images I don't think the concept of an original palette is relevant, it's okay to treat them as not having a palette (same as with HAM).
For flickering images it would be ideal if each frame could be accessed individually, with it's own palette. Otherwise I don't consider it as important. (Perhaps if there are only two frames with 16 colors each, a palette of 256 colors could be constructed.)
For images with different palettes for background and sprites I would prefer if the palettes where concatenated and the colors of the background and sprites mapped to corresponding part of the palette. But this would be a problem if the total number of colors exceed 256. Does such formats exist?

[Piotr Fusik]

Makes sense, thank you!

Perhaps if the format has a concept of a palette with fewer colors, only those colors should be included. Does such formats exist?

Yes, from http://recoil.sourceforge.net/formats.html#Commodore-64: CLE, IHE, LP3 and a few mono formats.

For multi palette images I don't think the concept of an original palette is relevant, it's okay to treat them as not having a palette

For Atari 8-bit multi-palette, I'd like to have the whole hardware palette of 256 colors.

But this would be a problem if the total number of colors exceed 256. Does such formats exist?

http://recoil.sourceforge.net/formats.html#MSX2p with the bitmap having thousands of colors, but sprites sharing a 16-color palette. Rare thing, I guess.

[Grim]

Here is a less intrusive patch against the current version. It add an optional argument to SetSize() which lets the caller request indexed pixels (instead of RGB pixels). In that case the image will never be converted to RGB then converted to PNG, and the original palette will of course be used. Everything will still function exactly the same from the API user perspective.

It would also be easy for a decoder to first request indexed pixels and at a later stage upgrade to RGB pixels (because it needs to do some color mixing or whatever).