ACES OpenColorIO-Configs (and other stories)

Sean Cooper


I know this is coming from a long and storied past but we (the OCIO TSC), high on the spirits of migrating our repo to the ASWF, would like to once and for all come to a resolution on the OCIO + ACES dilemma.

There are a number of issues that are rolled under this banner and by no means can they be (or should they be) resolved in this email thread, but I will do my best to lay them out as they are...

As the world exists today:
  1.  Due to HP's and Thomas's contributions to the OpenColorIO-Configs repo not being licensed, they are unable to be carried over to the ASWF as-is
  2. The ACES 1.1 OCIO configs, due to various factors, have yet to be merged into the SPI OpenColorIO-Configs repo and yet, are already seeing active use
  3. There will likely be multiple versions of the ACES 1.1 OCIO config in existence due to continued discussion about what should be included and the names they are given
  4. Ownership of the ACES OCIO configs presently sits outside of both ACES and OCIO (though the contributors are closely involved with both projects)
  5. The OpenColorIO-Configs repo size has become a burden to work with
A step towards tomorrow:
  1. The ACES OCIO Configs should be assigned a license
  2. The ACES 1.1 config should be merged to Master as-is
    1. Updates pushed and versioned as-per the next bullet
  3. I propose a repository structure such as can be found in my fork (
    1. All old ACES configs are removed from master
    2. Dedicated ACES configs branches and tags will be created
    3. The dedicated ACES config tags will have a secondary version number
    4. All users of the configs should be pointed to the Release zips
A path to the future:
  1. An ACES virtual working group should be formed to outline the clear path of the ACES OCIO configs
  2. A new-breed config repository should be crafted to move under the ASWF
    1. Clear license inherited from ASWF
    2. All Configs and LUTs must be generated by CI as artefacts
    3. Repo structure and artefacts must account for:
      1. External Versioning (e.g. ACES)
      2. Internal Versioning (e.g. naming changes)
      3. OCIO Versioning (e.g. utilising v2.x features)
As a general summary I personally don't think the OpenColorIO-Configs repo, as it exists today, should be merged to the ASWF at all. Instead, we really do need to build a fresh slate and a new way of thinking about creating and distributing OCIO Configs (both ACES and non-ACES). This should happen as a new wave of development.

I think its quite clear the present Imageworks Configs repo and its configs should (and will) continue to be supported while future development happens.

Please let me know your thoughts, and please start a new thread if your topic of discussion warrants in-depth conversation (such as the ACES Working Group). Or please continue the conversation on the relevant GitHub PR:

Join to automatically receive all group messages.