Transparency issues in gradients with alpha

[exeldro]

Transparency issues in gradients with alpha

[exeldro]

I think we got a fix with this build:
https://github.com/exeldro/obs-shaderfilter/actions/runs/7629693620

[exeldro]

Is this with version 2.2.1? I tried to replicate it, but no luck so far.
Do you have a link to the image used? Or maybe more extensive steps to reproduce the issue?

[COOLIGUAY]

I'm sorry. Yes, v2.2.1 and OBS Studio v30.0.2.

With v2.1.3 works fine.

The HS logo here:
https://images.app.goo.gl/PWAojB7VGFTEkXNH9

Or with the Composite Blur logo from the resources page https://obsproject.com/forum/resources/composite-blur.1780/
(downloaded with save image as)

[exeldro]

I am able to replicate it now and will investigate further.

[FiniteSingularity]

This is due to the Pre-Multiplied alpha issue that was fixed before. It looks like OBS does not pre-multiply alpha on image sources, for the first filter in the filter chain (all filters after do have pre-multiplied alpha).

Here is how to test this with a few cases (and some workaround until we figure out how to fix it):

Case 1:

1. Create an image source that has alpha transparency.
2. Add a user defined shader. (You'll see the alpha halo bug)
3. Add #define USE_PM_ALPHA 1 at the top of the shader text, to turn off the pre-multiplied alpha correction
4. The halo bug goes away.
   

Case 2:

1. Create an image source that has alpha transparency.
2. Add a user defined shader. (You'll see the alpha halo bug)
3. Add a color correction filter (but dont change any of the settings)
4. Drag the color correction filter before the User-defined shader.
5. The halo bug goes away.
   

Case 3:

1. Create an image source that has alpha transparency.
2. Add a user defined shader to the scene that contains the image source
3. No halo bug.
   

This is a little tricky to fix, as there may be other sources that don't pre-multiply alpha to the original source, but it also depends on what order the filter is in the stack. @exeldro do you know if there is any way to determine if the source coming into the filter has pre-multiplied alpha?

@COOLIGUAY: An interim workaround for you is to either add #define USE_PM_ALPHA 1 to the top of any shader file/text you are using on your image sources, or put a dummy filter like a non-changing Color Correction filter before you apply the user defined shader.

Quick edit to say- if you use the #define USE_PM_ALPHA 1, make sure your user defined shader is the first filter in the chain for that source. If it is not the first, omit #define USE_PM_ALPHA 1.

[COOLIGUAY]

Thank you @exeldro and @FiniteSingularity !

I have tried your #define USE_PM_ALPHA 1 solution and it definitely eliminates the halo😀

However, the alpha colors looks a little different from the original.

I have used this png for the test:
https://www.cleanpng.com/png-light-halo-aperture-cool-the-aperture-325637/preview.html

Applied the shine shader adding #define USE_PM_ALPHA 1, renamed to shineALPHA.shader.

Then, a color correction filter at the top (also works if the filter is off).
The alpha colors looks like it was overexposed compared with the original image (filters off).

To mitigate this color issue i add another shader filter with the #define USE_PM_ALPHA 1 code.

It's not perfect but it's more accurate.
Comparative:

Could be the fix introduced in v2.2.0 an option in the settings?
At least until a definitive solution is found.

[FiniteSingularity]

Unfortunately, it is not an easy toggle off/on. I'll dig into this a bit more, but doing #define USE_PM_ALPHA 1 should be rendering in pretty much the same way as before. I don't mean to "blame upstream" but for some reason images are rendered/passed through by OBS completely different from any other source. It could be that the image isn't SRGB- so you might try just #define USE_PM_ALPHA 1 with turning off SRGB in the blending mode, and see if that does the trick?

[FiniteSingularity]

Ok, so I've done some digging, and there is very strange behavior that goes on with image sources, and pre-multiplied alpha.

Case 1

Any source (that I've checked so far- video, media source, etc..) other than an Image Source. Color data is pre-multiplied by the source's alpha values, no matter where in the filter chain User Defined Shader is.

Case 2

Image source, and user defined shader is the first source in the filter chain. Color data is NOT pre-multiplied by the source's alpha.

Case 3

Image source, and user defined shader is not the first source in the filter chain. Color data IS pre-multiplied by the source's alpha. And the weird part is- this is true even if the prior filters are all toggled off.

I've been able to replicate this behavior both with this plugin, as well as with my Advanced Mask plugin.

[COOLIGUAY]

Thank you so much!

Solves the halo issue when only add an empty shader filter, without loading any shader.

The color issues still remains.

I tested the new build with the png from the last test:
https://www.cleanpng.com/png-light-halo-aperture-cool-the-aperture-325637/preview.html

If you add a shine shader, the alpha colors looks washed.

With #define USE_PM_ALPHA 1 added to the shine shader, the colors looks saturated (named shineALPHA.shader).

Adding another shader filter only with #define USE_PM_ALPHA 1 the png is displayed again like the v.2.1.3 of the plugin.

Tested with the HS logo and the bloom shader with and without #define USE_PM_ALPHA 1