Large asset libraries that changing the name would break and mean everything needs relinking.
Indeed.
But relinking under a very clear ruleset is super-easy to automate.
F.e., where it was “mytexture_diffuse.png” it’s now “mytexture_diffuse_srgb.png”.
It’s also easy to have a duplicate of the original asset data, and that alone be renamed and relinked, so that original assets stay untouched (and can keep being used under the old colorspace.), and disk space isn’t expensive, these days.
It’s truly the bread and butter of any pipeline TD to be able to provide for these kind of features in their tools, and there’s a swathe of free scripts to this effect around.
This said, Autodesk will have important improvements for color management coming for Max 2024, but we’re not at liberty to speak of them just yet.
That sounds exciting.
I agree with the auto renaming thing, and I wouldn’t be reluctant to renaming if every person or company that created assets also actually named their textures according to either a standard convention or even at all (be it diffuse or reflection or whatnot).
I have a library with over 25K 3D models, and there’s a shitload of different naming or not even clear names like 165024682740684qsdjoqsjd.jpg No use in renaming any of that. I understand for studios with big budgets that might not be such a big problem, but in smaller studios it’s not worth the hassle.
Although I always try to be updated with the latest of technologies or workflows, I think I might sit this one out for now, until a less cumbersome workflow arises. I remember the days of switching between gamma setups and all the shaders needed to be completely reworked. The horror.
I understand the predicament, i really think i do. 
But for those kind of assets, a rule naming system like Maya’s is only going to add complexity, not help solve any issue.
Besides, they are all sRGB-encoded, so why would you change the way they are interpreted by V-Ray?
The issue of haphazard naming and such is something that should be resolved before using the asset, rationalising naming and file placement.
If there is rhyme and reason (read: a convention) in how assets are prepared and stored, then both the rule system and our fixed-rule would be trivial to make work.
If there isn’t, then texture filename appending is by far the easiest, and safest, way to go about it.
Perhaps you could implement a meta file system where if there is a file with the same name as the texture .meta in the same directory this could contain info on the colorspace, etc as a text file of course.
I need to apologize here as i had missed one key part of this issue: that the bitmaps are treated as if they were encoded in the colorspace used.
This is great in a few cases, but it’s indeed cumbersome when someone wants to use an sRGB asset in an ACEScg colorspace, as the textures would then be automatically interpreted as ACEScg encoded, and they are instead left as sRGB.
This in turns leads to the need to use scripts to mass-change the bitmap properties.
It would work better if instead any 8bit texture for which the “_ACEScg” flag wasn’t specified was instead treated as sRGB by default.
Someone duplicating an asset and its textures to work in ACEScg would find the trivial to add the particle to the filename, and cascade the changes needed to the asset, while anyone bringing sRGB content to the ACEScg colorspace wouldn’t have to change a million sRGB maps settings manually.
So perhaps we’ll change to work this way (for versions of Max earlier than 2024).
Thoughts?
Sounds like a good idea, but I also like the idea of a separate .meta file or similar because you don’t have to rename textures and they contribute to work with old projects.
The VRayBitmap Loader could also give the option to create this .meta file (Like the way Loaders create .ifl files now) so that the setting would become permanent for future uses of the textures.
Sbs files are not liked universally, unfortunately.
The risk of losing them, along with the metadata they have, is great (ask anyone with a ton of retouched photos for which they lost the SBS files…), so relying on them exposes us to the risk.
Going forward, OCIO color management will provide for much better ways across the board, even in Max.
This would be perfect ^
Please consider this or at least an option under render settings >Color space options to “force sRGB for none specified bitmap color space”, so it doesn’t break other peopel workflow.
This sounds good.