OpenColorSpace.h feedback

Malcolm Humphreys <malcolmh...@...>

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.

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.

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.