3ds max 2024 OCIO - Automatic colorspace assignment

[^Lele^]

What does this have to do with anything that I asked or said? Let's break it down:

1. You said VRay follows 3dsMax 2024 Colormangement Rules
2. 3dsMax 2024 Colormanagement Rules define that all jpgs are assumed to be sRGB
3. I demonstrated that this is not the case. BOTH jpgs in my example are interpreted to be in ACEScg, in 3ds Max 2024 (with new Colormangement where jpgs are assumend sRGB following the Colormanagement Rules) and 2023 or earlier (without new Colormangement where jpgs are assumed to be ACEScg by V-Ray). It gives the same result.
4. My question: Why it gives the same result given that it SHOULD follow the Colormangement rules as claimed?

Just please answer this question in a logically followable way. Maybe I'm too stupid, maybe I'm doing something wrong, that's no problem. If it turns out I do some mistake I'm very happy to learn - really! Just please describe it in a way that answers this question.

To be perfectly clear, *nothing* has changed in the vraybitmaps' interpretation of primaries: if they are not tagged, they will be assumed to be encoded with the same primaries as the rendering color space (so, ACEScg textures encoding assumed for ACEScg color space, and sRGB encoding assumed for sRGB color space.).

The OP table of OCIO rules does *not* determine *primaries* for files that aren't filename tagged (i.e. it won't work by their extension, nor will it auto-match the render color space.), and Max/Arnold and their bitmap loaders will assume the files to be sRGB at all times unless tagged as ACES (ofc, this can be overridden in the loader, like with us.).
Notice *ACES is in the filename, not the extension. It's the OCIO spec wanting filename-tagged textures.
The vraybitmap however will match the assumed encoding of the incoming textures to the render color space.
We do follow the OCIO table for color space transfer function, AKA Gamma, or sRGB transform, that works by file extension in the OCIO list, when it's set to "from 3ds max" in the vraybitmap.
This can be seen at work also in the max bitmap loader, which now assumes every 8bit texture to be wanting a gamma of 2.2 (as per the table.), and offers a button to set it to "data", or linear.
Nothing to do with primaries. Max 2023 and max 2024 will behave the same with V-Ray and vraybitmaps in this respect.

[Joelaff]

Hmmm…

Why wouldn’t you make VrayBitmap work like the new max Bitmap node and honor both the gamma and primaries settings from Max2024?

This would be almost as good as giving a setting such that the user can decide in older versions of Max.

Does somebody think just ignoring the Max settings makes sense? Sounds like a support nightmare at the very least. Linear workflow nightmares.

[^Lele^]

The OCIO implementation isn't settled at all.
We are left reacting.

[JonasNöll]

Ok, thanks that answers my question.
So as it then appears at least for now Autodesk and Chaos have different ideas about the default primaries when rendering in ACEScg.
An additional option in V-Ray that defines the default primaries for non-nametagged images would help to clear up this difference.

[matanov]

Am I missing something or Bitmap and VRayBitmap act the same with defaults and non-tagged filenames?

[^Lele^]

You're not, i was wrong in that bit.
It is, after all, the OCIO spec demanding a match between incoming material and rendering primaries.

[JonasNöll]

Hi, there seems to be a difference how not nametagged images are interpreted between 3ds Max 2023 and 2024 and when the new 3ds Max Colormanagement in 2024 is turned OFF (so same as in 3ds Max 2023).
This is the same scene just opened with different 3ds Max versions and the not nametagged image is loaded differently in 2023 vs 2024.

Edit: Sorry the labels are wrong. So left is 2024 and right 2023

[^Lele^]

You're essentially saying that any sRGB texture that isn't tagged will load wrong in Max 2023 and V-Ray: that's most definitely not the case.

To put this issue to rest, I made an sRGB Jpeg in nuke



These are the results i got in max.
The top Row is Untagged bottom is Tagged.
From left to right, the primaries are set to "default", "sRGB", "ACEScg" and "Raw".





You will notice the only bitmap that differs from Nuke's is the one manually set to ACEScg, easily identifiable for the overboosted red (with spill to cyan).
Verify that in your tests you haven't overridden the image primaries by mistake.
If you think you have done it right, kindly share the texture file and the max files.

[GLASS-CANVAS]

This whole topic is very important for us. Up until now we have been using Max Tools' V-RayMax Converter Pro script to batch correct all the bitmaps; there is a section of the tool that does this specifically. We have always assumed it works exactly as it should, but it would be great if someone else could confirm this!

[^Lele^]

This whole topic is very important for us. Up until now we have been using Max Tools' V-RayMax Converter Pro script to batch correct all the bitmaps; there is a section of the tool that does this specifically. We have always assumed it works exactly as it should, but it would be great if someone else could confirm this!

Manually setting primaries for vraybitmaps will work as one expects, yes.
Primaries are automatically changed only on first bitmap load.

Besides this, it's hard to know if it's as it should without an image: you ought to know seeing the results of your renders.

[piotrus3333]

wait, regarding old scene conversion what is exactly missing from just using Lele's script?

and if renaming files is such a hassle then just create rules based on how your textures are named:

[GLASS-CANVAS]

Besides this, it's hard to know if it's as it should without an image: you ought to know seeing the results of your renders.

They look exactly as expected, so I guess that's a yes!
I guess the bigger picture here is that someone has indeed created a script to automate the task, and I felt it was worth giving it some publicity (I have zero investment in it, and pay for my copies like anyone else)

[^Lele^]

They look exactly as expected, so I guess that's a yes!
I guess the bigger picture here is that someone has indeed created a script to automate the task, and I felt it was worth giving it some publicity (I have zero investment in it, and pay for my copies like anyone else)

That script is a great tool, properly written too. There's a lot to like about it.

[phill_moris]

They look exactly as expected, so I guess that's a yes!
I guess the bigger picture here is that someone has indeed created a script to automate the task, and I felt it was worth giving it some publicity (I have zero investment in it, and pay for my copies like anyone else)

I confirm. I have been actively using this tool for several months now and it has never disappointed me since I purchased it. What I like most is that it can be used from the command line in conjunction with other scripts and for batch processing of multiple files.