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
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).
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”!