1. Ocio-Dev
  2. Topics

OpenColorIO stewardship

Mark Visser <mvi...@...>
 

Hi all, 

Development in the main imageworks/OpenColorIO branch seems to have stalled. The last commit is from September, 2014, and the number of issues and pull requests continues to grow.

What do folks think about creating an OpenColorIO github organization and centralizing development there? I know there are several active forks at other studios, but looking at the official repo and web site, the project would appear to be dead. I don't imagine downstream maintainers will pull from anywhere but the official repo, so any fixes and features made in other forks won't show up in Nuke/Maya/RV/etc.

best,
Mark
Mark Boorer <mark...@...>
 

Hi Mark,

We have a number of large changes about to land in the public repository, and whilst I know it's frustrating to see the repo stagnant, by no means is the project dead.
My current goal is to put our humungous patch out into the public domain, seek feedback, and then assess how that affects the state of the existing pull requests / issues.
This patch should tackle a number of outstanding issues, primarily the plugin arcitecture, differences between the GPU and CPU code-paths, better unit testing, improved CMake code for cross platform builds, documentation, and repository structure. There are others working on new file-format plugins whose work I am hoping to integrate soon.

In addition, there is also a large amount of organisation happening behind-the-scenes to do with our official ACES implementation on the config side of things.

I am working towards having this ready for feedback by the new year, and once this is done we will hopefully see a lot more activity in the open again.

Cheers,
Mark



On Tue, Nov 24, 2015 at 3:31 PM, Mark Visser <mvi...@...> wrote:
Hi all, 

Development in the main imageworks/OpenColorIO branch seems to have stalled. The last commit is from September, 2014, and the number of issues and pull requests continues to grow.

What do folks think about creating an OpenColorIO github organization and centralizing development there? I know there are several active forks at other studios, but looking at the official repo and web site, the project would appear to be dead. I don't imagine downstream maintainers will pull from anywhere but the official repo, so any fixes and features made in other forks won't show up in Nuke/Maya/RV/etc.

best,
Mark

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.
Deke Kincaid <dekek...@...>
 

It would be really good if we could also get the OpenColorIO-Configs up to date. 11 months is a little long for a simple update to the ACES config which Hp has had in his fork since it's release. Silly as it sounds, things like this actually prevent some software vendors from including the ACES 1.0 config with the official software distribution as it's not in the official release but a fork.  From the user POV this causes many people to use old & outdated configs and then they are confused about why it doesn't work right.
Mark Visser <mvi...@...>
 

Hi Mark,

Could you give us an update on the timeline?

thanks,
-Mark

On Tuesday, November 24, 2015 at 10:55:48 AM UTC-5, Mark Boorer wrote:
Hi Mark,

We have a number of large changes about to land in the public repository, and whilst I know it's frustrating to see the repo stagnant, by no means is the project dead.
My current goal is to put our humungous patch out into the public domain, seek feedback, and then assess how that affects the state of the existing pull requests / issues.
This patch should tackle a number of outstanding issues, primarily the plugin arcitecture, differences between the GPU and CPU code-paths, better unit testing, improved CMake code for cross platform builds, documentation, and repository structure. There are others working on new file-format plugins whose work I am hoping to integrate soon.

In addition, there is also a large amount of organisation happening behind-the-scenes to do with our official ACES implementation on the config side of things.

I am working towards having this ready for feedback by the new year, and once this is done we will hopefully see a lot more activity in the open again.

Cheers,
Mark



On Tue, Nov 24, 2015 at 3:31 PM, Mark Visser <mvi...@...> wrote:
Hi all, 

Development in the main imageworks/OpenColorIO branch seems to have stalled. The last commit is from September, 2014, and the number of issues and pull requests continues to grow.

What do folks think about creating an OpenColorIO github organization and centralizing development there? I know there are several active forks at other studios, but looking at the official repo and web site, the project would appear to be dead. I don't imagine downstream maintainers will pull from anywhere but the official repo, so any fixes and features made in other forks won't show up in Nuke/Maya/RV/etc.

best,
Mark

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Andy Jones <andy....@...>
 

Bumping this, specifically WRT ACES 1.0 in the configs.  It would be great to get some kind of (hopefully short) timeline on that.  The configs in Nuke seem to be some ancient checkout of the examples, and we'd like to pressure them to bring them up to date for their next release.  We'd really like to see ACES 1.0 included in that update.  It seems like there's a chance Nuke might end up pulling from HP's github if the update doesn't happen soon, but I would imagine it's in everyone's best interest to keep everything pointed at the original repo.

If there's a big refactor of the configs going on for the major release mentioned above, perhaps it's worth making a branch and merging HP's ACES 1.0 config into master until that's ready?  Even if the configs are likely to need to change with the updates, it seems like places may need a legacy ACES 1.0 config for a while, until the future library makes its way into the apps.
Haarm-Pieter Duiker <li...@...>
 

Hey Andy,

Here's an update from my side on the issue. After a bit of delay, Mark and the OCIO leadership have agreed to accept the pull request to integrate the ACES 1.0.1 config into the main OCIO configs repo. They have asked me to combine the commit history into a single commit before doing so, so the commit history for the general repo doesn't suddenly have a huge list of commits that won't mean much to most people. It's on my to do list. I'm also on a project that is barreling head-long towards a deadline this week, so that's taking precedence right now. I'm hoping to have the commits squashed this weekend so the pull request can be accepted.

Mark, correct me if that's not in line with your understanding.

HP




On Tue, Mar 8, 2016 at 2:37 PM, Andy Jones <andy....@...> wrote:
Bumping this, specifically WRT ACES 1.0 in the configs.  It would be great to get some kind of (hopefully short) timeline on that.  The configs in Nuke seem to be some ancient checkout of the examples, and we'd like to pressure them to bring them up to date for their next release.  We'd really like to see ACES 1.0 included in that update.  It seems like there's a chance Nuke might end up pulling from HP's github if the update doesn't happen soon, but I would imagine it's in everyone's best interest to keep everything pointed at the original repo.

If there's a big refactor of the configs going on for the major release mentioned above, perhaps it's worth making a branch and merging HP's ACES 1.0 config into master until that's ready?  Even if the configs are likely to need to change with the updates, it seems like places may need a legacy ACES 1.0 config for a while, until the future library makes its way into the apps.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.
Mark Boorer <mark...@...>
 

Hi All,

Apologies Mark, I missed your previous request for an update, it's been a bit busier this year than I expected!

Andy, et al; As Haarm-Pieter put it, I am currently awaiting his final changes before I can merge his ACES 1.0.1 config into the repo. At the moment, the OpenColorIO-Configs repository is not versioned in lock step with the library, so I see no reason why this cannot go out immediately. Initially I'd had some reservations about the sheer size of the commits, and that the addition of other, non OpenColorIO related data would have an adverse effect on the usability / maintainability of the repository, but people seem keen to use this repo as a central ACES reference implementation, rather than just a place for OCIO configs, so I plan on putting it through in one go.

The current re-factoring work is regrettably still not finished, as my other day-to-day production tasks at DNeg have become more pressing of late. I have some time for dev work booked out in the coming weeks though, so hopefully I will have something more to show soon. My greater goal is to have everything out, feedback gathered, and tested before the SIGGRAPH 2016 deadline in order to make the changes available in the VFX platform for 2017.

In short, the ACES 1.0.1 configs will go out as soon as the final cleanup is done, and the library changes will be out for feedback hopefully not long after.

Cheers,
Mark

On Tue, Mar 8, 2016 at 8:26 PM, Haarm-Pieter Duiker <li...@...> wrote:
Hey Andy,

Here's an update from my side on the issue. After a bit of delay, Mark and the OCIO leadership have agreed to accept the pull request to integrate the ACES 1.0.1 config into the main OCIO configs repo. They have asked me to combine the commit history into a single commit before doing so, so the commit history for the general repo doesn't suddenly have a huge list of commits that won't mean much to most people. It's on my to do list. I'm also on a project that is barreling head-long towards a deadline this week, so that's taking precedence right now. I'm hoping to have the commits squashed this weekend so the pull request can be accepted.

Mark, correct me if that's not in line with your understanding.

HP




On Tue, Mar 8, 2016 at 2:37 PM, Andy Jones <andy....@...> wrote:
Bumping this, specifically WRT ACES 1.0 in the configs.  It would be great to get some kind of (hopefully short) timeline on that.  The configs in Nuke seem to be some ancient checkout of the examples, and we'd like to pressure them to bring them up to date for their next release.  We'd really like to see ACES 1.0 included in that update.  It seems like there's a chance Nuke might end up pulling from HP's github if the update doesn't happen soon, but I would imagine it's in everyone's best interest to keep everything pointed at the original repo.

If there's a big refactor of the configs going on for the major release mentioned above, perhaps it's worth making a branch and merging HP's ACES 1.0 config into master until that's ready?  Even if the configs are likely to need to change with the updates, it seems like places may need a legacy ACES 1.0 config for a while, until the future library makes its way into the apps.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/d/optout.
Andy Jones <andy....@...>
 

Thanks for the update, guys. Much appreciated, as well as all of the ongoing efforts with both ACES and OCIO!

If it seems like it would make sense in the long term to distribute ACES configs separately from the OCIO examples, I wouldn't have any problem with that.  I can see where it might make it easier to juggle ACES updates and OCIO library updates.  But it does seem like our best bet for getting ACES 1.0 into this year's releases might be to avoid rocking the boat too much and stick with the plan you guys outlined.
nick....@...
 

Hi,

On Tuesday, March 8, 2016 at 4:33:21 PM UTC-8, Mark Boorer wrote:

The current re-factoring work is regrettably still not finished, as my other day-to-day production tasks at DNeg have become more pressing of late. I have some time for dev work booked out in the coming weeks though, so hopefully I will have something more to show soon. My greater goal is to have everything out, feedback gathered, and tested before the SIGGRAPH 2016 deadline in order to make the changes available in the VFX platform for 2017.

We are in the process of publishing the draft VFX Reference Platform for CY2017 so please can you give an update on when you expect this next release to drop and, if it's in time for vendors to incorporate into their 2017 releases, what version number it's likely to be released under so we can include it.

Thanks,

Nick

 

1 - 9 of 9