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 at 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 <tim at rowledge.org>:

> 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; tim at rowledge.org; http://www.rowledge.org/tim
> Compatible: Gracefully accepts erroneous data from any source.
>  
Cheers,
Juan Vuletich
-------------- next part --------------
Skipped content of type multipart/related