CG render sanity check - MtoA Nuke

Discussions - Using ACES VFX
#1

Hello!

I’ve been looking around to find answers, but so far I’m not finding anything just right to clear this up for me.

After (thinking) I wrapped my head around bringing live footage to ACEScg space, I dove into the CG part.
I setup Maya’s Color Managment Preferences and made a Cornell box with some spheres and got to rendering.
At first I thought the renders were fine, until I brought them in Nuke and my ACES confidence cam crumbling down.

ACESTestMismatch
ACESTestMismatch2518×1340 586 KB

#3 is a screenshot from the render view, which I save to an EXR. As far is I know, this is without any transforms on it.
#2 is that EXR read in as ‘ACEScg’. This matches with the render view. HOWEVER they look over saturated to me, with the green going towards blue and seemingly losing stuff in the reflections and such.
#1 is this same EXR, but read in as ‘Utility - Linear - sRGB’. Which, to me, looks more correct.

So I have got some questions about this.

  1. I’ve gotten confused about wether I should read these EXRs as ‘ACEScg’ or as ‘Utility - Linear - sRGB’
    Putting it on ‘ACEScg’ or on ‘Utility - raw’ gives the same result.
    Which makes me think the EXRs are in ACEScg space, so no change happens.
    But then why does it look so over-saturated and does #1 look correct (to me at least)?

  2. If the result from #1 is correct, how come I’m not getting that in the RenderView in Maya?

#2

Hello again @Eckhart

I have written about some very similar tests on my website and hopefully I can help a bit.

I think I would need to know what Color Management preferences do you use ? I assume you have loaded the ACES 1.2 OCIO Config ?

Did you use textures or colors for the Cornell box ? If you set plain colors, what color_picking role are you using in Maya ?

I think I need to know what primaries did you use to answer you correctly. But if you rendered in ACEScg, you sure need to load your renders as ACEScg in Nuke.

Regards,
Chris

#3

Hello Eckhart,

I’m going to assume that i guess some of your setup to give the answer below but bringing some precisions as mentioned by Chris would be helpful.

the #2 and #3 render are the correct ones.
But as you asked: why is the #1 looking more correct ?

  • In maya I supposed you used maximum RGB value like RGB(1,0,0) for red. As you are “rendering” in ACEScg, this means your red correspond to one of the most extreme value for the ACEScg gamut (the red primaries). ACEScg being a very wide gamut this mean you are using a very “strong” color (actually similar to a laser color). So that’s why the #2 and #3 looks so “saturated”.

And now the funny thing is that your #1 looks more correct because here, in Nuke, you tell that your render was actually rendered with sRGB primaries and need to be converted to ACEScg. So the extreme value (1.0,0.0,0.0) you used are in this case the limit of the sRGB gamut which when viewed looks less “extreme” that the ACEScg one.
And yes your render-engine is “colorspace agnostic”, so this is the color data that you are feeding him that determine which colorpsace it belongs to.

So now to get the #1 result with the #2/#3 setup you just need to convert your colors to ACEScg,
so for example RGB(1.0, 0.0, 0.0) from sRGB become RGB(0.613, 0.0702, 0.0206) in ACEScg.

–
And I highly recommend to read @ChrisBrejon 's website if not already: Chapter 1: Color Management - Chris Brejon. :wink:

#4

Right! Sorry! I was a bit rushed yesterday.
I’ll add screenshots of the settings here.

Maya Color Management:

MayaColorManagmentSettings
MayaColorManagmentSettings1997×1157 341 KB

Maya Color Swatch:
MayaColorSwatch

@ChrisBrejon I did not use textures. Only colors from in the shader.
Is the ‘color picking role’ the menu for ‘RGB01 - RGB0256 - HSV’?
In the Mixing color space I’m only getting that ‘Output - sRGB’

@MrLixm I did indeed use maximum values for the colors I believe (I’ve started second guessing myself with all of this… )
Or at least I used the suggested colors at the top of the color menu, which I assumed are the primary values.
But now that I look at it, I did have HSV selected.
Which probably isn’t the appropriate way.
I’ll now try to get these colors right and see what I get.

Thanks for the input!

ACES OCIO doesn't seem to affect render results
ACES OCIO doesn't seem to affect render results
#5

Alright.
Done some more fiddling in Maya/Arnold.
So if I understand it correctly, when I’m picking a color in the color picker and have ‘Color management’ ticked off, I’m setting the color in the sRGB range, right?
Because when I set R to 1, with ‘Color Management’ ticked on, and then turn it off, the R value goes to 1.308.

Also, are there any rules to the Cornell box or am I overthinking this?
I don’t know why, but I thought the red wall had to be (1,0,0) and green (0,1,0) in sRGB.
But that all looks so bright, so I started wondering if it just had to be a red and a green value.
And then match it in comp.

#6

Hey @Eckhart ,

it took me six months to figure out the color_picking behavior in Maya.

The color_picking role is set in the OCIO config on Output - sRGB which can mislead lots of artists.
I have put some examples on that on my website, using lights and volumetrics render.

So when you set (1,0,0) in the color dialog box, you are actually using (1.296,0.04,0.008) in the render !
And if you set to (1,1,1), you are actually using (18,18,18) in the render.

I am not sure why Autodesk has done that to be honest. The color_picking role is supposed to “output transform” the color dialog UI. But in Maya, it also drives the color selection. Very disturbing.

I see two alternatives here :

  • Edit the OCIO config to use ACEScg as a color_picking colorspace. The values you enter will be the values used during rendering.
  • Edit the OCIO config to use sRGB as a color_picking colorspace. It will give you the pleasing render out of the box.

You could also untick “Color Management” in the light, but I have never tried myself…
If you use ACEScg primaries on the Cornell box, it would be like using laser-like values in the albedo. Not sure you want to do that…

Hope it helps,
Chris

1 Like
#7

Heh, I’m happy to hear it’s not just me and actually Maya-related what was causing my confusion.
Next up are Clarisse and Houdini, which I hope will go smoother.

And yeah, after Liam’s tip, I also started to realize that I should stay clear from primary values.
So I guess the Cornell box just needs some colors to work with.

Thanks, I really appreciate the help!

#8

Chris, the color_picking role is identifying the space the artist should be mixing colors in. It does not specify the output or view transform to be applied to the color picker UI. The view transform menu in Maya controls the latter.

Maya offers the choice to enter color values in either the rendering space or the display space. If entered in the display space, the RGB value will be sent backwards through the viewing transform to get the equivalent rendering space value. For example, if an artist has a specific sRGB value that they want on output, they can enter that as the display space value and the colour picker converts it to the necessary rendering space (ACEScg in this case) value.

If the OCIO config specifies the color_picking role, this will lock the color picker to that space. If you want to give the artist the ability to choose between rendering and display space in the color picker UI, the config should not specify the color_picking role.

This is covered in the Maya documentation:
http://help.autodesk.com/view/MAYAUL/2020/ENU/?guid=GUID-EBC11F85-9CAB-4D33-ABF4-836AD47D5C76

Doug Walker
Autodesk

1 Like
#9

Thanks @doug_walker for the clarification. Your help is much appreciated.

As I said in my previous message, I have spent quite some time trying to wrap my head around the color_picking role. As I teach in a couple of schools and online forums, I have realized that the use of color picking_role in Maya was not clear for many people. Hence my comment.

I read from the OCIO documentation about the color_picking role :

color_picking - colors in a color-selection UI can be displayed in this space, while selecting colors in a different working space (e.g. scene_linear or texture_paint)

And after talking with a few developers who implemented OCIO V1 in their softwares, I reached the conclusion that the color picking role (in some softwares) was only for display purposes. For example, the color dialog UI would be displayed with the output transform (which is necessary/handy) but the color itself would be expressed in ACEScg (the rendering space).

Many schools use the default ACES OCIO config with the color_picking role set to “Output - sRGB” and actually very few students/teachers have realized that the values entered are not the ones used during the rendering. I think it is worth mentioning and explaining. It has caused me quite some headache a year ago.

I am looking forward talking with you about this topic in the new UX OCIO group.

Regards,
Chris

1 Like
#10

Thank you @ChrisBrejon for the added info, that’s interesting to hear. This is yet another example of how OCIO roles have been interpreted differently over the years. Clearing up the definitions of the roles will definitely be a high priority for the new OCIO UX working group and I am extremely pleased you will participate! Will look forward to continuing the conversation there!

(By the way, there is now some sample code in OCIO v2 that is intended as a helper function for color pickers.)

best,
Doug

1 Like
#11

Awesome ! Thanks Doug. Here is a screenshot of one my favorite render engine :

image

Just to show you an example. See you in the meeting. :wink:

Chris