LGTM - even without any tests : ) .malcolm

Ok lets jump in :) There are a few good articles on the subject of choosing XML 'just because', these two I

The ExponentTransform (a publicly exposed class for doing power / gamma operations) previously could not serialize itself to xml. This commit adds the

Sorry I will be responding to this soon, bit busy for the next 3 days. .malcolm

http://code.google.com/p/yaml-cpp/ ...is the compiled yaml io library. I believe yaml support is built into the python distro. -blake

I'm completely in favor of making the OCIO configuration files easier to read and edit. I have a few specific concerns about YAML, but it's definitely worth exploring. Care to take a stab at it? In

I'm happy to match what ever style you put forward, I mainly like doing this as it makes it really clear what a function / method is returning. We don't have function overloading but in code bases

Looks good to me! I really like the VERSION consolidation and the cmake "configure_file" mojo. Now that I know about that approach, I'll use it for the OCIO_NAMESPACE #define as well... -- Jeremy

Also - for future reference - you don't need to include the patch file. It will be sufficient to just include the SHA1 hash for the top- most commit that corresponds to the topic. For example, in

Looks good to me! I have a few comments, but these dont need to be addressed yet. * In terms of coding style, you put the return value on a new line, where as I tend to not. I'm actually fine

I wanted some pkgconfig (http://en.wikipedia.org/wiki/Pkg-config) support to make it easier to build against OCIO. Part of this needed burning the ocio version into the .pc file, so I rejigged things

Now that we've got a few people actively contributing code, we're going to start formalizing the development process. (Thanks to Malcolm Humphreys for being the guinea-pig in the process). Please

Are people super into the idea of using xml? We used xml for nearly everything at RSP, over time it became clear that it's a pretty poor choice for a lot of things. One of the developers introduced

I have been playing with littlecms a little (building profiles for photoshop etc) and was wondering if people have an idea on how they envisioned these fitting into OCIO? There could be reader and

Hi, I have a few emails to send through I have been discussing with jeremy, I have split them up so they can be discussed in different threads. Here is an initial pass at the Houidini lut loader. I

Version 0.6.1 (Oct 5 2010): * Exposed ExponentTransform * Added CineonLogToLinTransform - a simple 'straight-line' negative linearization. Not strictly needed (could be done previously

Branch: refs/heads/master Home: http://github.com/imageworks/OpenColorIO Commit: 5a24dca1b81c5275051b769adeaef6c634a10e1d

Hi Jeremy, Thank you for your replies. Everything is clear now. I think that the lut size is an implementation detail of the client and a recommended lut size function wouldn't have much use as most

Oops. This is actually a callback on commits themselves, not pull requests. I'll disable the callback until I get it worked out.

Testing, 1 2 3... I've updated our github acct. so all pull requests get cc'd to this list. I really like how OpenImageIO reviews commits in their public dev forum before adding them to the repo,