Re: State of OCIO development re: CPU/GPU mismatches
DBR - Ben <dbr....@...>
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:
|
|