Re: [Paracomp-devel] Standard Alpha Blending problems

[Shree K. <shr...@hp...>]

Hi James,

James S Perrin wrote:
>>>
>> Your conclusions about "incorrect Alphas" and "incorrect image" are spot
>> on. Alpha values you get out of the operation from Paracomp will not be
>> correct.
>>
>> If you use ParaComp to do (I0+I1+I2+I3) in one swoop, then you'll get
>> the right image, but wrong alpha values again.
> 
> We're not using the final resultant alpha. But to me it seems necessary
> to preserve it throughout the compositing procedure since only two
> inputs can be composited in a single OVER operation.
> 

Now I'm confused. Can you elaborate on what you mean by "only two inputs 
can be composited in a single OVER operation" ?

>> The right thing to do seems to be to fix Paracomp. Will changing
>> ParaComp's blending function from the current (faulty) equation
>>
>>   glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)
>>
>> to an equivalent of
>>
>>   glBlendFuncSeparateEXT(
>>     GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA,
>>     GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
>>
>> work for you ?
>>
>> Currently, I don't see anybody using the broken alpha value. So I see it
>> safe to fix this. Fixing this won't break existing apps either...
> 
> Looking a the code in compositecpu.cpp we're confused again as it
> actaully looks like more like glBlend(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
> as the src values are not mutliplied by SRC_ALPHA?

Oop! Sorry. I missed mentioning that glBlendFunc(GL_SRC_ALPHA, 
GL_ONE_MINUS_SRC_ALPHA) is the intended operator.

Since we expect premultiplied alpha values, we effectively implement
glBlendFuncSeparate(GL_ONE, GL_ONE_MINUS_SRC_ALPHA).

(So does that mean the final alpha would be correct if the initial 
alphas are correct ? Apologies for creating more confusion. I'm a bit 
confused myself at this point. So let me check this again and get back 
to you.)

(Note to self: some documentation is in order here!)

> 
>>> I forgot to say we also see that translucent parts of the front image
>>> that are composited against "nothing" in the rear image are being
>>> attenuated.
>> That's interesting.  Could be a bug. I'll look at this. Images, if you
>> can send them, will be useful.
> 
> This has been sorted. Blending was enabled in old code that was trying
> to support coloured backgrounds, similar to what Stefan has talked
> about,  when the frameresult was passed to gldrawpixels.
> 
Ok. Good to know that.

> Anyway the RGBA images are attached. I haven't tried the gimp thing yet.
> 

Looks like the Gimp approach may not work...

Regards
-- Shree

> Regards
> James
> 
> --
> ------------------------------------------------------------------------
>    James S. Perrin
>    Visualization
> 
>    Research Computing Services
>    The University of Manchester
>    Kilburn Building, Oxford Road
>    Manchester, M13 9PL
> 
>    t: +44 (0) 161 275 6945
>    e: jam...@ma...
>    w: www.manchester.ac.uk/researchcomputing
> ------------------------------------------------------------------------
>   "The test of intellect is the refusal to belabour the obvious"
>   - Alfred Bester
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
>