3ds max 2024 OCIO - Automatic colorspace assignment

[Joelaff]

I think the issue with previous versions ( I think you are saying this is no longer the case) is that primaries for untagged images defaulted to ACES when ACES was set in the renderer. This is the thing that pretty much nobody wants to happen. Untagged images should be assumed to be in sRGB primaries, even if the renderer is set to ACES. That way the user has to do nothing to render in ACES color space with all their existing sRGB images.

Generally, assuming something is in a brand new format (ACES in this case) is typically not a good thing. If an assumption is to be made it would typically be to assume the legacy format (sRGB) until told otherwise by the user. Of course settings and popups and buttons are what we really want... CONTROL!

Of course being able to define the defaults like Max 2024 is even better. Are we now saying that VRay will honor the settings in Max 2024 and we can have all of our sRGB images stay with sRGB primaries while rendering ACES witout having to rename or manually retag anything? I think that is what you are saying... which would be great!

[^Lele^]

I think the issue with previous versions ( I think you are saying this is no longer the case) is that primaries for untagged images defaulted to ACES when ACES was set in the renderer. This is the thing that pretty much nobody wants to happen. Untagged images should be assumed to be in sRGB primaries, even if the renderer is set to ACES. That way the user has to do nothing to render in ACES color space with all their existing sRGB images.

If you recall, this was my suggestion in the other thread on the subject, so yes, it's what we have planned.

Are we now saying that VRay will honor the settings in Max 2024 and we can have all of our sRGB images stay with sRGB primaries while rendering ACES witout having to rename or manually retag anything? I think that is what you are saying... which would be great!

Nope, that's the gamma settings, not the primaries.
So, LWF all over again.
Suggestion: nametag your files properly, or click a million clicks.*


*(or use the max bitmap loaders, and then convert to V-Ray bitmaps. Margin ally lower click count.)

[Joelaff]

If you recall, this was my suggestion in the other thread on the subject, so yes, it's what we have planned.

Excellent. Can we get that in the nightlies? It’s probably only a one or two line code change

As pointed out above, this would mean everyone could switch to ACES overnight. Problem solved, and nobody has to have an infestation of underscores in their file names.

[^Lele^]

Excellent. Can we get that in the nightlies? It’s probably only a one or two line code change

You can wirte a script to do that yourself, so easy it is, or fetch and modify the one i wrote a while back.
That's why it's low priority.

As pointed out above, this would mean everyone could switch to ACES overnight. Problem solved, and nobody has to have an infestation of underscores in their file names.

No, the infestation would remain regardless, as gamma settings cannot be handled by simple file format rules.

The script to change primaries to aces or srgb was written by me two yars ago, shared on this very forum, and made absolutely no difference to ACES adoption, whose issues lie well elsewhere: stop hinting it's due to some form of laziness on our part, as it's truly not a fun joke.

[JonasNöll]

Hi, not everyone is a coder and while this seems maybe trivial for people with scripting experience it poses a very big burden for other without this experience (speaking of myself here) and have to rely on the built in tools.
So wouldn't it be possible to just define in the Global Rendersettings what the "Default" option in the RGB Primaries of VRayBitmaps stands for?
Choices could be: 1. Follow nametags, 2. sRGB, 3. ACEScg

The thing with the nametag works, but it's not practical to rename your entire texture library with those and then always spend huge amount of time relinking textures whenever you open older scenes. That's at least my personal reason why I didn't do this so far.
Yes I know with some scripting this would be a piece of cake, but there are those people who use V-Ray and Max and literaly don't know how to write a single line of code (speaking of myself here).

[^Lele^]

Yes, we have gotten all that, ty, and it's the way it will work when the defaults will be changed.

Yet, the script's been available for ages to non coders, and made absolutely no impact: if one's not prepared to make rational choices around a pipeline, and keeps chasing half-baked solutions (like my script, or any other such "automatic" approach. You're likely too young to remember the dreadful LWF checkbox. So we're having the same debate, fifteen years on.), one will soon run out of luck.

I utterly resist this wish for ungainly approaches you and a few other express: i can't fathom why one would want all their material converted at once, nor why one would need to restore old stuff and convert it to ACES on a whim, *whitout* being willing to work on the conversion itself.

All conversions can be non-destructive, and progressive, and for *all* their steps there are free tools around (mass renamers, bitmap relinkers, the whole lot.).
Converted material ought to be a *copy* of the original anyway, as it's wise and often not optional (because time passes and versions diverge.).
Nor can i see why a run-of-the-mill texture renaming and relinking would turn into a "big burden" for an accomplished artist or studio.

Besides, you can't just switch primaries to ACES and call it converted, even if the source textures were considers to be in sRGB (and you ought to know this well, which makes your apparent affection for one-click solutions overly baffling.) so the little steps involved in reformatting and relinking the incoming material is exceptionally minor compared to the rest of a color space conversion for thirdly-approved renderings (as opposed as random play and ideal scenarios which have no bearing on reality.).

Reformatting that you'll need *regardless* of how we'll treat primaries, thanks to the per-format rules in max 2024 (OP.).
That, or manual setting of colorspace per map (which is only made marginally easier using the max bitmap loaders, for max 2024).
At which point changing manually the other dropdown for primaries looks like a very minor issue, given automation isn't possible, or it's plain wrong in results.

The elephant in the room, in other words, ain't disappearing once primaries for unknown-encoding source textures are defaulting to sRGB.
If i were still an artist willing to work under ACES primaries as a matter of course, by now i'd have a well established set of tools to take me there, instead of waiting for one or the other software vendor to carry me every step of the way to my destination: we can't, and won't (forcing a sRGB default *will* produce wrong results if the texture was encoded in ACES. And there is no way to know if it is. The *user* needs to know and keep track of it.).
Max 2024 adds parts we couldn't do ourselves (f.e. the color management across the whole application.).
We'll make a few minor changes to the pipeline (f.e. the very same the script already implemented, but in code.), and that will be largely it.

Texture file proper naming is a thing that's been around since the birth of 3d, and is here to stay: we -and you with us- have no (better) choice about it.

[JonasNöll]

Yes, we have gotten all that, ty, and it's the way it will work when the defaults will be changed.

Sounds great!
As for the rest I guess you missunderstood: I don't think I said this is a one-click solution to a complex issue. It would be just an option to give the user additional choice.

[Joelaff]

stop hinting it's due to some form of laziness on our part, as it's truly not a fun joke.

Wow. I am so sorry if you interpreted it that way. It was not meant in any way to insinuate laziness. The point was that it should be relatively easy to change, and not take many resources, which we know are of course finite. We get it-- every small change has overhead and slows down the implementation of new features, etc.

It was a decision that was obviously made for a reason. It just seems that most users disagree with the decision (at least those posting here). Sure, there are many ways to handle this on our end. Like any problem, there are multiple solutions. It just seems that the users posting here and Chaos disagree on the ideal solution.

Note that users' resources are also finite, and although solutions exist for things that doesn't always mean that we will have the time and resources to implement and test them. We hardly have time to upgrade things here.

I prefer Jonas' solution of a setting to let the user decide with a popup or similar.

[^Lele^]

Wow. I am so sorry if you interpreted it that way. It was not meant in any way to insinuate laziness. The point was that it should be relatively easy to change, and not take many resources, which we know are of course finite. We get it-- every small change has overhead and slows down the implementation of new features, etc.

The current defaults are used by users as they should be used right now.
Changing so that non-tagged textures default to sRGB would break their workflow, for which they spent resources converting textures to ACES encoding, and that'd be terribly unfair to them.
Currently there is no feature being impaired by this workflow, and so the resistance is quite motivated on our side.
We like to think we care for all the best we can.

btw, all it takes is a one-liner:
either

for m in getClassInstances vrayBitmap do m.rgbColorSpace = 1 --sRGB

or

for m in getClassInstances vrayBitmap do m.rgbColorSpace = 2 --ACEScg

The same would go for colors, but that's a non-issue, i assume.

[Joelaff]

Not sure how many users are relying upon the current default behavior. I mean how many people have untagged ACES textures? That would be silly, since they would be new assets that you might as well tag, and pretty much every other program will treat an untagged asset as sRGB-- as it should. I would bet a very large sum that most people's untagged textures are sRGB...

Jonas' solution would not break anything for anyone. Granted, it is slightly harder to do.

Maybe you could read it form an environment variable?

The script solution works, but you still have to remember to change it every time you add a bitmap, rather than having it behave the way to vast majority of the users would like it to.

I don't want to argue further on the value of something like Jonas' solution. If that is not the obvious solution then no amount of back and forth is going to change your opinion.

[dlparisi]

OT- This whole discussion is triggering in me a recall of a rather tedious discussion on the Adobe forum of how Photoshop was handling EXR alphas back in 2009: https://community.adobe.com/t5/photo...d/td-p/1520950. Basically, Photoshop was forcing (is still forcing? - I can't recall if I'm still using the ProEXR plugin or not at this point) any non-white alpha values to true transparency (checkerboard) and nuking anything in the RGB channels. It's a very interesting read if you have the time and does explain an awful lot for better or worse. Granted, nothing here comes close to the level of pedantry and derision that were displayed there but still akin to the "you're using it wrong" and "that's what the spec says". Really, the discussion here is WAAYY more civilized so don't think I'm conflating the two. We just want the tools to be as user-friendly and seamless as possible.

[^Lele^]

That was an epic one, thanks for retrieving it.
We're sadly under very different conditions, wish it was obstinacy holding us back.
Sadly, it's the ACES approach that is hobbling us: not having a way to figure out an input's encoding is a major, major issue that "defaults" aren't ever going to fix.
Resisting simplistic approaches in the name of catering for all of our users' needs is a very thin line to walk, but one we can't avoid walking.

[JonasNöll]

Hi,
so just coming back to the original question: Does the colormanagement in 2024 change anything for the V-Ray workflow in regards to VRayBitmaps as of now?

So if I understand correctly then in the colormanagement for 2024 there are the "Automatic Color Space Assignment Rules" where for example .jpg is automatically assumed to be sRGB.
In V-Ray that, at least from my testing, doesn't seem to be respected and in the VRayBitmap I would still have to manually select sRGB in the RGBPrimaries for my diffuse textures (- assuming they are in sRGB and no nametag is in place)

So from what I can tell the colormanagement in 2024 for V-Ray just sets the OCIO file automatically in the VFB but everything else is the same as in other 3ds Max versions (- apart from the new colorpicker)?
Or am I missing something?

[^Lele^]

There are a few aspects to this.

a) Enable OCIO in the Max Color Management (using the gamma workflow will *not* enable the new Max features.)
b) Rendering Color Space in the Max Color Management will now override V-Ray's in the render settings.
c) The V-Ray bitmap loader's RGB color space parameters set to "Default" will obey Max's Color Management Choices.

[JonasNöll]

c) The V-Ray bitmap loader's RGB color space parameters set to "Default" will obey Max's Color Management Choices.

Ok strange, for me I still get very oversaturated colors when having the RGB primaries set to Default in the VRayBitmap and only if I manually set it to sRGB then it seems correct. There is for me no difference if I use the (3ds Max OCIO Colormanagement) OR (3ds Max Gamma Workflow + Setting up ACEScg in VRay Rendersettings as before).
If I understood correctly then when using the 3ds Max Colormanagement it could be left to Default as it should obay Max's Color Management Choice.