ACES with 3ds max

[pablohooney]

Hello everybody,I am trying to better understand the right ACES workflow. Since vray 5 is out and there are new options that seems to help in this, I would like to know what's your setup.


As far as I understand, now it should be done this way:

step 0: select linear tone mapping form the Color mapping menu.
step 1: under V-Ray color management select ACEScg.
step 2: select Auto RGB primaries for VRayBitmap textures.
step 3: for albedo / diffuse textures select "from max" in the Color space transfer function rollout and select "RGB primaries" in the RGB color space rollout.
step 4: for reflection / glossy / bump / normal etc... select "none" in the Color space transfer function rollout and select "Raw" in the RGB color space rollout.
step 5: select OCIO in the frame buffer and load the OCIO file version ( 1.2 in my case ).
step 6: Input color space = ACEScg and View transform = sRGB / Rec. 709 or whatever color space you might want to use.

Is this workflow correct? Just asking because the main problem here seems to be highlights always washed out when I try to balance the overall exposure inside a room.

If I need to create a white material with some bump effects, I must set the diffuse color around a value of 180, 180, 180 to avoid loss in details ( bump or normal ), setting to something like 230, 230, 230 give me a complete loss in details. Is this supposed to be correct or am I doing something wrong in my workflow?

Does I still need to have gamma set to 2.2 in the max preferences?

[muoto]

It's funny actually, not really correct probably, but by eyeballing, i get the best results using the regular JPG or HDRI's and using ACESCG - ACES - REC2020 as settings in the VFB... (eventhough my monitor is sRGB)
JPG textures looks kind of similar, HDRI's background do not tend to get the cyan color in the blues...
but's a little desaturated i have the impression

[muoto]

Great ! that works with JPG's as bitmap texture

but how do you deal with mixed files ? some jpg as textures, and some 32bit HDRI as background for instance ?

using raw kind of removes the soft colors i get when i use sRGB in display transform on the hdri background

[^Lele^]

EDIT: i was wrong. Doing what i suggested would produce horrible negative components.

[muoto]

Hello,

i've been testing the acesCG setup for a while. I have a question concerning the bitmaps (JPG)...how do you get the correct same colors when rendering ?

Do you always have to use the sRGB output -> acescg transform VrayOCIO material

thanks !

[^Lele^]

Oh, thanks so much for feeding back on this: it's precious to me.

re: non-linearity of the HVS: yeah, i'm aware of how it works, and of the various caveats.
My point is sideways, however: i want control, not a pre-baked choice by someone else, much less so one which breaks linear workflow.

We're not talking of overbrights being rescaled here (which, debatable as it may be, would likely be feasible to work with.), we're talking of inputting a color as 1.0f, and seeing my data come out as something else by virtue of what should be a no-op.
You may or may not recall that infamous thread on the Adobe forums about what Alpha meant for EXR images, over ten years ago, but the issue with data preservation is identical, here: load a texture in the right space, inverse transform it to the working space, save it out (with the display transform) and it's a different thing.
Call it "Hollywood sRGB (TM)", if you please, but don't sell it as the same as non-ACES sRGB, for it is not, and *will break linear workflow*.

As an artist, i can't think of anything worse than being asked to do something (double the light's intensity, make it redder by ye much), and then being pixelfu**ed for daily after daily after daily because the intensity is never quite double, or the saturation isn't responding linearly to my conttrols, as the Supervisor expected.
Hell, they'd even go measure it, and lo! and behold, it's not twice as much (not when corrected, which is when you see it, anyway.).

Sure enough, if needs must, a way forward will be found, but why on earth Defaults have to be fought against?
They finally managed invertible LUTs and proper implementation up to the display, and bork it like this naming custom S-curves as the renown standard's, which besides the tri-stimuli adaptation, generally mean a simple set of gamma curves?
You want to do non-linear tone mapping, the place to do so is somewhere else than the display transform.
Way beyond my comprehension, i'll admit.

You should not use "save in image" option in VFB as it "collapses" the colorspace and lose flexibilité in comp, and there's no way to back-transform your render.
Utility - sRGB - texture is made for sRGB 2.2 file not sRGB ACES file ! You may not (and will not) get the same result for sure.

I could find the output transforms on the nuke loaders NP, so i am not sure what you mean.
I meant to bake the display transform in when saved off the VFB, and un-bake them in nuke using exactly the same LUT, so to check for invertibility.
Any precision loss was beyond the third decimal place (see the numbers in the graph), which i'd consider more than enough for visual inspection (and a bit, to be fair.).
And in fact the images look identical, and the measuring maths is in scene-linear space, while each image is loaded in with a different colorspace (raw, sRGB and rec709, respectively.).

Unfortunately, in nuke using the traditional sRGB transform for display isn't straightforward (once in OCIO/ACES, the standard nuke sRGB isn't available as viewer process. One needs to display Raw and use a colorspace node to apply the standard sRGB gamma, which is patently not the same...), so we're back to square 1 as for arbitrary visual squashing.

[JulianD]

Happy new year!

Thanks for sharing those tests Lele!

I further saved the ACES display transforms into the files, and back-transformed those in nuke on load.

You should not use "save in image" option in VFB as it "collapses" the colorspace and lose flexibility in comp, and there's no way to back-transform your render.
Utility - sRGB - texture is made for sRGB 2.2 file not sRGB ACES file ! You may not (and will not) get the same result for sure.

Whites set to 1.0 display as ~0.8 too, which is befuddling as a default, and the curve below 1.0 is squiggly (yeah, ok, S-shaped. psanitra did mention it).

That's the S-shaped curve yes. As long as the scene linearity is preserved I'm ok with that.
Again our eyes don't work like computer: we see more values in the shadows, this is why camera record with LOG curve to bring more values in the toe. I think I read somewhere that values superior as 0.88 aren't noticeable for our eyes. So why would you try to have pure white somewhere else than in "data" file (spec, gloss, ...)? On a cinema screen or on your monitor that would burn your eyes
The only problem I see is the s-shaped curve clamps too much highlights IMHO. The Academic should let a bit more highlights out on ACES.

So i'd personally render with ACEScg primaries and colorspace, a raw Display transform, and the sRGB gamma button active.
Or would that create other issues still?

Well that's kinda interesting. With that workflow you are using ACEScg for the calculation but don't use ACES SRGB but SRGB 2.2.
I don't see big issues, you lose RRT+ODT's tone mapping and it's not going to be a bit trickier to set tup Nuke, Resolve, etc. as you're "part off-workflow"


I made some new tests.

First of, Resolve : 100% done. Updated to the last version helped a lot to get a rid of all the confusions.
Mari : 100% done. As easy as Nuke.

I decided to play with XYZ texture to see what come up.
Convert them to ACEScg made a too strong color shift in my opinion. So I color corrected it and decided to create a Group node out of it.

Here's my result :

Left : Texture XYZ as you download them. On the right : my closest match (colorspace : ACEScg, display ACES sRGB).






Left : simple conversion. Right : conversion + my cc (and the group node that I created to optimize my node graph).






Let's now try on another XYZ texture :






Works fine!
I think I'll batch all my XYZ textures to ACEScg when I get free time.

At this point I don't know if it's a good idea to color correct the albedo to get closer to the sRGB 2.2 color or let as ACEScg converts it and let the render engine deal with it. It may depend of the shader. This part needs more tests but I pause it for now.

Next stop : Substance Painter!

[^Lele^]

Well, i redid some of the tests i made when trying out ACES in 2013, and they finally came out right.
It seems ACEScg uses invertible transforms, and that V-Ray is doing a good job at it.
I'm satisfied scene linearity is preserved, along with screen linearity (thanks to the above.), viewing material under sRGB displays.

Attached is a GI test.
The first row has a light with 1000 intensity and d65 white. The shader is a 0.75 white diffuse, the color picked in the right space through a vrayColor map (i.e. ACES primaries or sRGB, depending on output).
The second is the same as the first, but the light intensity is ten times higher.
The third row is like the second, but the diffuse color is 0.9.
I further saved the ACES display transforms into the files, and back-transformed those in nuke on load.
I then proceeded to do some simple enough measurements on the renders, and made a contact sheet of them.
For the sRGB part, i was in the right space in Max, and in Nuke while i measured values. I then imported the single-column contact sheet into the OCIO-managed project and attached it to the other three columns.
This should ensure that the pixel data has been read correctly for all the renders (but i ofc stand to be corrected.).



I have however still issues with the way stuff displays in the VFB when viewed directly under any display mode than RAW: see the three attachments below.
Both transforms seem to have a shaping, which DOES break screen linearity (not the scene one, though.), which is horrible to work with, imho.
Whites set to 1.0 display as ~0.8 too, which is befuddling as a default, and the curve below 1.0 is squiggly (yeah, ok, S-shaped. psanitra did mention it).

Thankfully, that's all restored using a Raw transform, and turning the sRGB curve button on.
So i'd personally render with ACEScg primaries and colorspace, a raw Display transform, and the sRGB gamma button active.
Or would that create other issues still?



Once again, thanks for the patience: a little denser, and i'd be lead.

[^Lele^]

Thanks for being so patient while i'm being this dense, Julian!
Lots of reading over the holidays!

[JulianD]

I gamut plotted sRGB 2.2 over sRGB ACES (clamped to sRGB) of my cornwell box to see how the colors react in a strict sRGB colorspace, just for fun.

Super nice stuff!

Thank you !

That Gamut plot is my very gripe: i need a display device which is able to show those amazing primaries.
Otherwise, all i see is either an oversaturated image (if one was to simply clip to the display bounds) or *some* compression of the primaries (the display transform isn't set in stone, that i understand. I may be wrong on this, though. See here. Your experiences with Resolve seem to confirm this.) to fit the sRGB monitor.

ODT (Output Display Transform) can be changed anytime, yes.
If you want a good monitor, you may choose an Eizo or this one: https://www.amazon.fr/ASUS-ProArt-PA...mputers&sr=1-1
It can display 89% of REC2020 gamut, which is awesome, but it costs 3000€...

Think of a light's intensity, f.e. it's going to be linear in sRGB OR in ACEScg, not in both, as one (sRGB) is derived with a further transform, and after the display gamut bounds have been reached, there will be no apparent brightening (at least when viewed directly), or the out-of-gamut values will need to be rescaled, hence a complex matrix multiplication will have crept in, ruining linearity.

I may not understand the problem actually, sorry.
Light's intensity is linear in v-ray as it's much easier for any algorithm to work that way and it doesn't care much about colorspaces actually. You give it an intensity, a color, and it deals with it.

Once your render is done you can still adjust your exposure the way you like.
It doesn't need to be linear and it would be better if it's not. The reason to that is simple: our eyes don't work like computers.
It is for this particular reason that we talk about f-stop when it comes to exposure. This is the same reason that a neutral gray is a 18% gray and why cameras use log curve to record (if we forget about raw).

Come on, out with the truth, where's that cinema projector of yours, JulianD ? ^^

haha! I'd love to! Sadly I'm stuck with a simple sRGB monitor at home, but I got an Eizo at work that can display 80% of dci-p3 I think.

EDIT: updating my reading on the ACES forums, i can't say my objections have been cleared up. Quite the contrary...

You should definately not start with ACES forums lol. It is very very technical.
Start here: https://chrisbrejon.com/cg-cinematog...or-management/ (chapter 1 and 1.5). I'm sure you'll understand everything

[^Lele^]

Super nice stuff!

That Gamut plot is my very gripe: i need a display device which is able to show those amazing primaries.
Otherwise, all i see is either an oversaturated image (if one was to simply clip to the display bounds) or *some* compression of the primaries (the display transform isn't set in stone, that i understand. I may be wrong on this, though. See here. Your experiences with Resolve seem to confirm this.) to fit the sRGB monitor.
Either way, there is *so much* gamut out of the artist's direct management (anything outside of the sRGB gamut.) while rendering that it makes my LnR TD cringe in disbelief: i always wanted to exert control, not once i was happy to leave it to faith.

The back-transform to sRGB would make a hash of any scene linearity, as well.
Think of a light's intensity, f.e. it's going to be linear in sRGB OR in ACEScg, not in both, as one (sRGB) is derived with a further transform, and after the display gamut bounds have been reached, there will be no apparent brightening (at least when viewed directly), or the out-of-gamut values will need to be rescaled, hence a complex matrix multiplication will have crept in, ruining linearity.
Under an sRGB linear tranform, we could always have *one* simple multiplier to gauge out-of-bound values: say, any superbright, through the exposure slider.
Come on, out with the truth, where's that cinema projector of yours, JulianD ? ^^

Regardless of where V-Ray is, i am still very unconvinced of the whole workflow, personally.
Will try and do some tests to better show my gripes at some point, after properly digesting all of your experiments and results.

EDIT: updating my reading on the ACES forums, i can't say my objections have been cleared up. Quite the contrary...

[JulianD]

ACES workflow with nuke: 100% done.
It was easier than expected. The only thing that bugs me it's the prefix they give to every IDT to make ACES more accessible. It actually did the opposite on me lol.

Anyway, I tried to load a ACES 2065-1 file and put a ACEScg IDT and it gives me something cooler:


It remaps the colors the same way ACES does it when you convert sRGB file to ACEScg.

I moved on and for now I'm a bit stuck with DaVinci Resolve's workflow. I can have the same result in the timeline but I don't know why the colors are shifted once rendered.... I should try to update my Resolve version. V14 only works with ACES 1.0.3 and I rendered on vray with 1.1

-----

Bonus:
A little gamut plotting just for fun to see the difference between sRGB and ACEScg colorspace (I should have posted it before):

[JulianD]

Ok I got it.
It changes the color but it doesn't switch the option "RGB primaries" from sRGB to ACEScg.
Thanks

[hermit.crab]

Did I miss something?

It should be working fine. Switch between color spaces to see the differences (either with vr.options_rgbcolorspace=1/2 or via the RGB primaries of the VRayColor).

[JulianD]

I didn't have the environment variable, I did creat it (user variable):

.





Now I have the "RGB primaries" option available in the vraycolor map.



1. I opened 3ds max
2. Create a vraycolor, set it's RGB primaries to "sRGB primaries"
3. I run this script:

vr=renderers.current
vr.options_rgbcolorspace=2

>>>
V_Ray_Next__update_3_1:V_Ray_Next__update_3_1
2
4. I updated my vraycolor with the U shortcut/ close and open mtleditor,...: nothing changed
5. I run this code to check if it was only a refreshing problem:

rootScene[#SME][#View1][#Map__1____VRayColor].Properties.reference.rgb_primaries

>>
1

Did I miss something?