What does 'Default' do on a VrayBitmap's 'RGB Color Space' dropdown?

[^Lele^]

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).

[^Lele^]

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.

[olly]

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...

[^Lele^]

it naturally leads to the wrong transform being used for both the diffuse and glossiness, when using "Auto" - something to watch out for.

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. ^^

[olly]

Good catch.

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%....

[3DZver]

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?

Yes, I can confirm that the current version of the "V-RayMtl Converter" script has a function to automatically setup the primaries depending on which node the VRayBitmap is plugged into.
A more detailed description of the function can be found here: V-RayMtl Converter 3

[piotrus3333]

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 appreciate the numbers, thank you.
I'm 3ds max only - I guess I treat everything color with 2.2 simply because of 3ds max as it can only handle gamma transform during saving. quickly rendering some maps straight from SME, using max's swatches for color input etc.
translation swatch-bitmap value is just easier with simple gamma (with VRayColor mostly).

heh, and the average 0.228% means nothing when you stare at those nice thick blacks: it can be the difference between slightly crushed and just a bit milky.

btw: I hope VRay's acescg not transforming color swatches from 3ds max is a bug? right?

[^Lele^]

btw: I hope VRay's acescg not transforming color swatches from 3ds max is a bug? right?

More than a bug it's a current Max limitation.
AD is well aware of this, it'll be hopefully corrected soon enough.

[hulpesergiu]

Just for clarification, does transformation happen in the background? when the auto RGB primaries option is enabled?

I renamed some textures as a test, but I don't see any changes in the material editor, so I'm not sure if it's working on not.

I tried naming them both _srgb and _sRGB, and _raw and _RAW

Also when using Auto RGB primaries, do we still need to manually set the Color Transfer function? or the "bitmap settings at defaults" means we shouldn't touch that? It's a bit confusing

[olly]

Have you checked "Auto RGB primaries for VRayBitmap textures" in Render dialog > settings > Color Management?
It is off by default in vray 5, not sure about vray 6...

[hulpesergiu]

Yes, as I mentioned I already have that checked, does 3ds max need a restart or something? or should it happen automatically?

[olly]

Sorry for missing that in your post

The conversion process isn't invisible, you will see it working. But I agree this area really is overly complicated and it took me a while to figure it out.

Try this:
Uncheck "Auto RGB primaries for VRayBitmap textures" in Render dialog > settings > Color Management.
Select ACES in the colour management settings.
Add the correct tags to your filenames.
Set colour space transfer to auto and RGB primaries to default (these are the defaults) for your vraybitmaps.
Your sRGB colour maps should now look wrong and too saturated in the material editor.
If you now recheck "Auto RGB primaries for VRayBitmap textures", you should see these colour maps change...

I hope that helps?

[hulpesergiu]

Don't worry about it! Thank you for your reply.

I was doing some tests, I'm not sure if I found a bug.

So I have my scene set to GPU as default, I was trying this way, and nothing was changing, but then I switched to CPU and it worked, then switched to GPU and it worked.

Unfortunately I wasn't able to reproduce it, seems to work well now! Thanks