I must admit, I've been calling it OpenColorSPIce. RGB <steve.l...@...> wrote:

Hah! :)

Pending on how the can of worm goes. The main observation I had with the name OCS is kind of what people are saying here. I feel the name is wrong (with any project not just OCS) if your not using it

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

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

Cool, sounds good. We have started to write some of the plugins we had before for 3delight, mantra, nuke, shake and houdini & mantra for applying the ASC-CDL. At the moment they all use the same

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

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

FYI, We've started the process for getting legal clearance on OpenColorIO. Bonus kudos to Malcolm Humphreys for suggesting the name! -- Jeremy

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

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

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

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

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

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

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

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

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

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