I saw that 3ds max finally supports OCIO and have this automatic colorspace assignment tool, where you can make rules depending on texture name or filetype.
Would this work with V-ray bitmap?
or do we have something similar?
I find it a bit tedious that i have to manually rename textures or assign IDT in the vray bitmap for every single colortexture, when 99.9% of the time i use only sRGB jpg, png or tiff.
So would be great if this could work with v-ray. If there is other solutions out there, that makes the process of assigning bitmap IDTs faster, then i’d like to hear about them
Auto – Automatically determines the color transfer function. If a bitmap file name contains the string “_srgb” the transfer function is sRGB. If a bitmap file name contains the strings “_lin_srgb” or “raw”, no correction is applied. For bitmap files with 8 bits per color component, 3 or 4 color components (like png, jpg, and other) and no suffix, the transfer function is sRGB. In all other cases, no correction is applied.
Seems to me that colortransfer function relates to gamma adjustment and not RGB primaries?
So it wont convert my srgb textures to ACEScg unless i use the naming convention “_srgb”
Any 8-bit texture map should be renamed according to the color space that they are in, using “_lin_srgb”, “_srgb” or “_acescg” suffix.
If neither is present, the map is assumed to be in the renderer color space as specified in the Color management rollout (in this setup, ACEScg). If the texture maps are properly named, auto recognition can be used by enabling the Auto RGB primaries for VRayBitmap option.
@matanov but thats what i meant, its quite tedious to do this setup.
Imagine you open a big scene, lots of textures that i want to convert to aces. So i would have to gather all color textures and batch rename them with this “_srgb” suffix, assuming they are all srgb maps, and HDRI to “_lin_srgb” ofcourse.
This new 3ds max 2024 automatic color space assignment, would save me from doing that.
Cause it will just assume that my jpg,png and tiff maps are sRGB and that exr or hdr are lin sRGB.
This would essentially mean that it would have converted my scene without me having to rename stuff, if I used with Arnold.
That is why i wanna know if we can do something similar with V-ray?
Like being able to set up rules based on filetype to assign RGB primaries.
I think a lot of people that wanna start using ACES, still work with sRGB textures.
There are conceptual issues with the Max approach.
It isn’t the file format determining the color space, it’s the content ecoding, and the channel the map drives.
For example, no one stops anyone from having EXR files in the diffuse slot (f.e. one of our old tiled EXRs promoted from 8 bit, stored as 16bit half-float, but with sRGB encoding), and a Png can very well drive a displacement, needing raw output.
And speaking of ACES, maps encoded for ACEScg cannot be told apart from sRGB ones. The user has to know and specify it.
For those old enough, this is what the old “LWF” checkbox used to do.
It has been removed because of the unsolvable issue above.
Tedius and right is much better than quick and wrong.
I guess most small to midsize companies are in the same spot than we are.
We have thousands of textures (mostly jpeg) without an suffix. Not a single one of them is in acescg colorspace or lin_srgb.
So why can´t we just assume all textures (jpeg,png, tiff) without a suffix are in sRGB color space?
Wouldn´t it still be better to assume some corner cases wrong and just have to manually adjust these instead of having to adjust every single texture?
I agree that having the right naming would be the ideal solution, but in our production enviroment it´s just not an feasible option.
We would have to copy and rename thousands of textures and relink them in hundrets of projects.
And also do this for each single new texture that are downloaded by our artists.
So we would also prefer the 3ds Max approach and just deal with some corner cases manually.
The option to default to sRGB primaries even with ACES as primaries for the renderer is one of the things we had planned.
We wanted to see what was done for 2024 first.
There are a ton of free mass-renaming utilities, and relinking scripts.
It’s a standard task of pipeline maintenance, for the upgrade that Max/ACES provides, and can be routinely done by individual artists and companies alike.
It’s not like you need to convert all your past projects at once: you can start on the upgrade path and set up the needed automation for the future projects, while the old material gets converted leisurely.
These are not corner cases either: assuming sRGB for an extension means *all* your incoming textures, including those inside data channels, will turn to a 2.2 gamma.
That will break all your your looks, badly, unless you happen to have shaders with just diffuse textures.
And the same goes for tiled material: .TX and .EXR can be in any channel, and have any bit depth and encoding.
So, you’ve saved on the renaming, and have now to fix every non-color texture’s gamma manually (notice the last paragraph in the OP’s screenshot. We prefer to make this quite clear, instead of relegating it to a footnote.).
One can’t have both for free: there was one option only (sRGB) now there are two, and they have to be dealt with manually, as automation isn’t possible.
The only option that involves no work on existing and future texture files is to not move to ACES at all, i’m afraid (but the gamma will still have to be set manually, if one doesn’t rename textures.).
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!
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.)
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.
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.
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).
