Date 1 - 1 of 1
[ocs-dev] Re: OpenColorSpace.h feedback
Malcolm Humphreys <malcolmh...@...>
On 23/06/2010, at 4:55 AM, Jeremy Selan wrote:
I like to keep about 3 classifications for colour operations: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,
- 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 aSounds 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 anThats 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.
I agree if you can't do it well, leave it till you can.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
I really want OCS files to be totally portable, where you dont have toOther 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 ifThats 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 youWe 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 thisI 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.
|1 - 1 of 1|