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 code, I was hoping to replace this with an OCS::Op::CDL() op. This I guess changes the requirements for Ops a bit, but I would like to use the same color math across client apps for the simple cases. For cases like 3delight and mantra were you just want to call a single simple Op per sample, having access to the Op directly would also reduce the overhead of setting up ImageDesc() so that you can evaluate a simple op.

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 CDLOp,
relying on the existing MatrixOffset and Gamma Ops). Have you seen
the processor class in our recent checkin? It currently has an
apply(ImageDesc & img) call. We can add an additional singlePixel
variant that takes a raw float *. This will make it efficient to apply
your cdl per-pixel with minimal overhead.

What I left out of my last post was the suggestion that Ops should be plugins. I have a few cases like non standard transfer functions and support for calling libs like truelight or cinespace as an Op which I don't think belong in the OCS core. Cortex already has an Op for truelight which you might find interestinghttp://code.google.com/p/cortex-vfx/source/browse/trunk/src/IECoreTru... I think having some form of extendibility at the Op level will be needed for OCS to be widely adopted. It will be hard for people to take on if they can't replicate the workflow (broken or not) they have right now.

I've been thinking a lot about op plugins -- I'm really on the fence
-- but my current thought it to avoid it for 1.0. First, I fear that
a plugin system, not done well, will lead to a lot of user confusion.
I really want OCS files to be totally portable, where you dont have to
think about versions or compatibility. I can picture a lead FX house
coming up with an OCS configuration not realizing it's using an
optional plugin format, distributing it, and then complications
arising downsteam once they've distributed the profile. There would
also be a whole range of issues related to plugin binary
compatibility, registration, image quality, etc. Furthermore, I've
always been strongly philosophically opposed to 'locked' LUT formats,
and would like to discourage their use in interchange. (Locked lut
formats are all pretense anyways, if you give me an API where I can
process an image, I'll guarantee you I can fish the lut out. In fact,
the OCS GPU pipeline takes advantage of this approach!)

For 'broken' current workflows that people need to emulate, I'd love
to attack them on case-by-case basis. I'd be really surprised if even
the worst workflows we need to support would rely on ops we couldn't
provide base level emulation of. It's an open source project, so if
someone wants to add an additional 'custom' op so their workflow can
be supported, I'd prefer that. Do you have any specific examples you
could provide more info on?

Finally, I'm worried about feature creep. My gut tells me that this
could be a can of worms, and we're short on time for 1.0 already.
There's a lot of intricacies in doing a proper plugin API, and I'd
rather give it the time it deserves. How does a plugin system work
with an .ocs bundle file? How does it work with GPU generation? What
about multi-platform plugin support? What about Op reuse? In the long
term, I'm totally open to reconsidering the idea; I feel it's just a
bit too much to add to our plate right now.

Thanks for the feedback!

-- Jeremy