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
crap).

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
<malcolmh...@mac.com> wrote:

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 classes are correct?
class Config;
is a top level configuration object that can be serialised into a .ocs file.
Will also define the reference space (most likely scene linear)
class ColorSpace;
is a definition of color space with an operation chain to get from this
space to the top level reference space.
class Transform;
is the base class for color transform operations
class GroupTransform;
manages an ordered list of color transform operations
class FileTransform;
is the base class for look up table transforms ops (Lut1D and Lut3D)
I got a bit confused between Ops, Transform and GroupTransform when looking
through the code. I can see how they will work just the concepts feel a bit
mixed to me. I keep wanting to call a GroupTransform a Transform (or OpList
or OpChain) and a Transform an Op.
eg,
Config ('fabricated')
  `- ColorSpace ('spacejam')
    `- Transform (to_reference)
`- [ Op::Lut1D (), Op::Gamma (), Op::Foo () ]
I don't think FileTransform should be in here. I'll send another email about
Ops if this feedback is going in the right direction as I don't want to
create two much noise.
Family
Can you give a brief description of what a family is? I can see 'family'
referenced here and there but not currently used.
Roles
From the description:
"ColorSpace Roles are used so that plugins, in addition to this API can
have abstract ways of asking for common colorspaces, without referring to
them by hardcoded names."
I can see the need for an abstract way to tag colorspaces so that client
apps don't need to deal with production details like the same ocs color
space being called something slightly different on two shows. But it feels
wrong for that abstract list of roles to be then hardcoded into the header.
I would prefer to have a site-wide .ocs file which defines the possible
roles (this file could also define site-wide color space but it wouldn't
have too). Then in the local/show/project .ocs you would be able to link one
of these abstract role names to a color space in that file/context.
I would also like to be able to define new roles just in that project .ocs
as well. These show roles would only be used with tools within that show
that were written to support them. The long term idea would be to roll them
back into the site-wide role definition (if it made sense to do so) but have
some ability to test the roll in the show context. I could see my self using
roles also for things like dealing with fixed production devices
ie ROLE_STILLS_CAMERA1 but I'm not sure if thats what you had in mind.
.malcolm

On 20/06/2010, at 10:36 PM, Jeremy Selan wrote:

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.

Cool, sounds good.

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
crap).

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.

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
http://code.google.com/p/cortex-vfx/source/browse/trunk/src/IECoreTruelight/TruelightColorTransformOp.cpp

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

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

colorspace(name='lgh')
to_reference(bitdepth='16f')
... op chain ...
to_reference(bitdepth='16ui')
... op chain ...
to_reference(bitdepth='10ui')
... 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 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).

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

.malcolm

On Sun, Jun 20, 2010 at 5:53 AM, Malcolm Humphreys
<malcolmh...@mac.com> wrote:

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 classes are correct?
class Config;
is a top level configuration object that can be serialised into a .ocs file.
Will also define the reference space (most likely scene linear)
class ColorSpace;
is a definition of color space with an operation chain to get from this
space to the top level reference space.
class Transform;
is the base class for color transform operations
class GroupTransform;
manages an ordered list of color transform operations
class FileTransform;
is the base class for look up table transforms ops (Lut1D and Lut3D)
I got a bit confused between Ops, Transform and GroupTransform when looking
through the code. I can see how they will work just the concepts feel a bit
mixed to me. I keep wanting to call a GroupTransform a Transform (or OpList
or OpChain) and a Transform an Op.
eg,
Config ('fabricated')
`- ColorSpace ('spacejam')
`- Transform (to_reference)
`- [ Op::Lut1D (), Op::Gamma (), Op::Foo () ]
I don't think FileTransform should be in here. I'll send another email about
Ops if this feedback is going in the right direction as I don't want to
create two much noise.
Family
Can you give a brief description of what a family is? I can see 'family'
referenced here and there but not currently used.
Roles
From the description:
"ColorSpace Roles are used so that plugins, in addition to this API can
have abstract ways of asking for common colorspaces, without referring to
them by hardcoded names."
I can see the need for an abstract way to tag colorspaces so that client
apps don't need to deal with production details like the same ocs color
space being called something slightly different on two shows. But it feels
wrong for that abstract list of roles to be then hardcoded into the header.
I would prefer to have a site-wide .ocs file which defines the possible
roles (this file could also define site-wide color space but it wouldn't
have too). Then in the local/show/project .ocs you would be able to link one
of these abstract role names to a color space in that file/context.
I would also like to be able to define new roles just in that project .ocs
as well. These show roles would only be used with tools within that show
that were written to support them. The long term idea would be to roll them
back into the site-wide role definition (if it made sense to do so) but have
some ability to test the roll in the show context. I could see my self using
roles also for things like dealing with fixed production devices
ie ROLE_STILLS_CAMERA1 but I'm not sure if thats what you had in mind.
.malcolm