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

On first glance, this looks great. Thanks! I wont have a chance to do a more thorough review until tomorrow... -- Jeremy

https://github.com/imageworks/OpenColorIO/pull/73 Replacing some pre ocio code for building luts at drd - Added new OCIO::Baker interface and initial pass at houdini lut writing - Added new app

Oh, of course - test data might be.. useful... http://dl.dropbox.com/u/796113/ocio_temp/csp_prelut_testfile.tar.gz - Source image (JPLogLin'd marcie) - a lin_to_rec709.csp test LUT - source image with

Sorry I'm working on some other stuff for the last few days in preparation for wrapping up next week. I'll be back on ocio tomorrow so I'll have a look at it then. .malcolm

Cool, looks good! Would anyone have an example csp file with a prelut suitable for testing? Malcolm? Even though what you've done looks totally reasonable, I'd like to QC it against some known good

Initial attempt at this, and an unrelated commit which prevents empty config sections being seralised: https://github.com/imageworks/OpenColorIO/pull/72