site_archiver@lists.apple.com Delivered-To: pro-apps-dev@lists.apple.com Hi Stoney, - Paul On Oct 31, 2008, at 7:46 PM, Stonewall Ballard wrote: I'm using RGB pixels. TIA for any advice. - Stoney -- Stonewall Ballard stoney@sb.org http://stoney.sb.org/ _______________________________________________ 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... This email sent to site_archiver@lists.apple.com This isn't a known problem, and I can't reproduce it with a simple test plugin. Here's the plugin I'm using to test: TemporalAPI.zip I believe that one difference between FCP and Motion is that if you request a non-existent frame (a frame that is before the start of the media or after the end), Motion will clamp to the nearest available frame while FCP will return an all-zero bitmap. Are you averaging multiple frames together? That could produce darker frames if some of the images aren't there. IN FCP 6.0.4, [temporalApi getInputBitmap: &bitmap withInfo: renderInfo atTime: renderInfo.frame] in a renderOutput: call, produces a significantly darker image than the FxBitmap in inputImage. This is with software rendering, and any quality setting. Motion produces the same image in both cases. I see in the SDK Overview, that Motion 3.0.2 has fixed a bug "Image Well Gamma Shift", which sounds related. Is this a known bug? Is there a workaround? Does this happen with YUV pixels too? This email sent to pschneider@apple.com