Prefix/suffix for color space names in the new configs

[doug-walker]

The basic question I am posing for the group is: Do we want to continue including a prefix (e.g., "Input") in the color space names in the new configs? And if so, should we update what the prefixes are or how they are used?

Color space names

In the OCIO v1 ACES configs, the color space names are prefixed in order to group them into families. Here are some color space names from the ACES 1.2 config:

    name: ACES - ACES2065-1
    name: ACES - ACEScct
    name: Input - ARRI - V3 LogC (EI800) - Wide Gamut
    name: Input - Sony - S-Log3 - Venice S-Gamut3.Cine
    name: Output - P3D65
    name: Output - sRGB
    name: Output - sRGB (D60 sim.)
    name: Utility - Dolby PQ 10000
    name: Utility - Curve - sRGB
    name: Utility - Gamma 2.2 - Rec.709 - Texture
    name: Utility - Linear - Adobe Wide Gamut RGB
    name: Utility - sRGB - Texture
    name: Utility - Raw
    name: Utility - Look - Blue Light Artifact Fix
    name: Role - compositing_log

The prefixes that are used in that config are "ACES", "Input", "Output", "Utility", and "Role". In some cases there are secondary prefixes, such as including the camera vendor under "Input" (e.g., "Input - ARRI") and "Linear" and "Curve" under "Utility" (e.g., "Utility - Curve").

The new ACES Reference config adds the "Display" prefix for use with the new display color spaces added in OCIO v2. For example:

    name: Display - sRGB

In all cases, the prefix is also used in the family attribute of the color space (although there is some minor variation in how that is done, for example, the family for the "Role" prefix falls under the Utility family). The family attribute is used to generate hierarchical menus for color space names. Some apps have done this in both OCIO v1 and v2 (although v2 makes it easier by providing some convenience functions for it in apphelpers).

In the earlier configs, prefixes were added to the color space names for several reasons. First, the official ACES naming, taken from the tag in the CTL files, often (although not always) includes a prefix.

Second, adding a prefix may help organize the long menus encountered in applications that do not use hierarchical menus for color space names. However, it should be noted that the ordering of color spaces presented by OCIO to an application follows the order established by the config author. So the config author should at least control the ordering (unless the application alphabetizes them, which is discouraged).

Display & View names

A related question is: Should a prefix or suffix should be used in the Display and View names?

In the ACES 1.2 config, there is only one display ("ACES") and the views do not have a prefix or suffix. Here are some views:

  sRGB
  sRGB D60 sim.
  Rec.2020 ST2084 1000 nits
  Raw
  Log

In the new ACES Reference config, all of the displays have a "Display - " prefix. (In OCIO v2, the display naming should match the display color space naming, so it is a related question.) And the views sometimes have an "Output - " prefix and sometimes an " - ACES 1.x" suffix. For example, here are some displays:

  Display - sRGB:
  Display - Rec.1886 / Rec.709 Video:

and some views:

  Output - SDR Video - ACES 1.0
  Output - SDR Video (D60 sim on D65) - ACES 1.0
  Output - HDR Video (1000 nits & Rec.2020 lim) - ACES 1.1
  Un-tone-mapped
  Raw

Considerations

It's clear that there are pros and cons to prefixing the names. On the one hand, some might argue that the names are too long and unwieldy. On the other hand, I've seen a lot of people saying that they really like the naming conventions pioneered in the ACES configs.

Here are some aspects of the problem to consider:

Versioning
The name for the views, at least, probably needs to indicate the ACES version. Once ACES 2.0 is released, there will likely be a transition period where both ACES 1.x and ACES 2.0 Output Transforms are in some configs. Should this be a prefix or suffix?

Color spaces vs. Displays/Views
The new configs are taking advantage of the OCIO v2 feature of splitting Output Transforms into a Display + View. Therefore, the config currently does not have any color spaces that have an ACES Output Transform baked in. Hence, there are no color spaces that need the "Output" prefix. The Reference config is still using them in the View names, but this may not be necessary. Similarly, per the previous point, the ACES 1.x vs. 2.0 distinction may only be necessary in Views and not in color space names.

Handling of video color spaces
One question often heard from users is around how to deal with sRGB images (or similar). There are two ways of managing these color spaces in the current ACES configs: treat them as display color spaces and simply linearize them; or apply an inverse ACES Output Transform. (Note that in OCIO v2, inverting the Output Transform is better handled using DisplayViewTransform rather than ColorSpaceTransform.) Future ACES configs may provide more options which fall somewhere in between (e.g. inverting some of the view transform but with slope limiting to prevent generating extreme values). But in any case, we may want to see if improvements to the naming could be made to reduce user confusion.

Changes to the Utility color spaces
In the OCIO v1 configs, there was a large (and arguably unwieldy) set of "Utility" color spaces. Taking advantage of OCIO v2 features will change this collection, as would raising the expectations around application UX support. For example, the "curve" color spaces will become Named Transforms. Many of the other color spaces are not needed any more. And the "Utility - Look" spaces will become simply Looks. Should the "Utility" collection be named/organized differently? Should "Texture" (which is now a suffix) become a family name or prefix?.

Duplicate names
The previous and current ACES config had a number of color spaces that show up multiple times under different names. For example, having separate color spaces for linear Rec.709 and linear sRGB rather than one linear Rec.709/sRGB space. Or having the same space both as a display and as a texture input. Should we try to minimize that, or continue with that practice?

Availability of categories
In OCIO v2, color spaces have a categories attribute which is intended to be used by applications to filter the list of color spaces presented in menus. This reduces the need for prefixes to organize color spaces.

Diversity of implementations
If all applications implemented features OCIO supports such as hierarchical menus and categories, it would eliminate the need to have the prefixes in color space names. Unfortunately, not all applications have done this and so a judgment call needs to be made about how long to bias the UX for everyone in order to work around the limitations of the least capable implementations. An effort is underway to survey how many applications still have not implemented hierarchical menus.

Backwards compatibility
The new color space aliases attribute in OCIO v2 may be used to provide backwards compatibility for the earlier names. This will allow old project data (scene files, etc.) that have embedded references to the earlier names to continue to work with the new config.

Clarity when used in isolation
In some cases, the color space name will be seen on its own, for example without the context provided by the hierarchical menu organization. For example, many applications (e.g., Nuke, Maya) will store the color space name as a parameter value for a color space conversion. Similarly, the color space name could be a command-line argument for something like oiiotool. The name needs to be sufficiently clear and unambiguous, even in this type of usage (i.e., where the family attribute is not present).

Proposal

An informal discussion during a recent working group meeting indicated that people are leaning towards removing the prefix from the name but keeping it in the family. Just to start the discussion, here is a strawman proposal (I'm still on the fence about a number of these, TBH):

1. The first-level prefixes "Input", "Utility", and "ACES" will be dropped from the color space names but will remain in the family (and thus in hierarchical menus).
2. The current second-level vendor prefixes (e.g., "ARRI", "RED") will be dropped from the color space name (but kept in the family) if they are clearly implied by the rest of the name.
3. Linear versions of the camera-primary color spaces will retain a "Linear" prefix.
4. ACES Views will get a prefix (rather than the current suffix), including the ACES version (e.g. "ACES 1.1").
5. In order to disambiguate display-referred video spaces from scene-referred texture spaces, the display-referred color spaces will have a "Display" suffix. A "Texture" suffix will be added to texture spaces. So for example, there could be a "sRGB - Display" and a "sRGB - Texture" color space (each connecting via its corresponding reference space). The "Display" and "Texture" would also be in the family.
6. Named Transforms will have a "Curve" suffix, where appropriate.
7. Both the full and short-hand names from the ACES 1.2 config will become aliases in the new Studio and CG configs (for color spaces with an equivalent in the new config).
8. Color space ordering in the config will be by family so that in applications which don't yet support hierarchical menus, the list will at least be organized.

[flord]

I agree with everything in the strawman proposal.
I would also keep the duplicate Rec.709/sRGB spaces for user friendliness.

[Dithermaster]

Often the list of colorspace names is large, and some applications may wish to create a hierarchy in the UI (such as expandable tree view or hierarchical menus), so it would be nice if this separator was consistent and parseable to make this list into a tree. Some OpenFX hosts do this with the OfxImageEffectPluginPropGrouping property.

[doug-walker]

Thanks for the feedback Francois! Dennis, the family attribute of the color space is what is intended for building hierarchical menus. In OCIO v2 we made the separator character customizable by the config author (the default is "/") and added some sample code under apphelpers for generating the menu hierarchy. As with the ACES 1.2 config, the proposal is that the new configs will continue to set the family attribute for this purpose and continue to use "Input", the camera vendor names, etc. It sounds like that will satisfy your request.

[Dithermaster]

Thank Doug! Yes, that sounds like it would work.

[KelSolaar]

I think that what would be useful for discussion is not a full config but a few examples to see how it would look.

Generally agreed with the proposal but I'm not sure to understand the rational that makes some stuff suffixes and some other prefixes, for example, why:

3. Linear versions of the camera-primary color spaces will retain a "Linear" prefix.
4. Named Transforms will have a "Curve" suffix, where appropriate.

Generally, I tend to prefer convention that roughly follows the What - Variant/Method - Version, e.g. lightness_Fairchild2010, lightness_Fairchild2011, lightness_Abebe2017. It makes introspection a bit easier.

For example:

• Curve - sRGB
• Curve - BT1886
• Linear - sRGB
• Display - sRGB
• Display - P3DCI

etc...

I'm not sure I like this one:

4. ACES Views will get a prefix (rather than the current suffix), including the ACES version (e.g. "ACES 1.1").

A version qualifier is typically always at the end, why putting it first now?

Cheers,

Thomas

PS:

or apply an inverse ACES Output Transform.

This is one of my pet peeves, worth putting a context here, e.g. logos or titles, as I spent to much time saying to artists that this is a bad idea to do!

[doug-walker]

Thank you for the thoughtful feedback Thomas! I do generally like your "What - Variant/Method - Version" philosophy, although we may have different opinions about which part is the "What"! ;) Here's my rationale for which part was made a prefix vs. suffix.

• "Linear" is analogous to the transfer function, and transfer functions go first in the other names. So it's similar to a prefix, but preferably it would not have the dash in this case, e.g. "Linear Rec.709" rather than "Linear - Rec.709".
• "Curve" is not really a "What" but rather a "Method", IMHO. In other words, the name of the specific curve is the "What" and "Curve" is the "Method" (a named transform rather than a color space). Hence I proposed a suffix.
• "Texture" is already a suffix in the ACES 1.2 config and it seemed better to keep it that way. I think of it more as a "Variant" or "Method" than a "What" according to your terminology.
• The displays are already going to be in a separate non-hierarchical menu and I feel that it would be annoying for users to see "Display" as a prefix, since all the items in that list will be displays. Furthermore, UIs sometimes have limited real estate in the viewport to show the display name and it would be unfortunate if all that shows is "Display - ...". Finally, since "Texture" is a suffix, it seemed more uniform to make "Display" a suffix so that you would have "sRGB - Display" and "sRGB - Texture".
• I moved the "ACES 1.1" suffix to a prefix for views because in many configs ACES will not be the only kind of view transform available, for example a config might have view transforms from ARRI, Filmlight, etc., in addition to 1.x and 2.0 ACES versions. Furthermore, the view menus are typically not hierarchical. I feel the view transform algorithm family is the "What" here and the rest of the name is more a "Variant". Hence the choice of "ACES 1.1 - SDR Video (D60 sim on D65)" rather than "SDR Video (D60 sim on D65) - ACES 1.1".

To summarize, my POV is that the most salient piece of information should preferably be at the start of the name. This strongly influenced my opinion of which part is the "What" according to your terminology.

But as I wrote above, my proposal was just a strawman and I'm flexible on any of this if the group feels improvements could be made. And once we see an actual config (or part of one, as you suggest), it may help clarify the trade-offs.

[KelSolaar]

A long time ago, a config I did was defining the colorspaces roughly as follows (random examples made on the fly):

Gamut - sRGB
CCTF - sRGB
Colourspace - sRGB (uses the two former)

Gamut - DCIP3
CCTF - Gamma 2.6
Colourspace - DCIP3 (uses the two former)

People found it simple to understand once they got what specifies a RGB colourspace.

Agreed with first and last point, not the Curve one though. When someone uses "Curve", it is a what from something, i.e. the transfer function as defined by sRGB, the gamut as defined by sRGB. I'm not sure whether the underlying implementation, e.g. NamedTransform should influence the name to the point of breaking the naming consistency. If we used a Colorspace, would you have kept it a prefix instead?

Texture is an odd one, it is a workflow thing.

Cheers,

Thomas

[MrLixm]

Hello, great to see this discussion.
A thing I'm wondering is why the unique identifier of the colourspace is also the pretty name used for interfaces?
Shouldn't decoupling the UI and the logic a better idea to allow for more flexible configs that can be updated at any moment ?

SImple naive example :

  - !<ColorSpace>
    identifier: displaysrgb
    name: True-PRO sRGB Display
    family: Display
    equalitygroup: ""
    bitdepth: 32f
    description: Convert CIE XYZ (D65 white) to sRGB (piecewise EOTF)

Where anyone could just change the name and it wouldn't break anything in any software.

This could then open a lot of other discussions (identifiers formats, identifiers conventions, ...) but just wanna know your thought about this ?
Cheers.
Liam.

[doug-walker]

@MrLixm , you raise a valid point. I agree it would be nice if there was a unique ID that is separate from the user interface name. If we were starting from scratch I think your proposal would be fine, but unfortunately this would be a big change for existing apps. Additionally, the UI model for some apps is so thin that it does not really allow for a distinction between the "real value" and "UI value" for parameters, unfortunately.

We did introduce some features in OCIO v2, namely the aliases attribute of color spaces and the inactive_colorspaces attribute of configs, that are intended to help cope with the drift of names over time. One advantage of the approach we took is that the complexity is handled within OCIO itself rather than requiring work from each app developer. We have found that it is relatively difficult to get changes made on the application side, typically requiring a period of years.

Regarding the concept of a "unique identifier", the name attribute of the config may be combined with the color space name to make a sort of unique identifier, across configs.

[doug-walker]

We had a good discussion about this during the last part of the Configs Working Group meeting today. Kevin brought up a good requirement that the name must be meaningful even if the family is not present. I added a new paragraph to capture this in the list of considerations above titled "Clarity in isolation".

[anderslanglands]

I understand that it may be too late but it would be really nice if compact, unique identifiers could be split from the “display name”, especially if the display name is forced to have extra context to be used in isolation.

For instance, some applications will bake the colour space name into file names (substance does this when exporting) and with the current ACES configs this results in some absolutely horrific file names. Plus all those spaces are just bugs waiting to happen.

As someone who likes to think he knows a little about colour, but doesn’t know OCIO very well, I find the current naming in the ACES configs extremely confusing - eg which sRGB is actually sRGB? Or are they both the same thing? (I still don’t know the answer to this).

[KelSolaar]

I will close this one as we implemented the OP suggestions! @MrLixm, @anderslanglands : I collected your feedback in #67.

Thanks a lot!