PNG importing appears to be broken ( was Re: [squeak-dev] Who understand bilinear interpolation for reducing image size?)

Bert Freudenberg bert at freudenbergs.de
Thu Dec 11 12:15:20 UTC 2014


On 11.12.2014, at 01:06, tim Rowledge <tim at rowledge.org> wrote:
> 
> Looking into why png imports sometimes have issues with the alpha channel has lead me to the conclusion that something is broken in the area of PNGReadWriter>copyPixelsRGBA:
> 
> In the (very) old version in the original Scratch image this code carefully checks pixels with an alpha == 0 and makes them ‘properly’ transparent. The newer code in 4.5 does not, and so some images import with supposedly transparent pixels where the ARGB is 00FFFFFF. 
> 
> It looks to me as if we can correct this part of the problem by changing 
> 
> 	| i pixel tempForm tempBits ff |
> 	bitsPerChannel = 8 ifTrue: [
> 		ff := Form extent: width at 1 depth: 32 bits: thisScanline.
> 		cachedDecoderMap 
> 			ifNil:[cachedDecoderMap := self rgbaDecoderMapForDepth: depth].
> 		(BitBlt toForm: form)
> 			sourceForm: ff;
> 			destOrigin: 0 at y;
> 			combinationRule: Form over;
> 			colorMap: cachedDecoderMap;
> 			copyBits.
> 		^self.
> 	].
> 
> to use 'combinationRule: Form blend' so that the alpha values are considered.

Don't think so. "Form over" is a simple copy, it copies everything including alpha unmodified. Besides, "form" is empty so there really is no reason to blend. There could potentially be a problem in rgbaDecoderMapForDepth: but it looks okay to me.

> Obviously a blend is a bit more expensive than an over, but we’re doing a lot of processing to import a png so I doubt it will make a noticeable difference - and it’s likely faster than manually iterating across all the pixels to fix things up.

If you look at alphaBlend:with: you'll see "blend" does not do what you might think it would be doing?

> I’m a touch puzzled that I can’t find any code that seems to be doing the ‘black=16rFF000001' fudge we have to do, so maybe that is in need of fixing?

No, the code assumes that if you are actually caring about alpha you know what you're doing. It assumes you will use proper alpha blending to display stuff, in which case fudging isn't needed.

> Also I find myself a little suspicious of #copyPixelsGrayAlpha:, copyPixelsGrayAlpha:at:by:, copyPixelsRGBA:at:by:, copyPixelsGray:, copyPixelsGray:at:by: and I’ve probably missed some. Interestingly #copyPixelsRGB: seems to carefully do the right thing to add the alpha channel.

Of course, because unlike its RGBA sister it does not have a real alpha channel to work with. Instead it has to do chroma-keying as a poor-mans replacement.

> Does anyone actually feel they understand this stuff?

It's not rocket science. You just need to find the exact point where things go wrong.

- Bert -



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4142 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20141211/ffa06fdc/smime.bin


More information about the Squeak-dev mailing list