New OCIO colour management

[simon_kotowicz]

The V-Ray's implementation of the ACES colour management hasn't changed with 3ds Max 2024/2025 and works well. If you have used it previously and had correct results there is no reason to have issues with the newer versions. As of now the 3ds Max's implementation does not work well for network rendering and distributed rendering (we have informed them about the issue) so keep this in mind as well. If viewing your render output in other softwares than the VFB we have to take care and make sure we do not mismatch the colour spaces. An image rendered in ACES colour space must be monitored in ACES transformed viewer otherwise we will be seeing wrong colours.

Thanks Vladimir,

You are quite correct. I discovered that the problems lies outside of VRAY and 3DS Max.

I'd found out I had my Affinty pointing to the wrong OCIO file, which was causing the biggest problem. So that one's my mistake. I've also discovered a problem with Affinity, with a couple of people on their forum having the same problem. Although I'm using an OCIO file and ACEScg view transforms, etc, Affinity reverts back to ICC profiles for export to jpegs, tiffs, pngs, etc. It's this step that's causing me probelms. Its EXR In and EXR Out works correctly.

And piotrus3333 , my mistake again. I misread the UV editor. My brain thought you'd written Slate Editor. But that's all this run around I'm getting from my OCIO file and Affinity/Photoshop.

I'll take a look at the icc in the VFB approach. But, meanwhile, this demostrates the NEED for a thorough tutorial on ACEScg. I feel like I'm going round in circles some times and finding reading material or videos to watch to see if I've made a mistake is really tricky.

Thanks for all your help. Now, back to battling this ICC problem....

SImon

[piotrus3333]

VRay has detailed tutorial about using acescg colour space for rendering.
what you are looking for is tutorial about colour management in Photoshop and Affinity.
you have verry spotty OCIO support in Affinity and no support in PS. how are you trying to compare the images? what workaround are you using in PS? (as it is impossible to turn off colour management completely in 32bit colour mode for example)

what I would suggest is to do it in Natron - it is free to use, it has better OCIO support than Max, VRay and Affinity combined plus all colour management is very manual (just few nodes and viewer's display transform) so it is easy to see what is going on.

[Joelaff]

Duplicate post

[Joelaff]

When I load a BG image into the VFB in Max 2023 and set the input color transform of the background to OCIO sRGB - Texture then when I view the background with the display correction set to an input of ACEScg and an output of sRGB Display I find I have to set the View Transform to Un-tone-mapped to match my source (PNG) BG.

How should I be using the View Transform? What if I am using the Filmic Tone Map in the VFB (like Power Curve or Habel, etc.). Should this be used in conjunction with the View Transform. Or should I have the View Transform set to un-tone-mapped?

The final use is to take the ACEScg files into Nuke and composite them there. I realize that neither of these tone mappings are saved in the EXR files (and I don't want them to be, but they are good for previewing).

Speaking of Nuke is there any issue with using ACES 1.2 in Nuke 15.1 with the VRay ACEScg stuff?

In the VFB I am using the OCIO files from studio-config-v2.0.0_aces-v1.3_ocio-v2.1.ocio which seems to be the latest that will work in the VFB.

Thanks.

[piotrus3333]

When I load a BG image into the VFB in Max 2023 and set the input color transform of the background to OCIO sRGB - Texture then when I view the background with the display correction set to an input of ACEScg and an output of sRGB Display I find I have to set the View Transform to Un-tone-mapped to match my source (PNG) BG.

How should I be using the View Transform? What if I am using the Filmic Tone Map in the VFB (like Power Curve or Habel, etc.). Should this be used in conjunction with the View Transform. Or should I have the View Transform set to un-tone-mapped?

The final use is to take the ACEScg files into Nuke and composite them there. I realize that neither of these tone mappings are saved in the EXR files (and I don't want them to be, but they are good for previewing).

Speaking of Nuke is there any issue with using ACES 1.2 in Nuke 15.1 with the VRay ACEScg stuff?

In the VFB I am using the OCIO files from studio-config-v2.0.0_aces-v1.3_ocio-v2.1.ocio which seems to be the latest that will work in the VFB.

Thanks.

BG image most likely is not sRGB Texture but Output sRGB (or ACES SDR Video sRGB in ACES 1.3 configs).
https://forums.chaos.com/forum/v-ray...71#post1211571

Use view transform or filmic tonemapping, not both.

ACES 1.2 VS 1.3: https://forums.chaos.com/forum/chaos...-the-right-one

[vladimir_krastev]

Joelaff do you mind sharing a test scene? It is not very clear what are you doing. Are you loading a PNG image into VFB and then blending a background layer with it?

[Joelaff]

In furtherance of a potential move to ACES I was taking an existing project and converting everything over to see the differences.

In this project there are cg elements comped onto a live action BG. I had the BG as a png sequence for display in the VFB while composing the shot. So I needed to see how I would go about doing that when working in ACES. Since the VFB is now using an ACES display transform the VFB Background image needed an input transform in order to be displayed properly. This needs to match the original BG footage exactly in the VFB, as the BG plates are often already colored. So we need to get a good display of the CG over the BG without modifying the BG at all.

Note this is Max 2023, and everything is being set to use VRay’s implementation, not doing anything regarding Max.

I need to do some more experimentation, but perhaps getting the VFB background outside of the OCIO transform is the best. It would be nice to be able to use the OCIO SDR video tone mapping (with the Reduced Gamut Compression) on the CG , but not have this affect the BG.

I need to see if I can move the BG outside the display correction, or apply the reverse of the display transform (formerly called output transform) to the BG image so that the BG image is unchanged. Ideally we would not have to go to Nuke for this, but could still get OCIO transformed and tone mapped CG over an essentially unmodified BG.

Of course we could transform the BG into ACES before hand in Nuke, and this may be the preferred method. Just trying to figure out how to tie it all in to a cohesive workflow.

[Joelaff]

I think I see the issue. In the VFB the Background layer only permits you to select certain OCIO transforms. Utility only. There is no option to apply the view or output transforms (or the inverse thereof) to the Background image. Nor is there an option to bring the Background outside the Display Correction completely (this is at least somewhat understandable).

What I would like in a perfect world would be the ability to apply the inverse of the Display transform (including what you label the "View Transform" or "look") to the Background in the VFB so that when you apply Display Correction with the forward transform you get an unchanged BG.

You can see here in the area where you set the input transform for the BG there are no display transforms (or inverse display transforms), only the utility transforms or a selection of the different ACES spaces.



Then if you look at the Display Correction below you can see we have the look option:



For example if I apply this to the BG image in Nuke (from a Read node set to Raw above it) and then import it as ACEScg I get what I want:


Right as I was about to ask if there was some way to modify the ocio file for this I realized that I have moved into the territory of this thread:

https://forums.chaos.com/forum/v-ray...io-on-aces-1-3

I am guessing this can solved by creating a colorspace as @piotruss3333 did there, but I wonder if one can be created that includes the RGC as well, such that it works as described above?

I truly no nothing about these ocio files, as I have not taken the time to study them or read the docs. So I will also ask Marcius if this is correct to have src: ACES2065-1 here or if it should be ACEScg here? Or is OCIO smart enough to know that that tranform is actually from ACES2065-1, but no that we are dealing with ACEScg here, and do that conversion properly itself (I bet it knows this).

Also do those 1.0 caps in the RangeTransform cause any issues? It doesn't look like it (I am getting uncorrected values > 1.0 from the transformed BG).



Sorry this is now spread between the two threads. Very interesting topic.

[Joelaff]

It looks like I can just add the following to the ocio file, but I have no idea if this is correct:



(I have to use images because the forum objects to some of the code in the text versions).

So this actually seems to be a perfect reverse.

So then if I want this to apply to a texture I would have to use the OCIO nodes in VRay I suppose? But I was having trouble getting that to work.

Simply taking a VRayBitMap (Colorspace transform set to none, primaries set to raw) And piping that into a VRayOCIO set to By colorspace and:


did not work correctly. It looks wrong. (EDIT: See below for edit)

So, although I have the background doing what I want, I am not sure how I would deal with textures that need to be reproduced 1:1, like a BG image that need to be self illuminated to then refract through a transparent CG object.

I think that is the best case for explaining they next issue. Imagine a scene of stand in geo that is projection mapped with your BG plate. This geo is designed to refract and reflect in the CG element, and thus must match the source plate exactly.
What would be the method for carrying that through correctly? (Assume the use of self illumination).

EDIT: I got it to work!
The issue was that the Display Correction was defaulting to an input colorspace of ACES2065-1 rather than ACEScg. (Oddly this was not affecting the BG which had the OCIO turned on, but it was affecting the render.)

So now my self illuminated texture matches perfectly with the source image, using the node setup above. VRayBitmap full raw into VRayOCIO with the input Colorspace set to match the DisplayCorrection colorspace, which is my custom SDR Video Look RGC based on Marcin's already custom OCIO file.

Amazing, but true!

[Joelaff]

So with the setup described above I can work with the SDR Video RGC look applied in the VFB, assuming that will be the display transform (Viewer Process) in Nuke, and the output transform for delivery of non-ACES files.

I like that the rolloff of the SDR Video (with or without the RGC) can be used both in the VFB and in Nuke. IN the past we would approximate such rolloffs with Filmic tonemapping in the VFB, and the recreate a look in Nuke/Fusion. This way is a bit more WYSIWYG at the outset.

I guess I need to further modify the ocio file in order to allow a conversion from Rec709 /1886 gamma for source footage already in Rec709 to be used as a BG or as textures.

Please let me know if any of this sounds like an incorrect or poorly conceived approach.

[piotrus3333]

Your sRGB ACES 1.0 - SDR Video Look RGC colour space looks ok.
you can look into studio OCIO config sample for more options to customise.
and here:
Dash (colour-science.org)

VRayOCIO map is actually the most complete OCIO implementation within VRay.

[Joelaff]

Your sRGB ACES 1.0 - SDR Video Look RGC colour space looks ok.
you can look into studio OCIO config sample for more options to customise.
and here:
Dash (colour-science.org)

VRayOCIO map is actually the most complete OCIO implementation within VRay.

Thanks for the reply. I will study it further. I added the Rec709 versions as well, and that seems to be working well too.

Yes, I see the VRayOCIO node is actually really nice. If only it had an invert transform option like the Nuke node, that could come in handy. Though we have found a way around it with your trick of making a ColorSpace (awesome, BTW).

So what would be the preferred way to deal with a custom color that, say, a client specifies. RGB 200,100,50 or somesuch...? Use a VRayColor node set to sRGB Primaries, enter those values (or the float equivalents) and then use the same VRayOCIO node to transofrm those into the ACEScg colorspace, using the already tonemapped color space as the source?
Like this image repasted here:


Does that sound right? Would be nice if VRayColor had a ColorSpace setting, rather than just a color primaries setting.

I'll check out the link. Thank you.

[piotrus3333]

I guess I need to further modify the ocio file in order to allow a conversion from Rec709 /1886 gamma for source footage already in Rec709 to be used as a BG or as textures..

but Rec709 footage can be yet another can of worms - it might be done with some other display transform from Resolve, ARRI, RED, Sony or something unique. at some point it will be different enough that it will not look ok next to the rendered content when reversed with ACES transforms.
in perfect world those plates would be camera log encoded or in ACES AP0 (or AP1).

[Joelaff]

but Rec709 footage can be yet another can of worms - it might be done with some other display transform from Resolve, ARRI, RED, Sony or something unique. at some point it will be different enough that it will not look ok next to the rendered content when reversed with ACES transforms.
in perfect world those plates would be camera log encoded or in ACES AP0 (or AP1).

Hmmm. Not quite grokking this. Say we get the footage already in Rec709. Say it's already color graded too. So nothing needs to match a specific reference (like neutral color patches on a Macbeth chart). How would you recommend we handle that such that we could still use it in the self illuminated texture example above to be able to refract it through some CG elements, but have it match the (already graded) source (which the CG would likely be comped back over)?

Wouldn't we want to use the inverse of whatever output transformation we intend to use in the end?

[piotrus3333]

Thanks for the reply. I will study it further. I added the Rec709 versions as well, and that seems to be working well too.

Yes, I see the VRayOCIO node is actually really nice. If only it had an invert transform option like the Nuke node, that could come in handy. Though we have found a way around it with your trick of making a ColorSpace (awesome, BTW).

So what would be the preferred way to deal with a custom color that, say, a client specifies. RGB 200,100,50 or somesuch...? Use a VRayColor node set to sRGB Primaries, enter those values (or the float equivalents) and then use the same VRayOCIO node to transofrm those into the ACEScg colorspace, using the already tonemapped color space as the source?
Like this image repasted here:


Does that sound right? Would be nice if VRayColor has a ColorSpace settings, rather than just a color primaries setting.

I'll check out the link. Thank you.

recreating specific colour would never be easy. primaries conversion is just math but pixel from a logo displayed on srgb screen needs to be adjusted before it can be a diffuse texture. intensity, saturation. some real life colours just don't fit in BT.709 space - that is where ACEScg comes in.
The Pointer's Gamut - The Coverage of Real Surface Colors by RGB Color Spaces and Wide Gamut Displays - TFTCentral

colour in general is quite elusive - just spend 10 minutes watching all the "what colour is that?" illusion illustrations.
my approach is to create a PBR mat reasonably close and the rest is post according to needs. every display transform like ACES, ARRI, RED, three flavours of AgX, openDRT etc will render colours in it's own way.