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

Hi Jeremy, Thanks - it's running happily now. I'm currently working on writing a quicktime generator using OpenImageIO, OpenColorIO, libquicktime and Qt. I'd like to check that I'm correctly

Alan, Good catch. I've updated the git repo and the downloads site ( http://code.google.com/p/opencolorio/downloads/list ) so all the configs will work with the latest trunk release. Unfortunately,

Hi all, The example config doesn't appear to have the required luma attributes. Could someone let me know what and where they should be? Also is there any documentation around or should I just run

It was great seeing some of you at today's Siggraph class! If anyone is interested in more detailed info (or just wants to say hello in person) we'll be having a BOF tomorrow. Hope to see some of you

Hi Jeremy, oops never mind looks like it will support it. Yep it all looks ok to me, just really feel like spliting out the non-core stuff into a plugin or similar dir. For now I think nearest

I've been using that lately on OIIO and OSL, and for our simple needs it works just fine. Also nice because if you're already using Boost for anything else, you can use its unit tests without adding

Boost sounds great; let's start with that. -- Jeremy <bruno.j....@...> wrote:

Malcolm, I believe the 1D lut op does allow for a different number of entries per channel. If we look at src/core/Lut1DOp.h, you'll see the entry for each color channel lut is stored in

We use boost's unit test suite here as well, a few quibbles but it works fairly well. b -- Bruno Nicoletti

Hi, I would like to write tests for the work that I do. What unit test framework are you planning on using, as I guess it adds another dependancy. I have gotten used to using the boost framework but

Hi, I started looking at adding csp lut format to ocio. A csp lut allows a 1D prelut with a different number of points per channel. The current Lut1DOp only supports applying the same 1D lut to all

Friends, So Siggraph is just around the corner, which means OpenColorIO is going public! Both this google group, as well as the git repo are now completely open to all. If you're attending

I view these as two separate problems. One is gathering color information. The other is performing color transforms. OCIO seems to be focused on the latter. I would like to see the OCIO API stay

Version 0.5.9 (June 28 2010): * Renamed project, classes, namespaces to OpenColorIO (OCIO) * Added single-pixel processor path * Improved python path makefile detection * Continued GPU

Agreed. The issue isn't how to do the conversion, it is how to determine the input arguments. But OCIO has this problem anyway. There is no definition for how a given image can help influence what

I thought of a simpler way to summarize the topic: In dynamic colorspaces, the color transforms are dependent upon a set of potentially changing input arguments. Our ideal solution is one where the

Stefan, This has been brought up before (previously by Rod), and it's a great question. Thinking out loud... From a purely technological standpoint, the API required to support a dynamic color