The Future of OpenColorIO-Configs

[michdolan]

We're starting this issue to publicly discuss the future of this repository. There has been a fair amount of discussion on this topic within the OCIO TSC, and with ACES leadership, and we need to put a plan into action as soon as possible. Here's where we stand currently:

• We intend to create one or more new OpenColorIO-Configs repos under the ASWF GitHub organization.
• The new repo(s) will be a clean start, and not a continuation of this repo or its history.
• The new repo(s) will use the same BSD-3-Clause license that OCIO uses, and all contributions will be made under that license, and adhering to the same CLA/DSO rules that OCIO contributors adhere to.
• This repo will be archived, making it read-only, and with a clear message pointing visitors to the new repo(s).
• The first new config will be a new ACES config, built on top of OCIO v2 features, with minimal LUT dependencies (it can mostly be self-contained now).
• The new ACES config would be maintained by OCIO contributors, in cooperation with ACES, as an official OCIO ACES implementation, and hopefully part of an application to join the ACES logo program.
• We may create a dedicated working group to oversee the design and maintenance of the ACES config, with a dedicated chair.
• The goal is to have this config ready to ship with OCIO v2 later in the year.
• We hope also that there would be opportunity for the OCIO community, both studios and individuals, to contribute additional OCIO configs to a repo, both for public use, and as modern OCIO production examples.
• Another goal is to not have large LUTs stored in the repo, but generated as a CI/CD process if needed. The "code" would entail config generation packages/modules, and possibly the generated config files. Complete config packages would be available for easy download as build artifacts.

That all puts us in the right direction to make some progress, but there are some decisions to be made to get started. To be discussed first (there is MUCH more to discuss, but let's focus on these topics initially):

• Should we create one new repo with some strategic means of releasing sub-packages independently (i.e. like this current repo, but supporting versioned releases per config instead of for the repo as a whole), or should we create a repo per config to isolate each config's history and releases?
• What should the naming scheme of these repos be?

[michdolan]

My proposal, based on previous discussions and feedback is the following (and this is just my opinion... other ideas are welcome):

• Create two new repos:
  • OpenColorIO-Config-ACES: Just the ACES config, since it will inevitably be the one config to rule them all, and needs a release mechanism to associate with ACES releases.
  • OpenColorIO-Config-Share: Community contributed configs, released separately, but living in a combined tree like this current repo. Some standard release mechanism, via GH Actions, would facilitate packaging for each sub-project. These configs could grow arbitrarily. Some sub-projects could simply link to other repositories as submodules if a contributor prefers to maintain their config under another GH organization.

Alternatively, we could create a repo per config instead of doing something like OpenColorIO-Config-Share. We could instead provide a standard template to be used under the ASWF organization where it makes sense, and within external projects where the contributor prefers to own their own repo.

[michdolan]

Also a quick shout out:

@KelSolaar and Michael Parsons have been doing an excellent job maintaining the ACES config in recent years. Thank you both for your efforts, which have been very appreciated by many! Thomas has also done a great job in keeping this conversation going over the last year and will be instrumental in making it a success IMO.

And a call to the OCIO community:

If you want to be a part of building the next generation of OCIO configs, please get involved. The OCIO community has a vast array of talent and your input is valuable.

[sobotka]

Would it make sense to have a bare-bones proof of principle configuration as part of this new "core" that works in conjunction with @scoopxyz's documentation project, complete with a low-barrier-to-entry Python generation file?

[KelSolaar]

Thanks @michdolan! :) @mlfp is Michael Parsons Github handle btw!

We could instead provide a standard template to be used under the ASWF organization where it makes sense, and within external projects where the contributor prefers to own their own repo.

Yes that would be a good idea, at least to setup all the requisites for CI, CLA, README, whatever...

Would it make sense to have a bare-bones proof of principle configuration as part of this new "core" that works in conjunction with @scoopxyz's documentation project, complete with a low-barrier-to-entry Python generation file?

Yes although I reckon that different Configs will have different requirements from a generation standpoint. Some facts about the ACES one:

• 350+ Colorspaces (179 aliases)
• 4900+ lines
• Semi-procedural generation against aces-dev

I think that the new ACES config should try as much as possible to be backwards compatible OR if we choose it does not have to be (which would be odd given OCIO 2 will be itself backwards compatible) we will have to implement a migration process.

The ACES config is huge and just because of that we need a generator of some sort, given the last point about semi-proceduralism, it is maybe worth reaching a state of full-proceduralism where the generator is able to do everything just by pointing at the aces-dev CTL directory to create the baseline and then on top of that, adding the extra sugar that makes the config production-grade.

[KelSolaar]

Oh and mandatory shout-out to @hpd obviously :)

[hodoulp]

I think that the new ACES config should try as much as possible to be backwards compatible [...]

OCIOv2 has many new Ops and features that makes OCIOv2 config files incompatible with OCIOv1 library i.e. limiting new configs to only use OCIOv1 ops forbids the use of these new Ops.

The OCIOv2 library is backward compatible to enable users with OCIOv1 configs to operate even after a library update and to ease their later transition from v1 to v2 configs.

The ACES config is huge and just because of that we need a generator of some sort [...]

Without addressing the number of color spaces in a config, a partial answer to the config size is a new OCIOv2 feature Issue 980. The change in PR 1006 adds the built-in transform mechanism and implements some ACES CSC transforms. That should help config maintainers writing much more compact configs i.e. less external file dependencies and also help coding of any config generator.

[michdolan]

Oh and mandatory shout-out to @hpd obviously :)

Yes! A huge thanks to @hpd for creating the ACES config! And to all those who contributed to the effort! That work has been invaluable to OCIO users!

[KelSolaar]

@hodoulp : Sorry if it was not clear, backwards compatible in term of public API, i.e. functionality, i.e. same layout, colorspaces, etc..., whatever happens inside the file itself is private business! :) Ideally, if a user loads a large comp template with the new config, his work should not break, likewise for a Maya scene.

And yeah, the plan is to use the built-in transforms!

[zachlewis]

^^ Ditto -- I'm really appreciative of everyone's past, present, and future efforts and contributions -- it's hard to overstate how valuable (and educational!) (and ubiquitous!) the ACES and SPI configs, tools, and documentation have been. Thanks HP, Thomas, Michael, Other Michael, Alex, Other Alex, Scott, Kevin, Joseph, Steve, Doug, Patrick, Jim, Nick, Troy, Sean, Jeremy, and everyone else... I owe each of you a beverage of your choosing.

• I think it's definitely a good idea to maintain "canonical" ACES-OCIO stuff separately from other community-shared configs, scripts, artifacts, and such.
• As for the community-shared configs, I think I'd prefer a singular OpenColorIO-Config-Share repo over individual, separate repos, but I don't feel too strongly one way or the other. I could see how having too many configs in too many repos could be confusing, but I can also see how having too many configs in one repo could be confusing, so... :)
• Hey, slightly off-topic, but what do you guys think about adding an optional UUID field to configs? It would be kind of cool if ociocheck could compute a value based on config content...
• I think it's worth considering how to meaningfully organize and relate community-provided configs, and perhaps collectively come up with a style guide with suggested naming conventions for ColorSpaces, aliases, views, looks, workflows, file naming, that kind of thing. I don't necessarily think conformance should be required, per se; but considering the spectrum of OCIO uses and users, it's handy to have an Esperanto.
• Anecdotally, each site at Method has its own preferred color pipeline naming conventions, vocabulary, and workflows, each with fairly understandable, external precedent -- one site goes with the ACES OCIO config conventions; another site based theirs on how The Foundry named things in their config, another uses the SynColor catalog; another is a hybrid of SPI config conventions and their own; one is based off of whatever the colour-science.org library is using; etc. And while there's a halfway-reasonable degree of continuity for "proper names" across sites, aliases are a free-for-all. It's hard to believe how many ways there are to say "ALEXA LogC v3 EI800". (Internally, each convention is keyed to a set of enums mostly derived from colour-science v3.12 naming). Anyway, that's how I've come to be such a strong advocate of EXR chromaticity metadata as the source of truth :)

[michdolan]

Hey, slightly off-topic, but what do you guys think about adding an optional UUID field to configs? It would be kind of cool if ociocheck could compute a value based on config content...

Actually, this is already supported via the OCIO API. The config's cache ID is a hash (md5) of the entire config. It isn't stored in the config, but is simple to get via Python: https://opencolorio.org/developers/bindings/PythonAPI.html#PyOpenColorIO.Config.getCacheID

[michdolan]

What are your thoughts @scoopxyz ? I know you have had great ideas around this too.

[michdolan]

Thanks everyone for the input! Discussion can now be moved here: https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES