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

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

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

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

* 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

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

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

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

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. ($ +

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

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

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

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

Man, I can't get anything past you guys! :) The clamp was omitted on purpose, but I could probably be convinced either way on this issue.* If this code were inside a compiler, there would be no

I guess my preference would be to allow someone to ask for optimization or not. In the glorious future when OCIO is involved in the creation of every pixel in every movie, the animated CTL

Added explicit control of transform direction + interpolation to the Nuke OCIOFileTransform node. Commits: 3143ccdb38fee9ec774a1be94150c8f04d9e70c5 -- Jeremy

hmm thats a bit weird the test should be creating all the files it is looking for. --snip-- std::string lut2(two_dir+"somelut2.lut"); std::ofstream

LGTM, sorry I did know about this I was in the middle of doing the spline op for the prelut section and waiting for a better name for GetAutodeskLut3DArrayOffset which we were discussing in one of the

LGTM

+1 I was tempted to always have a lut that would match in the searchpath, say a global identity lut. As this is possible to circumvent this way I would fix this later. The identity lut option should