January 29, 2021

Host: Michael Dolan

Attendees:

• [X] Michael Dolan (TSC Chair) - Epic Games

• [X] Carol Payne (TSC) - Netflix

• [X] Mark Titchener (TSC) - Foundry

• [X] Doug Walker (TSC Chief Architect) - Autodesk

• [X] Christophe Brejon

• [X] Zach Lewis - Method

OCIO UX Working Group Meeting Notes

• Working group goals:

  • WIP outline for topics: https://docs.google.com/document/d/1_NS2UMSjbkqoMI_tvdsaOvd8NIYg3MeWQ8pKpXFQEgM/edit?usp=sharing

  • Michael: Potential goals are to develop document outlining OCIO implementation best practices, along with code examples.

  • Chris: Recent discussion on ACES central. From user point of view, most software has implementation/usage examples.

  • Doug: Thread talked about how artists can be confused by concepts in OCIO. We dont realize what’s going to be confusing for non color scientists or those new to OCIO. Display space values vs. rendering space values, etc. Helpful to clarify intent of roles, provide use cases, user stories. What could improve usability.

• Roles:

  • Mark: Roles have been fundamentally misunderstood, how they were intended to be implemented in DCC. With roles in Nuke, did what made sense for each input file type. Can we come up more consistent roles between different applications? Trying to keep those available more consistently used, and then users can extend as needed. Mari needed more roles than were available, and wanted to get away from confusion of using builtin roles. Mari specific roles solves some problems and complicates others. Also fundamentals for DCCs implementing roles, how they are exposed, ok to create own?

  • Zach: Could solicit user stories about ad hoc use of roles. Studios have specific cases.

  • Mark: Some roles created in internal conflicts that shouldn’t be user facing. Something to address. DCC implementation and end user understanding.

  • Michael: Also have categories and encodings playing in now in v2.

  • Mark: Roles were previously aliases. Now we have separate aliases. Can be confusing.

  • Zach: Doug brought up 2 axes for categories, user (beginner/advanced) and task.

  • Chris: Will we create new roles? Color timing vs. color grading? Color picking or color selection/mixing?

  • Michael: Removing roles would break backwards compatibility. Changes public API. Can add roles though if needed.

  • Doug: Can create application specific roles.

  • Zach: Great to have central place for app developers to share custom roles.

• Examples:

  • Carol: Tossed around idea of adapting apps to be good example. Is that a goal? This is how it's done and examples, and DCCs have choice.

  • Doug: Think it would be helpful for sample code to reflect best practices.

  • Mark: We've talked about identifying areas where it's clear to use them. Do we just write docs and provide examples? Create OFX plugins?

  • Michael: OFX and ociodisplay are both good opportunities for examples.

  • Carol: Could work with OIIO IV too.

  • Michael: Could the Nuke plugins be shared as examples?

  • Mark: Want to do that. Need to untangle from Nuke as much as integrate v2. Trying to work on underlying design.

  • Michael: Nuke important tool for color scientists and experimentation with OCIO.

  • Mark: Not a lot of fundamental changes from nodes in repo.

  • Zach: Looking forward to interchanging CLF and CTF node graphs. Artists can construct these graphs with arbitrary nodes.

  • Doug: Should be viable. Take OCIO transform.

  • Mark: If people using same reference, interpolability becomes better.

• Viewport controls:

  • Michael: Another important topic is viewport controls for same appearance between apps. New DisplayView transform is more open than the LegacyViewingPipeline, so could diverge more easily.

  • Zach: Yes, like order of operations with exposure and contrast.

  • Doug: Agree good topic of conversation. Reason ExposureContrast transform has multiple modes is that our internal tool had those modes. LegacyViewingPipeline implementation converts to scene linear to apply exposure. Fine for viewing single image, but for other app with realtime log playback, do you want to do log to lin just to do exposure? Big performance hit for 4k, 8k. DisplayView transform the core part of it. Needs consistency between apps. Stripped out other pieces because some apps want to do those steps differently. Good to have best practice for guidance on what to do.

  • Zach: Color space attributes can inform that.

• Dynamic parameters:

  • Michael: Dynamic parameters example for supporting uniforms would be good. Can be a little confusing at first.

  • Doug: Unit tests best source right now.

• Grading transforms:

  • Zach: Good to have basic interface for playing with RGB grading curves too.

  • Michael: Are the grading transforms supported by CLF or CTF?

  • Doug: If you call write on transform to CLF format, will need to bake these. CTF can support all OCIO transforms though.

  • Michael: Is CTF a standard? Can others implement?

  • Doug: OCIO is open source implementation of CTF. There is some docs in AD product docs, but doesnt include all of it. To clarify on CTF. Started as AD thing. Now think of it as native format of OCIO. Can always serailize to this format.

• Task distribution:

  • Michael: For this meeting: Topical discussion on different pieces? One per meeting perhaps.

  • Doug: Yeah, how do you make progress in wg? Hard to have tangible output.

  • Carol: This group similar to ACES implementation groups. If implementors not part of conversation, not sure. It works if software implementors can come to an agreement.

  • Doug: How are we going to make progress in group? Comes down to what extent people are willing to spend time between meetings producing something tangible. Something written down, enhancements, etc. Or convincing someone else to do that. Relies on people taking action between meetings.

  • Carol: I think doc is good place to start, but good to reach out to implementors to see what’s confusing. If you were looking to make improvements for interacting with OCIO, what’s stopping you?

  • Chris: I can contribute outline and examples of different ways applications have implemented color picking.

  • Michael: Color picking complicated for diffuse textures and lit images. Great topic to cover.

  • Doug: Clears the way for rest of work.

  • Zach: My immediate priority is finishing doxygen translation. Making progress, but want to crank out that. Can write about considerations for config authoring after that.

  • Mark: And how to represent that in UI as well. Taking info from config and what best practices are for that. Willing to do things between meetings. UI facing things we would outline or document. Too much to go through. Need a way to prioritze it.

  • Carol: Could be separate event to reach out to people with how design looks and get feedback.

  • Doug: Happy to share my take on these things. Don’t want to say how everyone has to do it. Rather share thought process. How others can add value on top of that. Sharing concrete examples. Each product has unique priorities. Depending on releases, may or may not be able to implement things the way we like.

  • Mark: Agree that reference implementation would be nice to do on assumption that there are limitless resources. Could form good basis to know things you would like to do.

  • Doug: With OFX plugins could provide example that would be not fanciest, but would have core concepts, how to use categories, etc. UI and sample code.

  • Mark: Happy to mock up UIs for how to present options, and properties panel. Higher level outline.

  • Michael: Can create outline from shared doc, including concepts we might want to cover. Can then divide tasks amongst group to progress.