site_archiver@lists.apple.com Delivered-To: pro-apps-dev@lists.apple.com Hi, Steve, [outputImage fieldOrder] == kFxFieldOrder_PROGRESSIVE [inputImage fieldOrder] != kFxFieldOrder_PROGRESSIVE renderInfo. fieldOrder == kFxFieldOrder_PROGRESSIVE - Paul On May 10, 2008, at 4:42 PM, Steven Meyer wrote: [outputImage fieldOrder] == kFxFieldOrder_PROGRESSIVE [inputImage fieldOrder] != kFxFieldOrder_PROGRESSIVE renderInfo. fieldOrder == kFxFieldOrder_PROGRESSIVE This has confused me some, but I have adapted my code. Now for my question. Steve Meyer _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/pschneider%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.ap... But, if I call [temporalAPI getInputBitmap], the resulting bitmap has 1/2 height and rowBytes twice of the inputImage, ie half height image and [inputImage fieldOrder] != kFxFieldOrder_PROGRESSIVE but [inputImage fieldOrder] == kFxField_NONE in general, in a mixed-format situation, the images that are prepared for you prior to render (the filter input and output) are in sequence format. Images that you retrieve yourself (from an image parameter or from the FxTemporalAPI) will be in the source clip's format. This is not the most intuitive setup, but it's the rule we typically follow. So, I would expect that in your situation, the inputImage would be progressive frames, but images retrieved from the FxTemporalAPI would be single fields. It sounds like you are seeing this. In my tests, I don't see the mismatched field/fieldOrder problem that you report. Images from the temporalAPI have (fieldOrder != progressive && field != none). When an interlaced clip is rendered in a progressive sequence, I see the following results for fieldOrder in renderOutput This looks like a bug in Final Cut. The inputImage is progressive (because the sequence is progressive). So [inputImage fieldOrder] should be progressive. In my tests, [inputImage field] is correct, but [inputImage fieldOrder] is wrong. Has inputImage automatically been deinterlaced? In other words, has any deinterlacing processing been applied to the inputImage as a default without the user specifically applying a deinterlace filter. Yes. When you add an interlaced clip to a progressive sequence, the clip is deinterlaced before filters are run on it. You may be able to use the temporalAPI to access the original interlaced fields. You can request both fields of your input by asking for time N and N+0.5. When an interlaced clip is rendered in a progressive sequence, I see the following results for fieldOrder in renderOutput The heights and rowbytes of inputImage and outputImage are the same, i.e not half height for inputImage But, if I call [temporalAPI getInputBitmap], the resulting bitmap has 1/2 height and rowBytes twice of the inputImage, ie half height image and [inputImage fieldOrder] != kFxFieldOrder_PROGRESSIVE but [inputImage fieldOrder] == kFxField_NONE Has inputImage automatically been deinterlaced? In other words, has any deinterlacing processing been applied to the inputImage as a default without the user specifically applying a deinterlace filter. I am working on plugins with conditional deinterlacing code in the filters, and my client is seeing results that appear to indicate the input was already deinterlaced. This email sent to pschneider@apple.com This email sent to site_archiver@lists.apple.com