Re: Part 2: Bug with FxParameterRetrievalAPI in Motion
Re: Part 2: Bug with FxParameterRetrievalAPI in Motion
- Subject: Re: Part 2: Bug with FxParameterRetrievalAPI in Motion
- From: Darrin Cardani <email@hidden>
- Date: Mon, 23 Jul 2007 13:58:01 -0700
On Jul 23, 2007, at 12:54 PM, Peter Litwinowicz wrote: There are numerous circumstances (in both hosts) where the size of the bitmap returned from GetInputBitMap does not match the size of the source passed to render. This would never happen (AFIK) in AE.
Also, it doesn’t really matter what AE does :-)
I agree, but my point in referencing AE was that if your code was already doing the scaling for AE, you would be reusing that code. But I must not be remembering what AE does (or did) correctly, as apparently you don't have to do the scaling yourself. Sorry for the confusion. Seriously, if the user asks to render at 50% resolution, then all the images I get should be at 50% resolution. Also, big picture: InputImage passed to –renderOUtput should NEVER be different than calling: [ FxTemporalImageAPI::getBitmap:&srcMap withInfo:renderInfo atTime:fenderInfo.frame] That is, the inputImage should match calling getBitmap from FxTemporalImageAPI at the current frame time. And this goes for pixel dimensions, previous effects on effects stack applied ,etc.
... and previously: Motion is being inconsistent. If you say you want to save bus bandwidth and do no scaling, then why isn’t inputImage given to –renderOuput sent at 100% resolution (not that I’m asking that you do that!)
I understand what you're saying. Back in Motion 2 and before, we would often send a full-sized input and request a half (or third, or whatever) sized output in the render method (at least in the hardware case). We changed that in Motion 3 so that they're always the same size for 3rd party plugins. We just didn't make the same change for the temporal imaging API, nor I'm guessing, for the parameter retrieval API. So we should address that.
Thanks, |
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Pro-apps-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden