That’s what I’m doing now. I was just unsure at first about what I could or couldn’t get rid of. But I’ve kind of got the hang of it now.
1 Like
If you only need an ultra slim config with sRGB one is offered by CAVE Academy:
https://caveacademy.com/product/cave-cg-animation-aces-ocio-config/
But might be too slim for normal studio usage.
I just took a look at the CAVE Academy config and would like to make people aware that it has a bug. On the website it describes the “Utility – Curve – sRGB” color space as “the sRGB Gamma curve but uses ACEScg primaries”. In fact, it uses the ACES2065-1 primaries (AP0). (I’ve seen many people make similar mistake and that’s part of the reason we added the Named Transform feature to OCIO v2.)
Also, I’m a bit surprised it doesn’t have an un-tone-mapped view for looking at textures.
In any case, this does reinforce the point made above that it would be nice to have some basic “starter” configs that people could use. As Thomas mentioned, this is already on the radar of the OCIO Configs working group, and anyone is welcome to participate on that.
And if people here would suggest what their “minimal” set of color spaces, displays, and views are, that would be quite helpful to us.
Also, just a note about manual editing … yes, this is possible, although one benefit of using the Python API is that it will avoid syntax errors. There is also a command-line utility called ociocheck that may be run to validate a config. Sometimes that is a useful test (in addition to running it in the applications you typically use).
Doug
6 Likes
Good catch, thank you for letting us know. I am not using it but it is useful to know if I know someone who is. Has it been reported to cave-academy?
I think I did a pretty good job manually editing the file. I had a couple of syntax errors but found and fixed them without too much trouble. I probably eliminated half or more of the entries and now it’s nicely manageable for my needs.
Doing this has really lit a fire under me about learning Python (something I’ve wanted to do for years) and really learning and understanding OCIO/ACES. I find the whole subject fascinating. 
Bob
1 Like
Thanks @doug_walker I have let Jahirul Amin from the CAVE Academy know.
I have been playing a bit with the TCAM OCIO config lately. I am quite fond of its minimalism and terminology. So, if I had to share a minimal config preference, here it is :
Displays
- sRGB
- Rec.709
- P3D65
- Rec. 2020
- Rec. 2100 HLG 1000 nits
- Rec. 2100 PQ 1000 nits
- Rec. 2100 PQ 4000 nits
- Raw
- sRGB Un-tone-mapped
Colorspaces
ACES family :
- ACES2065-1
- ACEScg
- ACEScc
- ACEScct
Utility :
- Utility - Linear - sRGB
- Utility - Linear - P3-D65
- Utility - Linear - Rec.2020
- Utility - sRGB - Texture
- Utility - Raw
And maybe an update with the roles ?
Roles
(I have put in bold the changes from the ACES 1.2 OCIO config)
- color_picking: Output - sRGB
- color_timing: ACES - ACEScct
- compositing_linear: ACES - ACEScg
- compositing_log: ACES - ACEScct
- data: Utility - Raw
- default: ACES - ACES2065-1
- matte_paint: Utility - sRGB - Texture
- reference: Utility - Raw
- rendering: ACES - ACEScg
- scene_linear: ACES - ACEScg
- texture_paint: Utility - Linear - sRGB
But I can see in the ACES OCIO V2 config that some of the roles already match what I’m suggesting. Sweet !
Regards,
Chris
2 Likes
Look cool.
I would add Utility-Curve-sRGB that I used in Mari to get scene-referred value from color picked display reffered ones. (don’t know if it’s actually what it was made for.)
That’s looks pretty good Christofe. It’s very close to what I eventually came up with. I would definitely like to see something like that as a standard minimum config. I think a lot of people would find it very useful.
Bob
Hey @doug_walker ,
Many thanks for flagging the above. Really appreciate it. I’ll update things on oour end based on your above notes.
Which means I’ll be bugging @SeanCooper again 
Sorry Sean.
If you have any other suggestions or things you spot that are a miss, please do let me know.
Thanks
J
2 Likes
@ChrisBrejon, that is exactly what I was looking for, very helpful, thank you!!
@jahirulamin, yes, please contact Sean, he is an expert at this stuff and will be able to make it do what you want. Good to see you adopting OCIO, keep us posted on how it works for you.
Doug
1 Like
Thanks @doug_walker ! We have been discussing with a colleague about this minimal ACES OCIO Config, since we are very interested to ship it in Guerilla Render by default.
One thing that could be awesome/super useful (but maybe a bit out of scope for a minimal config ?) would be some default aliases to help users and developers to rely me on OCIO Standard/File Rule.
For instance, if we could add the default outputs from Substance Painter as aliases, I think it would be a good step to make the OCIO Standard/File Rule more known to the users :
- BaseColor → Utility - Linear - sRGB
- Height → Utility - Raw
- Metallic → Utility - Raw
- Normal → Utility - Raw
- Roughness → Utility - Raw
I believe something like that in the config :
- !<ColorSpace>
name: Height
family: Utility/Aliases
equalitygroup: Raw
bitdepth: 32f
description: |
The Raw color space
isdata: true
allocation: uniform
allocationvars: [0, 1]
Or even better using the OCIOV2 “alias” property (courtesy of @zachlewis ) :
- !<ColorSpace>
name: Raw
family: Utility
isdata: true
aliases: [Height, Metallic, Normal, Roughness]
I think supervisors I know would be interested to manage their IDTs by relying on strong templates and naming convention.
Thanks,
Chris
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.
1 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.
Views
- ACES
- Raw / None
- Un-tone-mapped
Displays
- sRGB
- Rec.709
- P3
Colorspaces
ACES family :
- ACES2065-1
- ACEScg
- ACEScc
- ACEScct
Utility :
- Utility - Linear - sRGB
- Utility - Cuve - sRGB
- Utility - Curve - Rec. 1886
- Utility - sRGB - Texture
- Utility - Raw
Roles
- color_picking: Output - sRGB
- color_timing: ACES - ACEScct
- compositing_linear: ACES - ACEScg
- compositing_log: ACES - ACEScct
- data: Utility - Raw
- default: ACES - ACES2065-1
- matte_paint: Utility - sRGB - Texture
- reference: Utility - Raw
- rendering: ACES - ACEScg
- scene_linear: ACES - ACEScg
- texture_paint: Utility - Linear - sRGB
Aliases
- BaseColor
- Roughness
- Metallic
- Normal
- Height (optional)
- Displacement (optional)
- AmbientOcclusion (optional)
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:
- Basecolor (for color sRGB 8bit texture maps)
- HDR (for HDR maps in sRGB primaries)
Since all the others use Raw, we simply set the “default” role to Utility - Raw which affects Maya’s input files.
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 !