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,
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?
is a top level configuration object that can be serialised into a .ocs file.
Will also define the reference space (most likely scene linear)
is a definition of color space with an operation chain to get from this
space to the top level reference space.
is the base class for color transform operations
manages an ordered list of color transform operations
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.
`- 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.
Can you give a brief description of what a family is? I can see 'family'
referenced here and there but not currently used.
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.