Hi All, I'm just reading through the Nuke plugin to get an idea of the API and how things are supposed to work together. I notice that it adds all color spaces to both the input and output. This

Alan, OCIO is being a bit clever under the hood, though in my opinion not in a dangerous way. OCIO's currently approach is that to make colorspace definitions "convenient", we assumes inverse color

Hi Jeremy, For practical purposes those are all probably invertible, but even a 1D lut can lose information (such as everything below black point getting pushed to 0 - though seeing that information

Version 0.5.13 (Aug 18 2010): * GPU Processing now supports High Dynamic Range color spaces * Added log processing operator, and updates to many other ops * Numerous bug fixes + updates to

Alan, Sorry for the delay in responding. (Had to attend to non-OCIO responsibilities this week). The approach you describe is exactly in line with what I've been thinking. Excellent. A few

Hi Jeremy, No worries :) This is great news :) I agree, the only benefit is from a UI perspective to assist the user in not doing something stupid. Downside to this is sometimes there is a good

Version 0.5.14 (Sept 1 2010): * Python binding enhancements * Simplified class implementations (reduced internal header count) Most changes this week were internal, all API changes were

Hi, Just looking at this again, one thing we didn't cover was a prelut which has non-uniform spaced points (scattered). Would you see this as support we would need to add to the Lut1DOp or would this

Definitely a new Op. How about Spline1DOp? -- Jeremy <malcolmh...@...> wrote:

Version 0.5.15 (Sept 8 2010): * Library is well behaved when $OCIO is unset, allowing for use in an un-colormanaged environment * Color Transforms can be applied in Python

Folks, If you're considering using OpenColorIO in the near term, we would greatly appreciate it if you would respond and let us know which of the topics below you personally consider to be most

1) Document 'best practice' for each config, provide examples with imagery 2) Flesh out the existing ocio configs (spi-anim,spi-vfx) for real use 3) Add example color config authoring scripts 4) End

Hi Jeremy, The top five for me would be as follows. 1) API Documentation (the classes and how the pieces are supposed to work together - I guess that may count as config documentation) 2) LUT

Hi Jeremy, I'm currently adding OpenColorIO support to my compositor. My list would be: - End User (Artist) Docs - Developer API Docs - Flesh out the existing ocio configs (spi-anim,spi-vfx) for

Hello Jeremy and all ! I don't have much time to focus on OCIO now but soon or late I will...;) And when that day will come, I'll be happy to find : - Developer API Docs - Color Config Authoring

Version 0.5.16 (Sept 16 2010): * PyTransforms now use native python class inheritance * OpenColorIO C++ namespace can now be configured at build time (for safe distribution in commercial

Hello Jeremy, I would like to see OCIO grow into a library that can handle all our color transformations. I can see it being used in the current xml'ized form within our production environment to

Hi All, For some reason the compilation of the latest trunk is failing on FC13. It's complaining about main not being defined, but from what I've read on the boost unit testing defining

Best way to solve a problem? Post on a mailing list asking for help, then you'll find the solution within minutes. Cheers, Alan.

Hmmm, that patch doesnt quite work for us locally at Imageworks. (I think it's probably because we use a namespaced version of boost, and the macro isn't quite right in our context). Let me see if I