Andrew

Example 2 To aid debugging, this test case is perhaps more obvious? See attached 'toolbar.png'. The image is RGB with a tRNS chunk defining RGB(0,0,1) as transparent. Critically, this colour doesn't exist in the image, so there should be no transparency. When viewing, the image has a bright green background. Details are also confirmed with TweakPNG. Image is optimized on Win32 with Batch command line optipng.exe -v -f0 -force "%~1" -out "%~1.out.png", producing: OptiPNG version 0.7.8 Copyright (C)...

I started to debug this before, but lost my notes... I observe the issue with non-paletted images (RGB/A), that have a tRNS chunk that specifies an RGB value not present in an image. May affect grayscale images too (G/A) ? When the image is optimised as indexed, the transparency is wrongly applied to the palette index. I think the issue is in the use of libpng png_get_tRNS…? “…For non-paletted images, the function retrieves the single color value which is treated as fully transparent. If the transparency...

I started to debug this before, but lost my notes... I observe the issue with non-paletted images (RGB/A), that have a tRNS chunk that specifies an RGB value not present in an image. When the image is optimised as indexed, the transparency is wrongly applied to the palette index. I think the issue is in the use of libpng png_get_tRNS…? “…For non-paletted images, the function retrieves the single color value which is treated as fully transparent. If the transparency information is valid, i.e. PNG_INFO_tRNS...

I have highlighted the defective pixel (that becomes full transparent), to red for clarity - attached.

Image corruption with invalid transparency

This issue can be Closed. It was fixed upstream (commit).

Tested with OptiPNG.exe v0.7.7 (27-Dec-2017), Win32. Confirmed. This 8-bit indexed image is more optimally stored as 2-bit indexed. This reduction should be evaluated, in addition to grayscale 8 bit. The extra run should not be necessary.

Avoid rewriting identical bKGD chunk