AcademySoftwareFoundation / AcademySoftwareFoundation/openfx

Conform Effects

Open
#217 3 comments 0 reactions 1 assignee Claimed by @john-paulsmith View on GitHub
standard change
Dominant language
C++
Stars
570
Forks
152
Avg merge
5m
Merged PRs (30d)
2

Description

# Open Effects Proposal for Standard Change

Please read the contribution [guidelines](https://github.com/ofxa/openfx/wiki/Extending-OpenFX-Guidelines#submit-a-proposal-or-bug-report-to-review) first.

## Standard Change Workflow
- [x] Create proposal as issue (you're doing this now!)
- [x] Tag this issue with `standard change` tag
- [x] Identify subcommittee: at least one plug-in vendor, and at least one host
- [ ] Discuss the idea in this issue
- [ ] Write new or updated code and doc
- [ ] Publish updates as a pull request (ideally on a `feature/PROPOSAL-NAME` branch)
- [ ] Make sure that PR references this issue number to keep them in sync
- [ ] Discuss and review code in the PR
- [ ] Meet all requirements below for accepting PR
- [ ] When subcommittee signs off and other members don't have any further review comments,
maintainer merges PR to master which closes PR and issue

## Requirements for accepting a standard change:
- [ ] Header files updated
- [ ] Documentation updated
- [ ] Release notes added
- [ ] Compatibility review completed
- [ ] Working code demonstrated with at least one host and one plugin
- [ ] At least two members sign off
- [ ] No further changes requested from membership

## Summary

Users want to move a project from a _foreign_ (non-OpenFX) host to an OpenFX host. This proposal includes APIs to facilitate the process.

## Motivation

Most shows have a two-stage editorial pipeline. A variety of names are used for these stages, but I will use the terms _offline_, where creative editorial decisions are made, and _online_, which includes colour grading, final VFX and other finishing tasks. The process of transferring projects from offline to online is _conform_, i.e. _conforming_.

Conform is facilitated using an EDL (edit decision list) file, which is exported from the offline host and imported into the online host. The dominant format is AAF, although OpenTimelineIO starting to become more popular. The EDL format used isn't important for this proposal, as long as it contains complete information about effects used in the offline.

This process often discards effects for a variety of technical reasons, and many users have requested we improve this situation so effects flow through the conform process as seamlessly as possible.

## Problem

Conforming between foreign hosts (mainly Avid Media Composer and Adobe Premiere) and OpenFX hosts is difficult. Although many plug-ins are available for both OpenFX and foreign APIs, effects and parameters might have different names, and parameter values might have different semantics (e.g. scaling). Hosts do not have the information to conform effects as this is proprietary to plug-in vendors and there is no standard way to communicate it.

## Impact

This will be an optional feature delivered using one or more new actions and properties. If plug-ins don't implement these, their effects won't be conformed.

## Documentation Impact

Usual documentation changes will be needed for the new APIs

## Stakeholders

Both hosts and plug-ins will benefit from this change.

## Discussion

There are two parts to this proposal:

1. Alternative naming: `kOfxPropAka` will allow plug-ins to list alternative names by which any named object could be known. A `kOfxPropAka2D` property covers multidimensional parameters.
2. The conform action: `kOfxActionConform` will allow plug-ins to update their parameter values and keyframes based on information passed from the host. Prior to invoking this action, hosts will set parameter values to the best of their ability, and the plug-in will examine these and update them based on internal knowledge about where they came from.

To support point 2, plug-ins will most likely need to modify their foreign implementations to store additional information in hidden parameters. This might be as simple as a host/version identifier or as complex as an opaque blob of their entire parameter set.

One concern is parameter interpolation, which is addressed by #116. Meaningful progress can be made without this, because hosts can already make a best effort to match the interpolation type during conform.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.