AspectOf
AspectOf(image)
Additional Notes
Versions of FCP before 3.0 used a different aspect ratio.
Current versions return the following:
NTSC (desktop preview): 1.125
NTSC (FW output, RT Unlimited: 2.25
PAL (desktop preview): 0.9375
PAL (FW output, RT Unlimited): 1.875
It's important to note that these are inverted ratios from what is usually specified:
DV NTSC: 0.9
DV PAL: 1.0666
These value are simply inverted versions of the standard aspect ratio notations. Instead of value:1, FCP's aspect ratios are reported as 1:value.
In a simple speed test, calling this function 3 million times took 132 seconds while shifting a stored aspect ratio value into a float variable took 119 seconds. (867mhz G4 PowerBook)
While this is about 10% slower than storing the value, it takes a very large number of iterations to see any slowdown.
AspectOf returns strange results with RT playback.The following values are for standard NTSC with various RT and zoom settings:
Unlimited RT - 50%, non-square pixels = 2.25 (wrong, image not interlaced)
Unlimited RT - 100%, non-square pixels = 2.25 (correct interlaced value)
Unlimited RT - 200%, non-square pixels = 1.125 (correct, not interlaced)
Unlimited RT - 50%, square pixels = 2.25 (wrong)
Unlimited RT - 100%, square pixels = 1.0 (correct, single field shown)
Unlimited RT - 200%, square pixels = 1.0 (correct)
Safe RT - 50%, non-square pixels = 1.125 (correct)
Safe RT - 100%, non-square pixels = 2.25 (correct, interlaced)
Safe RT - 200%, non-square pixels = 1.125 (correct)
Safe RT - all zooms, square pixels = 1.0 (correct)
All values are correct while the playhead is moving.
The errant value with Unlimited is a problem because any effect which compensates values to match the pixel aspect ratio will not display correctly. That the value is off by double is especially problematic. There may also be an issue with the frame height from dimensionsOf not matching the actual output frame.
In NTSC D1 (720x486px) timelines, aspectOf() wrongly reports DV aspect ratios. This is a serious problem because it means pixel aspect ratio values can't be trusted.
If D1 pixels were scaled by the DV aspect ratio, the square pixel frame would be 546.75px tall--clearly wrong.
Based on Apple's HD test footage, here are the numbers I'm seeing for HD Aspect Ratios: (RT Safe)
960x720 @ 24p = 0.75
1280x1080 @ 60i = 1.333...
The formula (Pixel Aspect Ratio)/(Frame Aspect Ratio) verifies those numbers.
Pixel Aspect Ratio = literal frame width/height in pixels
Frame Aspect Ratio = actual frame aspect ratio, ie: 16/9, 4/3
