September 4, 2023

Host: Doug Walker

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

  • Zach Lewis (TSC) - Method
  • John Mertic - Academy Software Foundation / Linux Foundation

  • Thomas Mansencal (TSC) - Weta
  • Carol Payne (TSC Chair) - Netflix

  • Mark Titchener (TSC) - Foundry

  • Carl Rand (TSC) - Weta Digital

  • Doug Walker (TSC Chief Architect) - Autodesk

  • Kevin Wheatley (TSC) - Framestore

  • Mark Reid - Mark Reid VFX

Apologies:

  • Carol Payne

OCIO TSC Meeting Notes

  • Python binding RPATH issue:
    • Mark T: I tried building OCIO 2.3 and when I tried to use the Python binding it gave me an RPATH problem. However, using PyPI worked. This was on an ARM macOS machine using Python 3.10 and 3.11.
    • Kevin: I just tried on Linux and had a similar problem, not sure if it's a bug or just needing to change some of what the scripts used for 2.2 are doing.
    • Remi: It looks like the if-statement that sets the RPATH is not being entered anymore, so probably a bug.
    • Remi logged an issue here.
  • OCIO 2.2 Configs for ACES:
    • Mark T: Are the OCIO 2.2 versions of the new configs finished? Doug: As far as I know, they are, however we should get confirmation from Thomas.
    • Action item: Doug to share the latest configs on #tsc.
  • Unit tests
    • Mark R: I've been looking at the various unit test failures on ARM. Found a number of issues, including differences in rounding methods and, in gamma op, using > in one path and >= in another. 
    • Doug: Thanks for looking into this!  This is an area that definitely needs some work to make the floating-point unit tests less fragile.
  • ocioview
    • Remi, Mark T, and Doug have tried running ocioview. Should follow up with Michael at a future TSC meeting to discuss next steps.
  • ACES AMF support:
    • Doug: I'd like input on what would be the best way to support AMF in the OCIO API. The goal is to improve the pyocioamf Python script with beta AMF support that was introduced back in February. One way to do it would be as another FileFormat module.
    • Mark B: There are still a lot of unknowns around the AMF specification. For example, one may not want to apply all the remaining processing, may only want to apply certain elements. As another example, what if the display a user has does not match what was used for the creation of the AMF? We should wait until the ACES group has clearer workflow guidance before officially supporting it in OCIO.
    • Kevin: There is the matter of image state as well, which LMTs should be applied, it's complicated.
    • Remi: Is it possible to tag media in any color space?  Is it a supported workflow to want to invert processing that has already been applied?  Doug: I suppose you could tag any media that has an ACES CSC transform associated to it, even if it's not a camera color space that has an IDT, but am not sure.  The notion of supporting inversion of steps that have been applied is interesting.
    • Doug: Thanks for the thoughts, that was helpful. It sounds like taking a FileFormat approach may not be best (\?) since we probably want to provide a fair amount of control over what processing elements OCIO could generate based on a given AMF file. At a minimum we probably want a way to specify the desired output color space (e.g. ACEScg, or use a different display) and give various options for which LMTs or working space is desired.
  • No labels