2.8 +1 - OSX 10.6 - CentOS 5.3 - Debian squeeze (testing) do you mean adding this to the yaml-cpp project? set_target_properties(<target_name> PROPERTIES COMPILE_FLAGS -fPIC) No bait intended

It does compile on osx, so I'll do further linux investigations tomorrow. -- Jeremy

Addressing the YAML topics: * I have pushed your commit, plus my non-contentious updates, to spi/yaml. Once build issues are worked out, this will be moved to spi/master (and delete the yaml

Hi, Comments below. +1 this would clean the whole thing up for me. Yeah thats sounds cool, ColorSpace.setTransform(Transform *) clearly makes a GroupTransform just another Transform which I like a

Only addressing the GroupTransform issue... I am in favor of keeping GroupTransform as is. Having a group of transforms (at the API level) be interchangeable with a single transform is a very

Hi, I think you just fixed this, but yeah there was a bit of code dup. With the current structure it would be possible to have GroupTransform()s containing GroupTransform()s and possibly more

Alan, By dynamic I mean c++ or python can create colorspace configurations dynamically. That way if you are using ARRI log C You could dynamically create or alter the colorspaces to handle the

I've also cleaned up the enum code. See 1307a8730ffe745daeb53cff4298518ed5ceafc3

Nice work. A few comments: OCIOYaml.cpp * There was a missing #include <cstring> * For the Enums, (line 512+) this could could be greatly simplified by relying on the helpers in OpenColorTypes.h. *

Hi Joseph, Yeah - I just thought it may be nice to have the capacity to provide the argument. That way you're not filling a list of color spaces with variations of the same one. Makes the List a

Alan, It seems that this can be taken care of by having multiple colorspaces. For Arri log or Red log it is simple enough to treat each ISO rating as a separate colorspace. If you didn't want to

Ok, so there is a initial go at this in the other mail. I have added a local copy of yaml-cpp and a patch to make it build static. Once we get a little further down the road, we can work with the

- Initial checkin of YAML serialization - Added ext/yaml-cpp-0.2.5.tar.gz with a patch to build it static - Added yaml-cpp to the LICENCE file - CDLTransform should be the only thing depending on

Hi All, Just wanted to throw a quick thought in on C++ LUTs. I've recently been dealing with Arri's Alexa. One of the more unusual aspects of it's Log-C transform is that it changes based on

Ok, I'm convinced. Let's give YAML a shot. In terms of broad technical strokes, I think either YAML or XML would be sufficient. But given your enthusiasm for YAML, and it's superior human

Hi Jeremy, You can use the CPACK_SOURCE_IGNORE_FILES to hold a semi-colon separated list of regexs to ignore files/directories. Cheers, Alan.

There is a cpack ignore dirs command, I would recommended doing out of source builds also. "Jeremy Selan" <jeremy...@...> wrote: -- Sent from my phone.

One gotcha: when you use `make package_source` it appears to grab all files in the subdirectory, including the build dirs and other files which may not be part of the repository. I'm looking at

looks good to me. -- Jeremy <malcolmh...@...> wrote:

* added cpack support to replace the tgz_create script. Run 'make package_source' to create 'olio.VERSION.tar.gz' * removed tgz_create