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

Thanks, I'm going to check this in then. -- Jeremy <malcolmh...@...> wrote:

yeah I guess you would either need to do that or have some config.getErrorMsg() function. No I think it's ok esp if people are used to the ilm code. The ilm code does call header.sanityCheck when

Either of our approaches will work, of course, but I'm still inclined to go with the exception route. A bunch of calls in OCIO can throw exceptions (the common one being config->getProcessor(...) ),

LGTM

Not really. Would you ever expect to call OCIO::GetCurrentConfig() and get back a pointer to an invalid profile? Throwing an exception from inside GetCurrentConfig() feels sensible, while throwing in

Malcolm - interesting idea! I do agree that right now families feel a bit like a second-class concept, and I would like them to be easier to deal with. I also agree that it's appealing to present

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