June 27, 2022

Host: Carol Payne

Secretary: Doug Walker

Attendees:

  • Rémi Achard (TSC) - DNEG

  • Mark Boorer (TSC) - Industrial Light & Magic

  • Mei Chu (TSC) - Sony Pictures Imageworks

  • Sean Cooper (TSC ACES TAC Rep) - ARRI

  • Michael Dolan (TSC) - Epic Games

  • Patrick Hodoul (TSC) - Autodesk

  • John Mertic - Academy Software Foundation / Linux Foundation

  • Carol Payne (TSC Chair) - Netflix

  • Mark Titchener (TSC) - Foundry

  • Carl Rand (TSC) - Weta Digital

  • Doug Walker (TSC Chief Architect) - Autodesk

  • Kevin Wheatley (TSC) - Framestore

Apologies:

  • Mark Titchener

OCIO TSC Meeting Notes

  • SIGGRAPH events:
    • Carol:  SIGGRAPH has changed the polices on events.  As a result, ASWF Open Source Days will be Aug 8 & 9 now, expect an announcement from Emily soon.  BoFs may be recorded but are still virtual-only.
    • Doug:  Do BoFs still require a conference pass?  Kevin: Yes, requires a fairly expensive Experience+ pass.  Group:  We don't think a BoF would be well-attended given those restrictions.
    • Carol:  I propose we not have a SIGGRAPH BoF and that we try to incorporate a lot of user discussion/questions into our OSD presentation.  Group:  Agreed.
    • Carol:  It would be nice to have an on-site event for OCIO people in Vancouver.  Group:  Agreed.
    • Michael:  I might be able to talk about the config editor I have been working on.  Group:  Cool!
    • Kevin:  Someone should talk about the CLF stuff, etc. that the Configs working group has been doing.  Group:  Agreed.
  • Documentation Tech Writer:
    • Carol:  I will take an action item to send emails to the three candidate writers.
  • Documentation issues:
    • Doug:  As part of our recent PRs, we have noticed some issues with the documentation.  First issue is that ReadTheDocs for the main branch is not updating automatically as PRs are merged.  Michael:  That might be due to the name change of the master branch to main.  I will fix the script on the RTD site.
    • Doug:  Second problem is that the Python API docs have been out-of-date for awhile but the CI process has failed to detect the problem.  Either there is a problem with the frozen docs comparison scripts or they are not being run as intended on CI.  Michael:  Contact me after the meeting.
  • Unique Identification of Configs:
    • Kevin:  What if someone using the latest OCIO lib has access to a Built-in Config and wants to collaborate with someone on an older release of the library, how could they obtain that same Built-in Config? 
    • Doug:  Each Built-in Config is identified by a unique name string that is chosen by the OCIO Configs Working Group.  It has version numbers for the config itself, OCIO, and ACES.  The Configs WG will be publishing the new configs on-line (location is still TBD) but it will be possible to download the config with the same name string.
    • Kevin:  Someone could download it and make some changes to it but not change the name.
    • Carol:  Agreed this is a potential problem, but it's a more general OCIO problem, not specific to the Built-in Config feature.
    • Doug:  There is a cacheID string already available from the public API for a config object that could be used to detect that.
    • Remi:  Should probably add that to the ociocheck command-line utility.  Doug:  Great idea.
    • Kevin:  Would that be changed by comments in the Yaml, or is it only based on the transforms?  Doug:  I think it's currently the whole Yaml.  The Processor cacheID is only on the transform ops, but that is specific to a given transformation, not a whole config.  But the pieces are there to make a hash that would only be on the transforms used by a config.
    • Group:  Would be great for someone to log an issue.
  • 2.2 Release
    • Remi:  Are there changes we should make to the 2.2.0 API in preparation for the 2.2.1 release?  Kevin: Only if there are things like LogC4 that are sure to happen.  Doug:  Agreed.  The 2.2.0 release will be late October, so let's discuss again as we get closer.
    • Doug:  There has not been much discussion on the 2.2 Planning board I put together.  As previously stated, I put a ton of stuff on there for the group to consider but we will not be implementing all of it (in other words, it is more of a discussion tool than a road-map).  Just to clarify, this was mainly to prioritize the features that the community would like the Autodesk team to implement.  We have been implementing things from this planning board and Remi has also been implementing some great features so there is some cool stuff in progress for 2.2.
  • No labels