Looks good to me. <malcolmh...@...> wrote:

After playing around with ocio profiles a bit more, I think it would be and idea to have multiple bitdepths defined in one <!ColorSpace> definition. Below is the vd and nc family colorspaces from the

now fixed with (git commit --amend) https://github.com/malcolmhumphreys/OpenColorIO/commit/c95536a609a6b72a612a505a9702abb4d4ac5b3f

(excuse the typos in the actual commit msg) Added TestForDDImageVersion.cxx to FindNuke.cmake so that we can workout which version of nuke we are building against. This now gets appended to the

Added ${Boost_INCLUDE_DIR} to the nuke CMakeLists.txt, this is temp till we remove '#include <boost/shared_ptr.hpp>' from

Version 0.7.2 (Dec 9 2010): * GPUAllocation refactor (API tweak) * Added AllocationTransform * Added LogTransform * Removed CineonLogToLinTransform * A few bug fixes Available for

Looks good to myself! :)

No objections? Rolling it in...

No one objected, so I've merged this in.

How about we shoot for tomorrow, I'm still getting backup to speed with things. .malcolm

As a pseudo-replacement for the CineonLogTransform, added LogTransform. This is the pure mathematical Log operator, with a user configurable base. Commits: 7f7ad979 -- Jeremy

It would also be super nice if the CDLTransform supported the full Color Correction Collection (CCC) in the CDL spec, where you could have something along the lines of '!<CDLTransform> { src:

What's your schedule like this week? Up for a conference call? I'd like to primarily discuss the env-vars / 'globals' / per-shot cc look options. -- Jeremy

Next week will be fantastic. Welcome back. -- Jeremy <malcolmh...@...> wrote:

Hi Jeremy, Just letting you know I'm back from Holidays now, I'll try and go back through and review what I have missed. And we should line up a chat maybe next week if you are around. .malcolm

Nuke's OCIOLogConvert node was being applied in the wrong direction. (What was listed as log->lin was actually the

CineonLogToLin was always occupying a sort of transform netherworld. It's too specific to count as 'general math', but not specific enough to be useful in many practical cases for linearizing film

These add a new transform type, AllocationTransform, which is useful in mapping HDR color ranges into LDR code spaces. Two options are supported: a uniform allocation, and a log-2 allocation, and

Merging this into trunk, no objections. -- Jeremy

For those not familiar with the IIF project, the Academy is sponsoring a project to standardize a single floating-point linear workflow across the motion picture