2021-03-29

March 29, 2019

Host: Michael Dolan

Attendees: 

OCIO UX Working Group Meeting Notes

• Google doc: https://docs.google.com/document/d/1_NS2UMSjbkqoMI_tvdsaOvd8NIYg3MeWQ8pKpXFQEgM/edit?usp=sharing

• Encodings:

  • Doug: Added description of encodings and two potential uses. Any feedback. Is it enough info?

  • Michael: Think the minimal subset of info with clearest direction is ideal.

  • Zach: Agree. Don't leave too much room for interpretation. Expectations that new features require more hand holding, but just enough to be unambiguous but not overbearing.

  • Doug: Encoding is optional - may or may not be present in a config, which may present challenges. Encoding is saying "how is the color space numerically encoded?". Linear and log might both be scene referred, but they are very different numerically. Operations react differently depending on encoding. Extra information that could be used. Another use would be if app is filtering color spaces for specific use, it could ask someone to choose a rendering color space and provide linear spaces, for example.

  • Zach: Some grading transforms operate in log or video spaces, so also useful for tracking image state metadata. In AE plugin the developer added an encodings menu option to filter by those. Would like to see this. Don't think we want many ways to organize color spaces at the same time, but they are each useful when needed.

  • Deke: Like a smart filter for menu items.

  • Doug: Patrick and I talked with Brendan who wrote the AE and PS plugins, talking about encodings. Talking about how we are doing things in Maya and knowing what type of color space a user is interested in. In these plugins you don't really know, since they are used more generically. That's why he approached it a different way.

  • Zach: I don't think it's useful to have categories, except for an app to use for filtering. For less color savvy users I don't think having many ways to get to color spaces is clear. Can be confusing. I think having encodings specifically as a families views is useful, and roles too, but don't think categories should show up as a default.

  • Evan: Agree that having many different things for sorting can not be good.

  • Mark: It is potentially confusing having all these ways. Hard to know what to show and how. Is picking the encoding the same as picking category? Helpful in this doc to be clear if we think these should be presented to users. Not clear what should or shouldn't be exposed to users, vs. for devs.

  • Deke: Could perhaps be used to add icon beside color space, etc.

  • Group agrees this is a good idea. Would be helpful for linear and log spaces, for example.

  • Zach: One use case for categories is to have basic and advanced, to filter what to be exposed. By default have basic spaces, and for advanced users can get all the others.

  • Michael: In ACES config WG we've been discussing use of categories for filtering which portions of the config should show up in an app. So you could filter spaces for a specific camera manufacturer's IDTs for example. I think categories are ideally used for filtering spaces, families for building hierarchical menus, and encodings more for informing an app as to spaces to filter for specific uses. Perhaps we should encourage not exposing encodings to the user unless really needed, or unless used in icons, etc.

  • Evan: Encodings can raise the bar for education as to what color science is (linear vs log), in tool tips, etc. Undecided.

  • Deke: Like idea of using them in tool tips. For ACES config have to look in config to find out what they are because of confusing names.

  • Mark: Informative without being complicated.

  • Michael: Should include set list of encodings, to be less open.

  • Doug: Encodings are intended to be a fixed list - in OCIO docs. Categories aren't like roles, where there is hard coded list. For encodings wanted a set list. Will add these to doc.

  • Zach: Viewing rules take this into account too right?

  • Doug: yes.

  • Evan: Looking at the list of encodings, would want to add a perceptual display encoding.

  • Doug: How is that different from sdr-video?

  • Evan: If rendering still picture vs. video.

  • Michael: We should create an OCIO glossary for defining potentially confusing terms. In OCIO "video" and "cinema" are mostly used to refer to viewing env and tonecurve, as implemented in builtin ACES transforms too. Not necessarily specific to moving images.

• Families & Menu Separators:

  • Doug: Added example of how a family would be used in hierarchical menu structure.

  • Groups agrees this section looks complete.

• NamedTransforms:

  • Doug: Started with background section where explain the purpose of named transforms. Repeating some of the OCIO docs, but thought it was useful to explain. Can't assume the full docs have been read before reading this guide. Going back to ACES config, there are utility curve transforms which just provide a 1D LUT, gamma curve, log-to-lin transform, etc. Don't want to do primary rotation. Issue with current ACES config is that unless image is in ACES2065-1, going to get primary rotation added into operations, which causes confusion. With NamedTransform, just allows applying the LUT. Intended to be a tool alongside other tools like color space transform, look transform, etc. Historically people are used to applying LUTs in VFX. They didn't necessarily know it was a named thing, just applied the right LUT. Some are used to working that way. It's different from OCIO, which is based on named color spaces. OCIO does something under the hood from choosing names. User doesn't know what it's doing. Takes color science implementation details away from user, giving it to software. Offloads that knowledge, which the config author has figured out for you.

  • Michael: Recommend calling out Nuke nodes to differentiate from OCIO transform classes. The OFX plugins will be a good example implementation here too.

  • Doug: Yes, OFX plugins can be one example. Still needs work to complete. Contributors have had trouble getting OFX compiled so far.

  • Michael: NamedTransform is essentially a toolbox implementation. In the new ACES config, all the utility curve spaces will be moved to named transforms.

  • Deke: Really useful for working on shots before color pipeline is setup.

  • Michael: Agree. Sometimes just need a transform.

• Context:

  • Zach: Started with background, explaining what contexts are and the expectation devs should have on how users are expecting apps to work. Provide specific examples for how different apps use them. Considerations for timeline-based workflows. How contexts change temporarily. Also use cases for an artist changing/overriding contexts for shot-specific looks, etc. Nuke provides basic key/value interface for specifying and overriding env vars. Should that be per-transform? Examples related to Nuke's design. Use cases for context variables and how users might like to see these exposed. Supervisor may have a lot of plates in nuke script, and want to toggle between them and have that change the viewer process, for example. In some contexts temporal workflows are important, and in others want to be able to change context in other ways. Recommendations on AMF support. Show different scenarios.

  • Doug: Great set of examples. 

  • Michael: This is a complex area, so good to cover so many cases. Could perhaps break into essentials and use case specific sections for more detail where needed.

  • Mark: I agree. Perhaps we can template answering these questions. Simplify format to: Should this be exposed to users? What's the background? Examples for specific apps? Can create template to share.

  • Doug: Agree, would be great.

  • Mark: Background can include link to docs, etc. Good to have that structure for the end.

  • Michael: Good for scalability too.

  • Group agrees using a template for final formatting of sections is a good idea.

• Items for next meeting agenda:

  • Colour picking investigation part 2