site_archiver@lists.apple.com Delivered-To: pro-apps-dev@lists.apple.com Piero (You can find the above example in http://web.mac.com/piero.fiorani/PieroF_FCE_Effect/Aspect_Ratio_Adjust_2.htm...) Il giorno 07/nov/08, alle ore 23:56, Paul Schneider ha scritto: Hi Stoney, Thanks! - Paul On Nov 6, 2008, at 8:03 PM, Stonewall Ballard wrote: TIA. - 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/piero.fiorani%40fastwebn... _______________________________________________ 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... Hi Stoney, I'm not sure I'm answering your question, but I see a relation between the two figures 0,4444 and 0,39506: their ratio is 1,1250, the same that measures square pixel AR (=1) vs. NTSC 4:3 CCIR 601 pixels AR (=0,8888): in fact 1/0,8888 = 1,1250. For example I ran into this value when inserting a square pixel 4:3 NTSC (640x480) clip into a standard NTSC 4:3 CCIR 601 sequence (720x480): then FCP automatically applies the value -12,5 % to the Motion/Distort/Aspect Ratio control to fix the aspect ratio. The relationship between the 2 pixel AR and the Distort control (in this case) is the following: Motion/Distort/Aspect Ratio = 100 * (1 - <inserted clip pixel AR> / <sequence pixel AR>) that is in this example = 100 * (1 - 1 / 0,8888) = 100 * (1 - 1,125) = -12,5 %. You can check it easily in FCP. (It might appear confusing, but in this specific example you can also find out that FCP sets Basic Motion/Scale to 112,5 to fit the clip frame to the sequence frame - but this is a different story). The conclusion I draw (but this probably is just a long shot...) is that in one case with getInputBitmap... you get the pixel AR (0,395062) of the clip before it is adapted to the sequence and in the other case with getBitmap... you get the sequence pixel AR (0,4444), the same as the pixel AR of the clip after being vertically squeezed to correct its aspect ratio back to normal. I hope this makes some sense, and helps a little - even if I understand in your question you are not talking about square pixel clip but CCIR clip.... Just my 2 cents I don't see that behavior in a quick test, but my DV media is 720 x 480, not 486. 720 x 480 is FCP's idea of "standard" NTSC DV, and what you get when you create a sequence with the NTSC DV preset. It sounds like you're in a situation where your media's aspect ratio isn't the same as your sequence's. It's certainly possible that we have some inconsistencies in that case. FCP considers "DV" aspect ratio to be 0.88889, which gets divided by two when we report it to FxPlugs running on a single field. Could you file a bug report at bugreport.apple.com, and include your media? It would be great if you could trim the media down to a second or two before attaching it to the bug. In FCP 6.0.4, in a sequence set to a Pixel Aspect Ratio of NTSC- CCIR 601/DV (720x480), and a Frame size of 720x486 (CCIR 602 NTSC 40:27), the output image info says it has a pixelAspect of 0.444444. When the input is a 720x486 clip listed as Pixel Aspect NTSC-CCIR 601 in the browser, its imageInfo says it has a pixelAspect of 0.395062. The same input frame fetched via the temporal API using getBitmap:layerOffsetX:layerOffsetY:requestInfo:fromParm:atTime: reports a pixelAspect of 0.444444. At least getInputBitmap:withInfo:atTime: shows that same frame with a pixelAspect of 0.395062, the same as the regular input. Why does getBitmap:layerOffsetX:layerOffsetY:requestInfo:fromParm:atTime: produce a different pixelAspect than the other two methods? Is there any way to tell what the *real* pixel aspect of that frame? Interestingly, when I set the sequence to use square pixels, all the pixelAspects are 0.444444. BTW, 0.444444 is 640/720/2, while I would have expected to see 648/720/2, or 0.45. I don't see where 0.39506 comes from. Anyone know what's going on here? Is there any way to know what the *real* PAR of an image param is? This email sent to piero.fiorani@fastwebnet.it This email sent to site_archiver@lists.apple.com