May 2007 - Pro-apps-dev - lists.apple.com

Re: FCP6 TemporalImageAPI - returning an image different from main input
by Paul Miller 02 May '07

02 May '07

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.0 (Windows/20070326) Well, there you are. It does start breaking down. Which is why AE always provides full frames, just time-sampled at the frame rate of fields, when appropriate. AE converts EVERYTHING to frames and works from there, and then 60i footage gets processed as 60p... Then these issues go away (with the problem that it is sometimes almost impossible to identify what was original interlaed material). Inefficient for a realtime editing app, of course. Note the Premiere Pro actually hands us full-res frames always. And it is an editing app... So it *can* be done in an editing app. Full-size frames are nice. I must admit I've been very spoiled by the way AE/Premiere does it. -- Paul Miller | paul(a)fxtech.com | www.fxtech.com | Got Tivo? _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… Peter Litwinowicz wrote: Earlier I said; This email sent to site_archiver(a)lists.apple.com

1 0

Re: FCP6 TemporalImageAPI - returning an image different from main input
by Peter Litwinowicz 02 May '07

02 May '07

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Thread-index: AceM4jhldvC3HPjVEduZggAKlbriPAAJzVsT Thread-topic: FCP6 TemporalImageAPI - returning an image different from main input User-agent: Microsoft-Entourage/11.3.3.061214 Earlier I said; > Well, there you are. It does start breaking down. Which is why AE always > provides full frames, just time-sampled at the frame rate of fields, when > appropriate. AE converts EVERYTHING to frames and works from there, and then > 60i footage gets processed as 60p... Then these issues go away (with the > problem that it is sometimes almost impossible to identify what was original > interlaed material). Inefficient for a realtime editing app, of course. Note the Premiere Pro actually hands us full-res frames always. And it is an editing app... So it *can* be done in an editing app. Just for your info. Pete _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: FxPlug versioning API
by Micah Sharp 02 May '07

02 May '07

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: FxPlug versioning API
by Christoph Vonrhein 02 May '07

02 May '07

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Hi Darrin, On May 1, 2007, at 3:47 PM, Darrin Cardani wrote: This is a great idea. I like that feature and it is quite useful too. Very important!!! - Christoph _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… We have a proposal for a plugin versioning API for FxPlug. This would allow plugins to know which version of their plugin was used to create an instance. For example, if the user created a document and applied WhizBangFilter version 1, we would save that "Version 1" information in the project file. If they then upgrade to WhizBangFilter version 2 and opened up the old project, we would tell the WhizBangFilter that this particular instance was created with version 1 of the filter. That would give the filter the option of: 1) Only displaying those parameters that existed in version 1 and rendering as if it were version 1 2) Appending new parameters, but with default values that didn't change the output and rendering as version 2 3) Adding a popup menu item for the user to choose which version they want the plugin to act like 4) Any other crazy thing you might want to do with version information Just the addParameters code snippet should look a little different. In you example only someone with a newer version of FxPlug SDK would be able to see the new features of the plugin and people with Motion 2 would not be able to use version 2 of the plugin. (Yes, I know. You've just posted a quick example.) You could also access it during render, if you want to preserve older rendering functionality. (I've tried to make it so you can access it during any method.) You know that Motion and FCP behaves strange when you try to retrieve a parameter that does not exit. So it is most important to be able to ask for the version during render to avoid crashes. This email sent to site_archiver(a)lists.apple.com

1 0

Re: FxPlug versioning API
by Christoph Vonrhein 02 May '07

02 May '07

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: FCP6 TemporalImageAPI - returning an image different from main input
by Peter Litwinowicz 02 May '07

02 May '07

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Thread-index: AceM4jhldvC3HPjVEduZggAKlbriPA== Thread-topic: FCP6 TemporalImageAPI - returning an image different from main input User-agent: Microsoft-Entourage/11.3.3.061214 > > Hi, Pete, > >> Input is input and has it¹s own settings and frame retrieval process. Same >> for output. > > I think this makes sense in the simplest case: > > footage -> your filter -> output > > But, doesn't this break down as soon as you start adding more filters? Let's > say you have this: > > footage (progressive) -> filter A -> filter B -> output (interlaced) > > In this case, it sounds like you would expect filter A to receive progressive > input and produce interlaced output. But, that means that filter B gets > interlaced input, which it doesn't expect. > I think the only reasonable thing to do is to keep all inputs and outputs in > the same format. The only question is whether you convert the input to output > format at the beginning, or convert the result of all filters to the output > format at the end. FCP takes the first approach. > > This breaks down with the temporalAPI because we go directly to the footage > and give you the native format. There are valid reasons for this, but it does > seem inconsistent. > > Am I missing something? > > Thanks, > - Paul Well, there you are. It does start breaking down. Which is why AE always provides full frames, just time-sampled at the frame rate of fields, when appropriate. AE converts EVERYTHING to frames and works from there, and then 60i footage gets processed as 60p... Then these issues go away (with the problem that it is sometimes almost impossible to identify what was original interlaed material). Inefficient for a realtime editing app, of course. Actually, what I would like to do is Filter A to be able to take progressive input and produce progressive output. Same with filter B. Then the ³output² sequence could resample to fields. The problem is really that ³output² should request 60 fps (suggested as fields, but filter B could decide to pass progressive back) and let filter B ask for 60 fps, then filter A gets asked for 60fps. Filter A sees that ³footage² is progressive. It creates progressive output (at 60fps and not 30fps), which is passed to filter B (as progressive) which is then passed to the output, which resamples to fields. Any filter along the way can query what the final output is and resample to interlaced to pass up the stream, if appropriate. An idea: let the plugin query the input stream based on the suggested output stream settings, but not hold tight to that suggestion. In one of my examples of my previous email, I know that the media is 30p, but my output is wanted at 60i. It would be great if I could return 60p and let the next plugin (or FCP for that matter) sample to 60i or not, as needed. That way, as a plugin (or FCP output sequence ) I could say that I want 60i, but the plugin could say ³I would rather pass you 60p, because my input is better handled that way.² Don¹t know if this scales or not. I guess we should think some more on it. Pete _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: FCP6 TemporalImageAPI - returning an image different from main input
by Peter Litwinowicz 02 May '07

02 May '07

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Thread-index: AceM4gW7RAyUBvjVEduZggAKlbriPA== Thread-topic: FCP6 TemporalImageAPI - returning an image different from main input User-agent: Microsoft-Entourage/11.3.3.061214 _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: FCP6 TemporalImageAPI - returning an image different from main input
by Peter Litwinowicz 02 May '07

02 May '07

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com Thread-index: AceM4RHyUFEbNPjUEduZggAKlbriPA== Thread-topic: FCP6 TemporalImageAPI - returning an image different from main input User-agent: Microsoft-Entourage/11.3.3.061214 _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… This email sent to site_archiver(a)lists.apple.com

1 0

Re: FCP6 TemporalImageAPI - returning an image different from main input
by Paul Schneider 02 May '07

02 May '07

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com On May 2, 2007, at 1:31 PM, Paul Miller wrote: This might make sense to you, but it looks like a bug to me. -- Paul Miller | paul(a)fxtech.com | www.fxtech.com | Got Tivo? _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… What is confusing is if I am working in a sequence that is 720x480 DV (interlaced), and my track has a 720x540 PROGRESSIVE movie clip on it (which FCP happily SCALES to fit the 720x480 sequence size), my plugin gets as INPUT a 720x240 FIELD. Unfortunately, I think it's more confusing than that. We do scale all inputs to the sequence size during RT preview. But, you will get a full-size input when you hit Cmd-R to render. The idea here is that you get speed during preview and quality during render. It's easier to justify if your still image is 2K than if it's just a few pixels bigger than the sequence. But it does complicate things more for developers. Peter Litwinowicz wrote: Right now, FCP's implementation of the temporalAPI will always give you the native format of the media. In other words, if you use the temporalAPI on a progressive clip, you'll get a full frame back, even if you are in an interlaced timeline. This is arguably confusing, since it's not the same as the input image that we pass to filters (input images are in the timeline format, not the media format). I think Paul Miller has a good point here. Not confusing at all. If the source is progressive, you get progressive frames. If the source is interlaced you get fields. What’s confusing about that? What’s more confusing to me is that the input is somehow tied to the output settings. I find it more confusing that I have to worry to use my output settings to somehow retrieve my input. And I worry also that when you tie input to output settings then you also get into the problems that FCP and Motion has that you can’t retrieve all 120 frames of a 120fps sequence when you are sitting within a 30p or 60 sequence. Of course, let’s address one issue at a time. What is confusing is if I am working in a sequence that is 720x480 DV (interlaced), and my track has a 720x540 PROGRESSIVE movie clip on it (which FCP happily SCALES to fit the 720x480 sequence size), my plugin gets as INPUT a 720x240 FIELD. But if I request a frame via the temporal API (using the RenderInfo that was passed in to me - you know, the one that tells me what field I am on and such), I get back a 720x540 FRAME. This email sent to site_archiver(a)lists.apple.com

1 0

Re: FCP6 TemporalImageAPI - returning an image different from main input
by Paul Miller 02 May '07

02 May '07

site_archiver(a)lists.apple.com Delivered-To: pro-apps-dev(a)lists.apple.com User-agent: Thunderbird 2.0.0.0 (Windows/20070326) Right now, FCP's implementation of the temporalAPI will always give you the native format of the media. In other words, if you use the temporalAPI on a progressive clip, you'll get a full frame back, even if you are in an interlaced timeline. This is arguably confusing, since it's not the same as the input image that we pass to filters (input images are in the timeline format, not the media format). I think Paul Miller has a good point here. This might make sense to you, but it looks like a bug to me. -- Paul Miller | paul(a)fxtech.com | www.fxtech.com | Got Tivo? _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.a… Peter Litwinowicz wrote: Not confusing at all. If the source is progressive, you get progressive frames. If the source is interlaced you get fields. What’s confusing about that? What’s more confusing to me is that the input is somehow tied to the output settings. I find it more confusing that I have to worry to use my output settings to somehow retrieve my input. And I worry also that when you tie input to output settings then you also get into the problems that FCP and Motion has that you can’t retrieve all 120 frames of a 120fps sequence when you are sitting within a 30p or 60 sequence. Of course, let’s address one issue at a time. What is confusing is if I am working in a sequence that is 720x480 DV (interlaced), and my track has a 720x540 PROGRESSIVE movie clip on it (which FCP happily SCALES to fit the 720x480 sequence size), my plugin gets as INPUT a 720x240 FIELD. But if I request a frame via the temporal API (using the RenderInfo that was passed in to me - you know, the one that tells me what field I am on and such), I get back a 720x540 FRAME. This email sent to site_archiver(a)lists.apple.com

1 0