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.
