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

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

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

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 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

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

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

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

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 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

Hi Jeremy, Awesome - good to know, thanks. I've implemented using that formula with the black point at 64 in 10bit. It looks pretty good and it'd be great to know if it's correct - if anything it

A new version is out! Version 0.5.12 (Aug 18 2010): * Additional DisplayTransform improvements * Additional GPU Improvements * Added op hashing (processor->getGPULut3DCacheID) The big

Alan, As a heads up, we're in touch with the Sony camera guys and may be able to offer a 'blessed' f35 linearization as part of OCIO soon... -- Jeremy

Sorry for the delay in answering this... Adding OCIO plugins is a really promising idea, which I'd like to explore in the medium term. I particularly like that it would allow for a clean

Hi Jeremy, Indeed - I'm still pretty fresh to dealing with this stuff so directly. Time to re-read Poynton's Digital Video. Yes - the F35 :) Anywhere you could point me to for reading up on doing

Ah, when you read Sony Camera documents you often have to put on your "video engineer" goggles. :) Which camera are you using? We've done a few Sony camera characterizations, and may have real data

Hi All, I was thinking it'd be neat if OCIO provided an API for plugin LUTs (i.e. libraries that perform a LUT - they could use formula or whatever internally without any restrictions on syntax,

Hi All, I'm currently writing a LUT to go from S-Log to Rec709. I've got the transfer functions for both and generally the curves I've plotted look like what I expect, but one part of the formula is

This is a relatively minor update. Version 0.5.11 (Aug 11 2010): * DisplayTransform API * ASC CDL Support Available on github, and as a .tgz on google

Cool! That sounds like a really good use case. On our medium term list is to build a bridge between OIIO and OCIO, so you can use OIIO's command-line utilities to do color conversions. But I wouldnt