Hello all,

This is mostly directed at those currently leading the OpenColorIO project, but I would be happy for any input or information anyone else can provide.

Most of you are likely aware of the outstanding issue that causes pretty severe banding and other visual differences in images processed using OCIO's GPU code path (documented here). This issue effectively prevents OCIO from being used in a GPU-dependent application like RV without resorting to workarounds like intermediate baking of temporary LUT files.

Because the Github repository has remained unchanged for two years now, and (more surprisingly) no one else seems to be asking about this issue in any public forums, I wanted to try and get some general information on the state of OpenColorIO development. This general question has been asked before (see this thread from November of last year), and there was mention of a large amount of new code that was about to be released, but that has yet to materialize. I don't know if there are other communication channels I'm not privy to, but to put it bluntly, the project seems to have lost its pulse.

At this point, we are seriously considering trying to fix the GPU code ourselves to make OCIO a viable part of RV. However, that post specifically mentioned that the forthcoming updates would tackle "differences between the GPU and CPU code-paths" (among other things), so if we decide to dive into that rabbit hole, I'm wondering if there would be any way we could get our hands on whatever progress has been made and get a better idea of the state of things first. Like I mentioned, I'm genuinely surprised that there aren't more people making noise about this, so at this point I have to assume that A) not enough people are aware of the problem, B) they don't consider it a serious issue, or C) they're not using RV or anything else that relies on OCIO's GPU code.

Anyway, I don't mean to come across as too doom-and-gloom, but I would appreciate any information anyone is willing to share, even if it's not very encouraging.

Thanks,


-Nathan

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Without tetrahedral interpolation you can get better results by creating 65x cubes instead of the default of 32x that the example OCIO configs use (very easy to create with Hp's python script included with the ACES configs).  It's still not as good as tetrahedral interpolation but it is close enough for gpu playback.  Kevin Wheatley had some good slides & charts on this from his ACES presentation at Digipro if you have an ACM account.

A Retrospective on the Adoption of the ACES Technology at Framestore 

http://dl.acm.org/citation.cfm?id=2947695

-deke

On Wednesday, September 7, 2016, DBR - Ben <dbr....@...> wrote:

I have no insight into the activity of the project - but from the outside the project does appears rather dead (no commits to the repo since Sep 2014, tickets piling up with little response, even simple pull requests unacknowledged)

If there is development happening, that is good.. but as one of the previously more active contributors to the project, it would sadden me the project has moved away from the "open-development" approach which encouraged me to contribute in the first place

(there was a nice part in one of the slides of an early OCIO presentation - http://www.tdforum.eu/pdf/2011ntfd_ocio_selan.pdf - "We really do our development in public/We’ve made some embarrassing mistakes/Integrity, not fear/Airing dirty laundry breeds trust amongst community")

> Like I mentioned, I'm genuinely surprised that there aren't more people making noise about this, so at this point I have to assume that A) not enough people are aware of the problem, B) they don't consider it a serious issue, or C) they're not using RV or anything else that relies on OCIO's GPU code

If the problem is as I suspect (mentioned in linked ticket #394 - there is no tetrahedral interpolation in GPU code path) - I suspect the the reasons people seem so quiet about the issue are numerous.. In addition to the options you describe, also:

- I would imagine some footage is more prone than others to highlighting the issue (so depending on the project and how the footage is processed, people might just not notice)

- we heavily rely on RV's GPU path without encountering this issue, using a config based of the ACES 1.0.1 config, but with a custom simpler viewing transform which presumably avoids this issue

- a common theme in that ticket comment was people found a workaround (like baking out intermediate LUT's), which lessens the need to "make noise" about the issue

On 7 September 2016 at 19:21, Nathan Rusch <natha...@...> wrote:

Hello all,

This is mostly directed at those currently leading the OpenColorIO project, but I would be happy for any input or information anyone else can provide.

Most of you are likely aware of the outstanding issue that causes pretty severe banding and other visual differences in images processed using OCIO's GPU code path (documented here). This issue effectively prevents OCIO from being used in a GPU-dependent application like RV without resorting to workarounds like intermediate baking of temporary LUT files.

Because the Github repository has remained unchanged for two years now, and (more surprisingly) no one else seems to be asking about this issue in any public forums, I wanted to try and get some general information on the state of OpenColorIO development. This general question has been asked before (see this thread from November of last year), and there was mention of a large amount of new code that was about to be released, but that has yet to materialize. I don't know if there are other communication channels I'm not privy to, but to put it bluntly, the project seems to have lost its pulse.

At this point, we are seriously considering trying to fix the GPU code ourselves to make OCIO a viable part of RV. However, that post specifically mentioned that the forthcoming updates would tackle "differences between the GPU and CPU code-paths" (among other things), so if we decide to dive into that rabbit hole, I'm wondering if there would be any way we could get our hands on whatever progress has been made and get a better idea of the state of things first. Like I mentioned, I'm genuinely surprised that there aren't more people making noise about this, so at this point I have to assume that A) not enough people are aware of the problem, B) they don't consider it a serious issue, or C) they're not using RV or anything else that relies on OCIO's GPU code.

Anyway, I don't mean to come across as too doom-and-gloom, but I would appreciate any information anyone is willing to share, even if it's not very encouraging.

Thanks,


-Nathan

--
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+unsubscribe@googlegroups.com.
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+unsubscribe@googlegroups.com.
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Thanks for the information Dennis.

If we do end up trying to tackle the OpenGL code path ourselves, I would definitely be interested in the idea of using your changes as a starting point, and an OpenCL code path sounds like it could be an interesting addition to OCIO by itself anyway. I also wonder if the RV developers would be at all interested in taking a look at them.

Are those changes the kind of thing you would potentially be willing to share directly, rather than requiring them to be merged with the main repo first? I ask because the radio silence around the project is starting to get a little unnerving.

Thanks,

-Nathan

On Thursday, September 8, 2016 at 8:19:52 AM UTC+10, Dennis Adams wrote:

This issue not just tetrahedral interpolation, it is the fact that the existing OCIO OpenGL GPU path folds all LUTs into a single 3D LUT, and this is not sufficient for many transformations (especially ACES when both 2D and 3D LUTs are being used).

We fixed this for our GPU processing pipeline and we were working on contributing it back to OCIO, but that effort got stalled (and it doesn't seem like there is anyone to take the pull request anyway). I'd like to gauge interest in what we did so we can determine if we should restart that effort. We added the ability to generate OpenCL 1.1 kernels which have the same processing steps as the CPU path and therefore produce very similar results (within numerical and math function accuracy). Benchmarked across a set of sample transformations it is, on average, 100x faster than the CPU path (ranging from 19x to 636x for the two dozen ACES transformations tested). However, our implementation is only beneficial to those using OpenCL, which is why I'm asking about interest. Notably, the technique we created could be for an accurate OpenGL path by someone needing OpenGL shaders instead of OpenCL kernels, and is only slightly more complicated for the caller than the existing GPU path, so even if you're not using OpenCL but are interested in an accurate OpenGL path, it would be a good starting point.

///d@

Dennis Adams

Sony Creative Software

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

Thanks for the responses everyone.

I'm attempting to reach out to some of the people who may have a connection to or interest in the project's stewardship, and will be asking them to weigh in on this thread so we can get as much information as possible out in the open. Sean, I'm wondering if you might be able to track down any of your colleagues who might have some interest or involvement in order to potentially get their input here as well. I'm not entirely sure how many of the original team are still at Imageworks, or how involved they want to be, so I don't necessarily want to blanket every name I can find.

In general, I'm inclined to agree with Deke that an ideal way forward from our perspective would be for active development to be out in the open on a development branch, rather than only landing in the form of releases.

Dennis, is your fork containing the OpenCL code path available to browse currently?


-Nathan

On Friday, September 9, 2016 at 2:18:51 PM UTC+10, Sean Cooper wrote:

Hello fellow color wizards,

I'd just like to introduce myself to the community here. I've joined Sony Imageworks as our Color Scientist this past January, and have been working on our internal color pipeline and taking on more responsibility as I continue to learn.

I have interest in seeing OCIO continue it's open development, and would like to help where ever I can. Admittedly my background is in pure color/imaging science so I won't be able to immediately jump on the reins of it's core development. However, it seems like we have the opposite problem, and I would be happy to work with you to siphon through its present state and work towards a game plan to give OCIO a fresh breath of life.

Sean Cooper
Color Scientist
Sony Pictures Imageworks

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Been lurking but glad to see a clearly outlined direction.

Also trying not to be mistook as Sean Cooper. 

Sean Looper

On Sep 12, 2016, at 8:58 PM, Larry Gritz <l...@...> wrote:

Thanks for teeing that up, Sean, I was already intending to wade into this tonight. :-)

It has never been SPI's intention to abandon this project, and we definitely want to continue having a significant role in its continued development. We rely on it as heavily as anybody, so we are highly incentivized to keep it alive. I think it makes sense for us to step up as continued host and overall organizer of the project, but without Jeremy we are certainly going to need a lot of help and leadership from the senior developers elsewhere.

I'm really not qualified to run the project -- I have only passing familiarity with OCIO internals and color science. But I do know a thing or two about the proper care and feeding of open source projects, and it makes sense for me as SPI's software architect to help shepherd the process. So I'm prepared to help or kibbitz as needed and to the degree that I'm able. I also have admin privileges on the repo, so if there are necessary tasks such as granting others push privileges and so on, I can help with that backlog.

If anybody is interested in my opinion:

I don't believe in discrete "releases" (in the sense of something being developed offline and occasionally dropped in big hunks into open source).  The successful projects seem to be the ones where the actual day-to-day development is done out in the open on the master branch, with the biggest contributors themselves using the top-of-tree for their own productions. It's ok to have tagged releases or stable branches for the sake of users or vendors who want to lock down to a point where the software and APIs are known to be stable. But it's the user who should move forward in large discrete steps, not the developers. This is how we do it for OIIO and OSL -- in both cases, SPI's production tools build straight from master, we don't use a single line of code that's not on the public GitHub and going through public code review/pull request, and there is no design discussion other than on the public mail list. 

I think the first order of business is triage:

* Revisit all the outstanding pull requests: which are still relevant, which are important, which have been adequately code-reviewed and tested. They should be ranked in terms of how important/helpful they would be to merge. (You can't do them all at once; there has to be some order in which they are rebased, tested, and merged.)

* Revisit all the outstanding issues, close the ones irrelevant, mark duplicates, assess the difficulty of fixing them, and identify if any are potentially addressed by the pull requests.

* Identify people who have made significant improvements in private branches and encourage them to turn them into proper pull requests, so they can be code reviewed and integrated into the master.

Then find a reasonable number of PRs and fixes that can be more or less immediately merged, do so, and tag/release. It doesn't need to be an ambitious release, but releasing something will help put a stake in the ground declaring this as a living project.

I also think it might be helpful to invest some time up front in setting up TravisCI/Appveyor continuous integration to build with several platform configurations and run tests (please tell me OCIO has a testsuite?). I've done this for OIIO and OSL, and it's a tremendous time-saver to know that any pull requests being considered are known not to break the build or existing functionality; this will greatly streamline the processing of a long series of overdue pull requests (which, even if we presume each one works correctly when applied on the TOT master, should NOT be assumed to work when applied one after the other).

Does this sound like a reasonable path forward?

-- lg

On Sep 12, 2016, at 7:16 PM, Sean Cooper <se...@...> wrote:

Larry Gritz has and will be following the OCIO activity, but from what I understand isn't looking to be directly responsible for its progress. Erik Strauss has / will also be watching it's development. Apart from that, it'll be me actively working with all of you.

I agree on the open development. I think it would be beneficial at this point to sort through existing pull requests and issues, see what's ready to go, and what is still relevant after 2 years. Perhaps wrapping these into a dev branch?

On Mon, Sep 12, 2016 at 6:15 PM, Nathan Rusch <natha...@...> wrote:

Thanks for the responses everyone.

I'm attempting to reach out to some of the people who may have a connection to or interest in the project's stewardship, and will be asking them to weigh in on this thread so we can get as much information as possible out in the open. Sean, I'm wondering if you might be able to track down any of your colleagues who might have some interest or involvement in order to potentially get their input here as well. I'm not entirely sure how many of the original team are still at Imageworks, or how involved they want to be, so I don't necessarily want to blanket every name I can find.

In general, I'm inclined to agree with Deke that an ideal way forward from our perspective would be for active development to be out in the open on a development branch, rather than only landing in the form of releases.

Dennis, is your fork containing the OpenCL code path available to browse currently?


-Nathan

On Friday, September 9, 2016 at 2:18:51 PM UTC+10, Sean Cooper wrote:

Hello fellow color wizards,

I'd just like to introduce myself to the community here. I've joined Sony Imageworks as our Color Scientist this past January, and have been working on our internal color pipeline and taking on more responsibility as I continue to learn.

I have interest in seeing OCIO continue it's open development, and would like to help where ever I can. Admittedly my background is in pure color/imaging science so I won't be able to immediately jump on the reins of it's core development. However, it seems like we have the opposite problem, and I would be happy to work with you to siphon through its present state and work towards a game plan to give OCIO a fresh breath of life.

Sean Cooper
Color Scientist
Sony Pictures Imageworks

--
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+unsubscribe@googlegroups.com.
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Larry Gritz
l...@...

--
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+unsubscribe@googlegroups.com.
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.