Date   

Re: pyOCIO Windows compilation error against Python36

renaudtalon@...
 

That's great news, thank you !


Re: pyOCIO Windows compilation error against Python36

Michael Dolan
 

I'm currently writing new Python bindings for OCIO (with pybind11, targeting the 2.0 release), which will support Python 3 (and 2). Stills a ways to go, but it's in the works.


On Wed, Oct 23, 2019 at 1:01 PM <renaudtalon@...> wrote:
Sorry for re-opening this so late. I did test the fix I thought work among other few things but I can't get OCIO to work with Python 3+ on Windows.
I tested with both OCIO 1.1 and OCIO 2.0 (master branch) and I can't compile against Python3. Any news on when this will be supported ?
Thank you.


Re: pyOCIO Windows compilation error against Python36

renaudtalon@...
 

Sorry for re-opening this so late. I did test the fix I thought work among other few things but I can't get OCIO to work with Python 3+ on Windows.
I tested with both OCIO 1.1 and OCIO 2.0 (master branch) and I can't compile against Python3. Any news on when this will be supported ?
Thank you.


Cancelled Event: OpenColorIO TSC meeting (weekly) - Monday, 14 October 2019 #cal-cancelled

ocio-dev@lists.aswf.io Calendar <ocio-dev@...>
 

Cancelled: OpenColorIO TSC meeting (weekly)

This event has been cancelled.

When:
Monday, 14 October 2019
9:30am to 10:00am
(UTC-07:00) America/Los Angeles

Where:
https://zoom.us/j/924729729

Organizer: Michael Dolan michdolan@...

Description:
Weekly meeting of the OpenColorIO TSC.

Add topics to the meeting agenda.

Meeting notes listed by YYYY-MM-DD.md format at: 
https://github.com/imageworks/OpenColorIO/tree/master/docs/tsc/meetings


Join Zoom Meeting
https://zoom.us/j/924729729

One tap mobile
+16699006833,,924729729# US (San Jose)
+16465588656,,924729729# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 924 729 729
Find your local number: https://zoom.us/u/abo9cwSMxj


Re: Expected release of OCIO from its new home in AcademySoftwareFoundation/OpenColorIO

jrb@...
 

Thanks for the update Michael,

 That all makes sense. I saw that assignment bug and got worried that cut wasn't something I should really consider. Looking forward to 2.x.

Cheers,
- James


Re: Expected release of OCIO from its new home in AcademySoftwareFoundation/OpenColorIO

Michael Dolan
 

Hi James,

OCIO 1.1.1 should compile if you tell your compiler to not treat warnings as errors, or pass a flag to ignore that particular warning.

That warning was resolved in master a while back, but was only fixed recently (after 1.1.1) in RB-1.1, which represents the 1.x source. Master is the OCIO 2.x dev branch. We will be making a 1.1.2 release later this year with that and some other fixes. You can test it now by building from RB-1.1.

If this doesn't solve the problem, you can file an issue in GitHub. These new warnings popping up are mostly due to newer compiler versions that were not included in OCIO CI until recently. I fixed this exact issue in RB-1.1 a few weeks ago when Travis-CI bumped their Ubuntu version.

Thanks!
Michael

On Wed, Oct 9, 2019, 9:19 PM , <jrb@...> wrote:
Hi,
 I was trying to pick a more modern version of OCIO than the one I've been using (1.0.9) so I started at the latest at the old download location https://opencolorio.org/downloads.html with v1.1.1. Unfortunately, that didn't compile because of a typo in Config.cpp in the operator= method that tries assign to itself. So then I wondered if that had been fixed in github (yes) and then wondered if any of the tags there were newer than the fix, no. What's odd is the fix to that typo was back in 2018 but the old website says v1.1.1 was from March 2019. A little confused at that point so I thought I'd ask here: 

What I really want to know is, when is the next (stable-ish) version of OCIO expected to be cut? Or has it been and I'm just too dumb to understand the branches/tags in github?

Cheers,
- James


Expected release of OCIO from its new home in AcademySoftwareFoundation/OpenColorIO

jrb@...
 

Hi,
 I was trying to pick a more modern version of OCIO than the one I've been using (1.0.9) so I started at the latest at the old download location https://opencolorio.org/downloads.html with v1.1.1. Unfortunately, that didn't compile because of a typo in Config.cpp in the operator= method that tries assign to itself. So then I wondered if that had been fixed in github (yes) and then wondered if any of the tags there were newer than the fix, no. What's odd is the fix to that typo was back in 2018 but the old website says v1.1.1 was from March 2019. A little confused at that point so I thought I'd ask here: 

What I really want to know is, when is the next (stable-ish) version of OCIO expected to be cut? Or has it been and I'm just too dumb to understand the branches/tags in github?

Cheers,
- James


Re: ACES OpenColorIO-Configs (and other stories)

Doug Walker
 

Sean, thank you for the detailed and well thought out proposal.  I fully support it but agree the versioning plan needs some more discussion.

 

Given that OCIO v2 has some features that are specifically aimed at benefiting ACES config development, I would anticipate needing separate OCIO v1 and v2 versions of the config during the transition period.  So I do agree that there are three versions to work into the release naming:  ACES version, OCIO version, and Config version. 


Any ideas for how to work the OCIO version into the branch naming and repo directory structure naming? 

 

Doug

 

 

From: Sean Cooper <sean@...>
Date: Tuesday, October 1, 2019 at 7:47 PM
To: Thomas Mansencal <thomas.mansencal@...>
Cc: Michael Dolan <mdolan@...>, "ocio-dev@..." <ocio-dev@...>, Scott Dyer <sdyer@...>, Mark Boorer <markboo99@...>, Doug Walker <Doug.Walker@...>, Haarm-Pieter Duiker <hpd@...>, Kevin Wheatley <kevin.j.wheatley@...>, Carl Rand <carl.rand@...>, Larry Gritz <lg@...>, Patrick Hodoul <Patrick.Hodoul@...>, Alex Forsythe <aforsythe@...>, John Mertic <jmertic@...>
Subject: Re: [ocio-dev] ACES OpenColorIO-Configs (and other stories)

 

The descriptions and release notes definitely needed some love, but since it was just a draft proposal I didn't put that effort in. I also think the release names could be better as "ACES-v1.1.0_Config-v1", which is as clear as it can be (I think).

 

"ACES-v1.1.0_OCIO-v1.1_Config-v1" starts to get painful, but it is the reality of the versioning-magedon.

 

I still think maintaining the releases for all configs that were once in the master branch is useful for now, instead of them just disappearing to the annals of git history. If a user can't figure out the releases from email announcements, in-line descriptions, and links from ACESCentral and the OpenColorIO website... then we're all just a stones throw away.

 

Keeping in mind my overall intention is to make all of this disappear with a better system.

 

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

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?

 

 

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

 

 

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

 

 

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

 

 


 

--

Michael Dolan

Color Scientist

Sony Pictures Imageworks

p. (604)673-3886

e. mdolan@...


Re: ACES OpenColorIO-Configs (and other stories)

Sean Cooper
 

The descriptions and release notes definitely needed some love, but since it was just a draft proposal I didn't put that effort in. I also think the release names could be better as "ACES-v1.1.0_Config-v1", which is as clear as it can be (I think).

"ACES-v1.1.0_OCIO-v1.1_Config-v1" starts to get painful, but it is the reality of the versioning-magedon.

I still think maintaining the releases for all configs that were once in the master branch is useful for now, instead of them just disappearing to the annals of git history. If a user can't figure out the releases from email announcements, in-line descriptions, and links from ACESCentral and the OpenColorIO website... then we're all just a stones throw away.

Keeping in mind my overall intention is to make all of this disappear with a better system.


On Tue, Oct 1, 2019 at 11:58 PM Thomas Mansencal <thomas.mansencal@...> wrote:
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:

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



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




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



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:




--

Michael Dolan

Color Scientist

Sony Pictures Imageworks

p. (604)673-3886

e. mdolan@...


Re: ACES OpenColorIO-Configs (and other stories)

Thomas Mansencal
 

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:

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



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




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



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:




--

Michael Dolan

Color Scientist

Sony Pictures Imageworks

p. (604)673-3886

e. mdolan@...


Re: ACES OpenColorIO-Configs (and other stories)

Sean Cooper
 

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:

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



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




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



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:




--

Michael Dolan

Color Scientist

Sony Pictures Imageworks

p. (604)673-3886

e. mdolan@...


Re: ACES OpenColorIO-Configs (and other stories)

Thomas Mansencal
 

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

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



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




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



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:




--

Michael Dolan

Color Scientist

Sony Pictures Imageworks

p. (604)673-3886

e. mdolan@...


Re: ACES OpenColorIO-Configs (and other stories)

Sean Cooper
 

@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




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



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:



Re: ACES OpenColorIO-Configs (and other stories)

Thomas Mansencal
 

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




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



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:



Re: ACES OpenColorIO-Configs (and other stories)

Deke Kincaid
 

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



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:



Re: ACES OpenColorIO-Configs (and other stories)

Thomas Mansencal
 

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



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:



Re: PLEASE READ: OpenColorIO repo moving

Richard Shaw
 

On Mon, Sep 30, 2019 at 12:10 PM Michael Dolan <michdolan@...> wrote:
The OpenColorIO repo has been moved. The new URL is:

https://github.com/AcademySoftwareFoundation/OpenColorIO
Previous URLs will forward to this new location.

Fedora SPEC file updated and at release-monitoring.org:


Thanks,
Richard 


ACES OpenColorIO-Configs (and other stories)

Sean Cooper
 

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:



Re: PLEASE READ: OpenColorIO repo moving

Larry Gritz
 

Please also note that contributors to OCIO henceforth need to sign appropriate CLAs with LF/ASWF. Please do not send any OCIO related CLAs to Imageworks. Not our circus, not our monkeys. :-)



On Mon, Sep 30, 2019 at 10:10 AM Michael Dolan <michdolan@...> wrote:
The OpenColorIO repo has been moved. The new URL is:

https://github.com/AcademySoftwareFoundation/OpenColorIO
Previous URLs will forward to this new location.



--
Larry Gritz
lg@...


Re: PLEASE READ: OpenColorIO repo moving

Michael Dolan
 

The OpenColorIO repo has been moved. The new URL is:

https://github.com/AcademySoftwareFoundation/OpenColorIO
Previous URLs will forward to this new location.

301 - 320 of 2155