I've removed the TODO file internal to the codebase, in favor of the github issue tracking. (Which is really nice!) Please feel free to add any issues (bugs or features) to this list as you encounter

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 dat

Nuke's OCIOLogConvert node was being applied in the wrong direction. (What was listed as log->lin was actually the opposite). Commits: b5bd0c824 Issue: http://github.com/imageworks/OpenColorIO/issues#

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 the

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

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

(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 '$CMAK

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

Added ${Boost_INCLUDE_DIR} to the nuke CMakeLists.txt, this is temp till we remove '#include <boost/shared_ptr.hpp>' from OpenColorTypes.hhttps://github.com/malcolmhumphreys/OpenColorIO/commit/0077676

Looks good to me, thanks! -- Jeremy

Commits: 54b464d255 Fixed the bug where the application of MatrixOps on the GPU (for GLSL only) had the wrong multiplication order. -- Jeremy

Commits: 1c2d95e82e Not much to this one... -- Jeremy

I've added a working GLSL image viewer example. It relies on OpenImageIO to load an arbitrary image, and then will display it using OpenColorIO. It's pretty awesome to see how little code in practice

Version 0.7.3 (Dec 16 2010): * Added example applications: ociodisplay, ocioconvert * Makefile: Add boost header dependency * Makefile: Nuke plugins are now version specific * Fixed bug in GLSL Matrix

Hi all, I've tested the OCIO 0.7.3 Nuke suite in Nuke 6.1v3 and have noticed some possible bugs (or user errors ). First of all, I downloaded the configs for 0.7 and pointed my OCIO env var to the nuk

Malcolm, I like it. However I'd like to keep the option for a family designation. For simple colorspaces I see this as great way to simplify things. The family designation is still useful for instance

This checkin removed config.getEditableColorSpace(...). Users should use the existing getColorSpace, and addColorSpace as replacements. getEditableColorSpace has always been a wart on the OCIO API, as

This will prevent the issues Blake encountered from happening again. http://groups.google.com/group/ocio-dev/browse_thread/thread/c073e0f4fde995f7 This also addresses an outstanding issue: https://git

Commits: 1a54ec8d76 Resolves Issue #16: http://github.com/imageworks/OpenColorIO/issues#issue/16 This commit enables color transforms to leverage environment variables + search paths to determine the

Issue: http://github.com/imageworks/OpenColorIO/issues#issue/48 Commit: http://github.com/jeremyselan/OpenColorIO/commit/a0fb960d0e8b083acc4bd18048d24ac8e49f99ad All the classes that relied on the m_i