MultiMatteElement Should Let US USe the Alpha (A) Channel

[Joelaff]

Would be nice to be able to put a FOURTH channel into the A channel of MultiMatteElement render elements. Seems silly that we can only set the RGB channels-- since we render to EXR and always get an A channel regardless (and really don't one all channels in one EXR monolithic files).

[vladimir_krastev]

Hi, thanks for posting. Do you mean something like this?

[Joelaff]

Right now it dumps the alpha from the standard RGBA (beauty) into the A channel. So your alpha contains all the objects. It would be way cool if we could add another selection (either an object selections, or a MatID, etc.-- just like how it works for the R channel for instance) and stick that in the alpha channel. Basically, I'd like to use the Alpha channel as a fourth channel to write whatever data I desire to, rather than it alpha being written with the alpha form the beauty pass.

For instance, in my current scene I have about five different MultimatteElement REs to get 15 channels (RGB 3 * 5 elements = 15 channels). All the REs now have the same alpha, because we have no control over it. So the alpha is wasted (it's in the beauty too, so why do we need it in the REs at all?). If we could pick what we wanted to go into the alpha then we would be able to use just four REs, and get 16 independent channels.

I know we could do monolithic EXRs with a bunch of channels, but that does not work well for our workflow, and becomes a pain if you want to re-render just one RE for instance.

Thanks.

[^Lele^]

There is no alpha in the multimatte RE, it's always been a three-channel one.


On storage, an empty RE channel will cost about 0, so one can add as many RE as one wishes, and in most pipelines the operation is automated (i am sure there are free scripts around that do just that as well).
Making the change to go to four, even as an option, after 20 years, would have repercussions on so many pipelines, and issues with compatibility with other engines (Arnold, RS, etc.) in post, not to mention potential issues with less EXR-centered apps (imagine PS finding multiple alphas in the single image.).

Rerendering a mask needn't be done with lights, or massive AA, so it's quite quick to set up and render, generally regardless of scene contents.

[Joelaff]

Hmm. Every app I open the MultimatteElement RE in loads the alpha channel, and it matches the alpha in the RGBA beauty pass. So the alpha is indeed being used. It is just useless. So it is wasting space with an extra copy of the alpha channel for every Multimatte element. Maybe I have some settings wrong someplace, but I *always* get the alpha form the RGBA in the Multimatte Elements EXRs saved. Always have. I assume it is that my EXRs are set to save RGBA so I get the Alpha in the Beauty. I don't think there is a separate RGB vs/ RGBA setting for the two outputs, is there? I know using the VFB saving we could use RGB (no A) EXRs and save the Alpha separately. Not sure this can be done if you use the default Max frame buffer.

An empty channel takes up only a few bytes, yes. But a useless copy of the beauty alpha takes up space. But the issue is not space-- drives are cheap. The issue is making use of the A channel so you can get four channels into a standard RGBA file, rather than having to use multiple files, or apps that support multi-channel EXRs. Many viewers do not allow this. So people QAing shots might not be able to see multi-channel EXRs. (I do see that Chaos Player allows you to split a multi-channel file into layers, which is very cool). Monolithic EXRs also make it difficult to re-render one channel/matte without having confusion about which version to use (the version in the multi-channel file, or the standalone version the compositor may not see).

I 'm not sure how changing this would affect anyone's pipeline. It would continue to export the beauty alpha channel into the A channel (as described above-- or not use the alpha in the way you are using it) unless the user set there to be some other data in the A channel in the EXR. It would not change how old scenes work. It would just let you write an arbitrary multimatte into the A channel. So any existing scripts or comps should work just fine, as they would be ignoring the useless A already, or if they were indeed using it then the user would simply not change what goes into the A channel.

Since Multimatte Element is a VRay thing there are no compatibility issues with other renderers. If you are using another renderer you have a pipeline for how that renderer handles mattes.

I am suggesting only ONE alpha in the A channel be used as an extra matte channel- not multiple alpha. PS is probably a poor example, since it does support multiple alpha channels

It would simply be a convenient and easy way to get one more channel per multimatte output, and shouldn't break anything for anyone.

Obviously, it is lower priority, since there are ways to do everything now, but it just seems silly that every MultiMatteElement we save contains a useless copy of the Alpha, and we can't set that to some other data.

[dans]

The whole point of the MultiMatte element was to conserve memory. If you store a single grayscale Matte in an RGB image, you have the same data in R,G and B - so are wasting memory. So Multimatte elements can store up to 3 separate mattes instead. The V-Ray MultiMatte elements in the V-Ray Framebuffer do not have/store a 4th Alpha channel in memory, so no memory is wasted. Most VRay channels are just RGB and when saving the channel as an image file Alpha information is simply taken from the global V-ray Alpha channel instead. VRayExtraTexture elements do have a 4th Alpha channel for example. So it all depends on the way you write your image files.
My PSD exporter (psd-manager) for example can split the MultiMatte elements into PSD layers (each RGB channels ends up as mask or transparency of a new layer) or PSD channels. That is how I learned about the internals. So I guess you actually may want to save your mattes without Alpha instead to avoid duplicating data. It can still be helpful to have the Alpha available depending on how your other apps/pipeline interpret footage (pre-multiliplication). That is also why it is often not a good idea to repurpose an alpha channel for other things.
What I mentioned applies to the V-Ray Framebuffer the 3ds max Framebuffer itself however does store an additional Alpha channel in memory for each render element AFAIK. So you do have a point, it is just that that Alpha channel is simply treated differently then RGB in 3ds max and other apps that makes it not a good idea to repurpose it. For example Photoshop would throw away data stored in areas of a PNG that are completely black/transparent on import. Saving to a file format in 3ds max that supports conversion from pre-multiplied to straight alpha also would cause issues.

[Joelaff]

Interesting and good points.

We use EXR and the workflow is pretty customized. So the repurposed Alpha would not be a problem, but rather a helpful addition.

But you make a good point about how Photoshop now handles things like alphas (it used to simply load them in as an alpha, rather than as "transparency"... then there was a setting to do it one way or the other...but only for PNG or something-- not sure if that is still there or not.)

Would there be a way to save the beauty with RGBA and the matte passes with just RGB? Perhaps the built in VFB does this now, we typically render with the Max frame buffer just because it is better supported by deadline (automatic strict pathing, and tile/jigsaw support, etc.) Perhaps this Max frame buffer is the reason our mattes contain A, while Lele's do not.

Sounds like this whole idea is too cumbersome. So forget it It works reasonably well as is. It was just that a recent project required about 10 different multimatte FILES (30 mattes) that had to be setup manually. By utilizing the A channel as well we would have saved files. (but don't want monolithic EXRs as explained above)