tannerhelland
Preserve 8-bit color tables when importing/exporting 8-bit images
I received the following feedback on photodemon.org and am seriously considering it for 7.2's release:
Today I came upon this app while searching for dither related apps and the sort and frankly this is very good!
However, there is one thing that could use improvement. Namely, when you open indexed 256 color images, be it gif/pcx/bmp/png-8 and do anything you lose the original indexing of the color table!
Method to reproduce is simple: open any 256 color indexed file and then go just save it, choose gif or bmp, doesn't matter which, and then go inspect the color table of result file. It has been reordered by PhotoDemon. In my example, PhotoDemon reduced the 255 colors into 160 shades and filled the rest with grayscale shades at end that are not even used by the art.
Now I figure the response is along the lines of...our app converts the indexed art into RGB24/32 within app memory for editing functions and thus mangles the color list when it rebuilds the table...
...but it's worth asking if this could allow edit and still keep original palette positions while of course allowing some of the editing functions (I realise not all editing options can be viable for indexed) to change said colors.
If not, then I will just have to settle for doing prior palettization edits than after hand edits with this.
I've just added a series of commits that will make this... "more" possible than before (see 7bd5e70fcb913a2d8a80c0ae5d83e68219f20e26, for example, also 490f58dc2d2ea83350d638c04421f6eb405223b0), but because file import/export is heavily reliant on 3rd-party libraries, there are parts of this equation I don't control - and as usual, they're the parts that will be most tedious to work around. (At present, I pass our internal 32-bpp RGBA data, with only minor preprocessing based on export settings, to various 3rd-party libraries - and they are then responsible of converting the image data to appropriate export color depths.)
To preserve color tables, I'll need to switch PD's export engine over to a fully internal solution for generating 1/2/4/8-bpp data. We have most of these capabilities already, thanks to a bunch of palette-related work in this release cycle, but these features are currently built around "effect" usage, not formal export usage. I'll need to rework a bunch of internal guts - including PD's entire export interface - so that PD itself handles things like 8-bpp data generation, and that data gets passed to external libraries who only handle the write to file (as opposed to generating the 8-bpp data themselves).
Because image export is horrifically complicated, and it's so crucial to a working program, I'll need to tackle this more slowly and cautiously than I usually do. I'll try to reference this commit as various bits fall into place.
