2021-06-21

Owned by Michael Dolan
Jun 21, 2021
3 min read

June 21, 2021

Host: Michael Dolan

Attendees: 

Michael Dolan (TSC Chair) - Epic Games
Doug Walker (TSC Chief Architect)- Autodesk
Sergio Rojas
Deke Kincaid - Digital Domain

Apologies:

  • Mark Titchener

  • Evan Wilson

OCIO UX Working Group Meeting Notes

  • Color Space Visibility:

    • Proposal: https://docs.google.com/document/d/1_NS2UMSjbkqoMI_tvdsaOvd8NIYg3MeWQ8pKpXFQEgM/edit#heading=h.cz4xa3a5nn7h

    • Deke: Also important to consider when opening a file with color spaces that don't exist. A script can change for a variety of reasons, causing a color space to be missing. Can cause script to be broken if those values are not preserved.

    • Doug: In AppHelpers you can add additional color space to menu, for cases like color spaces that are now inactive.

    • Deke: Nuke has callbacks to remap color spaces, before evaluating OCIO config.

    • Doug: In Maya, for missing color space, name will remain but will be red. Important that app doesn't overwrite those missing spaces or change them. Most of the time it's just that the path to the config is wrong or missing. Once artists re-paths it, want the scene to start working.

    • Deke: Will be important for transitioning to new ACES configs. Could make Inactive menu items yellow instead of red like used for missing spaces.

    • TODO: New section added to discuss handling of missing color spaces, Inactive and missing color spaces, aliases, and roles all have some similar menu behaviors when handling color spaces that were previously present in config as normal color spaces, or set via API. All of these sections can share UX guidelines.

    • TODO: Michael to adjust proposals based on feedback.

  • Color Space Reference Spaces:

    • Discussion: https://docs.google.com/document/d/1_NS2UMSjbkqoMI_tvdsaOvd8NIYg3MeWQ8pKpXFQEgM/edit#heading=h.3gxy5bkoq7f2

    • Doug: You can use ColorSpaceTransform to convert between display spaces, which have shared reference space.

    • Michael: Need warning when converting between scene and display referred spaces, that the default view transform is being used.

    • Doug: Can be confusing for users when color spaces to disappear from menu. Perhaps could be grayed out. This is the most confusing topic for users who aren't familiar with color science. That a view transform is needed between scene and display space. 

    • Deke: This came up in Nuke alpha list. Some things are working differently between v1 and v2. Suggested to have checkbox to use display/view in output instead of color space.

    • Doug: Users would like one tool which can do color space transform and display/view transform.

    • Deke: Yes, two nodes are less intuitive. Could be a Nuke gizmo to do this.

    • Doug: We talked about adding a view transform menu to color space transform. There were two reasons why we were hesitant. Would change the ColorSpaceTransform class, and with two separate tools it could help clarify the two types of transformations. ColorSpaceTransform is a change in encoding, where DisplayViewTransform is for output. Challenging from UX point of view.

    • Michael: Complexity in choosing view transform. Particularly in ACES configs there are many with subtle differences. Easy to do the wrong thing.

    • Doug: Could have dynamic tool which is aware of display color space referenced in display/views. UX which responds to user color space selection, etc.

    • TODO: Michael to complete section based on discussion.

  • Color Space Aliases:

    • Proposal: https://docs.google.com/document/d/1_NS2UMSjbkqoMI_tvdsaOvd8NIYg3MeWQ8pKpXFQEgM/edit#heading=h.vyqr591s9x2k

    • Deke: We prune alias color space names from ACES OCIO config. Too much bloat.

    • Doug: One reason we didn't put aliases in menus is they make them longer. No way for app to know which aliases are useful or not for menus. If config author wants alias in menu, could make OCIO v1 style alias color space.

    • Deke: What if you set the name via Python? Indicate via menu that it's an alias.

    • TODO: Note about showing alias like inactive color space

  • Config deep merge:

    • Deke: Will work on proposal about deep merging configs soon. Just thought of this again with inactive color spaces; could have inactive spaces in separate config. Could have clean config and have legacy spaces elsewhere.

    • Doug: Yes, would be great to discuss that at a TSC meeting. Don't know that it will make 2.1.0, but could be on a near term roadmap.

    • Deke: Current implementation deep merged YAML with one config being over the other to handle clashes.

    • Doug: Wondering what would happen if reference spaces are different.

    • Michael: Could use interchange spaces to help with that. Would make more ops, but in theory should work.

    • Deke: Primarily just adding things to config currently. Simpler case.

    • Michael: If it's in API, could assume the user knows what they're doing, and that reference spaces match.

    • Doug: Would need to use interchange roles, but client would need to specify precedence.

    • Michael: would OCIO know to optimize out roundtrip ops based on similar parameters? Or is optimization aware of transform instances?

    • Doug: Yes, the optimizer would unwind conversion ops based on matching parameters (matrices, etc). Will remove identity ops. Doesn't know where they came from, but if parameters result in identity, it should work.