March 6, 2023

Host: Carol Payne

Secretary: Carol Payne

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

  • Thomas Mansencal - WetaFX
  • Zach Lewis - Method Studios

Apologies:

  • Michael Dolan
  • Mark Boorer

OCIO TSC Meeting Notes

  • Moving from unittest to pytest
    • PR #1739
    • Will mean installing pytest & its dependencies prior to running the unit tests, which is a change vs. unittest which is included in default python
    • Is this change in dev env and extra steps ok?
    • Should this be in a virtual env / poetry to run tests instead?
    • Kevin - we should not dictate how environments are set up - we should be clear about what the needs are, and let end users handle it
    • Doug: is the extra install / setup worth the improvement/feature/time we gain from pytest?
    • Long term, using all the features in pytest might make it worth it
    • Right now, this PR is just to base level switch, and then we could move forward with optimization over time
    • Remi - we already have some of the package checks in cmake for the docs, etc. Right now if it doesn't find the packages, it fails. We could add it there
    • Kevin - virtual envs are ok as our recommended option, but we can't make it required - just a workflow to follow if you don't have established workflows
    • CI is separate and how we handle that - though if we were able to support a user/non system python install in our CI, we could just tell folks to run that script that we use in CI
  • CPU Optimization flags
    • Issue #1174
    • Please take a look and post comments as you have them
    • Kevin - would be interested to see these bundled options pulled apart to know if it's one thing really improving, or really just the combo of all of it added together
    • Remi - would be interested to see the results from both gcc and clang for more data points
  • Vendor plugins
    • Mark - foundry has untangled the OCIO nuke plugins from the main nuke codebase and are interested in contributing them back, but unsure if the main OCIO codebase is the correct place for them to be
    • Kevin - sort of makes sense for them to be separate, one is building the library and one is using it 
    • Remi - OFX plugins are built as part of the CI, so that makes them sort of an outlier from the other plugins
    • Doug - having them in the repo comes with strings - two approvals, etc but we definitely took the "plugin author knows best" approach
    • Mark - we think the best approach for Foundry is to host them on the foundry github & remove them from the main OCIO library 
    • Maybe a PR from foundry to remove them from the OCIO library and add a readme to where they will live in the foundry github
    • Mari as well? Yes, it would fall in the same category
  • Conformance tests beyond UX
    • Vendor has a bug or feature - how can OCIO support them to "do the right thing"?
    • First steps are to decide what the minimums are (hopefully via the OCIO UX working group / Google Season of Docs)
    • Could be written as a sort of set of test rails like a QA dept might run. 
    • Start conversations with historically "mature" OCIO implementations; use as a starting point
    • Use google doc as a starting point to dump info, try not to think too much about how we do this long term - just start compiling information (Carol will create a google doc to start)
    • build on what we have example wise already (LUTs, sample OCIO configs, images, etc)
  • No labels