site_archiver@lists.apple.com Delivered-To: pro-apps-dev@lists.apple.com Hi everyone, Gabe On Feb 14, 2007, at 12:06 AM, Paul Schneider wrote: Hi, all, <JustCopy.zip> Thanks, - Paul On Feb 13, 2007, at 12:14 PM, Paul Schneider wrote: 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 wanted to confirm Paul's findings. I spent a good deal of time testing combinations of plug-in's capabilities (RGB/YUV, INT/FLOAT) and came to the same conclusion: the color shift happens only in YUV 8 bit, and then only if the sequence is set to render at that setting too. Switching the rendering mode to Always RGB or High-precision YUV seemed to fix the issue every single time. I spoke with Emile offline, and we figured out that his issue doesn't have anything to do with FxPlug. His media was coming into Final Cut as (254, 0, 0) and not (255, 0, 0) - that is, the color shift happened on import, with no effects applied. This seems to be because (255, 0, 0) is either not a valid YUV value, or is truncated when compressed with the DV-NTSC codec. I was able to get (255, 0, 0) by switching to an RGB render using the Animation (lossless) codec. We have not quite figured out what is going on here, but we have ruled out FxPlug. I've also been trying to reproduce Trevor's problem, without success. I have tried a passthrough filter on several types of media on both Intel and PowerPC, and one of our QA engineers has also run some pretty extensive tests. We haven't found any color shifts, except for the 8-bit YUV issue I mentioned earlier. Here is the passthrough filter I used in my testing. It can run on either the GPU or the CPU; I tested on both. I tested using the Digital Color Meter application (in /Applications/Utilities) to compare pixel values with and without the filter. Trevor, can you try with this filter and see if you still see the problem? Also, if you could send me the media and project you see the problem with, that would be very helpful. If they are too big to email, let me know and I will find another way. If your media is sensitive, it would be very helpful if you could reproduce the problem with benign media. Has anyone else on this list seen this issue? If you have, please let me know, and include media and projects if possible. 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