Is it possible (and safe) to manually edit the config.ocio file? I have a mainly all CG based workflow and find the gazillions of entries for things I never use very cumbersome. Especially when they fill up and go off the edge of my screen and I can’t get to the IDT/ODT/etc. that I want.
At the moment, I don’t know how to generate a custom one so I was thinking of just removing all of the entries I don’t need. Will this cause any problems? If not, are there any entries that SHOULDN’T be deleted?
It is indeed highly recommended. Perhaps, a suggestion could be considered:
So far, 3D Image makers using ACES for CGI (specifically), have been sharing between themselves their edited OCIO config-file. Many are simply not aware that it can be edited and simplified.
It would be preferable, to avoid having such obnoxious GUI experience to many students, hobbyists, and professional individuals that are not familiar with an OCIO config file (and all the options that many never use, most of the time), to provide a simpler (“strict minimum”) version that could be supplied, for instance, on the official Github as an alternative config-file, for CGI image makers.
There seems to be a repetitive pattern of many individuals editing the OCIO config-file. While one config-file will not fit the needs and requirements of everyone, I still think it could help many, that are mostly working with linear-SRGB, sRGB (display referred) and ACEScg files, and an sRGB monitor (the most repetitive pattern I noticed and am referring to).
The OpenColorIO Config group is currently working on revamped ACES configurations and yes, there are discussions around making the config lightweight and also maybe provide a generator frontend that will help to generate a tailored config for ACES.
That would be awesome! My Python skills are basic at best right now and it’ll take me a while to wrap my head around all of this and be able to generate my own config file.
The simplest approach is to edit the config-file. It is a “text” file which you can simply open and edit, no “compiling” or “python-generated output” of any type are required. You could make a back-up of the original config-file, then do simple edits based on your needs and requirements.
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).
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
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 !
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.
@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.
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 ) :
Sorry Sean.