2021-05-11

Owned by Michael Dolan
Last updated: May 12, 2021 by doug walker
4 min read

May 11, 2021

Host: Michael Dolan

Attendees: 

Michael Dolan (TSC Chair) - Epic Games
Carol Payne (TSC) - Netflix
Doug Walker (TSC Chief Architect) - Autodesk
Christophe Brejon
Kevin Wheatley (TSC) - Framestore
Thomas Mansencal - Weta Digital
Zach Lewis - Method

OCIO Configs Working Group Meeting Notes

  • CG config:

    • Output color spaces:

      • Keep both HDR spaces (P3D65 and Rec. 2020 ST2084)?

        • Yes

      • Do we limit Rec. 2020 to P3D65?

        • No

        • Doug: When gamut limiting in view transforms, it's not always clear why it is the way it is. In OCIO might make more sense to implement gamut limiting as a look.

        • Group agrees.

        • TODO: Implement gamut limiting as an OCIO Look per limiting primaries in ACES configs.

        • Zach: Yes, don't want to differentiate the color spaces by gamut limiting.

      • Zach: Seen lately 600 nit ST2084. Should we implement this? 

        • Kevin: For OLED probably

        • Carol: Think we should start with standards.

        • Kevin: Include fewest color spaces for requirement in config.

        • Zach: Good strategy. Start small and expand out.

      • Doug: Thread on Slack about adding default material X spaces. Gamma 1.8 and 2.2 Rec.709 and Gamma 2.2 AP1.

        • Michael: Agree we should add these, especially since since MaterialX and OSL are working together, and we OCIO plans to collaborate too.

    • Texture paint role (recommended workflow?):

      • Is texture paint role for renderer or for texture painting?

      • Kevin: Distinguish between storage on disk vs what is used in renderer. For us, typically linear, viewing through OCIO view transform

      • Christophe: Similar. All textures linear EXRs. Kept sRGB primaries since not all software supports ACEScg. 

      • Michael: Since this is an ACES config, should likely go to ACEScg.

      • Group: agree.

      • Thomas: Promoted best practices and pushes vendors to do what they need to do.

      • Michael: Should we expose option to change roles?

      • Doug: could also leave roles unspecified, to indicate decision for end user, rather than strong opinion in part of config.

      • Kevin: Reference config not used in production, so roles don't make as much sense. Good to provide ready to use config, but could leave it up to builder in build interface.

      • Michael: Could generate multiple configs with different roles, for ACEScg and sRGB texture workflows, since those are the main use cases. Games pipelines would likely use the sRGB config for example. 

      • Doug: Can leave it open to application too. If certain roles not present, application can provide menu to choose. Two types of configs, Authored for show, to lock down, and the other is config like we're working on now, hoping to be useful to people at different facilities. Hard to predict best choices.

      • Zach: By convention can assign color space categories to different role spaces, and have app interface with options to choose an appropriate color space for specific roles, to provide limited color space selection.

      • Doug: AppHelpers menu helper could be used for this, with category. For texture paint and color picking, difficult to say how people will want to work. If config has role for that, an app should use it and not ask, since whoever authored the config wanted to lock it down. 

      • Christophe: Want to avoid primary clipping from using ACEScg.

      • Michael: Any objection to leaving the roles blank? texture paint, matte paint specifically?

      • Carol: Other option would be to do multiple configs.

      • Michael: I'm fine with either. The tricky thing with multiple configs is that we still have the issue of choosing a color picking role, which is more complex. If we leave them blank we'll need to document why, and provide recommended options and examples.

      • Christophe: Can help document this.

      • Thomas: Sounds great. Documentation on why something is missing and how to change it is often missing.

      • Kevin: Can understand reasoning, but users don't often want something that's going to modify their color spaces between pick and use.

      • Group agrees to leave roles blank if there are multiple color spaces that could be used, with proper documentation and recommendations for different workflows and roles that could be used.

    • Color picking color space (recommended workflow?):

      • Michael: Is there a sensible default for color picking?

      • Doug: First question, what is it telling the application? Currently says in docs "color in color selection UI can be displayed in this space while being selected in different space". Some interpreted that as a view transform for the color picker, but that doesn't make sense. Want that to match the other view transform. Other approach is that it's a video space. Historically using a video space for this. Would be for sliders and color picker display. What is this role telling the application to do? Is this something the app needs to enforce? Users sometimes may want to work in display space, and other times in rendering space. Feel like there are valid use cases for both. In Maya can work in display or rendering space.

      • Michael: Also complicated for apps like Mari where you may be working on color and scalar channels.

      • Christophe: The Maya support for both is useful.

      • Kevin: We've never used display or view transform for our role. Only used simple non-linear encoding. Like AP1 primaries with display gamma (sRGB, 2.4, etc.). In Mari you can do other things. More choices than color picking role.

      • Doug: Overlap between this group and UX working group. Think we should give more guidance to apps over how to interpret it. Like Christophe said, maybe we want two color picking roles. Or maybe used when conventional video space slider needed. But doesn't mean that they can't pick in rendering space.

      • Zach: Would also want failover behavior for when roles aren't defined.

      • Michael: Any objection to leave it blank and document practical examples?

      • Group agrees.

      • Thomas: Big issue with color picking is needing to know what's going on. Consistent behavior across application would be good. UX informed work.

      • Carol: Good to do work in UX to get apps on same page. And then look back at default roles.

      • Christophe: Think it's only correctly implemented in Maya. Docs are ambiguous. Maya good example.

  • Config generator update:

    • Thomas: Started work on CG config. With SIGGRAPH and other things starting at same time, will have low cycles for next months. Will work on it when time. Currently code mixes dictionaries and OCIO classes and given last week's discussion about serializing more, working on making it purely dictionary based, so can be serialized. When that is done, will implement features in CG config.