Handling Of Png Background Transparency In V3.72+ Options

[mrwarper]

Hi everyone, long time user of ancient versions (pre-name changes), new user of current ones, first post.

After doing a bit of research I'm afraid I'm not clear on how [newest] PMView handles transparency so I thought I would ask here...

I have a b/w png with its white 'background' set to transparent. It is used on a web page, the idea being that the image won't need to be touched to match the background color if it ever changes. Looks as it's supposed to in SeaMonkey.

Open it in PMView 3.72, 'save as' (Type: PNG, 'transparent': checked; -- Options: 'use transparent color if possible': checked, 'allow use of palette for grayscale': checked). Reload in the browser and poof! image has a solid white background -- transparency is gone! Tried other options with the same results (binary-identical output files).

File -> Info as reported by PMView:
Before save) No. of colors: 2, Color Type: Grayscale, Bit Depth: 1, Transparent Grayscale: 255
After) No. of colors: 2, Color Type: Grayscale with Alpha, Bit Depth: 16

What am I supposed to do to preserve transparency in old images?
Any recipes to save PNGs with transparent backgrounds in the newest PMViews?
Are b/w images handled differently than 4 or 8-bit images with transparency?

TIA.

[Peter]

I need more info to resolve this problem. You may be the first one that is actively using the new features in PMView v3.7x, and you may have stumbled on a bug. (I don't see why the saved file ended up with a bit depth of 16 bits - that does not look right!)

Please e-mail me directly peter@pmview.com


Thanks,
Peter

[Peter]

I have now fixed the bug. It turned out that the problem already happens when loading (reading) the specific PNG file in question. PMView v3.7x does not handle a transparent color definition (TRNS) correctly for grayscale PNG files (color type #0) that have fewer than 8 bits. If paying attention, this is obvious since the transparent checkerboard pattern is not showing after loading the file.

Once loading was fixed, I also noticed that PMView did not optimize saving of grayscale files and always saved the files at 8 bits which caused the file to be almost double the size compared to the original. The design in PMView was right, but due to a coding bug the optimization was never done. Once the problem was fixed, the file saved as 493 bytes. (Original was 507 bytes).

So, in short, these issues only occur for some not-so-common PNG files. For the bug to appear, the PNG needs to be of color type #0 (grayscale), it needs to have a bitcount of 1, 2, or 4, and it needs to use a transparent color (TRNS). If the PNG file falls into this specific category, then the alpha channel will not be correctly loaded by PMView and transparency is not displayed correctly. If now saving the file, the incorrect alpha channel will result in the file being saved as a 8 bit grayscale file with 8 bit alpha channel (i.e. a 16-bit PNG) just like the OP noted.

These two bugs will be fixed in v3.73.