2021-03-02

Owned by Michael Dolan
Last updated: Mar 02, 2021
5 min read

March 2, 2021

Host: Michael Dolan

Attendees: 

Michael Dolan (TSC Chair) - Epic Games
Carol Payne (TSC) - Netflix
Doug Walker (TSC Chief Architect) - Autodesk
Dennis Adams - Sony
Zach Lewis - Method
Kevin Wheatley (TSC) - Framestore
Thomas Mansencal - Weta Digital
Daniel Brylka

OCIO Config Working Group Meeting Notes

  • Reference config status update:

    • https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES/pull/11

    • TODO: Make "Raw" a shared view. Limitation with shared view API currently where null view transform must be passed in as an empty string. Could be resolved in OCIO Python API by creating an overloaded function without the view transform arg, instead of reordering args which would break API compatibility.

    • Use a prefix other than "ACES - " for IDT-like CSC transforms?

      • Thomas: CSC could be used as prefix. Made PR to add Venice transform as CSC to aces-dev.

      • Doug: Concern is end users. No idea what's in aces-dev. Usually presented as camera IDT. Should be input transform.

      • Michael: Can be aliased in studio config.

      • Thomas: Ok for reference config to call it CSC.

      • Doug: What is vision of reference config? Dev resource for aces contributor testing? 

      • Michael: Doubt will be used much in production env, more for validating ACES.

      • Carol: Agree. Most applications will ship with studio config.

      • Kevin: We could recommend that. Say reference config is for this purpose.

      • Michael: Could also be starting point for custom studio config.

      • Carol: If it is a jumping off point for custom studio config, consistency would be best. Could make them input in that case.

      • Thomas: It's tricky. Technically we're not using any IDT right now.

      • Carol: We know that but many users don't, so may be confusing.

      • Thomas: Good point. That's why we need ACES transform ID in desc. Maybe it's an aces-dev issue.

      • Doug: These camera transforms are CSCs for use in ACES metadata file. Only CSC transforms are usable to apply a look with AMF. That's why they're there. Will generate some confusion but understand the reference config emulating aces-dev.

      • Carol: Could ask Scott and Alex, to see what their vision is. Good partnership.

      • Michael: Could we use both and alias?

      • Carol: Think we should avoid aliases in this config.

      • Doug: Not sure aliases will help since only one will show up in interface. Think we should stick with it as-is for now and put out for feedback.

      • TODO: Get input from ACES team on whether CSC camera transforms should be treated more as input spaces in this context.

    • Put "Display -" in front of display color spaces?

      • Zach: "Output - " would be good, but used for view transform already.

      • Michael: Yes, that's a notable difference in OCIO v2, is that output transforms are now a view transform and a display color space, vs. just a color space like v1.

      • Kevin: What if we want to create a color space to do this?

      • Doug: Can use DisplayViewTransform in color space, which will do view transform. Other way to handle it would be for tools to allow use of display view transform in addition to color space transform. Also not using family for displays. If we use display prefix, also add to family.

      • TODO: Group agrees to use "Display -" as prefix

    • Blue light fix transform implementation:

      • Doug: Propose making this a Look instead of a color space.

      • Group agrees that all LMTs should be made into looks.

    • Config order:

      • Doug: Should we reorder spreadsheet to match config ordering?

      • Thomas: Categories can be added to spreadsheet too.

      • Kevin: Where does "Display" go in order. Depends on how conceptually thinking of config. Suggest putting it after "Output" spaces.

      • Michael: Is concern about ordering related to presentation in DCC menus? Since OCIO v2 has more filtering attributes (category, encoding, family), may have fewer color spaces in some menus which would impact order.

      • Zach: Also will take into account family hierarchy.

      • Doug: Have display color spaces, ACES color spaces, utility color spaces. CSCs show up as ACES. Once we get this completed we can look in app to see how it is organized. In terms of displays, P3-D60 is first, but not necessarily the most common. Might want to start with sRGB, then Rec. 709, etc.

      • Kevin: If you have long list, alphabetical is better, but for short list, categorization is better.

      • Thomas: Could use some help sorting the spreadsheet. Need to sort front page and pivot tables.

      • TODO: Michael and Doug will help sort spreadsheet

    • TODO: Set default view transform to "Un-tone-mapped".

    • Group consensus is that the config is in a really good place. All feedback at this point is really minor tweaks. Zach also gave good feedback that the Docker setup is working for generating config. 

    • Image comparison CI:

      • Thomas: Image comparison CI good thing to do. May take time.

      • Carol: Could be interesting for new developers. Do not need as much knowledge. Could be part of ASWF internship.

      • Doug: Academy hires student to work over the summer. Could propose to them for this work too.

    • Thomas: Can use generator on ACES end too. Use container to examine their work, picking up incorrect IDs etc. Good tool for OCIO and ACES

  • Studio config scope discussion:

    • https://docs.google.com/spreadsheets/d/1GB0LTJhf67NYb0GSc3yluac90yIY0bW2O58SWQxHts8/edit?usp=sharing

    • Michael: Thanks all for updating the include column. I added a "In Reference Config" column to show which spaces are already accounted for. The include column minus the spaces already in the reference config will be our list of spaces to add to the generator for the studio config:

      • Michael: Most spaces we need to sort through are IDTs and utility spaces. There's a ton of canon IDTs.

      • Carol: Should we be adding them? Could wait for input from users, in case they aren't being used.

      • Kevin: If we make that choice what are we left with to add?

      • Carol: Few things to add at bottom. Unofficial IDTs. GoPro, Davinci, BaseLight, etc.

      • Doug: Linear color spaces can be added. Not clear what some of the utility shapers are used for.

      • Kevin: Could demonstrate for users how shaper can be implemented to match what's done internally for v2. Help avoid solution being replicated from v1 config.

      • Doug: Could add them but make them not show up by default.

      • Carol: Should talk with ACES IDT group about the scope of IDTs to include. 

      • Thomas: Could have them in generator, but not include by default. Optional for building config you want. Vendors can choose what to include in shipping configs.

      • Carol: Like that idea a lot. Giving end user power to decide.

      • Kevin: Should also consider how many years till this is adopted. Config won't be relevant for a year-year and a half from now.

      • Zach: Depends on how it is used. Wouldn't be used in DCC apps until lowest common denominator.

      • Michael: Will likely ship with v2 integrations since it's the only public v2 config.

      • Thomas: Removing 1GB of LUTs will be welcome.

      • Kevin: Will add this in addition to existing configs likely.

      • Zach: Some DCCs have removed some older configs.

    • Studio config generator work:

      • Michael: Do you want help with this Thomas? Some transforms don't have builtins.

      • Thomas: Do you want to add builtins? Or express in config?

      • Kevin: Use builtin if exists, otherwise embed matrix. Until we have Mark's ability to generate from primaries. Then can stick to minimal filesystem interaction.

      • Michael: Can add builtins later, but should only rely on current release for now to stick with VFX reference platform CY2020.

      • Thomas: Many ways to express these transforms now, depending on what you want to do. Can be problematic. How are we deriving them? From colour?

      • Michael: Think it's a good idea to use colour. Was going to suggest the same. Easier to switch over later to builtins and it has trusted data. I've used it in the past to extend the ACES config.

      • Thomas: I don't want it to seem like conflict of interest. Open to other options if we prefer not to add another external dependency.

      • Zach: Can generate matrices if needed.

    • Topics for next meeting:

      • Continue discussion on non-builtin color space generation, whether to source data from colour, and on scope.