That's a great news. A better support of ACES (with new ops) and a better support of OpenGL capabilities (such as any types of texture & uniforms) will impose changes to the OCIO public API related to

Regarding the "No quality loss through GPU" bullet and the "Do studios maintain their own fork? / If so what features have been added" query, I have permission to contribute back our OpenCL kernel

Hello all, We've recently concluded the OpenColorIO Birds of a Feather here at SIGGRAPH 2017, so its time to mirror the discussion back to the greater community. Central to the discussion this year

Correction, this would be the example (unorganized) changelog Fix build when using libc++ Added support for yaml-cpp > 5.0.1 Fix YAML/TinyXML patches for GCC < 4.2 Updated Truelight support for

For those that haven't been following, there have been some steps towards 1.0.10 Sean - negative value clamp Sean - bump website to 1.0.9 documentation KevinJW - fix for extrapolation errors KevinJW

For those of you attending SIGGRAPH 2017 (conference pass required) in Los Angeles, we will be hosting a "Birds of a Feather" event for users and developers of OpenColorIO to get together and discuss

Hi Jep, I've recently added you, let me know if you don't get the email.

Hi Sean, I'd love an invite to the Slack conversation, please. Cheers, Jep

Pull request #392 could help you a lot.

Sorry I don't have an answer, but I am trying to do the same thing and having no luck. Were you ever able to get it working? If I can figure it out I will post my findings. Thanks

I'm not really a part of the OCIO dev community, so take my opinion with a grain of salt, but, I agree that any discussion about design or big issues of implementation really should happen on the

I would be interested in joining the Slack channel (although I'd rather discussions happened "in the open" - only so discussion/decisions can be easily referenced in future. However as long as people

I'd really like to see https://github.com/imageworks/OpenColorIO/pull/381 or some equivalent in the next official release. I personally don't like closed-door development of

Hey guys, I'd love to join the Slack channel (provided our corporate proxy will let me use slack :/ ) I'm really pleased to see forward momentum, both in terms of discussions and

Hello all, With a little bit of movement on the OCIO repo working towards addressing the most egregious image-quality-effecting bugs, we need to look to locking off to a 1.0.10 to help our users, and

Thanks Sean! I'll have a look at this and do some tests. Seems like it could do the trick :). ------------------------------- Simon Björk Compositor/TD +46

I'll also point to this: https://github.com/imageworks/OpenColorIO/issues/234

Per-shot colorspaces are generally handeled by the OCIOLooks not OCIOColorspace. Additionally, with Looks you are able to use conditionals (atleast on unix, Id have to try it on other systems) So if

Thanks Kevin, seems like it would work. However (if I'm not misunderstanding) this would require all shot luts to be named the same and also be in separate directories? In my case I would prefer to

Create a null lut is about the best you can do, combined with the search path you could do search_path: path/to/${SHOT}:path/to/null then use a name like "mylut.cube" if you squint hard you can make