Hi Jeremy and others, After looking at OpenColorSpace.h a bit today I have some feedback. First I just want to make sure I'm getting the concepts correct. Let me know if these summaries on the core cl

yah, these summaries are correct. go to the google group, and check out the 'internal architecture overview' doc. It's still a huge work in progress but provides a bit more of an overview. I have to r

Version 0.5.8 (June 22 2010): * Support for .3dl * Support for matrix ops * Code refactor (added Processors) to support gpu/cpu model * Much better error checking * Compilation support for python 2.5

I still believe that ops should not be part of the external API, though I think we can offer you a simple solution. We will expose a CDLTransform (note that it will be implemented without a native CDL

You've convinced me. OpenColorIO is pretty damn good. ... and your summary is dead accurate as well. Let's ponder this for the weekend.

Hi Jeremy, I like to keep about 3 classifications for colour operations: - transforms (eg, matrix multiplication) - transfer functions (eg, Rec709 -> Lin) - look up tables It's cool, I just need to ge

The new name is approved, OpenColorIO it is. Both github and the google group appear to allow project renaming, please email me directly if you can't find the group again. http://groups.google.com/gro

Jeremy, what are your thoughts on supporting a color pipeline that queries the files and/or workspace for color information and uses that information to define the transformation to the reference spac

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 workflo

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 in

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 con

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 progress (still

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 open

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 Siggraph, p

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 ch

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 I

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

Boost sounds great; let's start with that. -- Jeremy

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

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