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,

Your idea would also work. Not sure if either is better. sanityCheck() was inspired by OpenEXR, which has a function of the same name, and performs a similar action. Guess I just had that model in

Could we call this config.validate(), I know we are all a bit insane ;) enum ConfigValid { CONFIG_UNKNOWN = 0, CONFIG_VALID, CONFIG_INVALID } What do you think about not throwing an

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

An updated nuke-default profile has been posted that should resolve all your issues: http://sites.google.com/site/opencolorio/downloads Sorry for the trouble! (I'll be submitting a patch later today

Blake, Thanks for the testing! * Glad to hear OCIOFileTransform is working. My goal is to support (at a minimum) all of Nuke's lut formats in the near future. * We're lucky that the nuke cineon

Gah. Correction: The OCIODisplay node seems to ignore the 'input colorspace' knob. Display transform and exposure work as expected. As for the LogConvert node, switching the operation from loglin

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

Hi did you guys have any more thoughts on this? Jeremy do you see this fitting in somehow with contexts? .malcolm

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

LGTM

LGTM

LGTM

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

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

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

Yeah I can see 'family' would be really useful for grouping colorspaces based on purpose which could be as abstract as the profile builder would like. In the examples I couldn't see a case where

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

Looks good to me, thanks! -- Jeremy <malcolmh...@...> wrote:

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