ACEScg

[jandrewg]

My bad. I should looked through the documentation before I posted that.

[muoto]

From my understanding OCIO translations don't get baked into the images which is why you were getting the incorrect results with your .jpg

I am unclear on the step by steps on this, but you might be able to create a .cube LUT file for translating ACEScg to the RRT/ODT sRGB Output and then use the LUT and bake that in since the vray frame buffer does allow for saving the LUT into the image.

why not add a "save in image" like for the LUT ? so simple...no? Saving a 32bit exr, then re-applying the acescg conversion is a bit a hassle

[muoto]

From my understanding OCIO translations don't get baked into the images which is why you were getting the incorrect results with your .jpg

I am unclear on the step by steps on this, but you might be able to create a .cube LUT file for translating ACEScg to the RRT/ODT sRGB Output and then use the LUT and bake that in since the vray frame buffer does allow for saving the LUT into the image.

Hmm..anyone able to do that ? can't manage to get the deseired .cube file...

[muoto]

Here are the settings that seems to work fine...so if someone can get that translated to a good working .cube file to use with the vfb....he gets a beer (even a default vraysky looks so much nicer and subtle...)

[muoto]

Has there been any update on the ocio/acescg workflow ?

[jandrewg]

Sorry I haven't responded sooner. We put the workflow on hold till we upgrade to vray next.

[mouton007]

There is currently no UI option for the change, but you can type this into the maxScript listener:

renderers.current.options_rgbColorSpace = 2

And the whole V-Ray pipeline will turn into AcesCG, without the need to use custom maps and descriptors.

renderers.current.options_rgbColorSpace = 1

Will return V-Ray to sRGB.

Notice this is a render setting, so resetting the V-Ray settings, or opening a new scene, will have it return to its sRGB default.
It will however save correctly with a scene, so no need to change it after the first time.

HI Lele

how whould i know i am in AceswCG after putting this into the maxScript Listner and pressing enter

Regards
Mouton

[Morne]

Hi Mouton

If you just paste the bit without assigning anything (and press ENTER), it will return the current value

So if you just paste (and press ENTER):

renderers.current.options_rgbColorSpace

It will return either 1 or 2, depending on what you set it to

You can also press F11 to open the maxscript listener to a larger window to see what is output here when you do stuff or run scripts

[stevejjd]

Im very interested in setting up an ACECcg color pipeline but it's seems a bit complicated and could be worth waitintg untill its fully implemented into VRay. Also there needs to be some easy to follow guide on this subject.

[uforis]

I've been testing out ACES a bit, but I'm a bit mistified still regarding the VFB settings.

I've set it up this way:
Change VRay colour space to ACES using this command in Max script listener:
"renderers.current.options_rgbColorSpace = 2" for CPU
"renderers.current.V_Ray_settings.options_rgbColor Space=2" for GPU

In Material Editor:
sRGB 8bit jpg texture import with bitmap node > VRAYOCIO - "in" as Utlity sRBG Texture - "out" as ACEScg, using ACES 1.0.3 OCIO config.

The texture should now be in the ACES colour space unless I'm mistaken, and we should be rendering with ACES as well.

Now here's where I'm a bit confused still. I don't fully understand what's going at this stage, so I fiddled around until I got a satisfactory result, but I'm not sure this configuration is correct. I setup the VRay frame buffer OCIO settings section "Input Colour Space" to ACEScg, and "display device" (the only option for which is ACES), and a "View Transform" which I suppose you need to convert ACES back to sRGB or Rec 709, whatever your monitor is calibrated for, to view the colour accurately on your display, or to bake ACES back down into a sRGB image (which is now an option ). Are these transformations correct? I cycled through a lot of the input color spaces, however the only one that looked correct was setting it to ACEScg, which when I thought about seemed correct, as my textures were now in ACES and VRay was rendering in ACES.

As another follow up question, does it make more sense to approach working with ACES with linear sRBG textures? Should I be using 32 bit EXR diffuse maps?

I've probably done something wrong here, but the result was pretty nice. I did some minor exposure and curves adjustments, the raw render looked pretty grey, almost like a log image, which I suppose is the desired result for further grading later in the pipeline.

[JHorsley]

So I've been trying out ACES for a bit and I've got what seems to be the correct workflow to the best of my knowledge, at least for 3ds Max.
First thing as others have said, you should set vray to use ACEScg for some of it's built in maps (Temperature colour, Sky etc...):
"renderers.current.options_rgbColorSpace = 2"

Then you need to make sure your textures are properly converted into ACEScg space, this is simple enough to do but there are some pitfalls here you should be aware of.
The easy explanation, for sRGB diffuse textures, is to put a VrayOCIO node between your texture and the shader. It should be set as in: 'Utility - Linear - sRGB' out: 'ACES - ACEScg'.


The reason we use Linear sRGB as 'in' is that by default, when you create a bitmap in max it will be set to "automatic" gamma. For jpg and png files at least, this will convert the image data from gamma corrected sRGB to linear sRGB.

Probably the proper and more correct way is to always load bitmaps with the override of 1, then you get the raw data from the file and the OCIO node 'in' should then be set as 'Utility - sRGB - Texture' which does both the gamma and colour space transform.
This would also allow you to choose 'in' as 'Output - sRGB' which seems counter-intuitive but this is useful for textures that must be the same colour in the output as in the texture file, such as a logo with exact colours on an emissive plane.

You also only want to do this on actual colour images, maps like bump/normal, roughness, opacity, should not be converted as they are purely data and should be left as is.

Now to view your render properly in the framebuffer, make sure you disable display in sRGB space at the bottom.

Then enable OCIO with the input as 'ACES - ACEScg' and view Transform as 'sRGB' if you have a normal sRGB monitor.


And that should be it!
As for saving it into a regular image, your best bet is to save the raw image as exr then pipe it through something like Nuke with OCIO and set the image to 'ACEScg' space, and write with 'Output - sRGB' to your standard image of choice.
Photoshop can open the exr and if you assign the ACEScg space it is close but I think the Photoshop profile is outdated or something as it doesn't look quite right.
This method looks like it works in the few cases where I've tested it, I would like to know if anyone thinks this is wrong somewhere.
Hope this helps.

[^Lele^]

I found that the sRGB view transform (or rec709, for that matter) applies a contrast curve to the output, thereby breaking LWF.
You want the view transform to Raw, and the VFB's own sRGB correction active instead.
It's an easy test to do with textures, you can find more on this here.

[JHorsley]

Yes, it does apply a tone-mapping curve when using the sRGB, this is how ACES is designed to work as far as i can tell.
I did read through that thread and IMHO that is wrong.
I'm sure you don't want to be using the Raw view transform unless you have a monitor that is expecting ACEScg pixels because this will not perform any colour transforms, so on an sRGB monitor the colours will be on the wrong primaries.
For textures, it is not enough to switch the rgbcolorspace to 2, vray does not perform any colour space transforms on textures unless you use the OCIO node.
In that test you had there, i think the correct solution to get the exact colours as the texture, as i mentioned is to open the bitmap with gamma 1.0 override then pipe it through OCIO 'Output - sRGB' -> 'ACES - ACEScg' to then plug it into emissive/ self-illum.
All you had in that previous example was the bitmap node converting the image to linear sRGB, render outputting those values and then the framebuffer applying the sRGB gamma again, resulting in the original image.

[^Lele^]

Could i see a color pick from your method, please?
Against the same texture rendered for direct viewing under sRGB?

My contention is that the transform should be a no-op after all it's said and done, and i can't make it do so.
In fact, my sRGB transform is *not* invertible, and does *not* return 1:1 data.
It has enormous negative components, which are hidden by color clamping, and even the positive values return well skewed, as V-Ray interprets the image as ACEScg primaries, no matter how i transform it (that's the colorspace option at work.).

I have yet to see true scene and display linearity like under sRGB LWF.
Given the object is lighting, not comping, i still fail to see the benefits of a skewed approach.
Unless, of course, the whole issue rests with me alone (but i am not qualified enough, clearly, to decide so for myself. Hence me asking for color picks from you.).

[JHorsley]

Ok, I've thrown together this with a bunch of different tests:


The texture i'm using here is from https://github.com/colour-science/co...lorChecker2014
So, for the inputs at the top left, The first is the sRGB exr, saved straight to a png, this is your normal sRGB texture.
Right of that you have the ACEScg exr, this one as shown was saved through nuke with ACES 1.1 OCIO to an sRGB png with the 'Output - sRGB' transfer. This is what I'm considering to be the correct look for this texture in an ACES based workflow.
I have underlined the tiles in the renders that match these "ground truth" colours within minor rounding errors.

Underneath that I have a screenshot of the VFB with the material setup for each tile.
1. this should be the goal for a proper ACES workflow, using an ACEScg texture as is, no conversions.
2. this is standard sRGB workflow, a sRGB png texture, converted to linear sRGB by the bitmap node and straight into the shader, no conversions.
3. my suggested workflow for easy ACES setup, the now linear sRGB is converted to ACEScg with the OCIO node set as 'Utility - Linear - sRGB' to ACEScg.
4. the workflow for getting exact sRGB colours back from the ACES conversion. an sRGB png image with the gamma set to override 1.0 so it stays in sRGB space, not linear sRGB. Then through an 'Output - sRGB' to 'ACEScg' OCIO.
5. essentially the same as 3, except the OCIO set to 'Utility - sRGB - Texture' which converts the sRGB to ACEScg in one step.

On the right you can see 2 images and the nuke tree used to make them.
The left render is done with ''renderers.current.options_rgbColorSpace = 2" ACES and the right with "renderers.current.options_rgbColorSpace = 1" sRGB.
As you can see, the only difference is the colour of the 3000k light, textures are completely unchanged!

The top is with standard sRGB nuke, the only texture that is correct here is what you would expect, tile 2, normal sRGB texture usage.

The bottom is with ACES OCIO colour managment in nuke, and you can see that tiles 1, 3 and 5 now match the ACES texture which i'm considering to be correct.
These match exactly what you see in the VFB with my suggested settings.
Tile 4 is also matching the sRGB texture which i think is what you were hoping to see.
I hope this all makes sense.