Add Preference for "Color Depth on Save" (or similar)

[tannerhelland]

Add Preference for "Color Depth on Save" (or similar)

[Kroc]

You could use the "Count Image Colors" function to suggest an appropriate bit depth automatically when saving to PNG. Also, you could track the effective bit depth of the image as it's manipulated; e.g. when the user uses Black and White on the whole image, you can flag the image as 1-bit depth. When the user uses Greyscale, you can flag as greyscale for PNG and so on (of course, when the user chooses another filter on an image that is 1-bit for example, that would change it back to being flagged as 24 / 32-bit.

[Kroc]

Also, changing of bit-depth would be super useful in the batch mode.

[tannerhelland]

The "Count Image Colors" function is absolutely the right way to go - great suggestion. As of 780c12e the original color depth of all loaded images is initially stored (either by remembering the source file's color depth, or by counting colors at time of image import), which gives us a baseline to operate against.

Rather than tracking the image's color count during editing, the color count will only be recalculated when the user requests a Save, and even then it will only be calculated if it needs to - for example, JPEGs are always 24bpp so there is no need to count colors for that.

There will be three user preference choices for governing how color depth is handled:

1. Automatically save to the optimal color depth. (PhotoDemon will compare the image's current color count against color depths supported by the output format, and it will always choose the lowest possible color count that includes all colors and is valid for that file type.)
2. Automatically save to the file's original color depth. This way, 8bpp PNG files can be loaded, edited using any function, then saved back to 8bpp PNG without the user having to manually switch back-and-forth between higher and lower color depths at edit-time and save-time.
3. Always provide an export color depth prompt if relevant. This exists for power users who may want to have more fine-grained control over exported color depth, and who don't mind being prompted at every "Save As" click.

The real monster here is going to be the handling of transparency. 32bpp to 8bpp reduction is messy business. For individual files, an interactive "set alpha cut-off" dialog can be used, but there needs to be an automated solution for use during batch operations - for example, batch converting 32bpp PNGs to GIF format.

I haven't settled on the best solution for automated 32bpp -> 8bpp with transparency. Suggestions welcome. Right now I'm leaning toward a simple threshold solution during batch conversion, e.g. "alpha from 0 - 127 is always forced to 0, alpha >= 128 is always forced to 255, any pixel with alpha 0 is assigned the transparent palette index". I can't think of a better way to handle it without requiring user interaction on an image-by-image basis.

[Kroc]

You are aware that PNGs can be 8-bit colour and 8-bit alpha at the same time? :)

[tannerhelland]

Well, the palette can contain an alpha value for each entry, correct? But all pixels with that palette entry must have the same alpha value.

So an 8bpp image can't have unique alpha entries on a per-pixel basis - just a per-index basis. ...Right? Unless I'm misunderstanding?

Which still leaves a "simple transparency" approach as the only easily automated approach for 8bpp images. (I'm reliant on FreeImage for 8bpp reduction, which only works on 24bpp images - so all transparency data will have to be manually managed by me. The simpler the better!)

[Kroc]

"So an 8bpp image can't have unique alpha entries on a per-pixel basis - just a per-index basis" Wrong :)
PNGs can have a palette and a full 8-bit alpha layer! This means that you don't have to flatten an image's alpha to 1-bit unless requested. Check out this for examples: http://pornel.net/pngnq

[tannerhelland]

Ah, very interesting. The sample files on that site listed as "128 colors with alpha channel", don't actually have an alpha channel - they are 8bpp images with a very cleverly manipulated palette! To see further, open the PNG files in question with something like Irfanview - note how the appearance of the "alpha channel" is really just a modification of the paletted image. They make ingenious use of the tRNS chunk to mimic the look of an actual alpha channel.

Per the official PNG spec (http://libpng.org/pub/png/spec/1.1/PNG-DataRep.html#DR.Alpha-channel), emphasis added:

"An alpha channel, representing transparency information on a per-pixel basis, can be included in grayscale and truecolor PNG images... Transparency control is also possible without the storage cost of a full alpha channel. In an indexed-color image, an alpha value can be defined for each palette entry. In grayscale and truecolor images, a single pixel value can be identified as being "transparent". These techniques are controlled by the tRNS ancillary chunk type."

It would be no small programming feat to pull off what pngnq does and generate a palette that is both a good representation of the image, and a good representation of the alpha channel... I don't think I'll be adding that to my agenda any time soon. o_O

[Kroc]

Cheat :) You can use pngnq / pngquant to optimise the file into 8-bit for you, just compare these full-colour and 8-bit images http://pngnq.sourceforge.net/pngnqsamples.html

[tannerhelland]

Actually, I am in luck on this count - FreeImage implements the same NeuQuant reduction algorithm as pngnq. :) I've already stolen it for the Color -> Reduce Unique Colors tool. The results are stunning, and even more amazing is how little memory it uses (on a 0.2 megapixel image it uses 8k compared to 432k for a standard median-cut algorithm).

So reducing to 8bpp is no problem... it's handling alpha that is no fun. I'm a little reluctant to include pngnq directly as a dependency, especially since it has other dependencies (libpng) which would require a lot of changes to my plugin code, all for a fairly rare edge-case.

First things first, I need to get regular color depth and simple transparency handling working, then I can look at improving the 32bpp -> 8bpp w/ transparency technique. I'll leave this issue open in the meantime.

[tannerhelland]

Note: the newest version of pngnq includes libpng compiled right into the .exe - yay!

[tannerhelland]

Okay, after playing with pngnq for the past day, I've become a believer - it's an amazing tool, well worth inclusion as a plugin. Consider its inclusion in PhotoDemon officially "on the roadmap."

With the big feature for the next PhotoDemon release being an overhaul of the Batch Convert tool, it's as good a time as any to integrate something like this. I'll still need a non-pngnq fallback for handling the simple transparency involved in GIF files, and as a stand-in if pngnq can't be found, but when it comes to 8bpp PNG files pngnq is definitely the way to go. I love the thought of running a whole folder of 32bpp PNG files through the batch convert function, and producing a collection of tiny high-quality 8bpp PNG files ready for upload to a site.

Thanks for the recommendation and discussion.

[tannerhelland]

This issue is now resolved, in the sense that:

• there is a preference for how color depth on save is handled
• color depth is properly handled based on that preference

Transparency is not currently handled for 8bpp reduction (all alpha data is lost). I am in the process of fixing this, but it requires a specialized dialog for handling alpha cutoff.

Once that is complete, pngnq will be added as an option for 8bpp PNG files (as part of a larger plugin framework rewrite).

[tannerhelland]

As of b75d981, transparency is preserved when saving 32bpp to 8bpp formats. Binary alpha channels (e.g. alpha channels consisting of only 0 and 255) are automatically handled, while complex alpha channels result in the user seeing an alpha cut-off dialog with live previewing.

I am closing this issue and opening a new one specifically related to pngnq support.