Our minimal OCIO configs are pretty damn minimal.
For a show-agnostic texturing config, we’d probably have “linear-rec709”, “ACEScg”, “sRGB (~2.2)”, “Rec.709 (2.4)”, and “AP1-with-an-sRGB-piecewise-curve” color spaces, connected via an “ACES2065-1” reference; and we’d have “None”, “Un-tone-mapped”, and “ACES” Views for “sRGB” and / or “Rec.709” Displays. That’s it. Very close to what’s inside that CAVE Academy config Sean pointed to above, it looks like.
Excellent point @ChrisBrejon ! We should propose this to the Config working group. Naming conventions are difficult to agree on but they would be very helpful.
Thanks @zachlewis , for chiming in on your minimal set of color spaces and views.
Thanks @doug_walker ! I thought it would be interesting to do a recap and see if we can come if some Zach/Chris’ mix of suggestions. 
It is true that it is difficult to agree on naming conventions. For the record, the list I have written above is inspired by Substance Designer, Substance Painter and The Foundry Mari. And if we wanted to focus on the lowest common denominator, we could remove Height, Displacement and AmbientOcclusion (hence the optional tag).
Update : Due to popular demand, Displays P3 are back into this proposal. Thanks !
Thanks,
Chris
What we do in Maya is, rather than defining all of these aliases we just have two aliases:
Okay, gotcha. You set the default input color space as “Raw” since it will cover most of your needs an use 2 aliases for the rest.
If I recall correctly, this “default” option is only available in Maya ? So this workflow would not necessarily work in different packages ?
Chris
@ChrisBrejon , the default role should work for other apps, though in OCIO v1, you also needed to set “strictparsing” in the config to false. In OCIO v2, there is always a Default file rule and this defaults to the “default” role (see the File Rules section of the OCIO documentation for more info).
Doug
p.s. Thanks again for your presentation at the UX working group today, great stuff!
Thanks Doug Walker. Yes, I now understand better Derek’s answer and yours !
For the record, here is the explanation. If you do not set OCIO Standard Rule in Maya, you have access to this little menu on the right where you can set a “default” IDT (for lack of a better term).
And if you set OCIO Standard Rule, then you’d go back to the “behaviour” that Derek and yourself described (with the use of aliases and the “default” role).
From the OCIO documentation :
If the colorspace cannot be determined and
strictparsing: false, the default role will be used. This allows unhandled images to operate in “non-color managed” mode.
On a “similar” note, Guerilla Render (where OCIO Standard Rule has not been implemented) does something interesting. When an IDT is left empty, it does the following :
Note : When left empty, Guerilla looks for an adequate role or colorspace depending on the type of texture (8/16 bits integer or half/float) in the following order for 8/16 bits integer:
- the texture_int_paint role
- the srgb_equivalent role
- the sRGB color space (found in the Guerilla default config.ocio)
- the Utility - sRGB - Texture color space (found in ACES)
- eventually, the texture_paint role
And in the following order for half/float:
- the texture_float_paint role
- eventually, the texture_paint role
Chris
Just to be clear, in OCIO v2 and in Maya, the Default File Rule is always active as the fall-back of last resort when no other rule matches a file path. It may be set to any color space (e.g. Raw, for no color management), but it defaults to the role “default”. Thanks for giving people the link to the OCIO part, here is the link to the related Maya documentation:
http://help.autodesk.com/view/MAYAUL/2022/ENU/?guid=GUID-631C665F-3092-4B2B-90B7-2A94158870C9
Thanks Doug. That’s a very interesting feature !
