ASWF TAC Meeting - 06 April, 2022

Video Conference Link

Voting member attendance

  • Kimball Thurston - Chairperson, Weta Digital Limited
  • Bill Roberts, Adobe
  • Gordon Bradley, Autodesk
  • Roy C Anthony, DNEG
  • Matthew Low, DreamWorks Animation
  • Christina Tempelaar-Lietz, Epic Games, Inc.
  • Brian Cipriano, Google & OpenCue Representative
  • Sean C McDuffee, Intel Corporation
  • Larry Gritz, Sony Pictures Imageworks
  • Jean-Francois Panisset, VES Technology Committee
  • Cory Omand, The Walt Disney Studios
  • Daniel Heckenberg - Animal Logic Pty Ltd / Industry Representative
  • Eric Enderton, NVIDIA & Asset Repo Representative
  • Sean Looper, Amazon Web Services
  • Michael Min, Netflix
  • Michael B. Johnson, Apple
  • Greg Denton, Microsoft
  • Sean O’Connell, Advanced Micro Devices
  • Mark Visser, Unity Technologies
  • Ken Museth, OpenVDB Representative
  • Carol Payne, OpenColorIO Representative
  • Cary Phillips, OpenEXR Representative
  • Joshua Minor, OpenTimelineIO Representative
  • Chris Kulla, Open Shading Language Representative
  • Jonathan Stone, MaterialX Representative

Other Attendees

  • John Mertic, Linux Foundation
  • David Morin, ASWF
  • JT Nelson, Pasadena Open Source consortium / SoCal Blender group
  • Scott Wilson, Rust WG
  • Allen Rose, Madison Square Garden
  • Alix Robinson, ASWF marketing
  • Alex Meddick, Rising Sun Pictures
  • Deke Kincaid, Digital Domain
  • Jason Scott, FuseFX/Rising Sun
  • Dennis Adams, Sony Creative Software / OpenFX
  • Gary Oberbrunner, OFX
  • Michael R Carroll, Intel, RayTracing Software Technical Enabling
  • Patrick Hodoul, Autodesk, OCIO
  • Michael Dolan, Epic Games, OCIO
  • Doug Walker, Autodesk, OCIO
  • Pierre Jasmin, RE:Vision Effects / OpenFX
  • John-Paul Smith, OpenFX
  • Sergio Rojas, Arena World
  • Rachel Rose, ILM, D&I WG

Apologies

Agenda

  • OpenColorIO Project Review
  • OpenFX Project Proposal Review
    • Kimball: what the future looks like, how much code vs specification
    • Gary:
    • What is OpenFX?
      • Open Standard for creating and using image-processing effects
        • Replaces proprietary APIs to simplify host and plugin developing, allowing broad compatibility with minimal effort
        • Also known as “OFX”
      • 2D VFX plugin API: images in/out, parameter defs & values, user interface
        • CPU, GPU
        • Extensible C-based API (with a optional(?) C++ layer)
      • Mature: in wide commercial & open use since 2004. Flame recently replaced its proprietary Sparks API with OFX
    • What is the Open Effects Association?
      • UK nonprofit formed to promote and maintain the Open FX Standard
      • Corporate and nonprofit members
      • Directors are the steering committee
      • Association runs the open process for updating the standard
        • Changes implemented by a member host and a plugin, and entire membership review changes on github with a defined process
    • OFX Support
      • Some OFX hosts: Flame, Resolve, Scratch, Catalyst, Diamant-Film, Nuke, Filmlight, Fusion, Left Angle, Hitfilm…
      • Some well known plugins: Sapphire, Boris FX…
      • Also in house plugins
    • What could we do with ASWF?
      • Broaden host support (Blender and others)
      • Broaden plugin support, including open source outreach and promotion
      • Strengthen community with more regular meetings, update, publicity and responsiveness (just started a Discord channel)
      • New features: (see github)
        • New GPU pipelines: OpenCL, CUDA, Vulkan
        • Color Management
        • Spatial formats for generators
        • Timeline Suite
      • Examples and documentation
      • Test and compliance suites for hosts and plugins
      • Update website
      • Improve C++ host and plugin layers
    • Questions
    • Resources:
    • Gary: it’s a layered API, generic plugin API could be used for audio, 3D… And the image processing layer is based on that.
    • Michael: OCIO added support for OpenFX with a number of plugins, lives in OCIO repo, but would like to contribute back. Pierre: haven’t heard of it! Gary: mailing list management has been an issue…
    • Larry: the repo is mostly header files, how much do the host and plugin developer has to write, how much redundant work is there between hosts and plugins, should there be more of a library. Or are the header files all you need? Gary: API spec is the header files, which is the defined interface. But there is work every host and every plugin needs to do to implement that. The C++ layer should wrap this up. Pierre: by design, it’s not a library, want to be able to support all kinds of hosts, from simple video editors to complex compositing systems without having to support everything. There is a handshake mechanism to allow the plugin to understand what the host supports. Gary: have written lots of OFX plugins, tend not to use the C++ wrapper and write directly to the API. Dennis Adams: the things you have to implement are host specific, with the exception around parameters. If you were writing a host from scratch, a library to deal with parameters could be useful, but if you already have it, you wouldn’t use it. If you are writing a new plugin, typically use an existing one as boiler plate, not too much from the plugin side you wouldn’t be writing yourself.
    • Larry: how stable has the API over time, are there issues with backwards compatibility? Gary: make sure everything is backwards compatible, if people are careful. Mechanism to negotiate between plugin and host. Standard may have become “excessively stable”… Pierre: not being a library means we can just add to the headers.
    • Christina: interested in what a reference implementation would look like. Pierre: wrote a “property tester” at some point, have open source hosts like Natron that implements the entire API. Dennis: there are required suites and optional suites, no way to enforce that everything needed is implemented, each vendor typically has a “kitchen sink” plugin that tests everything. Typically test against the most important commercial plugins. A Conformance Test Suite (CTS) host and plugin would be useful. Christina: different hosts would implement different parts of the spec. Pierre: some hosts return misleading info about what they support.
    • Joshua: curious as OFX as a way to model video effects in OTIO. Pierre: the data model of OTIO needs to be defined to it can be a suite in OpenFX that talks to the data model instead of talking directly to the code. Joshua: looking to get a timeline renderer (offline), is there a body of open source OFX plugins that would implement standard wipes / dissolves? Gary: yes, all the TuttleOFX stuff is open source (from Mikros). Pierre: it’s a bit old, so not sure it’s an actual “reference”. Gary: the plugins would be able to do this. Also open source plugins that ship with Natron (outside of OpenFX project).
    • JT: Is Natron still in development? Yes, it has restarted, a developer who moved to Amazon has it as his weekend project.
    • Christina: what industries is OpenFX mostly used in? Gary: Film / TV / Commercials, editing and VFX. Pierre: Resolve has free version, and OpenFX is their plugin API. Because of that, that’s a large user base. Christina: is there a predominance? Pierre: started with Compositing / VFX, now see it in video editing as well, color grading.
    • JF: does OpenFX say anything about ABI? Gary: no, since it’s headers only. Whatever compiler you need to compile for a specific host, OFX will work with that. Pierre: when started to support M1, it mostly just worked. Gordon: for a target application, you need to match that application’s compiler chain and library version, but can’t use a simple compile of a library? Gary: from experience back at GenArts, only had a single OFX plugin set for Windows / Linux / macOS (same at RevisionFX), since the API is C only, so no issues of ABI compliance. Only export 3 C symbols from the plugin, then it’s manually created vtables. Plugin as insulated from the host as possible (can still get symbol clashes). Dennis: plugins can take multiple images in and out to create transitions, not just one image in / one image out. Can also have zero image in for “generators” (like noise generators). All “read file” are zero image in, one image out. Can be plugged in to various places. So more than just effects. Pierre: can use it for zero image out for tracking for instance, just writing to parameters / data blobs.
    • Kimball: will probably need to figure out the integration details at the organization level.
  • OpenColorIO ASWF TAC Update - April 2022 (Carol)
    • Also Michael Dolan, Doug Walker, Patrick Hodoul
    • Contributor Data: project health, how we are running within ASWF
      • 321 commits, 3.83M LoCs changed, 25 contributors, from several different companies
      • Large chunk of configs from OCIO-Configs-ACES repo
      • Large contribution from Autodesk
      • Good growth over last 3 years
    • Technical Steering Committee
      • Chair: Carol Payne (Netflix) Chief Architect: Doug Walker (Autodesk)
      • TSC Members: Remi Achard (DNEG), Mark Boorer (ILM), Mei Chu (Imageworks), Sean Cooper (ARRI), Michael Dolan, Patrick Hodoul, Carl Rand, Mark Titchener, Keven Wheatley
    • Current staffing level
      • Currently have about six people contributing at least 1 day/week
      • Another six or so that do an hour or so per week
      • Occasional sporadic contributions from a wider group
      • Estimating about 3 FTE equivalents currently being spent on OCIO
      • Autodesk remains the largest contributor
      • It’s an on-going challenge to staff all the activities- need more help:
        • Keep the lights on (answer questions, investigate bugs, keep the CI running, approve PRs)
        • Do OCIO meetings, ASWF TAC, other ASWF projects, ACES, GSoC, marketing
        • Develop configs, tools, documentation, UX guidelines, SIGGRAPH courses, website
        • Discuss, specify and develop new library features
      • ASWF should consider encouraging more than 1 FTE from members
    • Completed Releases (Doug)
      • Delivered releases: v2.0.0 on 28-Jan-2021, v2.0.1 on 4-May-2021, v2.1.0 on 31-Aug-2021 at SIGGRAPH, VFX platform asked for 2022 release to be finalized by end of August 2021 (also v2.0.2 on 3-Sept-2021). Was difficult to do that by August, agreement would be to lock the API, and complete features at an end of year release, that worked reasonably well (v2.1.1 on 14-Dec-2021). Would like to have a “beta” release around SIGGRAPH, since that’s best time to interact with user base. Would like to have this conversation this year. Kimball: VFX Platform will come to present at an upcoming TAC meeting. Also v2.0.3 release at 16-Dec-2021 (bug fix / minor enhancement).
      • V2.1.x delivered new features highlights
        • ACES 1.3 reference gamut compression
        • OpenFX plug-ins
        • Python Package Installer (“pip install opencolorio”)
        • Open Shading Language (OSL)
        • Metal Shading Language (APple contribution)
        • OpenGL ES
        • PyOCIODisplay
        • Imath 3
        • Focus on connecting with other standards
    • Infrastructure (Michael)
      • Infrastructure has settled / become mature: CI, GPU CI…, hasn’t changed a lot but some improvements:
        • CI support for VFX Reference Platform CY2022
        • CD Python wheel build/release on tag push
        • OpenColorIO-Config-ACES config artifact CI
        • Biggest win was supporting Python Wheels, makes the library more accessible to users on a large number of platforms. Would be useful to look at as a wider initiative across ASWF projects.
        • OpenColorIO-Config-ACES repo, using GitHub Artifacts feature. Lots of dependencies, can be involved process to build a config. When a new change is pushed, CI pipeline will build a config and make it available as a GitHub Artifact.
    • 2022 Plans
      • V2.2 release for SIGGRAPH (tentative plans, under consideration)
        • Milestones on GitHub page
        • Built-in default config(s)
          • Allow OCIo to provide basic color management without an external config
      • ACES Config for v2
        • Three brand new, fully supported ACES configs
          • ACES Reference Config
            • In pre-release
            • Intended for development & testing, not for production use
          • ACES CG Config
            • In pre-release
            • Self contained config designed specifically for fully “computer generated” workflows - animation, graphics etc
          • ACES Studio Config
            • In progress - pre-release in a month or so
            • Closest replacement for the previous ACES configs, but new, shiny and making the best use of new OCIO vs features!
        • Working group meetings - every other Tuesday @11AM PT
        • Join the #configs slack channel
      • UI/UX Standards and Documentation Updates
        • Status:
          • Monthly working group
          • UX guidelines for app developers
          • Coverage for user facing OCIO features
          • Standard page template with:
            • Background
            • Resources (links)
            • Use Cases
            • Guidelines
            • Mockups
        • Up Next
          • Plan to hire technical writer
    • Discussion Topics
      • OCIO focus has been on feature development, but needs to transition to long-term resiliency
      • ASWF focus has been on growth, but should likely transition to long-term resiliency
        • New features, new projects…
        • But need to use our resources wisely, long term resiliency of projects. Joining ASWF has been a huge boon for OCIO, but still in constant concern of what happens long term, what happens if you lose a core developer. How do you keep the project healthy long term. Doug: looking for advice, takes a lot of work to keep a project like this going, as this becomes relied upon by more and more applications and studios, important that it stays healthy. Carol: important that we have discussions on this topic, we could use double the developers to keep this project going long term.
        • Members should commit more than 1 FTE? Carol: we had talked about not enforcing the 1 FTE rule, but more members are probably already contributing more than 1 FTE.
        • Larry: we may want to keep an eye on the ratio of projects to premiere members, as we take on more projects, there is a danger of diluting the FTE contributions. Carol: yes, the ratio is important.
      • How do we grow our contributor base?
        • Software engineers, of course, but also…
        • Website, documentation
        • Marketing, recruitment
        • Project management resources
      • Technical writing resources (documentation, user guides)
      • Integration / CD
        • Artifacts for releases (storage, etc)
        • Should this be standardized
      • Release schedule
        • VFX Platform release in the fall?
    • David: strategic questions are really important, we can do a strategy meeting at the TAC like we do at the Board, “who do we want to be when we grow up”!