(Pierre Jasmin): Do we need to wait for V2 if we make a V2 version of EffectHandle suite?
Do we need an handshake to know if host supports that?
Spatial Formats Are Broken, Replace with New Properties and a new Action Proposed
Standard version: 1.5
Major Change
Pierre (RE:Vision Effects), Peter Loveday (BMD Fusion)
Regions of definition are well defined concepts within OFX, the ‘format’ of a clip is not. For example a clip may be HD, 4K, SD etc… while the RoD need not be congruent to the ‘format’ at all. Furthermore, effects have no way of changing the spatial format. For example an effect that up scales images from SD to 4K would want to flag the change in format as well as the RoD, otherwise it will be interpreted as a zoom.
The 'format' nomenclature is taken from Nuke.
(Pierre: Adding this thread from Nuke dev forum as reference
http://community.thefoundry.co.uk/discussion/topic.aspx?f=191&t=104638&show=openfx%2cgenerator
)
Currently we use the clip properties kOfxImageEffectPropProjectExtent, kOfxImageEffectPropProjectSize and kOfxImageEffectPropProjectOffset to represent the format. This should be simplified to...
- kOfxImageEffectImageFormatResolution a 2D integer indicating the resolution in pixels of the output image, this is always full res with no render scale applied,
- kOfxImageEffectImageFormatAspectRatio as per normal.
These are present on all input clips.
We have a new action to compute the format of the output clip, kOfxImageEffectActionGetImageFormat, which would ask the effect to set the appropriate properties on the outArgs.
(pierre adds this suggestion to make this more general purpose): Aside the action, we might want to help make this work in all hosts as it works in that host already when possible: For example, in Nuke there is also a format_knob in their native SDK (NDK)- this shows up as a menu with options for user to select from an existing defined choice of setups and even create new Format presets.
Format_knob(f, &formats, "format");
int, int, double (W,H,PAR)
This would not be directly supportable as presented here. So maybe we need at Descriptor time to check what the host can support. This could be as simple as for overlays - draw or not.
kOfxParamPropHasHostOverlayHandle and kOfxParamPropUseHostOverlayHandle (for plugin to know to draw or not 2D point parameters for example).
A. This plugin might need to resize output (plugin write 0/1) - Host supports Image Format? (host write 0/1)
B. If Host support Image Format and plugin requests that,
then there is another handshake needed: via Action?:
If yes again, then plugin must set regular parameters and expects an action to set this. (so this must be known during description)
Else plugin just query that as needed? This would like that create a very "workable solution" where an host that relies on sequence nesting to resize could display for the Format menu for example: match input size | match output size.
Would such suite work for all hosts, some hosts use sequence nesting to make output and input different sizes. Do we need for such host a way for us to request the actual input frame size so that then we don't get a padded or conformed image? Must work for small input in, large out (e.g. a defish that allows you to reveal all the pixels after undistortion), and large input in, small out (e.g. flat window from equirectangular source). I haven't done homework enough to understand all possible OFX hosts (I know Resolve and Catalyst have nesting for example, forget what to expect there) I wonder if it would make sense to make an enumeration with clear expected behavior description so that everyone could fit in somehow, I guess including NONE ?
To be complete here I guess we would need from each host to know how they can best handle this so this can fit all in the way the host can.
Input is 1000 x 3000 - output is 2000x2000 probably covers this in one example.
For example an host might not want to support such format action but has a checkbox in their effects control "Use plugin RoD for output size" ,then perhaps they would allow us to programmatically set it up if we had the proper API for that since as an effect I know I am resizing the output buffer not expanding the RoD because I am not like a gaussian blur of 5 - all such things seems to me to indicate that we need to initially request what is supported by host (including if it supports such new action).
So it's clear, I could use the example of a non-OFX host Premiere, where the buffers we get (input and output) are Max of Sequence and Video Track Width and Max of Sequence and Video Track Height (so plugin has to internally crop to remove padding for this to work...). In their case I can still make it work as I know the original layer size (distinct from the image buffer size they pass to us)... In such host instead of input resolution format and output format as 2D integer I would probably want an option menu: Set to kOfxImageEffectPropProjectSize (which I might relabel Sequence Size) and Set to Input Size -- OK I guess you get the idea :)
Alternatively an host might in it's non OFX usage have a Format menu, perhaps this could be supported as well?
This might have interaction with other flags such as multi-resolution support etc
In life in general, I like both things (e.g. increasing the RoD by 5 each margin if a gaussian blur is applied AND changing the actual size) to be distinct, but that's not always an option.