https://github.com/imageworks/OpenColorIO/pull/84 nuke ociodisplay: ocio_populate_viewer works again nuke ociodisplay: Renamed viewer knobs to "gain" and "gamma". This allows them, when used as

Not directly related to OCIO, but I thought those github users on the list may enjoy this article: http://lumberjaph.net/dancer/2011/03/06/how_to_use_github_effectively_for_your_project.html My

https://github.com/imageworks/OpenColorIO/pull/82 This adds a bit more infrastructure behind the internal FormatRegistry. This checkin fixes the make test error in Baker.cpp, so format ordering is

https://github.com/imageworks/OpenColorIO/pull/81 Removed boost dep from the code based, you now need gcc >= 4 to get access to std::tr1::shared_ptr This has only been tested on OSX, doing a bit of

If you can send me the header, I'm happy to flesh something out. I didn't get around to it before I left DRD but I was hoping to use the lut baker to build a tool to take advantage of the lutio table

Version 0.7.7 (March 1 2011): * Lut baking API + standalone app (ociobakelut) * Truelight runtime support (optional) * Cinespace (3d) lut writing * CSP prelut support * Boost

Thanks for the error text, that was definitely a bug. (Introduced by me). This is now fixed in the latest master branch, and I've updated the v0.7.7 tag. -- Jeremy On Wed, Mar 2, 2011 at 6:42 AM,

Aha, the key/value parameters sound great. Much less hacky solution than reloading env variables (which is a slightly flawed idea)! In your example, I don't understand what "context.name1" and

When building from the current imageworks HEAD revision (ce75762bdfaec287db029986cdc17d6f136b7447), I get: src/core/TruelightOp.cpp: In member function ‘virtual OpenColorIO::v0::OpRcPtr

As part of cleaning up the code base for stable I have moved these things so they live in ext with everything else. Moved pystring, tinyxml, md5 into ext, built with hidden symbol visibility so they

Now in a new pull request with cleaned up history https://github.com/imageworks/OpenColorIO/pull/78

Hi Ben, Thanks for the note. I was actually just looking at addressing this issue on our end! (if you had waited a week you may have never noticed). The issue is actually two-fold. First, I really

Today I've configured OCIO for a small project at RSP. It was perfectly straight forward, but I encountered a problem.. In short, with the Nuke OCIODisplay node, the env-variables are never reloaded

I'm going to start to use branches from now on, so that pull requests work as expected. btw have you thought about making a github user for the dev-list so that it could receive the pull

https://github.com/imageworks/OpenColorIO/pull/75 Processor class now uses the pimpl pattern, so new functions can added in the future without impacting ABI compatibility. This patch maintains source

Hi, Optional link dependancy, but all the profile serialisation will work the same all the time. You will only get an exception thrown when creating a processor with a truelight transform but have no

I think you can add additional pull requests if they are on uniquely named 'topic' branches. How interesting! - a Truelight Transform... Only quickly glancing at the code (always dangerous), does this

Can't seem to send more than one pull request while one is in the queue. https://github.com/malcolmhumphreys/OpenColorIO/commit/c1abbcb4061cd55461d90dfb29a41cbf0989fc20 I can send another pull

Thanks, looks great. Committed. I did a bit of superficial re-factoring; take a look if you're interested. The big changes where to separate lut parsing from evaluation. This lets us detect no-op

Thats cool, I'm trying to get all the remaining pieces in place before friday. So I will have a few more things over the next few days. .malcolm