Serious question, why not just publicly do a fork, and maintain it in the short term until the stewardship side of the official repository becomes clearer? At that point, the fork can be merged and everything carry on forward. If stewardship remains stuck, then the fork carries forward.

It seems win-win in this instance.

With respect,
TJS

On Wed, Sep 7, 2016, 9:55 PM Nathan Rusch <natha...@...> wrote:

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