PNGReadWriter bug?

Yet again my mighty Scratch related Nemesis is biting at my ankles. I’m more than a little puzzled how a single, simple file can cause so much trouble, but there y’go. Life.

Hi Tim,

I checked with the debugger and I'm pretty sure the pixel value for those pixels coded in the PNG file is 16r00FFFFFF. This is really transparent. Value for opacity (alpha) is zero, making values for R, G and B irrelevant.

In a Squeak 4.5 all in one, "latest update: #13680" (the one I have around), evaluating:

(Form fromFileNamed: 'C:\Users\Juan\Dropbox\CuisStuff\Cuis-Smalltalk-Dev\bananas1.png')
displayOn: Display
  at: 0@0
  clippingBox: Display boundingBox
  rule: Form blend
  fillColor: nil

does what you would expect, leaving the background around the bananas unmodified.

I think your problem lies elsewhere. Someone is handling the pixels 16r00FFFFFF incorrectly. For example, in the script above, using  rule 'Form paint' instead of blend paints those pixels white. What are you trying to do with the bananas and how does it fail?

Cheers,
Juan Vuletich

Quoting tim Rowledge <[hidden email]>:

Yet again my mighty Scratch related Nemesis is biting at my ankles. I’m more than a little puzzled how a single, simple file can cause so much trouble, but there y’go. Life.

 

In an old image - the one Scratch is originally built in - loading the attached ‘banana.png' produces a 32bpp image where the transparent outer area is made of pixels with a value of 0. Autocorrect wanted to make the ‘pixies’ which would be so much more attractive, but it is what it is, so ‘pixels’ will have to do. The bits are processed in PNGReadWrite>processNonInterlaced and are written to the actual Form via copyPixelsRGBA:

 

In a 4.5 image, the same file (yes, made sure of that) is processed via the PNGReadWriter code as above and results in outer area (supposedly transparent) pixels with value 16rFFFFFF. Which aint’ really transparent.

 

So far as I can tell the likely change that is causing the difference is in PNGReadWriter>copyPixelsRGBA: which dates back to 2004, so clearly not a lot of files manage to trigger any obvious issue. It looks like the chief difference is that the old code used 'Form paint’ combination rule instead of the new code’s Form over rule - but simply changing that makes no difference to the result, so that shows how well I’m doing with this. So maybe it is the rgbaDecoderMapForDepth: that is at fault? 

 

If anyone actually has a decent understanding of the whole PNG related stuff, do tell. It’s driving me ...

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Compatible: Gracefully accepts erroneous data from any source.
 

Hi Juan,

On 12-06-2014, at 6:54 PM, J. Vuletich (mail lists) <[hidden email]> wrote:
> I checked with the debugger and I'm pretty sure the pixel value for those pixels coded in the PNG file is 16r00FFFFFF. This is really transparent. Value for opacity (alpha) is zero, making values for R, G and B irrelevant.

Yup, that’s what I see too. I think the difference is that the old code for #copyPixelsRGBA: carefully checks the alpha bits and sets the entire pixel to 0 when alpha = 0. The new code doesn’t, and I guess would be relying upon the blend combinationRule being used ‘properly’.

[snip]

> I think your problem lies elsewhere. Someone is handling the pixels 16r00FFFFFF incorrectly. For example, in the script above, using  rule 'Form paint' instead of blend paints those pixels white. What are you trying to do with the bananas and how does it fail?

I think you’re right but it’s probably going to be ‘fun’ to fix. The Scratch code is handling forms with transparency pretty well in almost all cases (except this dratted banana bunch!) using ‘paint’. I’ll have to see if the ARM specific bitblt improvements allow me to use ‘blend’ without killing display performance. Hmm, maybe if I ‘blend’ it into another Form and ‘paint’ that?


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"Oh bother" said Pooh, as he reached for the reset button

Hi Tim,

Quoting tim Rowledge <[hidden email]>:

> ...
>
> I think you’re right but it’s probably going to be ‘fun’ to fix. The  
> Scratch code is handling forms with transparency pretty well in  
> almost all cases (except this dratted banana bunch!) using ‘paint’.  
> I’ll have to see if the ARM specific bitblt improvements allow me to  
> use ‘blend’ without killing display performance. Hmm, maybe if I  
> ‘blend’ it into another Form and ‘paint’ that?

That will most likely leave R, G and B alone, not zeroing them. A  
rather crude hack you might use is calling #preMultiplyAlpha. This  
will fix this case. But it will ruin any Form with alpha values other  
than 0 or 255, i.e. actual translucency.

Something else that might work is blitting the Form on a new one, with  
an appropriate ColorMap.

>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> "Oh bother" said Pooh, as he reached for the reset button

Cheers,
Juan Vuletich