Maybe we keep the tags as they are but create smaller amount of explicit releases with good descriptions of what they are? Users will most likely look for releases anyway.

On Wed, 2 Oct 2019, 11:11 Sean Cooper, <sean@...> wrote:

The dual version numbers is pretty gross, but I'm not sure how else you can have two independent versions tracked. Unless we just don't care about having independent ACES Config releases, and only track versions of the repository as a whole. Its an open question.

 

Its unfortunate that the OpenColorIO-Configs and ACES version are both v1.1 at the moment.

 

The general logic of my fork is:

vX.X are OpenColorIO-Config version numbers

 

ACES-X.X.X_Y.Y.Y are the <ACES>_<OCIO-Config> versions.

 

Other options could be:

• ACES-1.1.0_Config-1.0
• ACES 1.1.0 OpenColorIO-Config v1.0

 

 

On Tue, Oct 1, 2019 at 8:28 PM Thomas Mansencal <thomas.mansencal@...> wrote:

@Sean: I'm not saying we should remove them, but just clean up the stack:

e.g. which one do I take for ACES 1.1? v1.1 or ACES-1.1.0_v1.0.0?

Thomas Mansencal - colour-science.org - thomasmansencal.com

 

 

On Wed, 2 Oct 2019 at 07:04, Michael Dolan <mdolan@...> wrote:

The sony and nuke configs (with accompanying Python code) are also great as really simple examples of building a custom config. The aces config code is much more daunting to someone new to OCIO, so while these older configs themselves aren't as relevant these days, the educational value is high enough to keep them around IMO.

 

On Tue, Oct 1, 2019 at 7:57 AM Sean Cooper <sean@...> wrote:

@Deke

The Sony configs are heavily referenced in the present documentation (the only place where real OCIO usage is described) so until a new user-story is put forth they should remain accessible.

 

I'd wait to hear from The Foundry reps on whether the nuke-default should exist there or not. If it's still useful I don't think it's causing harm.

 

The onus is certainly on OCIO v2 Docs to learn from OCIO v1 and provide clear and obvious modern use cases and implementation references.

 

@Thomas

I don't think the tags/releases would pollute the ecosystem too much and provided a very simple link-able way for end-users to avoid ever touching git, which was my intent.

 

Doing this also drops the download size quite a bit because you aren't pulling down all of time when you download the zip, or even git clone from master.

 

On Tue, Oct 1, 2019 at 9:20 AM Thomas Mansencal <thomas.mansencal@...> wrote:

Hi Deke,

To be fair, at this stage, I don't think it hurts to leave them as they are.

To some extent, the SPI Gospel is what tipped the balance on my end to improve the shaper, if people did not do comparisons with it recently, maybe I would not have done it :]

I had the same quibble about the version number on the folder. I said to myself that while not super elegant, it was no big deal and would actually help non-techie users to know exactly which config they get. I must admit it is itching a bit :)

Cheers,

Thomas

Thomas Mansencal - colour-science.org - thomasmansencal.com

 

 

On Tue, 1 Oct 2019 at 21:08, Deke Kincaid <dekekincaid@...> wrote:

Comments on II #3

• Why even include the nuke-default?  Those are the configs from Nuke 6.3 when OCIO was first implemented in Nuke 7-8 years ago, wildly out of date compared to what ships with the software.  
• Same with both Sony examples, also wildly out of date compared to what is used internally at Sony (unless they contribute new ones as examples).  

• I have seen many people use the Sony configs as gospel when they should perhaps be looking at the ACES config instead as an example.

• minor quibble: Why include the ACES version number in the folder name, this should be representative of the tag, not the folder name.

 

On Tue, Oct 1, 2019 at 12:34 AM Thomas Mansencal <thomas.mansencal@...> wrote:

Hi,

Crossing fingers for things to move forward! I cannot say we have not tried :)

A few comments:

I.1: As mentioned in https://github.com/imageworks/OpenColorIO-Configs/pull/17, I'm fine with whatever license is chosen, and HP said that his work was done under the Academy Umbrella thus the Academy license should apply, so there should not be a problem fixing that.
I.3: Are you referring to the 2.2, 1.8 and Venice recent discussions?

II.2: Agreed!
II.3: Sounds good! Although we should drop some tags/releases, it is excessively confusing currently and because Github cannot render the diffs it makes the experience a bit traumatic.

III.1: Sounds good too, I'm assuming that the AMPAS drives it?
III.2: Yes!

I would need to think about the minute details but seems like a good plan to me, I like it :)

Thomas Mansencal - colour-science.org - thomasmansencal.com

 

 

On Tue, 1 Oct 2019 at 14:21, Sean Cooper <sean@...> wrote:

Hello,

 

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 (https://github.com/scoopxyz/OpenColorIO-Configs)

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:

https://github.com/imageworks/OpenColorIO-Configs/pull/17

 

 

 

--

Michael Dolan

Color Scientist

Sony Pictures Imageworks

p. (604)673-3886

e. mdolan@...