Hi Pete,
FWIW, there's a new document in the FxPlug 1.2 SDK called "FCP FxPlug Rendering Paths.pdf", which attempts to describe how FxPlugs get called by Final Cut in various circumstances. We put this together because Final Cut has so many knobs and dials which can change the rendering environment in surprising ways.
If you find it less than helpful, or you think it could benefit from some editing, let me know! Or better yet, file a bug, and email me to let me know the bug number. Radar is the sole dictator of how I spend my time.
And if I don’t support r408, then the 8 bit YUV images get converted to 8 bit RGB, correct?
Correct. It will be converted to 8-bit RGB *at the same gamma as the YUV image*. This means the RGB image will be at video gamma (2.2), not classic Macintosh gamma (1.8).
(I remember filing a feature request that it would be nice to have the opportunity to go to floating point YUV, because otherwise the user will see “rampant” quantization when going through the 8 bit YUV and 8 bit RGB to 8 bit YUV round-trip... And you told me the user can set sequence settings to “high precision” to affect what I wanted... Except when in RT preview (but final renders will look right).
Hopefully this is minimized by keeping the gamma the same. The biggest problem is that superwhite values are clamped. This isn't an issue in floating-point.
I do have your request on file, thanks! It hasn't been forgotten.
And floating point YUV (r4fl) gets converted to floating point RGB, correct?
Correct.
Both r4fl and floating-point RGB are linear (gamma 1.0) in Final Cut.
The floating-point images are unbounded; they can contain values < 0 or > 1.0. In particular, RGB images will likely have extended-range values, since video superblacks are expressed as negative values, and video superwhites are expressed as values > 1.0. In floating-point RGB, 0 is video black and 1.0 is video white.
And the answers to these last two questions should go into the doc.
Agreed!
On Jun 6, 2007, at 8:42 PM, Peter Litwinowicz wrote:
Hi, Pete,
all images in FxPlug are premultiplied, including the YUV images. It's a strange choice, but that's the way it is.
Really? Well, there you are.
You can check if an image is premultiplied or not with [FxImage isPremultiplied], but currently this will return YES in all cases. We've talked about adding an opt-in mechanism where plugins can request straight alpha, which would be more efficient in Final Cut since we are straight-alpha internally. That's not scheduled for the near future, though.
YUV support is optional. Your plugin implements a -properties method, which returns a list of properties. You can set the kFxPropertyKey_SupportsR408 and kFxPropertyKey_SupportsR4fl keys to indicate support for YUV. If you don't set these properties, you will always get RGB images. This should be in the documentation, please file a bug if it isn't explained clearly. You can choose to support R408 but not r4fl, or vice versa.
I completely forgot (and you guys did tell me this a while ago). And this is not in the document anywhere.
In fact, I can’t find which properties are valid to set, except to look in the example programs.
To Dave Howell: is there a document I’m not finding? Or is this info in the doc and I’m just losing it today?
As we've discussed before, there's no way to tell if a YUV image is Rec 601 or Rec 709. We ARE planning to fix this in the near future.
Right, I DO remember that.
RGB support is mandatory. Software plugins must support 8-bit and 32-bit-float RGB. GPU plugins must support 8-bit, 16-bit-float, and 32-bit-float RGB.
Cool. I don’t see this information anywhere in the Overview manual (which is just a short 18 page document, which is the one I downloaded from the Apple developer site and was uploaded on May 21, 2007).
In Final Cut, all images (including those from image wells) should be in the same format and bit depth. That format and bit depth is determined by your sequence settings.
Okay, another item for the doc (and another piece of missing info for me).
In Final Cut, if you return canRenderSoftware=NO and canRenderHardware=NO, we won't fall back to a lower bit depth. You'll get the red "the plugin failed to render" error frame.
Ah, good to know.
And if I don’t support r408, then the 8 bit YUV images get converted to 8 bit RGB, correct? (I remember filing a feature request that it would be nice to have the opportunity to go to floating point YUV, because otherwise the user will see “rampant” quantization when going through the 8 bit YUV and 8 bit RGB to 8 bit YUV round-trip... And you told me the user can set sequence settings to “high precision” to affect what I wanted... Except when in RT preview (but final renders will look right). Still think there needs to be a setting that allows the user to override this case too.
And floating point YUV (r4fl) gets converted to floating point RGB, correct?
And the answers to these last two questions should go into the doc.
Finally, in Final Cut, 8-bit RGB images are alpha-first, and floating-point RGB images are alpha-last.
Hope that helps,
As usual, greatly helpful!
Pete
|