(we -as in several thousand people - have no power and trees down across power/phone lines so things are bit iffy)

On 09-12-2014, at 1:59 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:


>> 
> 
> Looking at the code it should preserve pixel value 16r00000000, which is the only one recognized as transparent by BitBlt.
> 

Yes, but it also completely strips away the alpha channel, which causes problems elsewhere.

> It's the job if the image importer to make sure that if alpha is zero, the whole pixel value must be zero.

Well, yes. We need to fix that too.

> 
>>> This purposely does only output fully opaque and fully transparent pixels, which likely is a requirement further down the pipeline. Makes rendering faster, too: true alpha-blending is expensive.
>> 
>> The code gives the impression of having been written before the 32bpp ARGB pixel format was put into use.
> 
> Nope. The ARGB pixel format has been around forever. Dan took Smalltalk-80's 1-bit BitBlt and extended it to work in 1-2-4-8-16-32 bits per pixel before the first Squeak release.

If you say so; I don’t recall the alpha stuff being around till later but then I don’t recall a lot of things from last century.

> 
>> That could explain why it doesn’t set the alpha bits for the output.
> 
> No. What *has* changed is that people are much more willing to waste *thirtytwo* bits for *each* tiny pixel in stored image files nowadays. Think about it. Eight bits for transparency where surely one would suffice, right? I'm just half kidding. This code is from an era where "transparent image" meant "GIF". Which didn't even have 1 bit of transparency per pixel, but I think 1/32nd of a bit, if my math is correct (8 bits per pixel with 1 out of 256 values meaning "transparent").
> 
> There simply was no way to import an image with 256 levels of transparency, so the code did not waste cycles dealing with them. 32-bit PNGs got popular much later.

So we need to deal with them now.

> 
> The most common way to get a transparent sprite in Scratch is actually importing a photo (directly from camera, or via JPG, no transparency in any case) and use the eraser tool in the image editor to erase pixels. Again, no smooth alpha there.
> 
>> I could of course just do a bitblt with the fixAlpha rule but it’s faster to fix it inside the prim if possible.
> 
> Agreed.
> 
>> The question becomes one of the final effect that is wanted - doing ‘the right thing’ by mixing the alpha values is simple and works ok for the examples I have right now but yes, they’re not using partial transparency and are finally displayed with Form paint instead of blend. And that is an issue too, since people are quite likely to try importing images with partial transparency from assorted paint programs and clipart, only to find it looks really strange.
> 
> Yep. Kids these days ...
> 
>> The old code was fudging transparency and effectively rounding it up to opaque if the weighted average was > ~half.  I could do similar easily enough I think.
>> 
>> But I’m not at all knowledgeable about image processing stuff, which is why I ask.
> 
> Well, I would preserve the output (only 0 and 255 for alpha) but extend the inputs: instead of comparing input pixel value to 0 to determine if it's transparent, compare the alpha. I think if the pixel value is a sqInt then comparing "pix < 0" would work, although doing an unsigned compare with 16r7F000000 would be less obfuscated.

I guess something like that is probably best but I do dislike fudges of this sort.


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Any sufficiently advanced bug is indistinguishable from a feature.