I switch to OCIO and the speed drops 4 times

[Yuriy Bochkaryov]

Hi all.
I'm trying to study OCIO in 3d max 2024.2 and Corona 11 - since I've been waiting for this for a very long time, but after I switch the mode from Gamma Workflow to OCIO, the rendering speed drops 4 times
Gamma - 00:49
ACEScg - 02:41
Rec709-sRGB - 02:30
I don't change anything in the scene, only the color manager parameter, why is this happening?
Changing the color space should not affect the rendering speed, it is the same rendering but in a different color/light range
Can anyone explain why this happens?
and what is the correct way to use OCIO + Corona in 3D Max?

I also noticed that the rendering result may change, I switch to OCIO, do a test render, set up tone mapping in VFB using Linear to Cineon Log.LUT, for example, save the scene, open it in another 3dmax on my PC, start rendering and the pictures are different
2 3Dmax rendered the same scene, but the pictures turned out different
I restarted the scene on the first 3D max and then the picture also changed, it became similar to the second 3D max
It turns out that I saw the wrong picture in the first 3D Max, VBF showed me the wrong picture, and to fix it, I had to restart 3D Max

it seems that OCIO support in Corona 11 is not fully implemented and is very crude, which is very disappointing

[Yuriy Bochkaryov]

Hm
I always use texture maps through MAX Bitmap, now when I tried to convert MAX Bitmap to Corona Bitmap, the rendering time returned to normal, it became normal again

if I use OCIO and Max bitmap then I get - 02:54
  if I use OCIO and Corona bitmap then I get - 00:38, but at the same time the color of the textures changes, as well as the color of the HDRI map - this can be seen from the color of the sky, and for some reason the displacement map looks different

[James Vella]

Did you convert all your textures to the color profile?

[James Vella]

Its been a few years since my last deep dive on this topic but from memory you need to do some transforms for your srgb, linear and aces textures.


I would just re-read this article to get my head around it again since after getting it working in Vray with a basic scene, I decided to go back to the gamma workflow.
https://chrisbrejon.com/cg-cinematography/chapter-1-5-academy-color-encoding-system-aces/

[Yuriy Bochkaryov]

Did you convert all your textures to the color profile?

no, I didn’t change it, I just changed the color profile
but since the conditions are the same, only the color profile has changed, then there should not be such problems in rendering speed

[James Vella]

I thought you said you fixed the render speed?

I was just referring to the textures comment. In short (from memory) you need to convert all your inputs/outputs to the correct color space otherwise its not going to look right. Same goes with any linear textures (basically anything other than diffuse, as they both need different IDTs).

From my perspective, working in ACES (at this current point) is fine when doing film work and you need to match plates or color spaces, if you are doing archviz then I dont really see the payoff for all the work involved. I could be wrong, but after playing with it for a few years it was just too much work considering how archviz pipelines are setup to justify the switch.

Edit:
For me, until theres a 1 click approach to do all the conversions for me I wont bother with it again. Unless ofcourse I get some jobs on that need to match specific color workflows, otherwise whats the point when Corona can render photo-realistic images in srgb and keep the workflow simple and backwards compatible.

I dont work with archiving projects for re-release on new mediums, ACES doesnt automagically make your renders better, its just a wider range to work with, and if you dont intend on using it (which most of the time ends up in Photoshop 99%) of the time whats the point?

[Yuriy Bochkaryov]

I thought you said you fixed the render speed?

I was just referring to the textures comment. In short (from memory) you need to convert all your inputs/outputs to the correct color space otherwise its not going to look right. Same goes with any linear textures (basically anything other than diffuse, as they both need different IDTs).

From my perspective, working in ACES (at this current point) is fine when doing film work and you need to match plates or color spaces, if you are doing archviz then I dont really see the payoff for all the work involved. I could be wrong, but after playing with it for a few years it was just too much work considering how archviz pipelines are setup to justify the switch.

Edit:
For me, until theres a 1 click approach to do all the conversions for me I wont bother with it again. Unless ofcourse I get some jobs on that need to match specific color workflows, otherwise whats the point when Corona can render photo-realistic images in srgb and keep the workflow simple and backwards compatible.

I dont work with archiving projects for re-release on new mediums, ACES doesnt automagically make your renders better, its just a wider range to work with, and if you dont intend on using it (which most of the time ends up in Photoshop 99%) of the time whats the point?

I'm interested in a wide range of brightness
I know that you need to convert textures for correct display, but even if you don’t convert textures, they shouldn’t slow down the rendering, or look different every render, as if the color profile changes randomly, it should always be either consistently incorrect or consistently correct , but not like different, random color profiles every time the scene is loaded, there should be stability, but there isn’t and so far I don’t know what the problem is

[James Vella]

I'm not sure if Corona supports the 3dsmax new color management system. Maybe someone else can chime in on that. Ive only used the Vray built-in OCIO  since its fully supported (within Vray). From texture input to display to output. I'm sure that's why there is an ACES OT tonemapping curve for now, just a hunch.

I'm interested in a wide range of brightness

Well you have plenty of tools for that, highlight tone-mapping operator, rendering to 16/32bit linear exr (adjust in post), adjusting your renders to work well with the scene exposure, curves etc.

Can you share a video reference as to what you mean exactly by "I'm interested in a wide range of brightness"?

[Juraj]

Interesting report, I am glad I didn't move to 2024 yet. I am really looking towards color management, but if this is the current state between Max CC and Corona.. that's not good.
Hopefully this can help with more research and fixing by team.

2James: Max 2024 CC (to manage input/output, effectively just adds CC on top of basic Gamma 2.2. only), Corona's internal rendering Color Space (hidden within Devel/Debug settings) and ACES OT tonemapper are 3 completely unrelated things right now. They don't relate, or connect in any way. The ACES OT has nothing to even do with ACES color pipeline, it's just unrelated tonemapper.
And every possible combination (however weird, like sRGB input, AdobeRGB rendering space, ACEScg Output, etc..) should nonetheless produce fully stable, always identical result.

Corona has also never been rendering anything in basic sRGB (Vray was though, since Vlado had some strange argument with it..), it had this weird generic "WideGamut" color-space, which can now in DevelDebug change to either more industry-common standard AdobeRGB or ACEScg, neither will produce much different outputs. It's just different arbitrary limit to what space the calculations will run in.

Max 2024 CC will be most beneficial for correctly displaying colors on high-end displays, like in DCI-P3 (which all modern HDR supporting monitors offers, market-wide it defeating AdobeRGB, mainly because of Apple's support behind), offering seamless colors between Max and Photoshop (or other post-application). Right now you either downgrade your monitor colors to prehistoric sRGB, or Max will show wildly different colors than CC-managed app like Photoshop (hence 100 threads "why is my framebuffer different then image I opened in PS").

[James Vella]

2James: Max 2024 CC (to manage input/output, effectively just adds CC on top of basic Gamma 2.2. only), Corona's internal rendering Color Space (hidden within Devel/Debug settings) and ACES OT tonemapper are 3 completely unrelated things right now. They don't relate, or connect in any way. The ACES OT has nothing to even do with ACES color pipeline, it's just unrelated tonemapper.
And every possible combination (however weird, like sRGB input, AdobeRGB rendering space, ACEScg Output, etc..) should nonetheless produce fully stable, always identical result.

Actually it looks a bit more complicated then that by first glance. Didnt really play with it much but from memory when doing an ACES OCIO test with Vray it looks similar, you need different IDTs for srgb, linear and aces textures (Input Textures Rules). I remember with vray you could always add the srgb or aces suffix to textures for automatic rules instead of doing it manually... which is still manual if you dont have the pipeline lol. You can see in the 3dsmax 2024 Color Management section rules for this, also you can switch from gamma to cc workflow which instantly changes even the UI colors in 3dsmax (although I dont have a monitor profile other than srgb so probably explains the shift).

Color Management Mode (Gamma or OCIO):


Input Textures Files (Rules):


To be honest after doing the whole rabbit hole experiment I figure its not even worth it for my workflow at this point until it becomes automatic. Even the Vray method is not automatic enough without having some extra tags in each image or something that can be automatically configured, maybe if you used exr textures or something but again I lean on simplicity and standard workflows.

And yes I understand the ACES OT tonemapping checkbox is just a curve, my point was regarding other methods to achieve similar results without overcomplicating things. But each to their own I guess.

Edit:
"should nonetheless produce fully stable, always identical result." Yes, you are correct. The inconsistency here is odd, but I seen in another thread by the OP that the Corona team are looking into that, possibly a bug.

[piotrus3333]

ACES OT is not just a tonemapper / curve.
if you do not trust the official docs have a look - this is bottom part of what ACES OT transform does:

[James Vella]

Can you share a link to the "official docs"?

All I found was this which was 2 sentences:
Note that highlights and color information in them is better mapped with ACES OT enabled and the overall image balance is better.
You may also need to adjust the exposure and tones after enabling ACES OT to compensate for them in some cases.

[Aram Avetisyan]

Hi,

To shed some light on this, here is our Color Management article. The theory is also covered for our users to better understand the whole topic, interconnected parts and expect more "expected results", but feel free to skip it and go to the very bottom if the Corona related technical part is needed only:
https://support.chaos.com/hc/en-us/articles/20474209561617-Color-management-in-Corona-for-3ds-Max

In short, the Frame Buffer default settings is not supported, so in OCIO workflow, the results in VFB are always linear. Latest V12 daily build has Gamma Operator added for this. The color difference (no matter the settings) are not expected (https://forum.corona-renderer.com/index.php?topic=41817.0, no reply yet from OP), given that everything is the same, nothing changes, the scene is opened and rendered, closed, then opened and rendered - the results must be the same. This will be tested further.

The speed difference is drastic and shall be investigated too. For this, again, please attach the sample scene where we can do some tests.

[piotrus3333]

Can you share a link to the "official docs"?

All I found was this which was 2 sentences:
Note that highlights and color information in them is better mapped with ACES OT enabled and the overall image balance is better.
You may also need to adjust the exposure and tones after enabling ACES OT to compensate for them in some cases.

https://docs.chaos.com/display/CRMAX/Tone+Mapping+Operators

[James Vella]

https://docs.chaos.com/display/CRMAX/Tone+Mapping+Operators

Care to elaborate?

From the docs I see:
Applies approximate ACES Output Transform, which consists of Reference Rendering Transform (RRT) and Output Device Transform (ODT). Value range: from 0 to 1.

How is this different from a curve?