(Closed) [HOU-1726] Acescg primaries mode in Houdini

[Muhammed_Hamed]

docaml You need to use the OCIO tab in the file node, for each of your image textures(or the OCIO node)
>> For sRGB texture you use, Utility - sRGB - Texture like this,



>> And for textures that are made in Linear - sRGB like HDRIs you would use Utility - Linear- sRGB
You will need to do that for all of your textures, except normal maps and the textures that are used as multiplier(like bump maps, reflection roughness, reflection glossiness...etc)

>>You will need to go to color management in Vray ROP Parm and switch color space to ACEScg
(as far as I know this option takes care of things like temperature for lights or Vray's Sky color, so the input would be in ACES, but Vray itself is mostly colorspace agnostic)

>> Now in the Vray frame buffer you will need to turn off the sRGB curve

[Muhammed_Hamed]

Ideally you want your textures in ACEScg before Vray, because using the OCIO node affects RAM usage and rendering speed depending on how big your project is

[docaml]

Thank you Muhammed_Hamed, I have not noticed OCIO tab in image reader (haven't downloaded recent nightlies). I've used VrayOCIOtex after every color image before, with the workflow you kindly explained. But, as I understood, here is the point about primaries, and if I understood well, primaries are those color pickers in any node, and they are not textured with external files, temperature, hair shader colors, sun and sky colors, etc... So, I can not figure out, how to transform that colors to ACES?
Best,
Doca

[ronald_a]

use a user color —> ocio node—> plug it into your shader‘s inputs

[Muhammed_Hamed]

Thank you Muhammed_Hamed
primaries are those color pickers in any node, and they are not textured with external files, temperature, hair shader colors, sun and sky colors, etc... So, I can not figure out, how to transform that colors to ACES?

For the color pickers, Vray doesn't care what the RGB numbers mean. You need this transform only for Vray features that deal with spectra, things like light temperature, camera white balance as temperature, physical sun and sky. Other than that, it doesn't matter what color space Vray uses(ie. Vray is color space agnostic)

And from memory that option in Max/Maya was meant to solve the transform issue with the spectral features..
renderers.current.options_rgbColorSpace = 2 Which the devs just added to Vray For Houdini
From what I understand you shouldn't use a user color + OCIO node for conversion, it is not really needed. The ACES conversion is for 8 bit textures like Albedo maps(which you use utility-srgb-texture) or linearised texture maps that has its primaries in sRGB(which you would use utility-linear-sRGB)

[ronald_a]

For the color pickers, Vray doesn't care what the RGB numbers mean. You need this transform only for Vray features that deal with spectra, things like light temperature, camera white balance as temperature, physical sun and sky. Other than that, it doesn't matter what color space Vray uses(ie. Vray is color space agnostic)

And from memory that option in Max/Maya was meant to solve the transform issue with the spectral features..
renderers.current.options_rgbColorSpace = 2 Which the devs just added to Vray For Houdini
From what I understand you shouldn't use a user color + OCIO node for conversion, it is not really needed. The ACES conversion is for 8 bit textures like Albedo maps(which you use utility-srgb-texture) or linearised texture maps that has its primaries in sRGB(which you would use utility-linear-sRGB)

hmm, interesting. it would be good to hear from somebody from chaosgroup what the correct workflow with picked colors is. while vray may be colorspace agnostic, it would still need the correct input to produce the correct output for aces (especially if you need exact color results for logos etc.).

[Muhammed_Hamed]

(especially if you need exact color results for logos etc.).

If you need the exact same color, you would need to use your ODT as IDT to know the scene referred values(ACEScg)
This is because the RRT and ODT processes use tonemapping that affects what you see in the VFB

The example is from an article by Chris Brejon, he did an amazing job explaining this(I recommend to read the whole article)
https://chrisbrejon.com/cg-cinematog...rtodt-workflow

Lets say your client gave you a color in PS for a logo, and you want an exact match in your render
The color is 211 97 97 (you want this pixel info in your VFB when you set OCIO view transform to sRGB)
You would need to convert this color to None-Linear sRGB using this website
http://davengrace.com/dave/cspace/
It will give you 0.8274 0.3803 0.3803
Now you would use these values in a user color node, then use an OCIO node with these settings


Now if I got to my diffuse filter render element, I get the requested color 211,97,97
(I used a temperature Vray node, with color mode.. it works the same way as user color with couple more useful options)
And you can do the same steps in Nuke with an OCIOcolorspace node to get the ACEScg values.

Maya makes this easier to understand, because the color editor(color picker) uses whatever is set in your OCIO config.
By default the color editor is set to Output Rec.709 and to make it act like Houdini you can edit the OCIO.config like this


So now when I launch Maya and load my OCIO config I get this in the color picker, see the mixing color space set to ACES - ACEScg


This way it acts exactly like Vray for Houdini, which also shows that these are the real ACEScg values that Vray uses for calculation. Color picking in ACEScg is very helpful and allows you to get the most out of wide gamut rendering

[Muhammed_Hamed]

it would be good to hear from somebody from chaosgroup what the correct workflow with picked colors is

I prefer to pick the colors in ACEScg(unless I have a logo color to match like what was explained above) because picking colors in ACEScg you can reach very saturated values and make the most out of wide gamut rendering.
But I don't think there is right or wrong here, someone else might prefer to pick colors in sRGB then convert that with an OCIO node
This is Modo's color picker, which is a good way to get the none linear sRGB values with an option to change display to integer like PS

[ronald_a]

thanks @Muhammed_Hamed. That was very informative. Another question: (and there might be no right or wrong here):say I have a colortexture (to be used in diffuse) and I want to colorcorrect it using a colorcorrection node. Would you rather disable ocio on the image node --> colorcorrect --> ocio node --> plug in OR leave ocio enabled on the image node --> colorcorrect --> plug in?

[Muhammed_Hamed]

ronald_a

I say the OCIO tab or an OCIO node directly after your bitmap, few reasons for that,

-The conversion makes the bitmaps darker, which will help you quite a lot(when you use debug shading on the color correct node to play with saturation or brightness of the map) .. And in ACEScg you would feel like smallest steps in the color correction node make a big visual difference on your material, almost like a different rendering engine at this point.
-I usually have Triplanar node after a diffuse bitmap, and I would copy part of the diffuse setup to other places. I wouldn't want to add an OCIO node again after copying.
-And finally I remember that the devs recommend using the Triplanar map directly after the bitmap, not after a color correction node(to have the best performance possible) Read Vladimir Nedev's comment number 9 in this post,
https://forums.chaosgroup.com/forum/...pports-bitmaps

And you probably heard how the OCIO node have a big impact on performance overall. So better be safe using it after the bitmap directly at the start of the calculation.
Finally remember that you typically want to have your textures in ACEScg before Vray, for the best performance possible. Couple of the OCIO nodes are not an issue, but when you have hundreds of maps it will affect RAM usage and rendering speed.

[Jim Meston]

I have a *.bat file launching Houdini with an OCIO environment variable. Using COPs to convert the textures and hdris to ACEScg. Everything just seems to work, color pickers automatically sort themselves in color settings to use OCIO.
Using Utility - sRGB - Texture for srgb data and Utility - Linear - sRGB for linear colors (HDRI's) etc. No conversions on image data (normals, displacement etc).
Doing the conversions in COPs is probably more efficient as far as I can tell (after reading not to do inline conversions in the shader due to terrible slow speed on high res hdris etc)
Vray can just take the output node from COPs, doesn't even need the op:'path'.

[Gosho.Genchev]

Hey, Jim,

that's neat. Note that when using op path to a texture in COPs, the pixels are baked into the VRScene so a lot of very large textures will produce a fairly big file on disk.

[Jim Meston]

Hey thanks Gosho.
Are you suggesting it more efficient to convert in PS and reference in the vray image nodes?
I really don't want the answer to be yes.

[bdancer]

There is absolutely no way to re-implement COP nodes logic on V-Ray side, so the only way to make COP work is to bake data out of COP into the vrscene file.
V-Ray has OCIO texture node as well as OCIO parameters on "Image File" node for convenience.

[Gosho.Genchev]

In addition to what Andrei said, and take this with a grain of salt - I'm saying the VRScene size will be larger. If that doesn't concern you, you may as well reference the COP nodes. I haven't done any performance tests to compare rendering of baked textures vs referenced from disk so I've no clue if memory / render times will differ. I merely wanted to inform you what happens under the hood so you're not caught off guard down the line.