OCIO vs Maya Built-In ACES Configuration: Color Picker Rendering and Display Spaces question

[miladybridges (Milady)]

Hey Everyone,

This is my first post, so I hope all the images upload correctly. I’ve decided to convert to an ACES workflow this year and like most people here, I have questions! I’ve been reading forums, how-to articles, Chris Brejon’s awesome explanation on ACES, and just when I thought I understood what I was doing, my confidence has been shattered yet again.

I’m using VRay and the OCIO ACES 1.2 configuration. I’ve been struggling with inputting sRGB values into Maya’s color picker. When Color Management is enabled, is this applying the RRT + ODT to the sRGB values which ends up tone mapping pure white values from 1.0 to 0.811? Does this mean I should be inputting my sRGB values w/ Color Management disabled to avoid getting values above 1? In Chris’s article about color picking, he states these values are display referred, which leads me to my next question.

How do I correctly input RGB values to match color swatches or other materials that require specific RGB values (like metals). The swatch below was created in Photoshop with the following RGB values: 95, 148, 208.

When comparing renders of the swatch texture file (IDT set to ‘Utility - sRGB - Texture’) with Maya’s color chooser set to the same RGB values, the blues do not match. In the image below, the inner geometry has the texture file while the outer geometry had the RGB values inputted into the diffuse color w/ Color Management enabled.

Diffuse Element:

To match the swatch texture file, I connected the file to a surface shader and color picked the blue value. The RGB values that matched the swatch turned out to be 68, 125, 179.

How did Maya get to these values? If these are the display referred values, should they not match the RGB values from photoshop?

After doing some experimenting, I found that when I do not use the OCIO ACES 1.2 config file, but instead use ACES built into Maya, the RGB values in the material’s color chooser (when set to Display Space) now match the values from Photoshop. After adjusting the IDT for my texture file and HDRI map to follow Maya’s built in color space rules, the render looks exactly the same. VRay’s display correction is still using the OCIO file:

w7kDSeXWPscmNJxMyAOGLQIt0s0KrpRiWQ5NnycA-EHmiIe_TuxVxvloVD4t_9r)

My next question is, what is the difference between using OCIO ACES 1.2 config file and Maya’s built in ACES workflow? I read somewhere that Maya’s built-in ACES workflow doesn’t apply the RRT, but I feel like that’s inaccurate. I did some overexposed lighting tests and didn’t see any differences in the high values between OCIO Aces and Maya ACES.

When referencing sites like refractive index or Understanding metalness | Chaos, where you need to put in specific RGB values, should I assume these are display space values and do I need to use Maya’s built in ACES workflow in order to accurately represent these values?

Thanks ahead of time for any explanations! This forum has been a wealth of information.

Cheers,

Milady

[ChrisBrejon (Christophe Brejon)]

Hello and welcome to ACESCentral !

Lots of tricky questions on my favorite topic ; the color_picking role. It took me a while to figure this one out and I’m not even sure I understood all of it (lame excuses I know).

I see six questions in your post :

@miladybridges

When Color Management is enabled, is this applying the RRT + ODT to the sRGB values which ends up tone mapping pure white values from 1.0 to 0.811?

I am not quite sure to understand correctly the question. So let me give you a simple example. When you enable color management and load an ACES OCIO config in Maya, the input colors are driven by the color_picking role. Simple example :

• I put (1, 1, 1) in a spot light.
• This RGB triplet is interpreted as “Output-sRGB” (the default value for the color_picking role).
• It gets converted to ACEScg to a value of (18.912, 18.912, 18.912).
• This value is used for the rendering.

Why is that ? It is because by specifying (1, 1, 1) as an “Output-sRGB” value, I need (18.912, 18.912, 18.912) in ACEScg to reach (1, 1, 1) after the Output Transform (which includes some tone-mapping).

Makes sense ?

@miladybridges

Does this mean I should be inputting my sRGB values w/ Color Management disabled to avoid getting values above 1?

I would not recommend to disable Color Management to choose your input RGB values. I’d rather edit the OCIO Config file to set the color_picking role to something that suits your needs better. Probably lin_srgb or acescg ?

@miladybridges

How do I correctly input RGB values to match color swatches or other materials that require specific RGB values

Another tricky question ! In your example the swatch and the color chooser do not match for a simple reason :

• You have loaded the texture as Utility - sRGB - Texture. The swatch will be interpreted as such and will be tone-mapped.
• The swatch has been set as Output - sRGB which does the conversion previously described.

If you wanted to match, you could do the following :

• Load the swatch as Output-sRGB for the IDT. Just for this test since we don’t recommend to load textures this way.

OR

• Set the color_picking role to srgb_texture in the OCIO Config. this will be a good test to do.

@miladybridges

How did Maya get to these values? If these are the display referred values, should they not match the RGB values from photoshop?

I hope my explanations from above kind answer this question. I have actually never tried to use “Photoshop values” into Maya.

@miladybridges

My next question is, what is the difference between using OCIO ACES 1.2 config file and Maya’s built in ACES workflow?

There should be no difference except for over-exposed saturated values, because of the LUT discretization. The main difference here comes from your setup : you are using a sRGB Gamma as a View Transform and not the RRT.

@miladybridges

should I assume these are display space values and do I need to use Maya’s built in ACES workflow in order to accurately represent these values?

I don’t know how about the exact article you are referring to. I haven’t used 8-bit values for a while (0->255). I have tried (in a previous post) to come with my own chart for albedo values using ACEScg values (for clarity). But I never did such a chart for metals. Would be worth having a look !

Let me try the Maya / Photoshop workaround first !

Hope this helps a bit,
Chris

[ChrisBrejon (Christophe Brejon)]

Just did the test and it is a perfect match… Phew !!!

• On the left, color set in Photoshop.
• On the right, color set in Maya/Arnold as Emission and rendered on a sphere.

A few observations :

• Over-focusing on the color_picking role will make you loose your sanity.
• We were discussing the color_picking role yesterday in an OCIO meeting. It is a recurrent “issue” that is brought up.
• Questions about the color_picking role are super tricky.
• This “roundtrip” using the Output - sRGB as an input will not work for all values/colours. I have never seen it for myself but it has mentioned several times on ACESCentral that certain saturated yellows were giving issues.
• Everytime someone asks me about the color_picking role, I start to have cold sweat and headaches.
• I feel like I have done nothing but rendered colored spheres for the past year…

Best,

Chris

[miladybridges (Milady)]

Hey Chris,

Thank you for the explanation! I take comfort in knowing I’m not the only one who feels like my brain has been put in a blender when trying to wrap my head around this color picker stuff.

Just to make sure I truly understand, with the OCIO config setup and ‘Color Management’ enabled in the color picker, the RGB values I’m seeing are display-referred sRGB values. When Color Management is disabled, they are scene-linear values within ACEScg colorspace. If I input RGB values with ‘Color Management’ enabled, ACES will convert these values to ACEScg using an inverse of the ODT (which includes the RRT) that’s been specified in the color management settings. Does that sound accurate?

I was creating some transmissive shaders in Arnold recently and ran into some unexpected results that seemed to break the material when working with output-sRGB values. The conversion process sometimes results in values above 1 which can cause incorrect calculations in PBR shaders which is why I was asking about working w/ Color Management turned off. I’ll need to investigate that more.

Based on your explanation, I did some quick tests with mixed results. I was able to get matching colors between the texture file and color chooser in Arnold based on your explanation (setting the texture’s IDT to Output-sRGB to match the color chooser), but not in VRay. So I’m going to read over what you wrote again, do some more tests in both VRay and Arnold and report back.

As a side note, based on the VRay gold preset, I noticed that the RGB values from the preset match the gold RGB values listed in the article I linked to above when the ‘Color Management’ option in the color picker is disabled. I suppose that means they are linear values. I also found your post with the albedo value charts. I’ll read that in more detail when I have time.

Cheers,
Milady

[ChrisBrejon (Christophe Brejon)]

Hello again,

you’re welcome.

@miladybridges

with the OCIO config setup and ‘Color Management’ enabled in the color picker, the RGB values I’m seeing are display-referred sRGB values.

yes, display (post-tonemapping) values.

@miladybridges

When Color Management is disabled, they are scene-linear values within ACEScg colorspace.

also yes. if you want to see the real values used, check the channel editor (only works for lights unfortunately).

@miladybridges

If I input RGB values with ‘Color Management’ enabled, ACES will convert these values to ACEScg using an inverse of the ODT (which includes the RRT) that’s been specified in the color management settings. Does that sound accurate?

Also yes. It is using an inverse of the Output Transform (RRT+ODT). So if you put (1,1,1) the actual value used in rendering is (18.9,18.9,18.9).

@miladybridges

The conversion process sometimes results in values above 1 which can cause incorrect calculations in PBR shaders which is why I was asking about working w/ Color Management turned off.

If you’re disturbed by this behavior, you could try to change the color_picking role to ‘acescg’ by editing manually the config. That’s what I do personally.

@miladybridges

I was able to get matching colors between the texture file and color chooser in Arnold based on your explanation (setting the texture’s IDT to Output-sRGB to match the color chooser), but not in VRay.

I have never used V-Ray so I can’t help you here unfortunately. This might be a V-ray thing ?

Hope it helps,
Chris

[ChrisBrejon (Christophe Brejon)]

Here are two screenshots to show what’s going on :

Color Management turned on :

Color Management turned off :

It looks like it is “safe” to toggle it “on” and “off”. So maybe ignore my previous comment about avoiding to turn it “off”.

Chris

[Derek]

Personally, for Maya I prefer not having the color_picking role set in the OCIO config at all. This then uses Maya’s two drop-down choices of “rendering space” and “display space.” If you choose “display space” you will get the ODT for your config (in this case Output -sRGB) which will tone map white from 1 to 16. You therefore want to pick “rendering space” which will give you the rendering space (in this case ACEScg) so 1=1.

[doug_walker]

I’m glad Christophe was able to answer your questions. People should also be aware that Maya comes with Documentation. Most of the topics in this thread are also covered there:

http://help.autodesk.com/view/MAYAUL/2022/ENU/?guid=GUID-EBC11F85-9CAB-4D33-ABF4-836AD47D5C76

Doug Walker
Autodesk