[Bf-committers] pixelblending.c issues

Ton Roosendaal bf-committers@blender.org
Fri, 28 Mar 2003 12:02:50 +0100


Hi Jeroen,

In 2000 I've transferred the render part of Blender to Njin-zu Chen, he  
rewrote quite a bit of my code. The function you mention is from him,  
maybe if he reads this mail he can elaborate it some.

But I have the same doubts as you do, especially the the line

> 	cf[0] = target[0]/target[3];

where 'cf' is float, and 'target' is a char. It looks like a compiler  
will convert the right hand of the equation to float first, but it  
wouldn't be something I would count on for all compilers!

The weird results of the equation are correct though. The colors are  
supposed to overflow a lot. In Blender there are two alpha modes, this  
one is called the 'Key' alpha. In some situations (video keying for  
example) the alpha layer is used to multiply the colors in the image  
while it is being keyed... it's also sometimes called 'post-mul alpha'.  
It makes sense especially for anti-aliasing to a background. The pixel  
colors remain 'pure' and the key image (alpha) defines how much it has  
to blend.
A 'pre-mul' alpha would give less nice results here, typically visible  
as a dark shade in the anti-aliasing.

You can visualize it best, when you imagine a red text with alpha,  
which has to be keyed over a complete white image. 'Key alpha' will  
result in nice pink antialising colors. 'Premul alpha' will make the  
antialising dark...

This key mode is very rare in applications, we used it a lot ourselves  
in order to get the best results with third-party keying software or  
hardware.

-Ton-


On Wednesday, Mar 26, 2003, at 08:48 Europe/Amsterdam,  
<j.lamain@chello.nl> wrote:

> Hello,
>
> I'm new on this list and like to contribute to blender.
>
> Ok, so, here I go.
>
> I found the following function in pixelblend.c which is wrong:
>
> (sorry for the screwed layout)
>
> /*
>   One things about key-alpha is that simply dividing by the alpha will
>   sometimes cause 'overflows' in that the pixel colours will be shot
>   way over full colour. This should be caught, and subsequently, the
>   operation will end up modifying the alpha as well.
>
>   Actually, when the starting colour is premul, it shouldn't overflow
>   ever. Strange thing is that colours keep overflowing...
>
> */
> void applyKeyAlphaCharCol(char* target) {
>
> if ((!(target[3] == 0))
> 	|| (target[3] == 255)) {
> 	/* else: nothing to do */
> 	/* check whether div-ing is enough */
> 	float cf[4];
> 	cf[0] = target[0]/target[3];
> 	cf[1] = target[1]/target[3];
> 	cf[2] = target[2]/target[3];
> 	if ((cf[0] <= 1.0) && (cf[1] <= 1.0) && (cf[2] <= 1.0)) {
> 		/* all colours remain properly scaled? */
> 		/* scale to alpha */
> 		cf[0] = (float) target[0] * (255.0/ (float)target[3]);
> 		cf[1] = (float) target[1] * (255.0/ (float)target[3]);
> 		cf[2] = (float) target[2] * (255.0/ (float)target[3]);
> 		/* Clipping is important. */
> 		target[0] = (cf[0] > 255.0 ? 255 : (char) cf[0]);
> 		target[1] = (cf[1] > 255.0 ? 255 : (char) cf[1]);
> 		target[2] = (cf[2] > 255.0 ? 255 : (char) cf[2]);
> 			
> 	} else {
> 		/* shouldn't happen! we were premul, remember? */
> /* should go to error handler: 			printf("Non-premul colour  
> detected\n"); */
> 	}
> }
>
> } /* end of void applyKeyAlphaCharCol(char* target) */
>
>
>
> This function/comments frighten me ;-)
>
> Can someone (Ton?) explain to me what this function is supposed to do ?
> I can read te code, but I seems someone programmed around a  
> overflow/underflow bug. Is it just supposed to scale to alpha ?
>
>
> The cf[x] = target[x]/ target[3] lines have a gigantic loss of  
> precision, because the function will be calculated in chars and AFTER  
> that (in the assignment) converted to float.
> Besides the whole deviding is not necessary if you rewrite the if like:
>
> alpha = target[3];
> if ((cf[0] <= alpha) && (cf[1] <= alpha) && (cf[2] <= alpha))
> {
> }
>
>
> So please can someone tell me what the code should do ? (not what the  
> code does now, I can see that). I send a patch if ready.
>
> Thanks and happy coding,
>
> Jeroen (#RoccoD)
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers@blender.org
> http://www.blender.org/mailman/listinfo/bf-committers
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton@blender.org