Hi,
I’m having some problems with the new color management OCIO with 3dsMax 2026 and VRay 7.4.02 (latest one).
I have already setup correctly LINK, but I found in this way I have a lot of contrast, too much. So the shadow are really really dark especially when my scene are full of vegetation and forest, everything look too dark and need for sure some post. In the previous color management was fine, and it was more convenient. so basic scene were already ok with no mandatory post.
If I change ONLY in the VFB from OCIO to sRGB (jpgs attached) I like it more and it’s fine, but I can not save it as I see it in the VFB. I tried many things but the results are always different from VFB.
How can I do this?
Could you help me please?
Thank you
Nico
I want to add another example, more clear.
One image is with VFB Display Correction OCIO and in any case doesn’t match the saved render.
The other is with VFB Display Correction sRGB (the one I like it), but even here doesn’t match the saved render.
Thank you
Nico
Sorry, I did a test also in Gamma 2.2.
And it save the render different…
what I’m doing wrong?
The output image is dependent on 3ds Max’s Render Output Defaults, which you seem to have left out as “No conversion”. If you like the sRGB look with ACEScg as a rendering color space, you can set it like so:
Otherwise, Windows Photos is dependent on the monitor profile used by Windows. Make sure the profile used is sRGB IEC61966-2.1.
Hi Hermit and thank for letting me know!
I’ve updated Max from 2022 to 2026 version, so this is why before I didn’t have this problem.
As you can see attached with your setting I have the same result. During the saving I left “automatic”.
I don’t understand why what I see in the VFB is not the same from what I save.
NOT for sure I have to work in sRGB, ACEScg is fine and it should be better! But ACEScg in my test with basic stuff like, trees from Cosmos, VRay Sun…it is quite contrast and strong, the shadows are really dark (I’ve attached an example). It seems not natural light like in sRGB.
In sRGB seems by default, VRay sun/sky have the correct balance light/shadow.
Is this setting are correct for OCIO? In SAVE I left automatic and the images saved seems to match exactly the VFB as you can see.
I repeat, the only things it seems weird is the general contrast with shadows very strong to me. From YouTube videos I see that OCIO works nicely and better, but in my views seems to have this problem.
Thank you
Nico
The second method is not correct because BOTH methods of applying the View Transform are active (which should lead to double corrections).
The results seem similar because of this:
The Exposure (display only) option, which you’ve set to 1. The default (the one the image is saved in is 0.
This setup should yield the expected results with the sRGB look:
Hermit,
Thank you, it works well.
I never touched the Exposure (display only), so I don’t know why was setup on 1. Anyway…
Could you tell me instead which is it the correct setup forACEScg? So I can exactly compared them.
Thank you!
Generally, for a proper ACEScg workflow, the ACES 1.0 SDR-video view transform (instead of Un-tone-mapped) should be used (so as to correctly map HDR values to SDR values). Without it, you only benefit from the larger color gamut.
Hermit, when you can…could you make me a screen shot as you did before for sRGB workflow please? It would be great if you can.
I don’t want to understand wrong. So like this I have the both workflows correctly setup and make some test and see which one is better for me, with no setup mistake.
Because I don’t understand clearly “you only benefit from the larger color gamut.”
Thank you very much. I’m a bit “ignorant” about all of this “color management”. Make a lot of confusion.
Nico
Just a note: the first variant (with Un-tone-mapped) is not really an “sRGB” workflow. The rendering space is still ACEScg; it’s just that there’s no view transform applied. It looks the same as the sRGB display correction, because the OCIO Display Device is set to sRGB, so they match 1:1.
Otherwise, the other “proper” variant is the default one (with a view transform):
Check the ACEScg wiki to visualize the larger color gamut (amount of available colors/values).
What the ACES 1.0 SDR-video view transform essentially does is map the larger ACEScg gamut/values (which the renderer works with) and its HDR (pixel values above 1) values to the traditional sRGB spectrum and SDR pixel values (pixel values range 0-1). This is why in ACEScg a value of 1 is greyish.
In any case, everything depends on the way you want the image to look…
Hermit, thank you very much!
With “the first variant (with Un-tone-mapped) is not really an “sRGB” workflow. The rendering space is still ACEScg”…you mean that does is map still the larger cgamut/values?
Thank you very very much.
I’ll make later the two your workflows on the same view. And share.
Nico
By the rendering space ACEScg, I mean that the renderer uses ACEScg primaries (the R, G, and B “limits”, aka gamut). How these values (which the renderer sees) are “projected”/“previewed” on the screen is then controlled through OCIO’s Display Device/View Transform. In other words, a few transformations of these ACEScg (large gamut) values are happening internally to get a color that the renderer sees to what you see on the screen, and most importantly, to be the correct color (red being red, not orange). It is similar to the logic from RGB to CMYK in printing, but in digital space only (and with extra steps).
Really thank you for the explanation!
I’ll make the two tests.
Thank you Hermit!
Nico
Hi Hermit,
Here the two tests with your setting…sRGB and ACEScg. Are they correct, right?
Just VRay Sun/Sky and Cosmos and both renders saved “automatic” in the window.
This is what I was saying, ACEScg by default seems wrong (I know it’s not) but looks super strong, too much contrast ect. It’s weird to me.
On YT instead I see the examples that they are not strong like this. More soft. So this is why also I was wondering if I was doing something wrong.
Thank you Hermit for the previous exaplanation and helping on this.
Nico
what you are comparing here is not quite comparable: in legacy gamma 2.2 3dsMax scene this would be equal to comparing render with Filmic Tonemapping and without.
ACES 1.0 SDR is your new Filmic Tonemapping.
Un-tone-mapped is just translating linear rendering space into display space (simple gamma 2.2 in legacy scenes) - this will never look good if what you are after is photo-like output.
Fix: use ACES 1.0 SDR, adjust camera exposure so render is exposed correctly (much brighter) and instead of sRGB display use Gamma 2.2 / Rec.709 display (as this is most likely the characteristic of your screen) or even Rec.1886 / Rec.709 video display (gamma 2.4) as ACES 1.0 display transform is known for its rather harsh contrast.
Hi!
Thank you for the explanation.
Do you suggest
the setting like this?
Nico
yes, but gamma 2.2 display also in colour management settings of 3dsMax (window on the left on your screenshot)
edit: these settings will transfer to VRay’s frame buffer automatically.
Ok, Thank you.
But I don’t see any difference from leaving sRGB or Gamma 2.2 as you said.
how it should look (for “most people” with “most screens”…) is:
sRGB display with ACES 1.0 SDR - darkest areas “too dark”, “crushed” blacks
gamma 2.2 display with ACES 1.0 SDR - much more detail visible in blacks/shadows although still quite contrasty look
Rec.1886 / Rec.709 video display with ACES 1.0 SDR - noticeably lifted shadows, this is sometimes used when image goes through post production to soften contrast of ACES 1.0
if sRGB and gamma 2.2 options look the same on your screen something is seriously wrong with the screen.
