Preserve 8-bit color tables when importing/exporting 8-bit images #255
Comments
tannerhelland
added a commit
that referenced
this issue
Apr 20, 2018
I still need to do a final round of testing (and a bit of code clean-up now that everything is implemented), but with this feature finished and active, I can (proudly!) state that PhotoDemon now loads all PNG files using its own internal, custom-built PNG parser. Our parser handles all combinations of color types and bit-depths (yes, even strange ones like HDR grayscale+alpha), and for the first time, color-management is deeply integrated into the loader. When ICC profiles are embedded, they are applied directly to raw PNG data, without any pre-processing (as we had to do with 3rd-party libraries). This guarantees maximum quality across the board, and allows us to produce identical results to Photoshop on HDR images. Similarly, on paletted images we now detect and store the original, unmodified file palette. This is a huge step toward serious work on #255 (although I still need to write a PNG exporter, *sigh*), and it lets me drop a bunch of tedious code that requires multiple 3rd-party libraries to correctly identify embedded image palettes. Esoteric PNG chunks are also no problem; we grab the ones that are relevant to PD and process them fully. Ones that are *not* essential to PD are off-loaded to ExifTool. I'll be doing some heavy testing over the next few days to ensure that I haven't missed anything, but as of now, nightly builds are already using the new PNG parser. Please let me know if you run into any unexpected results.
tannerhelland
added a commit
that referenced
this issue
Apr 9, 2019
I think I'm about ready to call PD's new PNG engine "finished". By default, PD now outputs smaller PNGs than any other major software (including Photoshop!). It uses the full breadth of PNG encoding features plus a [high-performance Deflate engine](https://github.com/ebiggers/libdeflate) to achieve this. If you don't care about the new compression gains, note that the new system also outputs PNGs *faster* than previous versions - which is particularly relevant when exporting ORA files (which hold a collection of individual PNG layers). As part of this commit, PD's ORA exporter has been fully switched to the new PNG engine. Because I finally have total control of the PNG import/export process, I hope a number of long-requested features will finally be possible (e.g. #255 is *finally* feasible). Also included in this commit is a new German language file c/o Roy K. Thank you, Roy!
tannerhelland
added a commit
that referenced
this issue
Jul 1, 2020
Relates to #255 It has taken me a long time to add this, sorry! Also, this feature is only available for PNG files at present because that's a file format that I control end-to-end (e.g. no 3rd-party libraries involved). That's the only way I can make this work, as libraries like FreeImage can modify palettes internally (like always padding out to 256-colors) without any way to override 'em. Anyway, the idea here is simple: if a user loads a PNG file, then modifies it, then wants to save it out to file with identical color-depth settings (including palette order), there is now a "use original file settings" toggle that does just that. Per the request I originally received, this is useful when editing 8-bpp images with fixed palettes. Sometimes these files have palettes where palette order matters, and reordering the palette - even if it reduces file size - is undesirable. This was a complicated feature to enable because has to work across the huge matrix of possible PNG settings - some of which we now need to cache when a file is first-loaded, just in case we need to access them again later. I think I've covered all possible branches, including esoteric ones like HDR images, but please let me know if you encounter any surprises. In the future, I may be able to extend this to other file formats, but it'll always require custom encoders and decoders to make it work.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I received the following feedback on photodemon.org and am seriously considering it for 7.2's release:
I've just added a series of commits that will make this... "more" possible than before (see 7bd5e70, for example, also 490f58d), 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.
The text was updated successfully, but these errors were encountered: