Hi Jeremy,

On 23/06/2010, at 4:55 AM, Jeremy Selan wrote:

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.

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 get used to calling all of these transforms (which arguably they are all transformations of data) not ops.

Might be good to update the todo's at the top of OpenColorSpace.h so they talk about transforms not ops.

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?

Sounds ok, but I was just using that as an example of why I think it would be nice to have Ops as plugins. ie. like what units are your CDL grade parameters in? we have them set in printer points so we can integrate with other grading systems.

These workflow decisions I think should be kept out of the OCS core.

I really like the idea of OCS largely being a protocol for describing and communicating these transformation chains. Its going to be a huge undertaking to try and conform everyones workflow, I would really call this a 'soft' long term goal. A 'hard' goal would be having OCS integrated on all major platforms and applications, with vendors sharing .ocs profiles, luts and transform plugins.

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.

Thats a great addition.

I was also just thinking that renaming ImageDesc to TileDesc would make the interface a little more obvious (completely superficially) when used inside a 3d renderer.

ie. with a renderman simd plugin where you have access to an entire grid of points (which you can't in mantra), I would happily call that a tile of data not an image.. really I can live with how it is, but a suggestion none the less.

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 agree if you can't do it well, leave it till you can.

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

Other than yes it's easy to fish these functions out, thats not really what I was trying to get at.

I would say your adding a 4th hard goal (not in list of 3 I sent out before) to OCS.

- conform all color math operations between vendors

I can see this being something that works against OCS uptake in the short term at larger lead vendors where I guess you would like OCS to be used throughout the pipe.

You could slightly change this to a long term soft goal for OCS, where people can replicate their current internal workflow today with ocs profiles, internal ocs transforms and with custom developed in-house transforms. This would be a huge step in the right direction, over time I would hope to see either the in-house transforms are out in the open for everyone or they go away completely.

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.

Thats to say the company wants to open source it. All I'm trying to get at is if you support transform/op plugins you remove a potential road block for OCS uptake, which I think is this most important thing for a project like this.

Do you have any specific examples you
could provide more info on?

We use a different log transfer function designed to get scene referred values from a KodakLog file. This is also used throughout the viewing workflow to encode linear values from 3D for use with film emulation like cinespace or truelight.

The other is used in conjunction with this log transfer function which some people are calling 'paint' transfer. This is used to encode a linear image into a 16bit 'sRGB like' space for things like matte painting in photoshop.

On the round trip it has less than one cineon code value of loss which visually you can't perceive (the slight data loss is a compromise in getting something working in photoshop, which isn't a big deal when they are painting on the frame). We also create an icc profile so people can soft proof (ie. with the film emulation) their work while also in photoshop.

It's not really my decision to make any of this opensource as it might have perceived value for my employers (as they pay me to re-develop them) or some other issues.

For me (and I'm guessing others) it would be great to deal with these two separately ie.
- using the OCS framework to describe/apply our colour pipeline
- getting vendors dealing with colour math the same

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.

I agree, presenting something that isn't 100% coherent has the potential to add more confusion.

Thanks for the feedback!

No problem, happy to be involved in some way.

.malcolm