From what I remember, you can do this if the transforms are analytical. If you are referring to a baked in file based one then you will have to provide your own from for that. Piotr

Hi, all! I am a developer of Krita [0] painting application and we use OCIO for displaying wide range images. I'm having a bit of a problem now. Since we are a painting application, we need to be able

If you are using Looks heavily (and successfully), I’d like to hear from you. Currently, the documentation is somewhat inaccurate on the format of the definition and usage of Looks, so I’m

Ah cool, that could be quite handy. Just for posterity, the biggest problem with trying to take a dynamic approach in Nuke is timing. Ideally, when a user opens a script, one would be able to look at

Agreed. I inserted unistd.h above the #elif, and it compiles fine on 10.9. RGB

It looks like PathUtils.cpp needs unistd.h included. Looking at the source there’s: #if defined(__APPLE__) && !defined(__IPHONE__) #include <crt_externs.h> // _NSGetEnviron() #elif

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