A few alpha channel issues...

Set Alpha Component
When Set Alpha component is used, it overwrites what alpha there might be prior to this action. While it is useful in some cases, I don't think its the right default behaviour. Mostly the images we load doesn't contain alpha channels, so we simply don't notice this.

I think the correct action would be to multiply the present alpha values with the new alpha. It would be nice if you could add a checkbox in the Set Alpha component ("Combine Alpha" or something). It is somewhat annoying that you have to set up a "get alpha -> blend (multiply current alpha with new alpha) -> set alpha" each time..

Blend Component
With some blendmodes the blend component is in particular strange regarding alpha handling. Take linear burn for example - if opacity is < 100 % the foreground is mixed with the background color in areas where the background alpha is zero. I have attached a filter graph that illustrates the problem. The blendmodes that shows problem in this setup are:
Color Burn, Linear Burn, Color Dodge, Linear Dodge, Vivid Light and Difference.

Default processing modes for various components
Some components, like blurs, will process the alpha channel, others don't, which I find somewhat confusing. I think that processing modules (and maybe also some of the adjustment modules) should have an option called "Process Alpha". For example the highpass component ignores the alpha, but the low pass ("blur") doesn't.

What I mean is that if you blur (low pass) an image with alpha channel, the alpha channel is blurred, but if you high pass, the alpha is not high passed.

And no, the blendmodes does not behave like in Photoshop, thats the reason why I'm bringing this to your attention.

Look at the filter graph example above.. if you set up a similar case in photoshop, you don't get a pink tint (from background areas where alpha is zero) all over the foreground. Here's a screenshot from photoshop with a similar setup (same blendmode, same foreground, same background, same opacity):

Could you post the filter you used in the example above?

Quote
Vladimir Golovin wrote: Could you post the filter you used in the example above?

attached.

AFAIK, the different blendmodes should not affect the alphablending/combining. I have working code if you are interested.


Blendmode_Alpha Problems.ffxml

Quote
Sphinxmorpher wrote: AFAIK, the different blendmodes should not affect the alphablending/combining

As in.. the different blendmodes doesn't have special alpha blending..only special color channel combining (well, maybe "dissolve".. but that mode is fundamentally different)

Quote
Vladimir Golovin wrote: I'm attaching a filter doing the same task as your example, using the same blending mode and without pink tint. To understand where the problem comes from, try to adjust the RGB values of the Outer Frame color in the Frame component -- but don't change the alpha, this is essential.

Vlad, you miss my point..

In your "No Pink Tint" example you are mixing a white tint into the result image instead! This doesn't happen in Photoshop. Under no circumstances can zero alpha areas of the background become visible after blending.. makes no sense. Its a good question what actually should happen with a given blendmode for these areas.

In photoshop it seems like they simply pass on the foreground unaffected by the blendmode for areas where background alpha is zero.

I.e. the specific blendmode combining happens prior to the actual blending, and the result of the blendmode operation is then mixed with the foreground given by the background alpha it seems (I don't know... it just seems like that). Then after this, the normal blending takes place.

I'd be happy to give you some pseudocode if you acknowledge the problem (I have a working example running in delphi now... had to check it out )

Cool

Don't hesitate to bug me if you want further details.

psp works the same way. nothing is passed along the alpha except the alpha, blend modes inclusive. it is treated EXACTLY as a separate channel that has to be manipulated as its own channel all the way through. there are never any assumptions of the rgb being mixed in or passed through.

but i wouldnt put an 'alpha combine' as a slider within set alpha. i'd make it its own component.

I see where Sphinx is coming from with the multiplied alpha, (Yeah, I know everyone else has moved on to blendmodes. )


If you think of a image with transparent as not having an alpha but being transparent, then set alpha should cut NEW holes in the image, not replace the old holes.

I'd be FINE with this being a separate component, but it's anoying in that situation to have to put a get alpha, blend (to blend the old alpha and the new one) and then another set alpha.

I want it to work like Sphinx wants it to work. Of course, once we have 'groups' I'll just make a 'whack new holes in this image' group.

And here is a lua script bug fix (I'm sure you'll get the idea..)

function get_sample(x, y)
-- fetch inputs
local O = get_sample_grayscale(x, y, OPACITY)
local Ra, Ga, Ba, Aa = get_sample_map(x, y, FOREGROUND)
local Rb, Gb, Bb, Ab = get_sample_map(x, y, BACKGROUND)

-- blendmode callback
Ro = Ra + (get_sample_grayscale(Ra, Rb, BLEND_MODE) - Ra) * Ab
Go = Ga + (get_sample_grayscale(Ga, Gb, BLEND_MODE) - Ga) * Ab
Bo = Ba + (get_sample_grayscale(Ba, Bb, BLEND_MODE) - Ba) * Ab

-- combine foreground alpha and master opacity
Aa = O * Aa

-- blend individual channels
local Ao = Aa + Ab * (1 - Aa)
if Ao > 0 then
local rAo = 1 / Ao

Rb = Rb * Ab
Gb = Gb * Ab
Bb = Bb * Ab

Ro = (Rb + (Ro - Rb) * Aa) * rAo
Go = (Gb + (Go - Gb) * Aa) * rAo
Bo = (Bb + (Bo - Bb) * Aa) * rAo

return Ro, Go, Bo, Ao
else
--undefined, returning something that makes slightly sense in FF context:
return Rb,Gb,Bb,Ab
end
end;

Blend bug is still present. Zero alpha = zero influence, hence the following blend modes are visibly faulty:

Color Burn
Linear Burn
Color Dodge
Linear Dodge
Vivid Light
Difference

Attached is a screenshot of Vivid light blending issues.

I do not believe that the fault is in the individual blend mode formulas, but rather that the problem is a more general alpha related issue (see my proposal above).

Yep, still here

Hello again, I wonder if this alpha blend mode problem/bug (or whatever) is still the same in FF 3.0.14 or in FF 4.0 beta 2.

Sorry that I have not tested it myself

5.006 still there.

8.004 bug still there (12 years+).

There is an easy fix (already posted) that brings FF up to Photoshop standards (tell me that you don't care and I'll stop reminding you).

+1 the need to keep the RGBA space intact is important in complex filters. There are workarounds but... but they all slow down the filter so... just saying.