[squeak-dev] BitBlt alpha blend rules broken?

tim Rowledge tim at rowledge.org
Thu May 23 01:12:53 UTC 2013


The guy that is hacking BitBlt for ARM for me is having all sorts of fun and making good progress. I even have a VM working with an early version and am currently in the process of testing the results.

He's started on some of the more….curious… corners and right now is of the opinion that alphaBlend is getting its maths wrong. I'll just quote him rather than paraphrasing;

> "The next combinationRule I've tackled is alphaBlend. This is clearly only
> applicable to 32bpp source and destination images. Despite what the
> comments in the original source say, this *does* calculate the alpha
> component of the output, rather than zero it. In fact, it's using the
> formula:
> 
> da' =    sa + (1-sa).da
> dr' = sa.sr + (1-sa).dr
> dg' = sa.sg + (1-sa).dg
> db' = sa.sb + (1-sa).db
> 
> where sa = source alpha, etc.
> 
> This is actually incorrect maths for an alpha blend operation with non-
> premultiplied colours, as appears to be the intent. For the RGB colour
> components, the contribution from the first term is da' times too large,
> and the contribution from the second term is da'/da times too large. In
> other words, you only get the correct results if the destination image
> was fully opaque (which implies that the result is likewise).
> 
> Nevertheless, I suspect we'd run into problems if we attempted to fix
> this, so I'll endeavour to replicate the behaviour, bugs and all.
> 
> Next issue was the fact that for some crazy reason, they'd decided to
> renormalise the colour components after the multiplication by doing a
> divide by 255, rounding to +infinity. This is neither the "best" approach
> (arguably round to nearest with rounding half-values to odd or even would
> be the best), nor is it particularly efficient to implement - divisions
> rarely are. The current code also has a completely pointless bitwise AND
> with 0xFF following the division, since the inputs to the division cannot
> exceed 0xFF*0xFF to begin with."

We're talking about BitBltSimulation>alphaBlend:with: in this case. It's very old code. 

I'm not into colour blending maths etc and I can't see why we're using 255 instead of 256 (which would allow use of some ARM pixel engine instructions) nor quite what the intent is here. Thoughts, anyone?

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: IAM: Increase Amperage Above Maximum




More information about the Squeak-dev mailing list