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: Peter Litwinowicz <email@hidden>
- Date: Tue, 24 Jul 2007 17:23:04 -0700
- Thread-topic: Part 2: Bug with FxParameterRetrievalAPI in Motion
Title: Re: Part 2: Bug with FxParameterRetrievalAPI in Motion
Here's a proposal for how to fix this that we've discussed internally. I'd be interested in your feedback on the idea:
We've discussed using the renderInfo settings that are passed into the image fetch call to control the resolution, bit-depth etc. This seems like it might do what you want in the simple case, because you normally just pass in the same render info that's given to you, which has the same resolution settings, etc, as the main render. But if you needed a different rez or bit-depth, you could set them explicitly.
It sounds like there's a strong consensus that the current behavior is bad, is this idea better? Or should we just change the behavior so that you can only get the current resolution and bit-depth, for simplicity's sake?
Pete
That would be great. I would love to be able to request a bit-depth other than what is the native or natural bit-depth. For example, we often work in float even though the project is 8 bpc. This means we have to request the image, convert it to float, release the original image, process and copy back into the output buffer with bit-depth conversion again.
Of course, just getting the current resolution and bit-depth usind renderInfo as an additionally passed-argument works for me, even if that call doesn’t do bit-depth conversion for me.
Pete
_______________________________________________
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