When leaving the Auto RGB Primaries option OFF, how does V-ray interpret any VrayBitmaps with their Color Space set to ‘Default’ ?
also, the ‘Auto RGB primaries’ option only does anything if it detects the relevant tags on the end of the filename, correct?
Thanks
VRayBitmap’s default RGB primaries option tells V-Ray not to perform color transformations unless a relevant tag is present in the filename and the Auto RGB Primaries option is active.
Hi,
whats the propper filename tags when using aces. Should be just _acescg or _raw right? Bu I’m always getting color space transfer function utomaticly set to “from max” and rgb color space “defaul”
Thanks
Just for clarification. If I use the _srgb extension the value Color space transfer function is set to none. The RGB color space remains on Default. Doesn’t this value have to be sRGB primaries for sRGB textures and Raw for data maps such as normal, height eg.?
_srgb > Color space transfer function = sRGB and RGB color space = sRGB primaries
_lin_srgb > Color space transfer function = none and RGB color space = Raw
For working with ACES system, If you decide NOT TO USE NAMING (this is what I do personally)
-for 8-bit color maps(diffuse/translucency/textured lights) set Color space transfer function to sRGB (this is called linearizing the image) , then set RGB Primaries to sRGB*
-for HDRIs or linear exr files used for diffuse/translucency/textured lights set Color space transfer function to None or Inverse gamma of 1 (these maps are linear already), then set RGB Primaries to sRGB*
-for maps used for bump/normal/displacement/roughness (any greyscale/achromatic maps, meaning they don’t have any saturation) set Color space transfer function to none and RGB Primaries to RAW**
If you decide to USE NAMING (usually for studios or automation) Auto RGB primaries for VRayBitmap textures, needs to be checked in color management settings
-for 8-bit color maps(diffuse/translucency/textured lights) use _sRGB (bitmap settings at defaults)
-for HDRIs or linear exr files used for diffuse/translucency/textured lights use _Lin_sRGB (bitmap settings at defaults)
-for maps used for bump/normal/displacement/roughness use _RAW
*You are basically telling Vray this bitmap is in Linear sRGB color space and needs a transformation to ACEScg color space
**RAW means no conversion and if you set RGB Primaries for a greyscale map to sRGB it will look exactly the same after the conversion, hence RAW is recommended, basically a transformation here has no effect on how the image looks
I hope it is clear now, frodopytlicek arcmos Let me know if you have questions
NOT TO USE NAMING (this is what I do personally)
I don’t use naming (yet).
I also do it manually and change the value for Color space transfer function AND RGB Primaries. Do you have to change the RGB Primaries value at all to get a correct result? I ask because the name extension _srgb, _lin_srgb and _raw do not change the RGB Primaries value at all.
By the way, I believe 3DZver’s script “V-RayMtl Converter” has a tool within it to set the primaries automatically, depending on what node the VRayBitmap is plugged into. @3DZver might give us confirmation about this?
If you are using ACES system, yes!
Only if you are dealing with a greyscale map, but if it has any saturation you will see a difference
_RAW doesn’t do any conversion
_sRGB will have an effect 100% , the bitmap will look less saturated (I have to use wrong terminology here to get my point through, what happens actually is a conversion for Linear sRGB color space to Linear ACEScg color space
_Lin_sRGB will have an effect in the same way (only difference is that the bitmap is already linearized)
If this still confusing just do this,
-for 8-bit color maps(diffuse/translucency/textured lights) set Color space transfer function to sRGB (this is called linearizing the image) , then set RGB Primaries to sRGB*
-for HDRIs or linear exr files used for diffuse/translucency/textured lights set Color space transfer function to None or Inverse gamma of 1 (these maps are linear already), then set RGB Primaries to sRGB*-for maps used for bump/normal/displacement/roughness (any greyscale/achromatic maps, meaning they don’t have any saturation) set Color space transfer function to none and RGB Primaries to RAW**
Best,
Muhammed
Now we have the “Auto” option in VRayBitmap’s “Color space transfer function”, I am interested to know if there are any practical reasons to use any other value here.
I know some people like to specify the gamma of sky domes, but I consider that an edge case for handling HDRIs with low dynamic range.
Are there any other reasons to change this from “Auto”?
No, you could always keep it on Auto
Then with ACES workflow, RGB Primaries is used to specify the right conversion
Best,
Muhammed
That is what I suspected - thank you @Muhammed_Hamed
Maybe there is some scope for UI optimisation here?
Probably yes, the issue is that 3Ds Max has no color management. So we needed to break up an Input Device Transform into 2 components, Gamma/transfer function and Primaries/Gamut
In Maya, V-Ray adapts to Maya’s native color management so you have a drop down menu for all IDTs(like the OCIO texture)
If 3Ds Max gets proper color management it will make this easier on everyone
Best,
Muhammed
in 3ds max for non-hdri maps describing color the proper Color space transfer function is Inverse gamma 0.455 or From max 3ds max (if max is on defaults). not sRGB.
edit: aces or no aces.
That depends on the encoding of the incoming map, i’d wager.
If it was saved with a gamma 2.2, then it is intended to be used with the inverse of that, or a power curve at 0.4545 exponent.
If it was encoded as sRGB, then one needs the sRGB inverse matrix to represent it correctly.
what is Substance Painter outputting by default? (not a user but I guess it is the standard today)
It can do practically anything, really.
It seems the default for color is sRGB8, however (see attached image, right-hand pane).
One can choose between single and triple channel images at 8, 16 and 32bpc, and the aforementioned sRGB8.
I should hasten to add: most monitors today are still sRGB, so the color transform makes sense, otherwise minor, but perceptible difference would arise in colors.
I should also add that this is just the default, i see nothing stopping anyone to export color as RGB8 (i.e. linear), or normals as sRGB, so one has to be mindful of using the correct encoding, in the output and once in the V-Ray bitmap loader.
As the encoding often isn’t specified in the file formats, assumptions have to be made, and if one saved wrong, the “auto” mode would likely get it wrong (i.e. load a linear Color image as sRGB).
To put some number to my ramblings above, see the attached image (best viewed 1:1 @ 2160p res).
I made a procedural color wheel (see the aptly named node in the top-left), and proceeded to save it as an sRGB-encoded, 32bpc EXR (yellow box. I did so to avoid any precision loss.).
I then loaded that image twice, once setting its interpretation to “Gamma 2.2”, and the other as sRGB (see nodes and property boxes).
I then differenced (Abs (A-B)) the original, and the two loaded images, and measured the max difference (blue boxes in the property pages).
That comes to as much as 0.85% for R and G (as the original image is in the 0-1 range), while it averages to 0.228% when loading an sRGB as gamma 2.2, while it’s negligible, as expected, for the correct colorspace.
The images seen in the viewers are the differences multiplied by 10, so to make them more visible.
I have just been doing a bit more testing and it appears that setting “Color space transfer function” to “Auto” can lead to unexpected results when converting some Itoosoft library assets.
As an example, their material “_RC_Slate_Roof”, applied to the “Railclone Library/Architecture/Exterior/Roofing/Tiles/Slate 1”, uses 8bit grayscale maps in the diffuse slot and 24bit RGB maps in the glossiness slot.
I’m not sure why they would create a texture like that, but it naturally leads to the wrong transform being used for both the diffuse and glossiness, when using “Auto” - something to watch out for.
I have asked Itoosoft about ACES support, but they don’t sound optimistic as they say they still need to support vray 3.6…
Good catch.
In fact, this is the kind of issue inferring *intent* without solid metadata to base it on can lead to.
As a texture can be in any number of other places, it’s difficult or impossible, to treat it right (if it’s instanced in both a color and a data channel, f.e.), and it’s also unwise, for the bitmap loader, to attempt and traverse a user scene to find instances and shader/node channels used (that can be milliseconds on a lean scene, or a long time in a big one.).
In other words, Auto is the user’s friend if the setup was done right beforehand (say, analogous to the defaults in Substance Painter), but the user is the only person to truly know their, and as such the texture’s, intent, and it’s ultimately on the user to ensure they pick the right transform for a given map.
More freedom, more responsibility. ^^
Hopefully Itoosoft will find a graceful solution!
When working using ACES & vray, what colour space are the colour swatches on Vray materials & maps considered to be in?
Also what about native & third party map colour swatches, such as noise, checker, Bercon?
I’m considering how best to handle old assets that have maps applied to slots, that also have colour swatches, and the map multiplier is less than 100%…
