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.