ACEScg

[^Lele^]

Well, but color picking shows the Red in your brown, f.e., to be lower in the renders than in the texture (while G and B stay exactly the same, to the sixth decimal place).
The amount of gap changes depending on how intense the red is, and ranges from negligible (~1%), to quite tangible (~4%).

Just like in the attached image: that is *not* LWF.
My color has been reduced in magnitude and tinted, albeit slightly, by the time i am viewing it.
Notice V-Ray does it perfectly right: it remains a 1.0 float in red, with the other two components stay zeroed out.
But i do not live off color pickings only, i need to see a *perfect* correlation to my actions in the DCC app: this is a quasi-perfect one (and an attempt at a joke.).

I appreciate people work in all sort of ways (LUTs/CC applied, Log space, you name it.), and it's entirely their right to do so, but all i ask is to see a 1.0 be shown to me as 1.0.
Only the "Raw" transform does so (i.e. it is correctly a no-op), that i could find.
Everything else applies a look, and that is not ok with me personally, I'd want one view transform which behaved *exactly* like the sRGB LWF does, that is all.

I'm this hung up on this a little bit because I worked with Coca-Cola directly, many years ago in London, and god forbid i was *any* liberal with their hues.
I had to light that advert entirely with white light and little to no speculars, to ensure i was matching their reference, within well less than a 4% difference.
Doing it having to go through an unknown (and so far undocumented?) curve seems to me an added effort, for arbitrary perceptual gains (see the same thread linked previously, a few posts up.).

[JHorsley]

You can, if you really must, use the OCIO node in nuke to go from ACEScg to 'Utility - Linear - sRGB' which does get you exactly the values you are after however, i think this is then not really using ACES as it should be.


In this, you will find tile 5 is exactly matching the srgb values of the texture, even though tile 3 is very close, this is the difference between max's bitmap node doing the gamma correction.

You should also keep in mind that tests like this, with an emissive surface is not going to show the other differences of rendering in ACEScg space, you're essentially just using vray to transform the image in 3d space, all the colour results are exactly the same as using those OCIO transforms in nuke on the input textures.
I don't want to go into too much detail of how it benefits light bounce calculations and such as i'm not too sure on them myself.

I'm not exactly sure on your definition of LWF, but I take that to mean all light and colour math (rendering & comp) takes place in a linear space which is still the case with this ACES workflow.
If you haven't already you should read through this document, in particular from page 36 which describes a bit more of the when and why of using ACES.


Edit: Just saw the image, That red value in ACEScg (1,0,0) is impossible to view in sRGB space as it is outside of it's gamut so it needs to be adjusted in some way.

[^Lele^]

I asked those more prepared than me on this to check this out.
It's about time i let go of this.

[JHorsley]

I appreciate the probing, makes me double check my logic, I would like someone who has more knowledge on this to verify my understanding.