ECT can change opaque pixels to transparent when optimising PNG files to RGB + tRNS based alpha

[NeRdTheNed]

Tested on MacOS with ECT 0.9.3.
Here's an image that demonstrates this bug (originally from here):

It's an indexed PNG with a tRNS chunk, which has two different palette entries for black. The first entry is set to be transparent with the tRNS chunk, and the other entry remains fully opaque. When ECT optimises it, it converts it to truecolor (RGB) with a tRNS chunk. The tRNS chunk now sets all instances of the color black to fully transparent, which results in some previously opaque pixels becoming transparent:

I'd suggest that when --strict is passed, PNG files are not converted to RGB + tRNS based alpha if it would result in this issue occurring. When --strict is not passed, lossy transparency optimisations could be used to change the color of the transparent pixels to avoid this issue.

[fhanau]

Sorry for the late response – I have been able to reproduce the issue with v0.9.3 and it's certainly something that should not be happening. With the latest commit ECT seems to only produce valid images – the recent changes to lodepng may have fixed the issue.
Can you check if the issue still occurs with the latest code? If needed, I can provide an updated binary.

[krishty]

With the latest commit ECT seems to only produce valid images – the recent changes to lodepng may have fixed the issue. Can you check if the issue still occurs with the latest code? If needed, I can provide an updated binary.

I’d like to see 0.9.4 when OP confirms the issue is fixed 🙂

[NeRdTheNed]

Sorry for the late response – I have been able to reproduce the issue with v0.9.3 and it's certainly something that should not be happening. With the latest commit ECT seems to only produce valid images – the recent changes to lodepng may have fixed the issue. Can you check if the issue still occurs with the latest code? If needed, I can provide an updated binary.

@fhanau The example image no longer has this issue using when using a build of ECT from the latest commit, and I think the bug has been fixed, thank you!

I'd note that the new behaviour produces correct images, but doesn't apply this optimisation for images which would previously cause this issue. When "./ect -9" is run on the original example image, it now isn't able to optimise the image any further. Here's a version of the example image, with the transparent palette entry edited to be a different color than any other color in the palette:

This is visually identical to the original example image, as the transparent color is completely transparent, so changing the transparent color does not change how the image looks. Editing the palette entry of the transparent color allows ECT to perform the same optimisations as it previously did, without changing the color of the opaque pixels. When "./ect -9" is run on the edited image, it is able to optimise the image, saving 4 bytes:

The image is converted to RGB with a tRNS chunk, presumably saving some space from not needing the overhead of a palette chunk. The optimised image is visually identical to the original image (only the alpha channel is different). ECT could perform this optimisation automatically by changing the transparent color to be different from any other palette entry, which could result in a small file size reduction for images which previously caused this bug. This probably would only apply to a very small amount of images, as the input image would need to:

• be a indexed PNG with a tRNS chunk
• have only one transparent color / be able to be reduced to only having one transparent color
• have the transparent color be fully transparent
• have the transparent color be the same as any other palette entry
• and benefit from being converted to an RGB PNG with a tRNS chunk

If it's possible, I'd be very happy if you could add a command line option to force ECT to process an image, as well as an option to force using a specific PNG encoding type (i.e. RGB with a tRNS chunk), as it would help with testing this fix, but that's probably beyond the scope of this issue.
Sorry for the long response!

[fhanau]

With the latest commit ECT seems to only produce valid images – the recent changes to lodepng may have fixed the issue. Can you check if the issue still occurs with the latest code? If needed, I can provide an updated binary.

I’d like to see 0.9.4 when OP confirms the issue is fixed 🙂

Yes, I plan to make another release soon – might still add a few other things beforehand.

[fhanau]

@NeRdTheNed Thank you for confirming that the issue is fixed.
As for improving the color optimization for this image – ECT supports the 'key' feature (i.e. using the tRNS chunk to mark one color as transparent) through lodepng, so it already does something like this. I'll try to figure out why this image is not being optimized that way (perhaps because some fully transparent pixels have a color that is also found on non-transparent pixels and clearing colors behind fully transparent pixels is handled elsewhere than color reductions), maybe I can get it to work.

Forcing a set color type/forcing recompression would be a nice feature to have, but would be more work, so probably not happening anytime soon.

[fhanau]

@NeRdTheNed As of ec2f6e6, alpha cleaning support has been overhauled and ECT can convert the original image to key (i.e. RGB PNG with tRNS chunk). Many images that support having key are better compressed using palette, so in my test set this is only a small improvement but I'm glad it's now supported.

I will also make a new release in the coming days.