zero-alpha pixels sometimes not preserved with -lossless/-noalpha

boring said on 10/13/2018

It is my understanding that -noalpha and -lossless are supposed to preserve the RGB values of pixels that have zero alpha. However, this doesn't seem to happen for some files (maybe because they have 256 or fewer colors and are therefore converted to use a palette?).

original.png original-hiddenpixels.png

pingo.png pingo-hiddenpixels.png

original.png has zero-alpha pixels with both black and white RGB values, as shown in original-hiddenpixels.png. I ran "pingo -lossless original.png" to get pingo.png. The process changed all the zero-alpha pixels to have a RGB value of black, as shown in pingo-hiddenpixels.png The same thing happens when I use the options "-noalpha -s9".

cédric (dev) said on 10/13/2018

The process changed all the zero-alpha pixels to have a RGB value of black

no, it did not

pingo-hiddenpixels.png

whatever the way or the tool you used to get this representation, this is not what pingo did in this case

boring said on 10/13/2018

I downloaded the file named pingo.png from opening post, and it's not the same file I submitted (or tried to submit, if I messed it up). The pingo.png I meant to submit is this one: https://www.dropbox.com/s/j4u8xspww7yvw0h/pingo.png?dl=1

The testing method I use is:

  • Open the PNG in GIMP, change the Image mode from Indexed to RGB if needed
  • Right-click the Background layer, Add Layer Mask, Transfer layer's alpha channel
  • Right-click the Background layer and choose Disable Layer Mask

The pingo.png in the opening post has a black background after the process above, but the pingo.png I meant to submit has a black-and-white striped background.

If it helps differentiate, original.png is 32-bit RGBA, and pingo.png is supposed to be 8-bit palette RGBA.

boring said on 10/13/2018

Whoops, I reversed something. In the post above, I meant to say:

The pingo.png in the opening post has a black-and-white striped background after the process above, but the pingo.png I meant to submit has an all-black background.

boring said on 10/13/2018

Okay, now I see what you mean. The correct pingo.png does have the striped background, as reported by XnView MP using Show colour information. However, even with this method, running:

pingo -s9 -noalpha original.png

...does create an image with the problem I described: https://www.dropbox.com/s/kzq8pzpemw011n4/pingo-s9-noalpha.png?dl=1

pingo-s9-noalpha.png

Is this a case of me misunderstanding the -s9 flag, or is -noalpha supposed to preserve the invisible striped background?

cédric (dev) said on 10/13/2018

i see now. this comes from -s9. this should be fixed in 0.98.33, thanks for report

Masterfireheart said on 10/15/2018

Using 98.34, the problem persists for me.

Arguments used were

-lossless -sN -multiblocks=12 (IMAGE)

-s0 through -s3 didn't result in any reductions or processing. -s4 through -s9 all shared similar reductions (s4's 45.90% to s8's 46.02%), all of the reduced images having their zero-alpha data be changed.

https://imgur.com/a/muCqaLD

bt13Q7F.png source image (dark souls mod texture)

EZ8lOY0.png pingo -lossless -s9 -multiblocks=12

PyxBxby.png source image with alpha channel stripped

8InQ8Gk.png pingo -lossless -s9 -multiblocks=12 with alpha channel stripped

cédric (dev) said on 10/15/2018

i forgot something. this should be fixed in 0.98.35, thanks

comment this