ACES with 3ds max

[JulianD]

The variable should work fine with recent V-Ray builds. Here is the requested screenshot.
http://ftp.chaosgroup.com/support/3d...9_15-10-37.png

I updated my vray to the last version and I run this code:

vr=renderers.current
vr.options_useColorSpaceForBitmaps=true
vr.options_rgbcolorspace=2
VRAY_SHOW_COLOR_SPACE_UI=1

>
V_Ray_Next__update_3_1:V_Ray_Next__update_3_1
true
2
1


And all I got is:


Vray Next update 3 - 3ds max 2018
what's wrong?

EDIT: I just updated to be sure: Vray Next Update 3.1 - 3ds max 2020 : same result.

[JulianD]

Updated to vray next 3.1 and 3ds max 2020: I have the same result.. There's something I don't understand here (?)

[hermit.crab]

Updated to vray next 3.1 and 3ds max 2020: I have the same result.. There's something I don't understand here (?)

Make sure you've set the environment variable (System properties>Advanced>Environment variables) correctly - see this screenshot: https://ftp.chaosgroup.com/support/S...0_12-50-19.png

Afterward, do the following to test it out:
1. Create a VRayColor, set its RGB primaries to 'sRGB primaries'. The color is now read as in sRGB color space.
2. Change the V-Ray internal color space to ACEScg via MaxScript.

vr=renderers.current
vr.options_rgbcolorspace=2

3. The VRayColor is now transformed into ACEScg color space. (Update node with 'U' if it didn't update)

[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?

[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]

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

[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):

[^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]

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^]

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

[^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.

[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^]

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.

[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^]

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