More OCIO/ACES questions

[tmbarker531]

Hi, I'm sorry but I am adding yet another post about correct ACES workflow...I know there are already many, I think I've read them all. I'm hoping to get some general guidance from some of you who seem to have a lot of experience with rendering and compositing in ACES across multiple softwares.

General context- I mostly work on short photorealistic animations that are often comped into real video footage, the real footage ranges from iPhone videos to professionally shot video. I work in 3ds Max 2025 and render these animations on chaos cloud and do all the comping work in After Effects. Last spring I decided to switch to a workflow rendering out EXRs instead of 8bit jpegs or pngs, it's been very useful for some of the more complex compositing situations but it's also introduced more issues. This is when I started learning about OCIO and ACES and have had issues/questions on and off since then so....here is a compiled list of questions in an attempted clear order.

1. What is the general consensus on using 3ds Max's color management settings OCIO mode and setting the rendering color space there to ACES? It seemed to me like a lot of people don't recommend it and still opt for setting this to gamma/2.2 and vray's color managment to ACEScg. Does anyone suggest using max's OCIO mode? I have been using it and am not sure if that's where some issues I'm having are coming from
2. If you do suggest using max's OCIO mode, does anyone change the global defaults in the displays and views roll out to something other than ACES 1.0 SDR-video? I was setting this to un-tone-mapped because it was the only way I could get textures in the material editor and their preview windows and the frame buffer to all appear consistently. When set to the defaults I could never get vraybitmap textures to appear as they look in photoshop or any other image viewer even when the color space transfer function is set to sRGB and sRGB primaries in the bitmap settings.
3. What are the benefits and reasons for using a custom OCIO config file? Where do you find these files and what would you recommend for the work I'm doing if using something other than the 3ds max default?
4. When saving images for my situation/workflow, I have the "save in image" under view transform in the VFB unchecked and the color management in the save image dialog box set to no conversion, is this correct?
5. A test I keep performing- I would like to load an srgb image into a vraybitmap, load that into a vraylightmat and apply it to a plane, render an image of that plane and save out that image- i keep trying to find a way where the image looks identical at every stage (also the look of the image in the viewport
6. I know AfterEffects is not the best, but I don't have a clear grasp of the pros/cons of switching to Nuke or Davinci Resolve. AfterEffects works with an ACES workflow but something I've found very strange is using curves adjustments in the 32bit comps, they don't behave naturally at all and sometimes I find it extremely hard to control and edit the footage which then makes me question the point of rendering in 32bit in the first place. I also use to use the matte choker quiet a bit in AE and its useable on 32bit footage...I know this isnt an adobe forum but looking for advice
7. Regardless of the compositing software you use, do people typically render mattes and alphas in 32bit as well?

Thank you in advance to anyone who can help!

[piotrus3333]

1. what is your delivery colour? rec709? DCI-P3? camera specific space?

ocio colour management in 3dsMax works. there are same limitations listed on autodesk's site.
two renders, the difference is rendering space, setup through 3dsMax in colour management options, acescg and bt709. scene is setup with VRayBitmap and VRayColor maps, most colours described in acescg space, default 3dsMax ocio config with srgb display aces video display transform.

[piotrus3333]

global illumination:

[piotrus3333]

2. aces display transform is based on "cinematic look" - saturation is behaving more like film. it will never match a bitmap displayed on a screen next to frame buffer. you can use some other display transform more suited to the look you are after or try "untonemapped" view with Filmic tonemap - Power Curve below for example.

[piotrus3333]

3. different display transforms. scenario with strong saturated spotlight (full red in acescg):

default current max, aces 1.3 with gamut compression, default blender 4

[^Lele^]

The blue cast of ACEScg is omnipresent and personally really disturbing.
You will also lose LWF and any chance of matching sRGB material accurately.

Unless you've done extensive quantitative analysis, and you're fully aware of where your output will land, and that you'll be able to correct it in the direction you'll need, I personally wouldn't recommend ACEScg for general use, in a world largely dominated by sRGB display devices and input references.

Ofc, if it's just about taste, then hey, it looks more saturated.

[piotrus3333]

The blue cast of ACEScg is omnipresent and personally really disturbing.
You will also lose LWF and any chance of matching sRGB material accurately.

Unless you've done extensive quantitative analysis, and you're fully aware of where your output will land, and that you'll be able to correct it in the direction you'll need, I personally wouldn't recommend ACEScg for general use, in a world largely dominated by sRGB display devices and input references.

Ofc, if it's just about taste, then hey, it looks more saturated.

rendered with the same camera so it is just the difference between white points: D60 vs D65. easy to match.
LWF is maintained and comping that with srgb material is not difficult even in photoshop.

but I have to agree - if your world is predominantly srgb display and you don’t have an easy way of converting older assets (specify transfer function and colour space for every texture or colour input) - acescg is a hard sell.

edit: unless rendering lasers is your cgi niche.

[^Lele^]

Only scene reference is maintained (that is what V-Ray does, and what you may pick as raw values.).
The sRGB view transform takes care of butchering that, sadly.
Try with a 0.5 gray, scene referred, and pick it for viewing in sRGB and ACEScg: while both pick 0.5 in raw, sRGB is correctly picked display-referred (click on RAW in the VFB, so that it says "RGB) at ~0.73, ACEScg at ~0.65.
That's LWF out of the window.

If you stop to think about it, it's only logical: the display device is smaller for Gamut than the color space used for rendering, so it needs fitting, which means compressing tones, severely non-linearly.
Unlike in a fully sRGB pipeline.

The cast, for me, has always been a side-effect of the ACES color spaces.
ACES plain, 12 years ago, had a pink cast. ACEScg a blue one.
I could very well have been doing something wrong back then, and now, however.

[piotrus3333]

gamma transform (0.5 scene to 0.73 display) can not be seriously considered a display transform in 2024. even good old Reinhard with gamma on top (very dear to me, this is how I was usually seeing scenes for almost a decade) is a thing of a past.

Hable filmic tonemapper - can you perfectly invert it back to sweet linear? i think so, should be doable (same gamut, just some magic math and done).

but what is super easy to invert? (well, maybe not with default autodesk ocio config)
aces display transform.
apparently this was important during design. so important this is still in aces 2.0.

and the pink one from long ago I think might be the one that is apparently still in use by some colourists favouring it for being closer to film look then more recent iterations.

anyway. display transform is a matter of taste, aces for me is bit too dark in the shadows.
but acescg space does what it is expected to do pretty well. not that BT2020 wouldn’t do the same but oh well. just standards to accept, nothing new.

even new wide gamut from arri (awg4) is very similar to acescg. although without the wierd whitepoint what needs to be noted.

[piotrus3333]

corrected white balance (in VRay cam):

[piotrus3333]

tmbarker531

4. yes, this is correct

[^Lele^]

gamma transform (0.5 scene to 0.73 display) can not be seriously considered a display transform in 2024. even good old Reinhard with gamma on top (very dear to me, this is how I was usually seeing scenes for almost a decade) is a thing of a past.

Hable filmic tonemapper - can you perfectly invert it back to sweet linear? i think so, should be doable (same gamut, just some magic math and done).

but what is super easy to invert? (well, maybe not with default autodesk ocio config)
aces display transform.
apparently this was important during design. so important this is still in aces 2.0.

and the pink one from long ago I think might be the one that is apparently still in use by some colourists favouring it for being closer to film look then more recent iterations.

anyway. display transform is a matter of taste, aces for me is bit too dark in the shadows.
but acescg space does what it is expected to do pretty well. not that BT2020 wouldn’t do the same but oh well. just standards to accept, nothing new.

even new wide gamut from arri (awg4) is very similar to acescg. although without the wierd whitepoint what needs to be noted.

Linear Workflow is unchanged to this day, under sRGB, and the only thing that's guaranteed to work with sRGB display devices.
That's Maths, not preference (and sure, we approximate the matrix transform for sRGB with a gamma 2.2 in natural language.).
That you would add a tone compressor on top, thereby breaking LWF, is your prerogative, but not the recommended workflow (never was. ) to maintain LWF.
To be perfectly clear on what i mean by LWF: you set a light to a specific value, and it looks like X, you double the value, and it looks like X*2, exactly.
Unattainable with anything but a linear workflow: any form of skewing (tonal compression, s-curves, tone mapping, however you want to call them.) breaks the relationship.

The pink cast i speak about was when trying to convert a white 1.0 in sRGB to a white 1.0 under ACES.
Thankfully the compositing supervisor on the job wasn't silly, and we didn't go that way.
Nothing at all to do with Film look or preferences: it was bad maths for CGI.

The blue cast is very evident also in the color corrected material: the bounced lighting won't clean up, as it's cumulative an effect.
It may disappear if viewed through the proper display device, although what would then happen to the rest of the whites now showing as white is a bit of a mystery.

There is nothing invertible going into ACEScg and expecting to come back to sRGB: It's a wider gamut that doesn't fit the smaller one, so at best you can squeeze the big into the small, lossily.
ACEScg's sRGB ODT shape is unknown by design, but what is known is that it was built perceptually, not with numbers in mind, so it's not invertible at all (and invert to what, exactly? Raw data? Then it's enough to not apply it. It's an ODT, not some CC LUT.).
The above is fairly easily findable in aces central, as people asked, and were told.

[piotrus3333]

5. so your test is like creating a lightbox. you have an image on your display but before it gets into VRayLightMtl you need to convert it into linear data in your rendering colour space.

same scene with two VRayLightMtl planes:

[piotrus3333]

tmbarker531

5. how to get an image from your display space into appropriate rendering space (lightbox scenario, old school archviz self illuminated cards with scenery etc). in VRayOCIO node use display transform used for creating said image but you can simplify things and assume it is the same one you are using. VRayBitmap is set to None/Raw as we do the transform manually. if your rendering space is not acescg pick the correct one for you. default autodesk ocio config will not let you do it in that way - use this one for example: https://forums.chaos.com/forum/chaos...ne#post1211568
aces display transform, when inverted, creates float values of a bit over 16. this might not always be enough for sky etc. be aware of this and correct when needed.

[piotrus3333]

Linear Workflow is unchanged to this day, under sRGB, and the only thing that's guaranteed to work with sRGB display devices.
That's Maths, not preference (and sure, we approximate the matrix transform for sRGB with a gamma 2.2 in natural language.).
That you would add a tone compressor on top, thereby breaking LWF, is your prerogative, but not the recommended workflow (never was. ) to maintain LWF.
To be perfectly clear on what i mean by LWF: you set a light to a specific value, and it looks like X, you double the value, and it looks like X*2, exactly.
Unattainable with anything but a linear workflow: any form of skewing (tonal compression, s-curves, tone mapping, however you want to call them.) breaks the relationship.

The pink cast i speak about was when trying to convert a white 1.0 in sRGB to a white 1.0 under ACES.
Thankfully the compositing supervisor on the job wasn't silly, and we didn't go that way.
Nothing at all to do with Film look or preferences: it was bad maths for CGI.

The blue cast is very evident also in the color corrected material: the bounced lighting won't clean up, as it's cumulative an effect.
It may disappear if viewed through the proper display device, although what would then happen to the rest of the whites now showing as white is a bit of a mystery.

There is nothing invertible going into ACEScg and expecting to come back to sRGB: It's a wider gamut that doesn't fit the smaller one, so at best you can squeeze the big into the small, lossily.
ACEScg's sRGB ODT shape is unknown by design, but what is known is that it was built perceptually, not with numbers in mind, so it's not invertible at all (and invert to what, exactly? Raw data? Then it's enough to not apply it. It's an ODT, not some CC LUT.).
The above is fairly easily findable in aces central, as people asked, and were told.

I don't think I follow. LWF is LWF no matter the gamut. but sure, you go from one to another and issues may surface at some point.
is this what what we are discussing?:
RGB Saturation Gamut Mapping Approach and a Comp/VFX Perspective - Discussions - ACESNext / VWG – Gamut Compression/Mapping - Community - ACESCentral