[ocs-dev] OpenColorSpace.h feedback
Malcolm Humphreys <malcolmh...@...>
On 20/06/2010, at 10:36 PM, Jeremy Selan wrote:
On another note that im about 50% done with the GPU design, and thisCool, sounds good.
The big distinction between transforms and ops are that transforms areWe 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.
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 interesting
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.
A family relates to bit-depthness, and though the concept is fullyThat feels like you could drop the extra color spaces and make that part of the Transform() or TransformGroup(). This would make a ColorSpace() define how it would be represented in/at different bit depths.
... op chain ...
... op chain ...
... op chain ...
The other option would be to make that part of the Lut1D and Lut3D Ops, ie reading different luts for different bit depths.
But after thinking about it I feel the to_reference(bitdepth='16f') would be better as you most likely will need different color op chains in certain situations which would get you back into having color spaces for different bit depths.
Roles (their concept) are super useful to have in production becauseI still feel this should be in OCS configuration of some kind with an small api for listing and selecting roles in the current context. I don't think a change in configuration like renaming or adding a role should require recompiling of the OCS core.
Give me a kick if this feedback is too much like noise.
Jeremy Selan <jeremy...@...>
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 run in a few, gonna do a super-quick reply...
On another note that im about 50% done with the GPU design, and this
will change the class design a bit yet a again. (It introduces a
processor class, and all the ApplyTransforms go away. You instead do a
instead, and processors have fcns like renderCPU(Img),
getGPUShaderText, etc. It's actually much cleaner.
The big distinction between transforms and ops are that transforms are
client-facing, and ops never escape the library. I could ditch
GroupTransform in favor of a transformVec, but it seemed useful to
have to avoid all the trouble with returning a vector (windows dll
A family relates to bit-depthness, and though the concept is fully
fleshed out in our internal spi library im still grappling with how to
de-imageworks-ify it. For example, we use the colorspace 'lg10' for
10 bit file io, but the luts used dont have enough precision for 16
bit use. So we also have lg16 for that case. Also, lgh (h standing
for half float). These are all in the lg family. It's actually called
prefix in the SPI codebase. It would be cool if the concept could go
away, but I havent yet figure out how to efficiently make that happen.
Roles (their concept) are super useful to have in production because
shows often names their colorspaces differently. We found ourselves
wanting 'constants' for a whole bunch of em repeatedly, so thats why
they're in the library. SCENE_LINEAR being an obvious one, where its
useful to want to sometimes reference it by its 'concept'. They are
also integral to the display pipeline (code not yet used), where they
correspond to certain defaults. (in the display pipeline, fstop
expose offsets default to a multiplier in SCENE_LINEAR, and this is
how it's driven).
The roles (and their API) are just strings though, so facilities are
free to use new ones at any time using the same storage mechanism.
(At SPI we add extra ones specifying each output media colorspace:
quicktime, avi, omf, etc).
On Sun, Jun 20, 2010 at 5:53 AM, Malcolm Humphreys
Hi Jeremy and others,