Date   

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.


Re: PLEASE READ: OpenColorIO repo moving

Diogo Girondi
 

Thanks for the heads-up Michael!

Cheers,
Diogo

 


From: ocio-dev@... on behalf of Michael Dolan <michdolan@...>
Sent: Thursday, September 26, 2019 7:34 PM
To: ocio-dev@...
Subject: [ocio-dev] PLEASE READ: OpenColorIO repo moving
 
Hi all,

It's been a busy year for OpenColorIO!

We recently graduated from an incubation to adopted ASWF project (more on what that means at this link). It was a lot of work getting to that point, but we got it done. Now it is time to move the OpenColorIO GitHub repo from the Imageworks organization to the AcademySoftwareFoundation organization.

The good news is GitHub handles this process fairly seamlessly. The old URLs will forward to the new ones, so the impact on the wider community should be minimal. We will update this thread with status updates and to provide further information about the move or any expected disruptions.

This process will likely be completed over the next week, so stay tuned. Also note that we are NOT moving the OpenColorIO-Configs repo at this time. That will remain with the Imageworks GitHub organization for now.

Thanks!


PLEASE READ: OpenColorIO repo moving

Michael Dolan
 

Hi all,

It's been a busy year for OpenColorIO!

We recently graduated from an incubation to adopted ASWF project (more on what that means at this link). It was a lot of work getting to that point, but we got it done. Now it is time to move the OpenColorIO GitHub repo from the Imageworks organization to the AcademySoftwareFoundation organization.

The good news is GitHub handles this process fairly seamlessly. The old URLs will forward to the new ones, so the impact on the wider community should be minimal. We will update this thread with status updates and to provide further information about the move or any expected disruptions.

This process will likely be completed over the next week, so stay tuned. Also note that we are NOT moving the OpenColorIO-Configs repo at this time. That will remain with the Imageworks GitHub organization for now.

Thanks!


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

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

Cancelled: OpenColorIO TSC meeting (weekly)

This event has been cancelled.

When:
Monday, 2 September 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: Setting OCIO->Displays->Active in RV

Ravindra Korde
 

Hi Michael,

No problem at all.
I will check the links you provided & try to create it in RV.


On Mon, Aug 19, 2019, 8:22 PM Michael Dolan <michdolan@...> wrote:
Sorry for the late reply. It might be worth asking this question on RV's support site instead, since it pertains to their bundled OCIO package:

https://support.shotgunsoftware.com

Here are some really old developer docs about customizing OCIO in RV, which may or may not be a helpful starting point:


On Thu, Aug 1, 2019, 10:47 PM Ravindra Korde, <rravindrakorde@...> wrote:
Hi All,
 
Every time after loading a ocio.config file in RV i have to go to the ocio menu & select displays to active. so I'm trying to set displays to active automatically as i load a config file, but i couldn't find anything it.
I have search for it in every .mu file in RV which supports to assignments.
 
Can anyone have any idea how to do it in RV?


Re: Setting OCIO->Displays->Active in RV

Michael Dolan
 

Sorry for the late reply. It might be worth asking this question on RV's support site instead, since it pertains to their bundled OCIO package:

https://support.shotgunsoftware.com

Here are some really old developer docs about customizing OCIO in RV, which may or may not be a helpful starting point:


On Thu, Aug 1, 2019, 10:47 PM Ravindra Korde, <rravindrakorde@...> wrote:
Hi All,
 
Every time after loading a ocio.config file in RV i have to go to the ocio menu & select displays to active. so I'm trying to set displays to active automatically as i load a config file, but i couldn't find anything it.
I have search for it in every .mu file in RV which supports to assignments.
 
Can anyone have any idea how to do it in RV?


Re: SIGGRAPH 2019 - OpenColorIO Birds of a Feather

Pipeliner TD
 

thank you for sharing the presentation!

Am Mi., 31. Juli 2019 um 20:44 Uhr schrieb Michael Dolan <michdolan@...>:

Hello all,

We held the OpenColorIO Birds of a Feather yesterday at SIGGRAPH in LA. Thank you to everyone who could join us! We directly followed the ACES BoF and both events had very good attendance. For those who couldn't be there, we recorded the meeting and will make the video available following SIGGRAPH. 

I opened the BoF with a project update covering our ASWF incubation status, related improvements to the OCIO build and CI systems, and a summary of Thomas Mansencal's work on the ACES 1.1 OCIO config. Doug Walker and Patrick Hodoul then outlined their progress and roadmap for OCIO v2, as well as discussing support for new pixel formats, ACES output transforms, CLF, and measurable CPU renderer performance gains. Lastly, Mark Boorer gave an overview of his work on the companion OpenColorMath library, covering its design, interface, and vision for where to take it next.

The presentation slides are attached to this thread, where you can find a detailed outline of the information presented. Feel free to respond with any questions or points of discussion.

I wanted to also give a big thanks to Emily Olin, John Mertic, and the rest of the Linux Foundation team for skillfully organizing this event (as well as 9 other open source BoF meetings for Open Source Day!).

Thanks!


Re: Compile order for OCIO, OIIO, OpenExr?

Mark Boorer
 

> Is there a target to build only the OpenColorIO tools?

-DOCIO_BUILD_APPS=OFF

-DOCIO_BUILD_APPS=ON

You will unnecessarily build the core lib twice, but reinstalling it over the top should cause no issues.


On Thu, 8 Aug 2019, 19:39 Gonzalo Garramuño, <ggarra13@...> wrote:

El 8/8/19 a las 15:32, Mark Boorer escribió:
> 1. OpenEXR
> 2. OpenColorIO
> 3. OpenImageIO
> 4. OpenColorIO tools
>
> The core OCIO library doesn't depend on OIIO, only the extra tools.
Is there a target to build only the OpenColorIO tools?

--
Gonzalo Garramuño





Re: Compile order for OCIO, OIIO, OpenExr?

Larry Gritz
 

This is all my understanding, too. To recap:

OIIO's dependency on OCIO is fundamental (well, if you want all the color conversion functionality, which of course any studio user does). 

OCIO's dependency on OIIO is limited. If you just need the OCIO libraries, OIIO is not needed at all. The ways that OCIO uses OCIO are strictly for ocioconvert, ociodisplay, and ociolutimage.

ocioconvert is a historical quirk dating from a time when OIIO did not have OCIO support and there was an actual purpose to 'ocioconvert', whereas now you just want to use 'oiiotool --colorconnvert.

ociodisplay is really just an example (and maybe ocioconvert is, too), and as examples, they don't need the full flexibility of an OpenImageIO-backed support of all possible data and file formats. So maybe a solution there is, say, to support OpenEXR only and use tinyexr (a header-only implementation of just exr core features).

ociobakelut is a little more fundamental, though only used by power users. But again, if you're willing to stipulate that the baked LUT images are always openexr, maybe there as well using OpenEXR or even tinyexr will let us avoid pulling all of OIIO in.

Also, it is worth noting that if these utilities were changed from C++ to Python, even if they still use OIIO, it would at least be a simple runtime dependency and not a circular build-order dependency.

-- lg


On Aug 8, 2019, at 11:39 AM, Sloan, Blake <bsloan@...> wrote:

Hi Steve!
 
OpenEXR does not (and should not) depend on OCIO.
 
I think I bring the OCIO->OIIO dependency up at every BoF.
 
What Mark suggests works but is a bit more complicated for shops using an automated build system (OCIO build may succeed but link to the system’s installed OIIO libs instead of the yet-to-be-built ones)  
 
Build OCIO without ociorender
Build OIIO against OCIO (make sure rpaths do not explicitly point to OCIO build directory)
Build OCIO with ociorender against OIIO
Install OCIO
Install OIIO
 
OIIO’s dependency on on OCIO is, in my opinion, a necessary thing as it allows OIIO clients to manage color using OCIO.
 
OCIO’s dependency on OIIO is not essential and should be deprecated (I think its current custodians are in agreement). One of OCIO’s example executables (ociorender?) depends on OIIO for image file IO. This executable can either be 
  1. moved to a separate package, say OpenColorIOExtensions,
  2. made a build option that defaults to off, or better,
  3. made to depend on a lightweight image library whose code ships with OCIO (ppm?)
  4. dropped altogether from the build, as an installation of OIIO built against OCIO will already have oiiotool, whose functionality overlaps with ociorender.   
       
 
-blake
 

--
Larry Gritz




301 - 320 of 2147