Add Alpha Channel + FFGLPanSpinZoom Bypass = Bug [Bug Report Submitted]

[Woland]

Hello all,

I was getting some strange behavior from the FFGLPanSpinZoom actor, so I deleted actors until the Scene was down to bare bones. There's no media involved, I used Shapes actors instead to rule that out.

The setup is two Shapes actors (with two different colors) hooked up to the two inputs on an Add Alpha Channel, which in turn is attached to the input of an FFGLPanSpinZoom actor, which finally passes video to a Projector actor. 

Note: every actor, (excluding the one Shapes actor set to a different color), uses its default values (i.e. the values any given actor will have when it is placed in a Scene for the first time).

The bug: When you toggle the "bypass" input on the FFGLPanSpinZoom actor, it changes the intensity of the image. If the Add Alpha Channel actor is bypassed or removed, the change in intensity no longer occurs, so I believe it's something to do with the interaction between the two actors. I can't think of a possible reason that toggling the bypass on the FFGLPanSpinZoom actor should affect the intensity, which leads me to believe that this is a bug. Please find the patch attached, and also a video of the behavior:

https://www.dropbox.com/s/0n5v...

FFGLPanSpinZoom Bug.izz

Specs and Isadora Version

Best wishes,

Woland

Edit: Just to be thorough, I tested each actor in the "Video Effects" tab in place of the FFGLPanSpinZoom actor, and found six other GPU-based actors and two CPU-based actors that behave the same way.

GPU Actor List:
Chroma Key
Effect Mixer
FFGLPanSpinZoom
Matte
Matte++
Text Draw
Threshold*

*When the Threshold actor is set to
white = bright
black = dark
causes a dip in intensity when the bypass is toggled.

CPU Actor List:
Dots
MultiVid*

*Intensity on MultiVid changes if set to anything above 1 column and 1 row and the bypass is toggled.
If set to 1-1, the MultiVid bypass will not affect the intensity.

Second Isadora Patch: FFGLPanSpinZoom Bug v2.izz

 

[Michel]

@Woland

This is a good find that seems to address a bug over quite a few actors. The problem does not seem to be the interaction between the add alpha channel and the culprits. It is more that these actors interpret the alpha value different. If you change the opacity of the fill color in the shape actor and connect it directly to the FFGLPanSpinZoom you have the same problem. Did you file a proper bug report?

Best Michel

[Woland]

@Michel I will file one now. I tend to hold off until someone confirms that I'm not just being silly so as to avoid making unnecessary tickets.

[DusX]

If you add a 'Premultiplier' actor before the FFGLPanSpinZoom actor the issue is resolved.

I think Isadora tries to us unpremultiplied video as much as possible, but some actors force premultiplying.

It does seem that bypass should leave this untouched, but that might be problematic since the premultiply state of the video stream would then change and how you deal with it down stream would also need to change based on the bypass state.

Perhaps, rather we need a clear way of indicating the premultiply state of a video stream.

[mark]

Dear @Woland and All,

Yes, this is an inconsistency that needs to be fixed. The Isadora actors are designed to use either premultiplied or non-premultiplied alpha – whether or not the texture is premultiplied is known by Isadora internally. I went with the possibility of using either mode in Isadora because, if you're doing keying, you really want the texture to be non-premultiplied alpha.

In my debugging version of Isadora, the video thumbnail actually indicates if Isadora the texture to be premultiplied or not. I guess it would be important to add this feature to the release version so you all can tell the difference as well.

But when it comes to FreeFrameGL, the specification is unclear; it doesn't say which whether or not FFGL plugins should use premultiplied or non-premultiplied alpha. I wrote the "powers that be" of the FreeFrame list, and one person [who works for Resolume] said it should all be premultiplied, but another person said non-premultiplied. Sigh....

I went with the assumption that the FFGL plugins should expect non-premultiplied alpha. So, in this case, the non-premultiplied alpha should be converted to premultiplied before the FFGL plugin receives it. So, for now, you'll have to use the Premultiply actor.

Best Wishes,
Mark

[Woland]

@mark

In the meantime, would it make any sense to add a small note in the end of the Actor Descriptions for the affected Isadora Actors that says to use a Premultiply actor if one is dealing with alpha channels, or maybe just a list of the actors that display this behavior in the description of the Premultiply actor, so there's something that users can reference? 

Or if messing with Actor Descriptions is too time-consuming, perhaps people could just use this "reminder" Macro I made for myself.

Best Wishes,

Woland (Lucas Wilson-Spiro)

[mark]

Dear @Woland,

Well, in the meantime, I just need to fix these issues. ;-) so that you won't  need notes like this; the actors should do what you expect.

I've fixed the Matte & Matte++ actors. I'll look at Effect Mixer and Text Draw next. But I don't understand the issue with the Threshold actor. Can you explain that? Or post a patch that exhibits the behavior you mention?

Best Wishes,
Mark

[mark]

@Woland 

The Threshold actor issue you mention is not a bug. The Threshold actor manipulates the video, making everything brighter than the 'threshold' input one color and everything below another color. Given that there the alpha in the 'bright color' is 100%, and the alpha in the source image is not, it is correct that turning on the 'bypass' input should produce a noticeable change. (To make what I'm saying really clear, change the 'bright color' to red.)

The other GPU actors had issues which I'm addressing. 

The MultiVid and Dots actors needs to be converted to GPU; when I do that, I'll solve the problem so that the GPU versions work properly.

Best Wishes,
Mark

[Woland]

@mark

Great, thanks! I haven't really used the Threshold actor before, but it looked like it was displaying the same behavior so I included it in my list.

Cheers,

Woland