Clarify intent/appropriate use of ColorSpace family

[jeremyselan]

New users designing color configurations are very likely to misuse 'family'.

Currently, we rely upon it to determine colorspace equality in colorspace conversion 'early exit' scenarios. I.e., it's relied upon to determine that lg10 -> lg16 is a no-op, even when there transforms rely on potentially different table. Instead of using 'family', we should either clarify its use or introduce a new explicit concept for this equality.

One non-contrived example of this distinction is the adx10/adx16 spaces included in the IIF workflow. There are not merely different precision version of the same encoding, but rather represent a different dynamic range slices of the adx scanning space. One would very much be inclined to put them in the same adx family, even though currently doing so would be in error.

[dbr]

Agreed. I've made exactly this error when first playing with OCIO.. It seems perfectly sensible to put, say, two different log colourspaces in the same "family", even though this is actually a bad idea

Not sure what could be done to clarify the feature.. One way could be to make family optional (when unspecified, the transform is always performed), although this may not help much, as new users would likely base configs of existing examples (which would almost all specify family)

I've not had any need for the bit-depth awareness in OCIO (using it almost entirely in Nuke) - how common is a transform between "family members" attempted? Does the retransforming cause problems (quantisation etc)? I guess my question is, would removing family be an absurd solution, if it causes more confusion than good?

[jeremyselan]

In our pipeline, an implicit transform between family members is often done in the display pipeline. The most common reason is that our luts often take log as input, but on a show with multiple flavors of log (10/16/float), which do you specify? With the family comparison, this log to log conversion rightly becomes a no-op.

Perhaps we could introduce an additional concept (same-as, equal-to, etc) that makes the equality explicit? And then demote family to a ui only hint. This would be more intuitive, the tough part about the families right now is the over-use (for both ui, and for equality). Splitting the concepts up would also be a binary compatible upgrade.

[dbr]

Ohh, that makes perfect sense - I forgot about avoiding the internal "lg10 to lnf, lnf to lgf"-type steps that would happen in the situation you describe!

An explicit equality config sounds good.. Think the only complicated part would be choosing a good name, as is always the case! equal-to sounds like you would specify another colourspace name (like name: lg10\n equal-to: lgf, which could end up rather cyclical), maybe.. equality-group: lg or something?

I quite like the idea Malcolm suggested in this message, but it does make the config format a bit more complicated

[malcolmhumphreys]

If the main purpose of the current family is to tag things as a no-op, why don't we just rename family to something like 'noop-group' or 'noop-family'.

I think using words like 'equality' could also be unclear.

[jeremyselan]

FYI this is almost ready, will have a pull request ready tomorrow.

[jeremyselan]

Addressed in 20e8b49