zero-alpha pixels sometimes not preserved with -lossless/-noalpha
boring
said on 10/13/2018
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
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.
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
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".