Commits:
http://github.com/jeremyselan/OpenColorIO/commit/843407c6a15df2afa817412614d3d6606d2fa613
http://github.com/jeremyselan/OpenColorIO/commit/dd77b2c5b789d56d8043a33a2e4bea7e99886f2a

Issue:
http://github.com/imageworks/OpenColorIO/issues#issue/64

Prior Thread:
http://groups.google.com/group/ocio-dev/browse_thread/thread/61f660d1eb96121b

This adds support for loading .cc and .ccc files in the FileTransform
operator / node.
.CC files are the ASC CDL <ColorCorrection> text stored in a single file
.CCC files are the ASC CDL <ColorCorrectionCollection> group of
transforms (a well defined format).

To support the .ccc format, a new parameter on filetransform is added,
"cccid". When a .ccc file is specified, this is required to
determine which transform contained in the list is used. The new
cccid parameter supports the Context lookups (woohoo!), so one can
define it conveniently using an environment variable. This should
fully address the context/per-shot grade workflow mentioned above by
Ben.

There is one known bug in this implementation; when I exposed this new
cccid property as a String_Knob in nuke, when I update the value in
the interface it does not appear that the value is being incorporated
into the Op's hash id. Is this a limitation of Nuke? An issue with
using PixelIop(s)? I have confirmed that if I use the File_Knob UI
type, everything works as expected...

-- Jeremy