Is this semantically correct if the presence of the 1D lut also triggers clipping to 0-1? Is there now a missing clamp? RGB

On Lut loading, 1D luts are checked to determine if the underlying transform represents 'identity'. If so, they are skipped during op generation. This is particularly useful when working with 3D

Added support for Truelight .cub luts. (Both 1D shaper + 3d lut). 1D shaper lut currently uses linear interpolation, until something better comes along. Note: This checkin tested with a limited

The list of defined roles within a config previously maintained order. Conceptually, this is actually a mapping type where order does not matter (and the yaml serialization dropped ordering). This

Minor optimization: the potentially expensive EnvExpand call (which expands envvars in file paths), does an early exit for paths which do not contain special characters. ($ +

In the absence of any objections, I will be merging this (and the previous commits) into OCIO. -- Jeremy

Malcolm, I like your suggestions. My thoughts: * The name 'globals' is good. * I like pre-declaring the list of allowed variables beforehand for the config. * I like the use of env-vars as

Upon further testing, it appears the channel swizzling was backwards during CSP lut importing. I used Nuke as the baseline in terms of lut channel order, so it's possible that I've actually broken

* LogConvert, which is a handy node that does the colorspace transform between the SCENE_LINEAR role, and the COMPOSITING_LOG role. While this isnt strictly needed (it could be accomplished using

In the public API we were storing references to m_impl using autoptrs, which really was unnecessary. This only saved one line of code per use, and made the memory model less obvious. This doesnt

Unit tests for envvars were failing, referencing files that weren't checked into the source tree. Disabling these specific tests for now. Commits: 0a052d9090c9d693f63cdb409260627406790d75 --

Definitely, I went to add tr1 on mac, and realized we're already doing it. From export/OpenColorIO/OpenColorTypes.h, #ifdef __APPLE__ #include <tr1/memory> #define OCIO_SHARED_PTR

Would #include <tr1/memory> be an option for now?

Hi, It might have to wait a few weeks, I'm in Hong Kong right now and I'm going to be MIA in asia for a bit. But yes a chat would be good when we are both free. They are a common mechanism for setting

+1 it should be pretty easy to add boost back as a dependency if we need to. I have seen a lot of projects copy the shared_ptr so it seems fairly common practice. .malcolm

LGTM

+1 it should be pretty easy to add boost back as a dependency if we need to. I have seen a lot of projects copy the shared_ptr so it seems fairly common practice. .malcolm

LGTM

I've added a nuke python script to src/testbed that lets you export specified nuke color spaces into an OCIO profile. It also is a good example of using the python API to create an OCIO

A new profile, 'nuke-default' has been added to the 0.7.1 config bundle. http://sites.google.com/site/opencolorio/profiles This profile emulates the 'out of the box' color processing luts that come