ACES with 3ds max

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

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

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

[hermit.crab]

Still no changes. Could you screenshot the new parameter for me please?

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

[^Lele^]

Oh, i'd be interested in seeing those samples, personally!
I don't think they'd be OT at all, rather completing the analysis.

[JulianD]

I think we can agree on it all, and most of all, i'm super curious to see this mature and be widely adopted.
I heard Blur all but transitioned to it too, and they don't do just cartoony stuff, which makes me want to be a fly on their wall. :P

Same!
ACES 2.0 is coming somewhere in the end of 2020. Maybe we can wait for good improvements.

i think I'm done with ACES in vray for now. Still remains the big question about VRAY_SHOW_COLOR_SPACE_UI lol. I updated my script so I can go and forth on ACES / old sRGB workflow easily.


I think I'm going to try to make the whole ACES workflow by now and I'm going to begin with the post-prod. So next stop: Nuke.
I'll probably post some results here and there if it's not too off-topic.

Cheers!

[^Lele^]

I think we can agree on it all, and most of all, i'm super curious to see this mature and be widely adopted.
I heard Blur all but transitioned to it too, and they don't do just cartoony stuff, which makes me want to be a fly on their wall. :P

[JulianD]

What i see so far is an debatable change (i.e. i may like it, but that doesn't make it right.), and one that cannot be undone after the fact.
In the same vein, it'd be very doable to saturate and contrast FP renders in post to make it look like if ACES primaries were used.
We rendered in sRGB with a linear transform for decades without issue (when not messed up somewhere else along the pipeline), and proceeded to twist the living beejesus out of those in post, so the cost to benefit of this is not readily apparent to me (it could just be i am dense, and i say this without sarcasm, or too pragmatic, having see all sorts of issues stem from well simpler situations that this kind of setups.).
Notice i have been reading nigh all there is out there for half a decade now, a few times over, and still am not convinced, because besides words, proof seems to be exceedingly scarce, or an overly well kept secret.

I agree with you, as long as we are in the sRGB monitor area it's complicated to have a real difference whatsover. It's like saving your 16bit exr file instead of a 8bit jpg: it clearly gives more controls in post-prod, but at the end your image will be displayed on an 8bit monitor anyway.. Not a lot of people can afford a +10bit monitor nowadays.
Maybe in a couple of years that will become a standard, fingers crossed.

Take the UHD TVs for example, their colorspace is REC2020 which is really close to ACEScg, the new Macbook has a P3 colorspace which is wide gamut. The iPhone 5 has a gamut as wide as the one of our monitor (!!). It still surprises me to see that in the "windows"/"common" environment we still use sRGB monitor. Those are from an ancient time to me, clearly.

Well i ain't sure it's the case.
The primaries are R,G, and B: there is no native split into an HLS model, so they are longer and rotated just so, but still three vectors expressing those three quantities.
Further, the render engines do not make the diferentiation between value and hue, and that's also why you get forever changed GI results (And in fact, with any other kind of recursive, cumulative effect contributing to the final pixel).
It seems to me this stuff has been dragged by color scientists dealing with Cameras and display devices (where the final pixel color is all there is to transform.) into the wrong realm (where the transformed source color gets multiplied over itself tens and hundreds of times, leading to all sorts of undoable issues.).

After re-reading my previous post I went back to it and added a few clarifications to prevent any confusion about this.


Every "color" you see is unique (here shown at a brightness (= a value ( = bit depth)) and saturation given, just for our eyes convenient).
So the color xG:0,17 yG:0,797 (Green primary of rec2020) exists for the rec2020 colorspace but it doesn't exist for the rec709 one. So basically that color is lost if you display/render with that colorspace.
hues are all around the horseshoe.

Personally, I'll be waiting for more proof of this working as smoothly as sRGB with a linear transform did, for as many people, and in as many different jobs, before calling myself a convert.
So far, i only heard of selected companies, and selected jobs, and a good few years of trial and error to get there, by incredibly smart people. The opposite of plain sailing.
That, to me, spells immaturity for the standard, still.
I'm also very glad of seeing these examples, for when i test by myself i can't ever quite tell what it is the result i am looking at.

Some studios already use ACES. Animal Logic were the pioneer with Lego Batman and ACES helped them get those awesome vivid colors.

Sorry, you would need to add the VRAY_SHOW_COLOR_SPACE_UI=1 environment variable to be able to see the option.

Still no changes. Could you screenshot the new parameter for me please?

[^Lele^]

I think you could cheat on saturation here and there to get to something close to it, there are just colors after all.

The most important point of ACES is to use the widest color range to make the best calculation for lighting so you can get vivid colors on direct and indirect lights (see the bounces of the boxes on my cornell render). From there you can decide to desaturate your render if you wish, it's just a matter of taste.
If I would popularize the color of ACES versus sRGB by taking the image size as a comparison (where ACES = 1080p and sRGB = 720p), I'd say that's easy to go from 1080p to 720p without loss but going from 720p to 1080p won't give you a nice result. Plus, in 1080p you have better resolution so your render might be clearer, like ACES when it comes to colors.

One last thing awesome about ACES when you choose sRGB as a colorspace display (or any other btw). It doesn't simply convert your colors from ACEScg to sRGB by clamping them to the nearest sRGB gamut's boundary. It tries to adjust them so you could get a bit more saturated colors than you should get in sRGB. This is why we talk about ACES sRGB and not 2.2 sRGB (or commonly called sRGB).

This is what still leaves me unconvinced, however.
Once the colors have been bounced by the GI, they are essentially baked into the final pixel color.
Changing saturation will not get back the greens drowned out by the red sphere, as it will only be able to act on the final pixel color of a GI solution, rather than on the source ones. It's going to miss the many multiplications of said broader gamut colors unto themselves.

Because we don't shoot images, but make them, to me this skewing of colors, albeit for the introduction of a broader range, feels inherently wrong at the rendering stage, especially when the remapping to the same display device we use daily makes it look different than if it was displayed on broader gamut devices (f.e. cinema).
That it's gentler than working in Log we can agree on, that it's correct at the rendering stage, i am still doubtful of (there ought to have been tests against spectral ground truth yadda yadda, but i have not seen them, besides hearing of them. I'd love a link if someone has it.).

Of course, when i make this comments i assume we stay in the broadest data format we can, as it's a staple of data handling.
Still, i'd like to see proof of a match through a simple CC, as i think it is not doable at this stage (i.e. after the render is done.).
Further, i'd love to see visual proof of a matching between an ACES and a standard sRGB (its gamma curve is slightly more nuanced than a simple 2.2) with a linear transform applied.
There have been entire shots on which i worked which happened within the range of darks the render above crunched, for example.

What i see so far is an debatable change (i.e. i may like it, but that doesn't make it right.), and one that cannot be undone after the fact.
In the same vein, it'd be very doable to saturate and contrast FP renders in post to make it look like if ACES primaries were used.
We rendered in sRGB with a linear transform for decades without issue (when not messed up somewhere else along the pipeline), and proceeded to twist the living beejesus out of those in post, so the cost to benefit of this is not readily apparent to me (it could just be i am dense, and i say this without sarcasm, or too pragmatic, having see all sorts of issues stem from well simpler situations that this kind of setups.).
Notice i have been reading nigh all there is out there for half a decade now, a few times over, and still am not convinced, because besides words, proof seems to be exceedingly scarce, or an overly well kept secret.

Yes we could recover the crunched shadows but we need to clarify something first.
We use the word "color" wrong. Color = hue + value. hue is given by the gamut (the largest the better (that's what ACES is all about)), value is given by bit depth (8bit, 16bit, 32bit).

Well i ain't sure it's the case.
The primaries are R,G, and B: there is no native split into an HLS model, so they are longer and rotated just so, but still three vectors expressing those three quantities.
Further, the render engines do not make the diferentiation between value and hue, and that's also why you get forever changed GI results (And in fact, with any other kind of recursive, cumulative effect contributing to the final pixel).
It seems to me this stuff has been dragged by color scientists dealing with Cameras and display devices (where the final pixel color is all there is to transform.) into the wrong realm (where the transformed source color gets multiplied over itself tens and hundreds of times, leading to all sorts of undoable issues.).

Personally, I'll be waiting for more proof of this working as smoothly as sRGB with a linear transform did, for as many people, and in as many different jobs, before calling myself a convert.
So far, i only heard of selected companies, and selected jobs, and a good few years of trial and error to get there, by incredibly smart people. The opposite of plain sailing.
That, to me, spells immaturity for the standard, still.
I'm also very glad of seeing these examples, for when i test by myself i can't ever quite tell what it is the result i am looking at.

[hermit.crab]

What parameters of the VrayColor need to be tweeked? I didn't get it, sorry.

Sorry, you would need to add the VRAY_SHOW_COLOR_SPACE_UI=1 environment variable to be able to see the option.

[JulianD]

The parameter controls the internal color grading system and affects internal V-Ray components using color. You most likely need to set the VRayColor map's 'rgb primaries' to 'sRGB primaries' to see an effect (so as to apply a certain color transform) or for example change the temperature of a VRayLight.

What parameters of the VrayColor need to be tweeked? I didn't get it, sorry.

[JulianD]

I think the blacks look a bit too crunched with Aces, but i think it's got to do with out of range values for the sRGB device to display.
I too like the way it doesn't burn out the whites (my guess is that the bigger primaries accommodate the values better.), and i think i'm in love with the saturation of hue, as well.

I went back on my renders and figured out I was a bit too generous with the normal and bump map which made the blacks crunched more than they should. I re-rendered them and edited my post. Now it looks a bit softer.

Say at some point you needed to show your product on sRGB monitors, however.
Could you match the looks of the AcesCG to the one of the standard primaries sRGB?

I think you could cheat on saturation here and there to get to something close to it, there are just colors after all.

The most important point of ACES is to use the widest color range to make the best calculation for lighting so you can get vivid colors on direct and indirect lights (see the bounces of the boxes on my cornell render). From there you can decide to desaturate your render if you wish, it's just a matter of taste.
If I would popularize the color of ACES versus sRGB by taking the image size as a comparison (where ACES = 1080p and sRGB = 720p), I'd say that's easy to go from 1080p to 720p without loss but going from 720p to 1080p won't give you a nice result. Plus, in 1080p you have better resolution so your render might be clearer, like ACES when it comes to colors.

One last thing awesome about ACES when you choose sRGB as a colorspace display (or any other btw). It doesn't simply convert your colors from ACEScg to sRGB by clamping them to the nearest sRGB gamut's boundary. It tries to adjust them so you could get a bit more saturated colors than you should get in sRGB. This is why we talk about ACES sRGB and not 2.2 sRGB (or commonly called sRGB).

Could you easily recover those crunched blacks with simple enough CC?

Yes we could recover the crunched shadows but we need to clarify something first.
We use the word "color" wrong. Color = hue + value + saturation. hue is given by the colors based on human vision (all around the horseshoe of a CIE) saturation is given by the primaries of a gamut (the largest the better (that's what ACES is all about)), value is given by bit depth (8bit, 16bit, 32bit).
So if you render in ACEScg but save your image as a 8bit jpg file you won't be able to do anything in post-prod with your shadows as your value range is too small. You need to save it at 16bit minimum.


wide range = more control = smoother result

Or would you rather need to back-transform it all into a neutral middle, and transform again into the new space?

If we are talking about post-prod process: I wouldn't go back to another colorspace to make my shadows look better, I would be afraid to lose color or bit depth information in the process.
The only time I would do it, would be going to a LOG-look to apply a LUT I like, just because I'm lazy to manually match my render to the LUT looks haha.

Brilliant thank you.

You're welcome! Glad that helped!

[hermit.crab]

@aleksandar.hadzhiev:
Can you tell me more about this parameter please "options_rgbcolorspace=2" ? What does it do on lights and GI?
I rendered my cornwell box with rgbcolorspace=2 and rgbcolorspace=1 and saw no difference. Is it only working with textures? (All my colors are vraycolor map)

Also do you know when the new VFB (with full aces workflow) will launch?
Thank you

The parameter controls the internal color grading system and affects internal V-Ray components using color. You most likely need to set the VRayColor map's 'rgb primaries' to 'sRGB primaries' to see an effect (so as to apply a certain color transform) or for example change the temperature of a VRayLight.

[DanSHP]

I would prefer the following expressions to prevent any confusion:
Linear sRGB: In = Utility – linear – sRGB. Out = AcesCG
2.2 sRGB: In = Utility – sRGB – texture. Out = AcesCG

By the way I haven't converted any data maps for my part. Should give it a try to see what would come up
edit: I just tried with a displace map in Linear sRGB exr file: I just plugged it in the displacement map slot of a vraymtl and made 2 renders: one with and one without a vrayOCIO (in: Raw, out: acescg): I don't post a comparison because there is absolutely no changes.
edit2: tried with a reflect map as well: same result. I don't know what <in:Raw out:AcesCG> really does I never used it before, but to me it's a simple linear conversion where no values are shifted, so the conversion is useless.



Funny, we had this discussion a few message ago. Actually you can use any of the displays available but the best choice for you might be the colorspace of your final monitor/projector/tv.
Setting up your textures as sRGB doesn't mean you have to stay in that colorspace until the end You set up sRGB textures because they are sRGB textures, that's all. There is no real link between the textures' colorspace in entry and the display's colorspace in exit since there's a big ACES converter in the middle.

Brilliant thank you.

[^Lele^]

I think the blacks look a bit too crunched with Aces, but i think it's got to do with out of range values for the sRGB device to display.
I too like the way it doesn't burn out the whites (my guess is that the bigger primaries accommodate the values better.), and i think i'm in love with the saturation of hue, as well.

Say at some point you needed to show your product on sRGB monitors, however.
Could you match the looks of the AcesCG to the one of the standard primaries sRGB?
Could you easily recover those crunched blacks with simple enough CC?
Or would you rather need to back-transform it all into a neutral middle, and transform again into the new space?

I dread that i never got production experience with AcesCG: sorry if i'm being close to useless, here.