Alpha Mode bug

Hi, I found a serious bug in Fusion.
The bug is that when we select Change Alpha Mode - Premultiplied alpha behaves as if we had selected Straight.

Below is a video with an example. The right window Buffer A RGB image - Buffer B alpha. There is also a colorinspector tag in the window - on the right you can see the RGB and alpha values.

At the beginning the image is with the mask off. Then I select, Premuliplied, the alpha values appear but the RGB values are unchanged. Then I select Straight and at this point the RGB values change. They are multiplied by the alpha value. So Straight behaves like Premuliplied and vice versa.

Link to the file if anyone would like to check. Render from Arnold, Maya, with motion blur.
https://drive.google.com/file/d/1KiuGNI ... sp=sharing

Is it possible that someone from BM will confirm or comment on this. I don't understand how to report an error. The forum is apparently not a good place for this.

Still this approval of posts. I write a post, the post disappears. I don't know what is happening to it. Who approves it, why does it reject. Zero information.

[Peter Chamberlain]

Are u on 18.1.2? Windows 10?

Hi,
I am using 18.1.1 build 7, macOS.

Definitely this is a bug. Because when I attach alpha using ChannelBooleans, it is ok. It is not the renderer's fault. Of course you can assume that Straight behaves like Premuliplied, and work that way. But it gives a slight headache, especially to beginners who are trying to understand the difference between Straight and Premuliplied. How is it possible that no one has detected this. Strange.

Can you confirm that this error also occurs with you?

Normal image data state in comp is premultiplied, so if alpha interpretation is set to premultiplied, RGB doesn't change, this is correct. Because you tell that premult has already been done on RGB values. If you set alpha interpretation to straight you say that premult is not done, so it is applied and RGB values change, because RGB values are multiplied with alpha value.

You are probably expecting the alpha setting to be a method to be applied (premultiplied == apply premult), but it is actually description of the data state (premultiplied == do not apply premult, it is already done). Current behavior is correct.

If I understand you correctly you claim that multiplication is done at the file level. When importing a render from alpha. Fusion expects it to be premultiplied. And for this reason it does not do anything with the RGB values if the file is marked premultiplied. Whereas if I choose straight, Fusion do RGB multiplication by alpha. Because this is what is used in composition.

I disagree with that. After all, multiplication by alpha does not happen at the file generation level. For example, rendering. During rendering, the RBG and alpha image is saved. The use of alpha and the selection of the method happens only in the composition program.
But maybe I'm wrong.

Attached is an example. RGB image with alpha turned off, below alpha. If it were as you say, alpha would change the RGB value by multiplication. Multiplication by alpha would already be in the file itself. You can see that this is not the case. You can see that the RGB values are not in any correlation with aplha. In my opinion, this indicates that the multiplication by aplha occurs in the compositing program.
Attached is an example
https://drive.google.com/file/d/1sPCh-A ... share_link

It depends on file format whether the convention is to store premulted or straight data. Png is usually straight, exr-s are usually premulted.

If you are claiming that all files always have straight data, you are obviously wrong. And again, alpha mode selector is not a selector of method, it is a descriptor of state and comp software is free to do whatever it wants with that state interpretation. Usual behavior is to premult the data if state is set as straight.

I assume that the image I have. Rendering Maya, Arnold, Exr format is Premultiplied. Could you take a look at the example to which, below link

https://drive.google.com/file/d/1sPCh-A ... share_link

This is what I don't understand. Why doesn't the RGB value change despite changing the alpha value?
Alpha 1, RGB value 0.9
Alpha 0.5 RGB value 0.8 - shouldn't the RGB be 0.45? (The whole object has the same color)

Can you share your actual exr file? This screenshot doesn't tell much. It is possible that the values you are probing are shown post-colormanagement, where they have gamma correction applied.

Below is the link to the file. Color correction in DaVinci disabled. In Fusion only media in node plus colorpicker.
The file is tiff, rec709, Arnold Renderer.
https://drive.google.com/file/d/1KiuGNI ... sp=sharing

Is it possible that this file, render is in Straight mode. This is the only explanation. Nowhere have I found information on what mode Arnold's transparency renders in.

Your file looks normal to me. It has premultiplied RGB data and RGB is gamma-corrected for either sRGB or gamma 2.4, can't tell from the image itself exactly. This is why it shows higher than expected values in areas where alpha is for example 0.5. Pure white should have premulted value of 0.5 where alpha is 0.5 but applying correction for gamma 2.4 will raise it to somewhere around ~0.75 range.

I don't understand this behavior. The file I am using is Premuliplied. After using merge it looks like this. It looks like Straight.

Screenshot 2023-01-25 at 20.45.57.png (683.03 KiB) Viewed 1506 times

And when in node merge uses the Subtracive function it looks like Premuliplied. I don't understand, according to the Fusion documentation. The Subtracive option in node merge is used if the input file is in Straight format.

Screenshot 2023-01-25 at 20.46.23.png (684.31 KiB) Viewed 1506 times

From Fusion Doc.
If you are compositing with a non-premultiplied alpha, you can fix these bright edges by changing the Merge to perform a Subtractive merge in the Inspector.

I'm also wondering take into account what you said. How to use the Straight file.

If in fusion I mark the file as Straight (Change Alpha Mode) it will change it to Premuliplied for me.
I need to mark it Premuliplied, then fusion will not make changes and I will have Straight format file.

This is not very intuitive. Without the explanation you gave it is hard to understand.

I messed with your file a bit more and something a bit funky is going on indeed which I didn't notice before. There seems to be a discrepancy between RGB and alpha that can't be straightened with any kind of transform I tried.

What you can try is to render a linear exr from your render engine and try that. Your tiff might suffer from precision issues as it is 8bit and gamma corrected.

I will render EXR, it will be ACEScg, because this is now the standard in Maya and Arnold. I would like to finally understand this. That's why I started this thread. At first I thought there was something wrong with Fusion. Still despite your explanation of how it works to mark a file as imported in Change Alpha Mode, something is wrong.
So maybe it's a format issue. Until now I thought that tif skipping bit depth in terms of alpha brings the same information as EXR. I hope to clarify this in this thread.

I still have a question for you. My file is Premuliplied. If in fusion I set - Change Alpha Mode - ignore. Then I have a file without alpha. How to understand the RGB value in this case. Are they Premuliplied or Straight.

Second question.
My render is Straight file. If in fusion I mark the file as Straight (Change Alpha Mode) it will change it to Premuliplied for me.
I need to mark it Premuliplied, then fusion will not make changes and I will have Straight format file. Am I thinking right?

I will render EXR, it will be ACEScg, because this is now the standard in Maya and Arnold.

Is your current tif also ACEScg in this case?

I still have a question for you. My file is Premuliplied. If in fusion I set - Change Alpha Mode - ignore. Then I have a file without alpha. How to understand the RGB value in this case. Are they Premuliplied or Straight.

This depends on your actual file. If RGB data is stored as premulted it is premulted. If it is stored as straight it is straight. Ignore means "I don't care and don't read alpha" which translates to RGB values read as-is (color management still applies) and alpha values being ignored.

Consider the over blend operation in merge, where per-channel expression for merge is: C = A * alphaA + B * (1 - alphaA)
It is basically linear interpolation between background B and foreground A elements where alpha is the interpolation weight. Premultiplication operation is the A * alphaA part. Since alphaA is associated with A, it can be baked into stored data, meaning one less multiplication operation in each merge. When A * alphaA is performed before data is stored in a file, it is baked into data and to read that data again properly, you must instruct the software how to interpret the data - is it straight or premultiplied. Then software can perform necessary conversions to its internal representation (usually permultiplied).

Second question.
My render is Straight file. If in fusion I mark the file as Straight (Change Alpha Mode) it will change it to Premuliplied for me.
I need to mark it Premuliplied, then fusion will not make changes and I will have Straight format file. Am I thinking right?

If your file is straight and you mark it straight, Fusion will do the premult for you, yes.

If your file is straight and you mark it premultiplied, Fusion will not do anything, data will be kept straight and you have to handle the premultiplication yourself as most comp ops expect data to be premulted, otherwise you get brightened semitransparent areas.

If your file is premultiplied and you mark it premultiplied, Fusion will not do anything and data will stay premultiplied (not straight, as that would need unpremult operation to be added).

If your file is premultiplied and you mark it straight, it will get double-premultiplication from wrong interpretation, which will show darkened semitransparent areas (RGB values are multiplied with alpha twice, once before file storage and second time when Fusion reads the data in).

The file we are talking about is not ACEScg. According to the Autodesk documentation it is - ACES 1.0 SDR-video. I have read that it is equivalent to sRGB.

"(Default) Tone-maps using the ACES Output Transform for standard dynamic range video (previously known as the RRT and ODT). Neutral colors (equal RGB values) are mapped to the chromaticity of a D65 white point.
The Display menu specifies which type of monitor (i.e., primaries and gamma) the RGB values are encoded for."

But it seems to me that the color collection does not matter in our case. If we consider its effect on Alpha.

It seems to me that this file is in straight format. If this is true then everything is correct. Everything you wrote about the interpretation of alpha by Fusion. But you wrote that this file is premultiplied. Maybe you can check again?

I'll do a render test, make a TIF and EXR, two versions each of sRGB and ACESsg. Maybe there is an error in this file. It was rendered on renderfarm.

Ok, that seems to explain it. It has ACES tonemapping baked in, so it needs to be read properly using inverted sRGB ODT from ACES CM config, in an ACES managed project.

File is definitely premulted. It is easy to test: read the data as-is, without any conversions whatsoever (I do these manipulations in Nuke which I'm more familiar with) and probe the RGB values. If on semitransparent transition areas RGB values fall off to zero it is premulted. In straight file RGB should keep its intensity until zero alpha region.

Thank you for your time. Yes, I finally understand it and know where the mistake was. Where my erroneous thinking was coming from.
Below is an example with the new rendered AND my summary.
I made the new renders to EXR format. On the left side
ACESsg, on the right ACES 1.0 SDR-video.

Screenshot 2023-01-28 at 14.47.29.jpg (181.29 KiB) Viewed 1039 times

In the case of ASEScg, the file behaves as I expected when merging with the background. In the case of ACES 1.0 SDR-video. there is this white border. That's why I thought the file was Straight. Now I know that the border is because of the ACES 1.0 SDR-video conversion.

If the file with ACES 1.0 SDR-video conversion uses node OCIOcolorspace with these settings.

Screenshot 2023-01-28 at 14.57.00.png (42.79 KiB) Viewed 1039 times

This file behaves like Premuliplied. And there is no problem when merging with the background. Now I know that the ACES 1.0 SDR-video file is obviously Premuliplied, and the white border is caused by the conversion to ACES 1.0 SDR.
I learned a lot in this thread. Thank you.

Great to hear you got it solved!