/
TSC Meeting Minutes 2026-03-03

TSC Meeting Minutes 2026-03-03

OpenFX TSC — Meeting Minutes

Date: Tue, Mar 3, 2026 (monthly)

Duration: ~1:30

Attendees:

  • Gary Oberbrunner (Dark Star Systems)

  • Pierre Jasmin (RE:Vision Effects)

  • Guido Veldkamp (Assimilate)

  • Paul Miller (Boris FX)

  • John-Paul Smith (Boris FX)

  • Phil Barrett (FilmLight Ltd.)

  • Mikki Wells (Boris FX)

Regrets / Unknown: Carol Payne (ASWF), Resolve/Blackmagic team

Topics & Notes

1) Clip and image metadata / Property metadata PR

  • Gary pushed a new PR with full property metadata support, including:

    • A YAML file (OFXProps.yaml) describing all known properties, their property sets, types, dimensions, and read/write parity.

    • New auto-generated C++ header files (OFXPropsBySet, OFXPropsMetadata) providing type-safe property definitions and accessors.

    • Auto-generated documentation replacing the old, outdated property set descriptions.

    • A genprops.py script that runs as part of the regular build (or manually) to regenerate headers from YAML.

    • An example plugin demonstrating usage of both standard OFX properties and host-specific custom properties.

  • Host-specific/vendor properties are supported: hosts can define their own YAML files and generate host-specific header files. An example ("my host") is included in the PR. Best practice documented in the README: host vendors should pre-generate the header file from their YAML and ship both to plugin developers.

  • Pierre asked about extension suites — confirmed the framework supports vendor-specific properties with fallback detection.

  • Phil asked whether custom actions with properties are covered — currently property names are defined but custom actions don't get additional type safety beyond the standard mechanism.

  • Documentation split concern (JP): Canonical documentation is now split between the header files (textual descriptions of what properties do) and the YAML file (type, dimension, writability, etc.). JP suggested embedding YAML fragments directly in the header comment blocks (like front matter) so the YAML file could be fully auto-generated from headers, eliminating the two-source-of-truth problem. Gary found this idea appealing and will investigate. The alternative of moving all documentation into the YAML was considered too daunting.

  • Contrib directory proposal: Discussion of creating a contrib/ directory in the OFX repo where host vendors could publish their custom SDK headers and examples (e.g., contrib/resolve/, contrib/nuke/). Show of hands from attendees was unanimously in favor. Potential licensing concerns noted (vendors would need to agree to the repo's BSD license), but Phil suggested vendors unwilling to open-source could at least commit a pointer/link. Gary will raise this idea with host vendors, including at NAB.

  • Paul asked to review the PR carefully against his own work; Gary hopes the PR provides a foundation for Paul's dynamic property/metadata suite work.

2) Windows ARM64

  • Current state: Resolve and Vegas Pro are both ARM64EC hosts.

  • Core issue debated: where should ARM64EC plugins be installed?

    • Option A (JP's position): Put ARM64EC plugins in the existing Win64 folder so unmodified Intel hosts running under emulation on ARM64 hardware can load native ARM code plugins (the key benefit of ARM64EC).

    • Option B (Pierre's preference): Create a new WinARM64 (or similar) folder for ARM64EC plugins, keeping the Win64 folder for x64-only binaries. This preserves clean separation for heterogeneous network rendering environments (mix of Intel and ARM machines sharing a plugin folder), but means unmodified Intel hosts won't discover the ARM plugins.

  • Pierre noted practical concerns: MediaTek ARM chips are also entering the market (alongside Snapdragon), GPU driver support on ARM is still immature, and most heavy computation is GPU-bound anyway so the Intel-vs-ARM CPU difference may matter less than expected.

  • JP pointed out that hosts already in the market (Resolve, Vegas Pro) currently look for ARM64EC plugins in Win64, so changing the spec would require those hosts to release updates.

  • No consensus reached. Gary will send an email and Slack message to the broader membership explaining the tradeoffs (including an explanation of ARM64EC vs ARM64X vs native ARM64 flavors, per Guido's suggestion) and solicit feedback.

  • Pierre asked whether other ASWF projects face a similar plugin-path issue; the group noted that most other projects (OpenEXR, OCIO, USD) are built from source rather than distributed as binary plugins, so the issue is somewhat unique to OFX.

3) Color management for color parameters

  • Extended discussion on how to tag color parameter values with their color space so plugins can interpret them correctly.

  • Background: Currently, when a host delivers an RGB triple to a plugin via a color parameter (e.g., from a color picker or eyedropper), the plugin has no way to know what color space it's in. Different hosts behave differently (some deliver sRGB from UI pickers, some deliver scene-linear from image picks, some deliver the working space).

  • JP's proposal: Leverage the existing color space negotiation mechanism (from the color management extension for clips). Once the host and plugin have negotiated a color management style (basic spaces vs. OCIO, etc.), the same agreed-upon set of color space strings can be used on color parameters. A color-space property would be added to each color parameter, set by whichever party (host or plugin) writes the color value.

  • Key design questions discussed:

    • Should the color space property be read-write by both host and plugin? Consensus leaned toward yes, with the rule: "if you set the value, set the property."

    • Should there be a new atomic API call (set value + color space together)? Paul initially liked this but noted it could imply animated color spaces, which is undesirable (interpolation issues). The group settled on preferring a simple property approach.

    • Mikki Wells argued clearly: since color space cannot be animated (interpolation would be undefined), it shouldn't need to be set with every keyframe — a single property on the parameter is sufficient.

    • Gary proposed that the plugin could set the color space once at parameter creation time (from the negotiated set) and it would be immutable thereafter. This simplifies things but doesn't cover the case where a plugin does image analysis and wants to write results in the clip's color space.

  • Pierre's proposal (revisited): Define a "normalized" internal color space for parameters, and provide a suite with conversion functions (to/from working space). Paul expressed support for this approach as it relegates conversion to a suite and avoids the complexity of mutable color-space properties. JP noted this could be a new suite sitting alongside the color management extension, using the same color space strings.

  • No final decision reached; the group acknowledged incremental progress. Multiple viable approaches remain on the table. Discussion to continue next meeting.

4) NAB attendance

  • Pierre is attending NAB. Gary may attend for a day. JP unable to attend due to injury. Paul not attending.

  • Gary suggested using NAB as an opportunity to discuss the contrib directory idea with host vendors.

Action Items

  • Gary Oberbrunner

    • Investigate JP's suggestion of embedding YAML fragments in header comment blocks to eliminate the separate YAML file as a source of truth. (DONE!)

    • Send email + Slack post to the broader membership explaining the Windows ARM64 plugin path tradeoffs (with explanation of ARM64EC/ARM64X/native ARM64 flavors) and solicit feedback.

    • Capture color parameter discussion proposals in a write-up for continued discussion.

  • Paul Miller

    • Review Gary's property metadata PR carefully against his own metadata suite work.

  • John-Paul Smith

    • (Continued from previous) Update conformance-related PR and re-engage Blackmagic for feedback.

  • All

    • Review Gary's property metadata PR (#233).

    • Consider the contrib directory idea; host vendors should think about whether they'd publish their custom headers under the repo's BSD license.

    • Think about color parameter color-space proposals ahead of next meeting.

Meeting Recording and transcript are at https://zoom.us/rec/share/vROA3vQa2cbzGH-DGSohHOoWxrUQZ7uC7oDe9NuS-IoP6SFD1yy3fj7YAPQWuEHm.XAwWGy3DBgIpmT4g

Next Meeting

Date: Tue, Apr 7, 2026, 11am EDT (monthly; note time change for US!)