On Feb 9, 2014, at 12:43 PM, <ocio...@...> <ocio...@...> wrote: No, but 338 does: https://github.com/imageworks/OpenColorIO/issues/338 Rod, if you can have a go at this, it would be much appreciated;

Thanks. Yes, it is the master branch. I have not yet spent time on the fix, but I believe you are correct; it should just be headers. RGB

I haven't yet updated by OSX dev machine to 10.9 yet, so unfortunately I can't test this at home. (Sounds like a good weekend project though). When I browse the open issues

Do we expect 10.9 to properly compile the git master version of OpenColorIO? Steps to reproduce: “Clone in Desktop” to download software Cmake (with defaults) to populate build dir cd

Cool. In the medium term, we hope to do a cleanup of the OCIO API to make it easy to install as a system library in a binary compatible manner. That way, should similar circumstances arise again you

Foundry bug ID is 40576 in case anyone comes across this later and wants to poke them about it.

Thanks Jeremy. Good to know I'm not missing something. Unfortunately The Foundry have a tendency to drag their feet when it comes to updating third-party libraries, so they're still shipping OCIO

It was definitely our intent to have a setCurrentContext, that looks like an oversight. In the meantime, can you see if your config object has a "addEnvironmentVar" option? This was introduced

Hey all, I'm wondering if there has been any thought or discussion internally about allowing a config's Context to be replaced in place. I've been looking at ways to change the context variables of

Hi again! [1] is now attached to avoid unavailability due to build machine refresh. So, any advice? TIA. -- Matteo F. Vescovi Debian Maintainer GnuPG KeyID:

Hi Matteo can you checkout https://github.com/imageworks/OpenColorIO/pull/345 and see if this solves the issue for building against yaml-cpp-0.5.x? before we merge this into master. .malcolm

Congrats and great job! - this message sent using an e-approved device

Woot! Jeremy Selan <jere...@...> wrote:-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

Woo-hoo! I can't think of a better way to start 2014. :) It goes without saying that OCIO is a community effort so I'd like to give a *huge* thanks to all the developers, users, and

Hi! Actually, this version FTBFS as you can see at [1]. Former versions didn't have this kind of problem. Is there any change I should care about? Thanks in advance. Cheers. [1]

Brilliant, I hadn't thought of that. Just stuck that into our viewer process gizmos and it works like charm. I wasn't aware of the metadata trick, neat. cheers, -Mark

Or you can save the context data in metadata (if the import format supports it, like exr). and use: key1:SHOT value1:[metadata "look"] this will make it possible to do different looks based on the

If you only need a limited set of the env variables, you can set the Nuke node context tab up like so: key1: SHOT value1: [getenv SHOT] ..etc, then it will dynamically pick up changes to the SHOT

Hi folks, A feature that our artists fought long and hard to have is the ability to change shots from within their software, without going back to the shell and doing a "setshot" (which sets up

Congratulations Jeremy!