site_archiver@lists.apple.com Delivered-To: pro-apps-dev@lists.apple.com Hi, list, Thanks, - Paul On Feb 13, 2007, at 9:48 AM, Gabriele de Simone wrote: On Feb 12, 2007, at 7:31 PM, Paul Schneider wrote: Hi, all, - Paul On Feb 12, 2007, at 7:10 PM, Dave Howell wrote: Begin forwarded message: Dave, et al, -- Emile Tobenfeld, Ph. D. Video Producer Image Processing Specialist Video for your HEAD! Boris FX http://www.foryourhead.com http://www.borisfx.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... I think I may have misspoken earlier. We recently found an issue with running YUV FxPlugs on PowerPC in 8-bit, where the image would be darkened by one after going through the FxPlug. This is something that will be fixed in an upcoming version. This issue only happened in 8-bit YUV renders on PowerPC. It sounds like the issue that Trevor reports happens with RGB effects as well as YUV, and in float as well as 8-bit. This is not something we're aware of, and not something we've seen internally. You don't say if the issue happens on x86 as well; is this something you're able to test? Also, what kind of image are you applying the effect to? Does it have a fully opaque alpha channel? Are the red and blue channels significantly brighter than the green channel? So is this true in all cases? In other words, the workaround to fix it under FCP 5.1.2 would be to add 1 to the output whenever the plug-in is asked to render in 8 bit RGB/YUV, on PowerPC? Emile: the color shift is actually visible on the computer screen, but it is understandably quite small so you'll catch it easily only with bright scenes (e.g. a sky) or by building a passthrough filter and keeping an eye on the scope and toggling the filter on/off. sorry I was silent on this topic - it somehow didn't come across my radar. This is in fact a bug in Final Cut, which only happens on PowerPC. We've identified the problem, and a fix should appear in an upcoming version. Sorry about the inconvenience! From: Emile Tobenfeld <emilet@borisfx.com> Date: February 12, 2007 4:09:09 PM PST To: Trevor Anderson <andtrev@gmail.com>, Gabriele de Simone <gds@noiseindustries.com>, dhowell@apple.com, pro-apps- dev@lists.apple.com Subject: Re: FxPlug adding color cast. At 3:29 PM -0800 2/12/07, Trevor Anderson wrote: I found the problem. I logged the pixel data by running two plugins, one after the other. Final cut is decreasing all values by one. If you simply pass back the input values in the plugin, FC then subtracts one from them, after fixing this in the plugin, passing back the input data plus one, the cast went away and everything works as expected. Seems like there is a bug in there somewhere, and it's in Final Cut after it gets the frame back from the plugin. Thanks to everyone who helped me out, I'm glad it was this simple, as I really wanted to avoid the workaround. Trevor Good catch, Trevor -- though it sounds like the shift affects all RGB colors and is not really a cast. I'd noticed some 254's in my debugging code where I expected 255's , but had been too busy with other issues to dig further. Can you comment on this. We don't really want to bump our input values by 1 every time we are called. "Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!" -- The Red Queen This email sent to site_archiver@lists.apple.com