Re: Question with regards to componentAlpha

In your message of 14 September 2002 you write:

> 
> Around 13 o'clock on Sep 14, Thomas Roell wrote:
> 
> > I you suggest using explicite formulas like I used in my example would
> > clarify things quite a bit.
> 
> I'll do that; I'm currently cleaning up the Render spec as I add 
> projective image transformations.

Would you mind send this one over our way early, as we implemented
the whole extension independantly, and hence might have more
clarifications.

> > I'm not to much arguing the usefullness of the operation, although it
> > seems to be overcomplicated and does not mach very well current
> > hardware.
> 
> The complexity is as required by the desired operation; we want 
> to treat each sub-pixel separately with it's own alpha value all the
> way through the basic computation.  If image compositing did planemasks,
> we'd do this in four passes, one for each component of the signal (well, 
> on TrueColor hardware at least) with separate mask pictures to modulate 
> the source image as appropriate.

Why doesn't render support planemasks (or channel-masks) anyway ?
OpenGL/DX7 do, and hence HW does.
  
> > It is just very frustrating for somebody to actually implement the
> > extension using the spec as a reference and then running into convoluted
> > cases like this where IMHO the spec contradicts itself.
> 
> That's why I always like to see additional implementations for each spec.  
> The X11/NeWS server performed some of the same tasks for the core 
> protocol, discovering inconsistencies in the specification and errors in 
> the sample implementation.
> 
> The Render spec has seen very little detailed analysis like this; there 
> are many areas which could use clarification.  The important thing is that 
> the intent is to make the spec the standard, and not the XFree86 
> implementation, but inconsistencies between the XFree86 implementation and 
> the spec may show either bugs in the code, or a mistatement in the spec,
> or both.  It's an incremental process, and one which so far has been 
> working better than most of the specs developed by the X consortium.

Sorry to say, but my experiance with render is exactly the opposite
way around. The wording in the spec is very often extremely unclear,
and only by looking at the fbcomposite.c/fbpict.c code it becomes
clear what could have been meant.

But back to the HW issue for a moment. Still waiting on which kind of
HW might support this type of blending operation with componentAlpha.
Here now a quick analysis of the problem that we have found with
regards to implementability. Let's take the xor operation and
componentAlpha. The formula for all color channels should look like
this:

	dest.b = (src.b * mask.b) * (1 - dest.a) + dest.b * (1 - src.a * mask.b)
	dest.g = (src.g * mask.g) * (1 - dest.a) + dest.g * (1 - src.a * mask.g)
	dest.r = (src.r * mask.r) * (1 - dest.a) + dest.r * (1 - src.a * mask.r)
	dest.a = (src.a * mask.a) * (1 - dest.a) + dest.a * (1 - src.a * mask.a)

With a normal 3D pipeline blender you cannot do this, because you use
3 different components in the term (src.x * mask.x), dest.x, (src.a * mask.x).
You cannot split up the operation into two passes likes this:

	dest.b = dest.b * (1 - src.a * mask.b)
	dest.g = dest.g * (1 - src.a * mask.g)
	dest.r = dest.r * (1 - src.a * mask.r)
	dest.a = dest.a * (1 - src.a * mask.a)

	dest.b = dest.b + (src.b * mask.b) * (1 - dest.a);
	dest.g = dest.g + (src.g * mask.g) * (1 - dest.a);
	dest.r = dest.r + (src.r * mask.r) * (1 - dest.a);
	dest.a = dest.a + (src.a * mask.a) * (1 - dest.a);

The issue is that one the second pass, your destination alpha will be
wrong. So you have to apply complex transformations to avoid this problem:

	dest.b = dest.b * (1 - src.a * mask.b)
	dest.g = dest.g * (1 - src.a * mask.g)
	dest.r = dest.r * (1 - src.a * mask.r)
	dest.a = dest.a

	dest.b = (src.b * mask.b) * (1 - dest.a) + dest.b;
	dest.g = (src.g * mask.g) * (1 - dest.a) + dest.g;
	dest.r = (src.r * mask.r) * (1 - dest.a) + dest.r;
	dest.a = (src.a * mask.a) * (1 - dest.a) + dest.a * (1 - src.a * mask.a)

Still, unless your HW allows you to have separate blend functions for
color and alpha channels, you cannot do this in two passes (unless
dest.a is know to be either 1.0 or 0.0). 

So esstentially you either have to use 4 passes with planemasking, you
you cannot do this in HW.If you have to use 4 passes anyway, the
question becomes then, why not to let the application explicitely use
4 passes instead.

- Thomas
-- 
	     Thomas Roell   /\	       Das Reh sprint hoch,
	     Xi Graphics   /  \/\ _     das Reh springt weit,
	 [email protected]	  /   /	 \ \	 was soll es tun,
			 / Oelch! \ \     es hat ja Zeit.