Agreed; now moved into 'apps'. <malcolmh...@...> wrote:

Oh, and an observation: we now essentially have two masters for the docs, the inline documentation, and the webpage version. My inclination is to treat the git version as the master, and then to

Looks good to me. These commits were all on the same topic, so I merged them into a single checkin, "Documentation cleanup". Thanks! -- Jeremy

Added Python versions of most of the C++ usage examples (except the GPU one, as the Processor.getGpuLut3D method isn't exposed). Might not be terribly practical code, but it's a nice demo of the

Good point about the viewers. Thinking about it now, I wouldn't use the viewer-proc registration from the OCIO installation, as it'd be untweakable.. So, perhaps this would be more appropriate as part

Yep this fixed it, and yeah I was just copying large sections of ociodisplay. Ok thats good to know. I've been using what ever the values are in the current spi-vfx profile just to cutout any added

In your example, is the native type float linear? Presuming so, I would check two things. In your gpu version, make sure that the gpu texture buffer you're loading into is floating point. You'll

LGTM I was thinking rather than having these in src/examples they should be src/apps as they will be pretty useful things to have around. .malcolm

While working on this ocio photoshop plugin I noticed a difference in the cpu vs gpu path. Attached is a screenshot. The image on top has been imported by the plugin already and processed on the

Issue: http://github.com/imageworks/OpenColorIO/issues#issue/51 Commit: http://github.com/jeremyselan/OpenColorIO/commit/afe8a04366515a152197c345e0362bd6f5540c37 * Added makefile support for

LGTM .malcolm

3 unrelated commits. 1) Updated an error message in config loading. http://github.com/jeremyselan/OpenColorIO/commit/05b84bca45187f4f5f2c8117ce0bb2a553a36f16 2) GLSL shader doesnt use invalid

Done. I've checked this into master, with a few changes: * Nuke_INSTALL_PATH is now NUKE_INSTALL_PATH (all caps) I know the old value predates this checkin, but now that it's publicized I figure we

It all looks great other than the ocio_viewer as I would need to disable this for our install. I think the nuke nodes should only be registered as part of the ocio project initialisation. Viewer

Thanks for the commits! Look great at first glance. (I'll run it all this afternoon to make sure it works multi-platform, etc). I like all the nuke cleanup, very sensible. My one concern is I'm

I've made a few minor changes, partly to familiarise myself with the code, partly to say thanks for open-sourcing this extremely useful project! First change - there was a hardcoded Nuke path, which

done. <malcolmh...@...> wrote:

perfect

Spaces in knob names have always worried me. How about an underscore in the knob name? <malcolmh...@...> wrote:

I would do both just for consistency.