Re: Reference !<Colorspace>

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

I'm not sure what promoting the reference colorspace to something
special - either in the API or the format - buys us. Can you provide
details on how this would make things simpler (or any other benefits
you see)?
Mostly I see this is for notation, right now profiles infer that all to_reference and from_reference entires go to/from the same reference space.

But I don't need a reference space in 'roles:' or even in 'colorspaces:' for ocio to work. This really isn't a problem if all your reference spaces are the same for all profiles across jobs.

It gets just a little murky when you open the possibilities of different connection spaces in different profiles.

Coming clean, I have to admit that in our internal SPI Color library
(the predecessor to OCIO) we actually never exposed a function call to
query the name of the reference colorspace in 7 years of use. There
was always a call to query scene linear, but the fact that this also
happened to be the internal profile connection space was never
relevant to end users.
Well thats another option, enforce scene_linear as the reference space for all profiles (I would recommend using that as the working space anyhow).

I'm just not sure if that will make it tricker for uptake at smaller shops which would be mostly working in some type of display linear pipe.

My thought in adding it to OCIO was for completeness sake when
spec'ing out the ROLE listings, but until it has an obvious use case
perhaps we should remove ROLE_REFERENCE? It can always be added back
in, when needed. (This is probably the API corollary to premature
optimization, where you speculatively add a feature that only adds to
confusion and in practice is never used).
I would remove it till it is needed.

I do believe that understanding what a particular color configuration
uses as its connection space is critical, but in my opinion this is
best solved textually at a configuration level (i.e. config docs).

Thats not so good if people are sending around profiles with out docs.. 'hmm this profile seems funky but I don't know why, oh and the docs are out of date..' moments.

In terms of your specific suggestions, I think I would prefer to have
the reference color space just be another colorspace, with no
particular distinction. While it doesn't have a transform block, it
does have all the other colorspace markup, so it really does feel
'colorspace-like'. I could also foresee a situation where someone was
using the connection space implicitly, and it wasn't intended to be
either named or used by the end user. (We havent done this, but I see
no reason to disallow it).
I agree I think having it as a normal colorspace is good, just if there was a specific tag at the top of the profile which told which colorspace was the references space. We could also barf when that colorspace isn't defined in the 'colorspaces:' section.

The use case I keep thinking about is dealing with two profiles with different reference spaces, but maybe this is just over complicating things for where we are right now.

Addressing the extra nesting added to your .ocio transform block, your
version doesn't strike me as any more readable.
old: to_reference.children
new: to.reference.children
This was actually: reference:to:Transform()

Isn't redundant nesting bad?

Perhaps there is a better name for the "to_reference" and
"from_reference" values? I'm totally open to revising that enum name.
Depending on your thoughts about the reference space we might want some other naming. I was wondering could we rename the <GroupTransform> children param to something like 'items', 'transforms'. (maybe I'm too pedantic parent -> children relationships look like a trees while lists, items etc have an order)


Join to automatically receive all group messages.