Manual Editing of config.ocio

Discussions - Using ACES VFX
#1

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?

Thanks.
Bob

1 Like
#2

Absolutely. It’s very common practice to make a custom config by editing the standard ACES config in a text editor.

#3

Good to know. Thanks!

#4

Not only that but recommended! One of the goals of the ACES config has always been to be a starting point for people to tailor it to their needs :slight_smile:

#5

Awesome. Thanks! Now if I can just figure out how to properly set everything up so all my apps work together with it I’ll be all set. :slight_smile:

#6

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).

1 Like
#7

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.

Cheers,

Thomas

2 Likes
#8

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.

#10

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.

#11

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.

#12

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.

#13

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
#14

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?

#15

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. :slight_smile:
Bob

#16

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
#17

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.)

#18

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

#19

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 :wink: Sorry Sean.

If you have any other suggestions or things you spot that are a miss, please do let me know.

Thanks
J

1 Like
#20

@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
#21

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. :wink:

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