Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

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.
    • Discussion: whether to 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.
    • Discussion: Whether to 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 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
    • Discussion: 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.
    • Discussion: 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 can 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.
    • TODO: Set default view transform to "Un-tone-mapped".
    • Group consensus is that the config is in a really good place. Aall feedback at this point is really minor tweaks. Zach also gave good feedback that the Docker setup is working for generating config. 
    • Discussion: 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.
    • Needed color spaces that aren't in reference config:
      • Carol: Should account for CSCs in reference config. 
      • Michael: There's a ton of canon IDTs.
      • Carol: Should we be adding them? Could wait for input from users.
      • Kevin: If we make that choice what are we left with?
      • Carol: Few things 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.
      • 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.
      • Thomas: Removing 1GB of LUTs will be welcome.
      • Kevin: Will add this in addition to existing configs likely.
      • Zach: DCCs have removed some older configs.
    • Studio config generator work:
      • Michael: Do you want help with this? Some transforms don't have builtins.
      • Thomas: Do you want to add builtins? Or express in config?
      • Kevin: Use builtin if exist, 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 its a good idea to use colour. Easier to switch over later to builtins and has trusted data.
      • Thomas: Some may not agree, and don't want it to seem like conflict of interest.
      • Zach: Can generate matrices if needed.
      • Thomas: Couldn't sort rows in spreadsheet. Could use some help getting that in order. Sort front page and pivot tables.
      • Michael: Will help.


  • No labels