How does AP 32-bit Preview work under the hood?

[cgidesign]

This is a difficult one, I hope I can explain my confusion.

In general it is about: "How does AP 32-bit Preview work under the hood?"

In more detail:

Starting point:

• I have a linear exr out of the iray render engine. The exr uses sRGB primaries.
• I have a the same image as png - tonemapped within the render software before saving as png.
• Monitor is calibrated to sRGB with gamma 2.2 (not gamma sRGB).

First two examples show what I understand. 32-bit Preview does what I expect it to do.

First example:

Affinity Photo Preferences 1:

• RGB Color Profile is sRGB for none 32 bit files
• RGB Color Profile is ROMM linear for 32 bit files
• Conversion is set to "do not convert". But I see that AP assigns ROMM anyway because it is the default color space for 32 bit images.

What I did in 32-bit Preview and why:

• Exposure to -8.4 because the EV setting in the render engine to create the png was around plus 8.4. So, the 32-bit Preview uses the same EV as the render output.
• Gamma to 2.2 because the exr is linear.
• Display Transform off. Examples with it ON come later.

Result:
Left is the normal png, right is the exr.

I get what I expected. The tonemapped png and the exr mapped via the 32-bit Preview look the same.

 

Second example:

All is the same except for Color Space Conversion in preferences.

Result is the same. Both images look the same. I expected that, because the ROMM color space was used in the first example as well.

 

Now comes the part I am unsure about:

Third example:
Same images but a change in the 32-bit Preview.
I use ICC Display Transform and set the gamma to 1 instead of 2.2. I understand the gamma change. I think ICC Display Transform already does the 2.2 gamma for me. So, I need to set my "custom 2.2 gamma" back to 1.

What I don't understand is the change in the colors. The exr is still in ROMM color space, it still has sRGB primaries. Why does ICC Display Transform change the colors? There is a color mapping going on, but I don't understand how and why that happens.

Regarding the color information in the exr. I know two things from the exr specification:

• an exr can contain tags describing its rgb primaries and whitepoint
• if those tags are missing, sRGB / REC.709 primaries and whitepoint should be assumed by the software opening the exr.

My exr has those tags. They describe the primaries and whitepoint as sRGB / REC.709 and the gamma as 2.4.

If the ICC Display Transform does some kind of color mapping should'nt it read those primaries and leave the colors where they are?

Forth example:
This time I changed the 32 bit working color space to sRGB linear. As a result the png and exr look the same again.

 

Conclusion: My point of confusion is the color change when ICC Display Transform is active and the 32 bit color space is not the same as the intended sRGB output space.

Can anybody help to solve this confusion?

(I think I read all articles about the subject and watched all videos; yes, the one about filmic blender as well, but none mentions the influence of the 32 bit working space.)

 

!!!!_TM-off_SR-off_REC.709_Beauty.exr

[James Ritson]

Hi @anim, I'll do my best to break down the reasoning for this approach, hope it makes sense.

I think this is the key part to explore:

Quote

The exr is still in ROMM color space, it still has sRGB primaries.

EXR files should usually contain scene linear encoded values—the colour space is arbitrary here and Photo doesn't touch the colour values. Those linear values are then view transformed based on your document profile (when using ICC Display Transform) or based on a mandated device and view transform combination (when using OpenColorIO transforms).

Quote

If the ICC Display Transform does some kind of color mapping should'nt it read those primaries and leave the colors where they are?

We don't do anything with this and always bring EXR files in as scene linear. OpenColorIO integration is designed to help with colour management—for example, you would set up the configuration that you wish to work with, then you can 'tag' your EXR files by appending a colour space to their filename. If I had an EXR whose primaries were in the ACEScg colour space, I would append "acescg" to the filename. Affinity Photo would then give me a toast to let me know that it had converted from 'acescg' to scene linear.

OCIO isn't really applicable in your case, so it leaves us with the mismatch you are seeing when using the traditional document-to-display profile colour management.

Sorry if I'm just being slow (it is the morning here 😉) but you've said here:

Quote

• I have a linear exr out of the iray render engine. The exr uses sRGB primaries.
• I have a the same image as png - tonemapped within the render software before saving as png.

Then later on have said:

On 2/24/2022 at 8:41 AM, anim said:

Result is the same. Both images look the same. I expected that, because the ROMM color space was used in the first example as well.

On 2/24/2022 at 8:41 AM, anim said:

What I don't understand is the change in the colors. The exr is still in ROMM color space, it still has sRGB primaries. Why does ICC Display Transform change the colors? There is a color mapping going on, but I don't understand how and why that happens.

I'm not sure where ROMM comes into the equation—why are you wanting to use ROMM as a default working colour space? It sounds like within iRay you were just working with scene linear values and previewing with a standard sRGB non-linear device transform. The EXR should not contain any particular colour space encoded values. I believe this should be evident when you switch to Unmanaged and non-destructively transform the gamma and exposure values. If the EXR contained values encoded in a wider colour space, the result should look very different to the tone mapped PNG in sRGB, but it doesn't (there are some slight differences, probably due to small variations in the transform curve etc for the gamma-encoded sRGB values in the PNG).

I'm checking with development whether it's just an oversight that we don't explicitly 'convert' the linear colour values to the working profile that is set in Preferences>Colour (and seemingly assign the profile instead). I'll hopefully be able to update you on this..

You likely know this already, but it's worth mentioning that the EXR document is imported and converted to a working format of 32-bit unbounded float—all compositing is done in linear space (as it should be), then those linear values are view-transformed based on the document colour profile, which defaults to sRGB. This will 'bound' the linear values during the transform, so you will only see colours inside the range of that profile. You can bring in an EXR document using the default sRGB profile, then convert to a wider profile such as ROMM if you wish. Internally, the linear values are stored as unbounded floats, so you don't lose any information by importing with an sRGB profile and can simply choose to display a wider range of values when converting to a wider profile.

 

Hope the above kind of helps—I think the takeaway is that you should just use the default sRGB working profile and convert to a wider profile if you want to use it for compositing. Just be aware, however, that if you choose to export back to EXR those linear values will now be encoded specifically for that linear profile, and other software may not recognise this. If you are simply exporting from Photo to a final gamma-encoded delivery format however, this will be fine.

For more advanced colour management, such as using Photo in a VFX pipeline, you should definitely look into using the OpenColorIO integration...

[cgidesign]

Thanks for chiming in and taking the time to explain.

You already mentioned "assign" vs. "convert".

Please let us know if there is a missmatch of those two in either 32-bit Display Transform or by opening the exr.

This is what I get if I "assign" the ROMM to the png. Now exr and png are similar again (ignore the brigtness - and ignore ROMM, I tried various other ones as well).

 

The part where I am still not sure after reading your information is the one about rgb primaries and the whitepoint:

From the exr specification:

The IlmImf library defines a “chromaticities” attribute, which specifies the CIE x,y coordinates for red, green and blue primaries, and white; that is, for the RGB triples (1, 0, 0), (0, 1, 0), (0, 0, 1), and (1, 1, 1). The x,y coordinates of all possible RGB triples can be derived from the chromaticities attribute. ... . The chromaticities attribute is optional, and many programs that write OpenEXR omit it. If a file doesn't have a chromaticities attribute, display software should assume that the file's primaries and the white point match Rec. ITU-R BT.709-3.

From  https://chrisbrejon.com/cg-cinematography/chapter-1-color-management/  (great read and a lot of information to digest).

"... I thought it would be worth mentioning that 16 or 32 bits files do not give you magically access to infinite color ranges. You still have to take into account the primaries (or gamut) you are working in."

If I check the primaries in my exrs I see that the various presets write corresponding tags. RGB primaries and whitepoint differ for sRGB, ACESCG, REC.2020. I interpred this in a way, that an exr, even though being scene linear, indirectly carries a color space information with it. The question is, what is a software doing with this information? If the exr says "I was made with REC.709 red" is AP taking this information into account somehow?

(The puzzle is slowly coming together for me but some pieces are still missing )

[cgidesign]

On 2/25/2022 at 11:28 AM, James Ritson said:

I'm checking with development whether it's just an oversight that we don't explicitly 'convert' the linear colour values to the working profile that is set in Preferences>Colour (and seemingly assign the profile instead). I'll hopefully be able to update you on this..

Any update on this ?

[James Ritson]

On 3/3/2022 at 5:09 PM, anim said:

Any update on this ?

Hi, yes, it's an intentional behaviour as we don't know explicitly which colour space to convert from—at the time of implementing EXR support, we were aware that the format could specify chromaticity values and white point but didn't have any documents that contained them. It was always designed to be used in conjunction with OCIO for explicit colour management.

Essentially, Photo doesn't touch the pixel values and just sets the document profile to whatever is specified in Preferences>Colour, which by default is sRGB. This only bounds the pixel values at the final presentation stage, so internally everything is being composited with linear unbounded floats. Doing a specific profile conversion via Document>Convert Format / ICC Profile, however, will change the pixel values (but remain unbounded).

Ideally, you would have an OCIO configuration set up within Photo, then append the colour space of your EXR to the end of its file name. Since Photo always works internally in scene linear, it would then convert from that colour space to scene linear. Again, though, this is mainly intended to be used with the OCIO device and view transforms to ensure accurate colour rendering.

tldr; Photo doesn't touch pixel values unless there's a valid OCIO configuration and the EXR filename contains a colour space name (e.g. "filename acescg.exr")—if this is the case, the pixel values will be converted from that colour space to scene linear. Changing the 32-bit colour profile in Preferences>Colour is essentially the same as assigning a colour profile.

Hope that helps!

[cgidesign]

Thanks James for coming back.

After further testing and investigation I am already fine with OCIO.

But there is one confusion left regarding your explanation:

On 3/21/2022 at 11:56 AM, James Ritson said:

it would then convert from that colour space to scene linear

As far as I learned, an exr saved as e.g. aces-cg is already scene linear - or better any file with unbounded linear data is considered being scene linear.

So, I assume, when for example Preferences>Colour is set to aces-cg and the exr has aces-cg in its filename, AP does not do any conversion. Is that right?