ACES OCIO doesn't seem to affect render results

Discussions - Using ACES
1

I have ACES 1.2 set up in Maya as per the typical instructions ( download to folder, environment variable point to OCIO config file, Maya rendering space ACEScg , view transform sRGB ACES ) yet when it comes to rendering my renders didn’t improve and I can’t match any examples I can find.

Basically my renders still look like sRGB linear no matter what I do with the settings.

Any help here ?

2

Hello Hyperviktor and welcome here.
Could you specify which render Engine are you using ? OCIO might be setuped in Maya but it might not be supported by your render-engine and each one necessit it’s own approach.

Cheers.
Liam.

3

Maya 2019 + Arnold 6 with the latest MtoA.

4

Arnold is the smoothest case, So in theory setting the OCIO environnement variable is all you have to do.
Could you share a screenshot of your renderview ?

5

Thanks Liam, let’s hope it’s gonna be smooth.

Here are the steps I’ve done :

  • downloaded ACES 1.2 to folder to an easily accessible folder , C:\ACES1.2\
  • I set the OCIO environment variable to point to the ocio config file in the above folder
  • maya then loads the settings as expected
  • for color textures I set Utility - sRGB - texture as color space in the aiImage node
  • my color picker says Output - sRGB

I did a test render with a box where the walls are red and green and the result was just as saturated as if I was rendering linear sRGB as before , someone else did a test and they had a nice softer looking render

Also, my mid grey 0.5 in the color picker turns into 0.303 when color management is turned off which is weird.

Attached is my render view and settings.

aces_setup
aces_setup1066×1111 157 KB
render_view
render_view1095×765 67.8 KB

6

This is not an “issue” but “normal”. I wouldn’t be able to explain it as good as some people here but keep in mind that a mid grey(perceptually halfway between black and white) value is 0.18 in scene-referred.
I recommend you to read @ChrisBrejon 's books : Chapter 1: Color Management - Chris Brejon about this.

Choice of the IDT will depend of your source. Without having the context of the file (file format mainly) we can’t tell if it’s correct or wrong.

I didn’t try the latest Arnold version but to my eyes everything is working fine. Could you maybe send a render comparison of what look “over-saturated” with the scene setup against what looks “softer” to you ?

Else reading the Chris’ books might help you understand a bit more what’s going on.
Cheers.
Liam.

7

Hey Liam,

I did read pretty much everything on Chris’s site and understand what should be going on, that is why I think I have problems with my setup because I see opposing things happening.

When he talks about mid grey he says it supposed to be 0.214 or 0.18 , no source ever mentions 0.303 as mid grey and I’m trying to figure out where’s that number coming from.

A color managed green primary ( 0,1,0 ) turns into ( -0.809 , 4.032 , -0.019 ) which again, seems very wrong and since ACES has much wider gamut, should be the other way around at best.

I will put together a scene with a render so you might be able to cross-check.

Thanks,
Viktor

8

Actually I’ve found that mid grey in ACES should be around 0.310 so I’m not far off.

I will put together a scene though, to see how that works. It probably would be great if the ACES central designed a reference scene with a reference render image that anyone could download and check if they get the same result, thus the setup is correct.

9

Hello @hyperviktor,

you are facing this behavior because of the color_picking role which is set by default as Output - sRGB.

You could switch to ACES - ACEScg or Utility - Linear - sRGB if needed.

With Output - sRGB as mixing color space, 0.5 becomes 0.303. That’s completely normal. On a recent update on my website, I have tried to list all pros/cons for different mixing color spaces in Maya.

Otherwise, you have this thread on the same topic.

Sorry for the late reply,
Chris

10

Hey Chris ,
Thanks for the input, I’ve actually found the values for ACES mid grey on your site, so that seems ok now.

What about this bit :
A color managed green primary ( 0,1,0 ) turns into ( -0.809 , 4.032 , -0.019 )

Actually that thread you have linked explains the color values so I think I just need to choose which space I want to use my color picker and set it in the OCIO config, so this one seems ok, thanks again for the input.

V

11

Exact same deal. Your color selection goes through an inverse Output Transform because of the color picking role being set to Output - sRGB in the OCIO config.

Doug Walker’s answers (from this thread) should give some good explanations about this behavior. If you don’t like it, you can change the config to your needs.

Cool ?

Chris

13

So here’s a maya scene, similar to what you have on your site ( box with red and green sides )- https://we.tl/t-NuxoQ1p0mK

Also here’s my render :

testrender_RG_01
testrender_RG_011280×720 89.8 KB

It looks about right finally, if anyone has the time to render this and compare / post the result that would be amazing!

14

Hey,

I opened the scene and did a render.

  • Which color_picking role are you using in the end ? Did you modify it ?
  • What ODT are you using ?

Update : my render is similar to yours. But I jut wanted to check. :wink:

Thanks,
Chris

15

Hey Chris,

Color picking is defined in the OCIO config as follows :
color_picking: Output - sRGB

View transform sRGB(ACES)

16

Cool, so the default config.

Which makes me think : if you didn’t modify the color_picking role in the config, what have you done to make it look right/good ? I’m curious.

On a personal note, I never keep the color_picking role as Output - sRGB because I like when the values I enter in my DCC software are the actual values by the render engine. If the value I enter goes though one transform (and then is used at 0.8 weight in the aiStandardSurface), it makes it complicated in my opinion to know what is the value used in the end (like negative ones)…

But maybe I’m over-complicating things…

Chris

17

I haven’t touched it yet but my worry was that if it’s not in output - sRGB I may use colors based on incorrect visual selection , it definitely sounds better the way you have it.

What do you use for the color picker ? ACEScg ?

I cheated - since there is no point using exact primaries I slightly pulled back the values. In a real scenario there never would be a strong primary color on anyting I guess, even a single color value is rare, almost everything has image textures.

18

Yes, most of the time I use ACEScg in the color_picking role.

I will not enter the debate of using primaries in albedo : it is a very long and interesting topic indeed ! But it is good to know that ACEScg primaries are outside of the spectral locus and that BT.2020 primaries can only be achieved by lasers. Just to give you an idea of a real-world value equivalence.

Great power means great responsibilities. :wink:

Regards,
Chris

19

I’m glad it sorted, I will keep testing it for a while but at least everything looks fine for now :slight_smile:

Thanks,
Viktor

20

Yep, ACEScg it is for the color picker, works better definitley, more stable. Before I had to fiddle to get certain color values, this setup is rock solid!

Thanks again!

V