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. 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.

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?

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.

Does anyone actually feel they understand this stuff?

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Old programmers never die; they just branch to a new address.