The frame dimensions of DV Anamorphic are...

Well, depends on who you talk to, seems like.

I got most of my frame sizes years ago from the usually unimpeachable Trish and Chris Meyer
in their terrific Creating Motion Graphics with After Effects, 4th edition (2008)--
and here are the dimensions as published on page 620:

DV NTSC 16:9 Source size:

720 X 480 (with all image data squeezed into standard DV frame)

Square pixel (and Photoshop authoring) size:

864 X 480


Yet I keep hearing and reading here and elsewhere:

853 X 480


So...?

- Loren

Today's FCP 7 keytip:
Play from Playhead to Out Mark with Shift-P !

Your Final Cut Studio KeyGuide? Power Pack.
Now available at KeyGuide Central.
www.neotrondesign.com

If you're working in Apple software you'd better use Apple calculations. Apple calculates it as 853x480.

All the best,

Tom

Hi, Tom-

Well, that's confusing. After Effects IS Apple software. And PC. By Adobe. In the sense that it has to work properly on the Apple platform, in Apple QuickTime.

When you do the aspect ratio check:

864 / 16 = 54 * 9 = 486 - it comes out nice and neat.

It may be a typo-- this seems to describe a D1 anamorphic video size. But this "typo" is repeated from a disc PDF addendum in their 3rd edition book.

Apple's recommended

853 / 16 = 53.3125 * 9 = 479.8123-- yuch! Messy.

Of course it may well be correct. One wants to be accurate.

- Loren

Today's FCP 7 keytip:
Play from Playhead to Out Mark with Shift-P !

Your Final Cut Studio KeyGuide? Power Pack.
Now available at KeyGuide Central.
www.neotrondesign.com

It's this way because they can't agree on a pixel aspect ratio for anything in SD formats. If you notice, both frame sizes do not match up when you turn on correct for aspect ratio in both FCP and PS/AE. How many ways are there to draw a perfect circle? Many, apparently. And pi can be both 3.16 and 3.11.



www.strypesinpost.com

"After Effects IS Apple software."

No, AE is on Apple hardware, running on an Apple OS; it is Adobe software. Adobe writes it, and they write it the Mountain View way; Apple writes FCP, and they write it the Cupertino way. Apparently there's a change in the world's geometry as you travel through the Silicon Valley.

All the best,

Tom

Guys you are all forgetting that for Broadcast we have to allow for the extra width of the digital image.

In the UK the actual active picture transmission area for PAL DV/D1 720x576 is 702x576 with 18 extra pixels (9 either side) that can be left black.

Not sure if there is a good example of the NTSC based transformations but here is the PAL one from the BBC explaining why we use 1050x576 for creation of square pixel graphics for SD D1 PAL.

[www.bbc.co.uk]


Of course this is all moot when doing HD GFX but you will have to remember to correctly downconvert to 702x576 (on 720x576) with 9px black borders left and right...

...or for ATSC (or now defunct NTSC) the active broadcast picture width is only 704x480 DV or 704x486 D1 so you have to allow for the redundant picture or black either side of the digital image.

When creating in square pixel graphics in Adobe products - the templates allow for the extra width so that when converted back to non-square 720 width (both PAL and NTSC) that the correct aspect ratio is maintained along with the extra pixels.

From: [help.adobe.com]

? 4:3 DV (NTSC) or ATSC SD?create and save the square-pixel file at 720x534
? 4:3 D1 (NTSC)?create and save the square-pixel file at 720x534
? 4:3 DV or D1 (PAL)?create and save the file at 788x576
? 16:9 DV (NTSC)?create and save the file at 864x480
? 16:9 D1 (NTSC)?create and save the file at 872x486
? 16:9 DV or D1 (PAL)?create and save the file at 1050x576
? 16:9 1080i HD?create and save the file at 1920x1080
? 16:9 720p HD?create and save the file at 1280x720


Hope this helps (or freaks you out because you never took it into account before )



For instant answers to more than one hundred common FCP questions, check out the LAFCPUG FAQ Wiki here : [www.lafcpug.org]

The problem, as Tom pointed out, is that between the twin ridges of the great Sillicon Valley, a perfect square (or circle), is not the same square (or circle) when seen on each side. And when you're far enough away from the picture, you probably won't notice a thing. Thankfully, SD was meant for the small screen and not the stage.

Do this. Create an SD frame with a circle in Photoshop, at widescreen 720x576 PAL (or NTSC, it really doesn't make a difference). Make sure Photoshop corrects for aspect ratio. Then export that and import that into a widescreen SD PAL sequence in FCP. Compare the dimensions of your two rectangles as well as the circle in the middle. You will notice that the frame (as well as the circle) in Photoshop is wider than the frame in FCP.

Now, why? Blanking or no blanking, they cannot agree on the pixel aspect ratio. Switch the PAR in Photoshop to 1.42, and you realize the aspect ratio correction in the two softwares now align perfectly, and the circle is identical.

Why? For PAL widescreen, Adobe uses a PAR of 1.46, Apple uses a PAR of 1.42. In square pixels, Adobe (and the BBC) says 720x576 pixels = 1050x576, while Apple says 1024x576.

Quote
http://docs.info.apple.com/article.html?artnum=36836
Final Cut Pro uses a non-square pixel aspect ratio of 8/9 for NTSC 4:3, 32/27 for NTSC 16:9, 16/15 for PAL 4:3, and 64/45 for PAL16:9.

The numbers that Ben quoted are the defaults for Adobe as of CS5 (and CS4), but they will not import into FCP correctly, simply because, like the old Orwellian saying, all circles are round, some are rounder than others, and the same confusion that us PAL folks have, transcends equally into the dark world of NTSC between the forces of Adobe and Apple. I wonder what Avid thinks of square pixels.


>So...?

If you ask me, create graphics in either 720x480 with pixel aspect ratio correction turned on in the Adobe suites (or render them out as such), or create them as square pixels as 853x480, and pretend you didn't know anything. This is trickier to explain than interlacing.

On the bright side, we're almost out of the SD world now.



www.strypesinpost.com

> On the bright side, we're almost out of the SD world now.

It's hip to be square.


www.derekmok.com

Quote

On the bright side, we're almost out of the SD world now.

Precisely - I always make my GFX in HD regardless now usually 1920x1080 and if necessary I render out at D1 but at least I have the project files at a decent res.

Quote

Why? For PAL widescreen, Adobe uses a PAR of 1.46, Apple uses a PAR of 1.42. In square pixels, Adobe (and the BBC) says 720x576 pixels = 1050x576, while Apple says 1024x576.

Not quite - Adobe and the BBC say that the active area in square pixels is 1024x576 - the conversion however to Broadcast D1 702x576 requires that we have 18 pixels of dead picture either side of the 720x576 stream.

When you extrapolate the 18 from 720 D1 to square then its an extra 26 pixels or 13 either side.

So you work on a 1050x576 image then convert it to 720x576 and voilá! Your image is the correct aspect of 702x576 within a 720x576 D1/DV image for broadcast at 702x576 FHA.

Yoda says: "Confusing it may be yeeeees, but accurate always it is"



For instant answers to more than one hundred common FCP questions, check out the LAFCPUG FAQ Wiki here : [www.lafcpug.org]

I perfectly understand what you are saying Ben, but you're missing the fact that...

The PAR is different between an adobe pixel and an apple pixel! PAR is the ratio of how wide vs how tall each pixel is irregardless of whether you fill the 18 pixels with picture or black.

Launch FCP and Adobe Photoshop. And take a pixel ruler to measure the different width. You really don't need a pixel ruler. Adobe is 26 pixels wider than Apple's frame.

Let me rephrase this again. 1024x576 square pixels according to Apple, fills up 720 horizontal pixels and 576 vertical lines of alternate fields. However, 1050x576 square pixels according to the BBC, fills up the exact same damned thing as what Apple is trying to fill up. The numbers are different and this time, it's not the metric system.



www.strypesinpost.com

Thanks to everyone for giving me a headache...

Yes G you are correct.

The problem is with Apple's implementation. Which is why everyone should know this if they work in SD Broadcast.



For those following the thread but slightly confuddled...


In the UK (and other PAL countries) you are required to make your image WITHIN the 702 width for broadcast - WITH 18 pixels of left & right black border/redundant image. Its a harking back to the days of analogue broadcast when we had to allow a clean signal at either side of the picture.

To explain the 16:9 FHA widescreen workflow:

The 16:9 image on PAL D1 720x576 Broadcast is actually only 702x576 FHA pixels

Not the full 720x576px


However the D1 PAL format is 720px wide so people often think this mean the full picture width.

Actually you have 18 redundant horizontal pixels on each line - 9px each side of the main picture like so:


|< 9px Black >|< 702px width for image >|< 9px Black >|

9px + 702px + 9px = 720px



The image in the 702px area if shown as square pixels on a computer display would be 1024px.


So because we scale 702 up to 1024

~1.46x larger


We must scale the borders up too!

9px x ~1.46 = 13px (approximately)


|< 13px Black >|< 1024px width for image >|< 13px Black >|


13px + 1024px + 13px = 1050px wide.


Then when you finish your square pixel GFX in 1050x576 you save as 720x576


So when you scale this down...

...the 1024px image now sits in the correct broadcast image area of 702px

and you have two 9px borders left and right.


This makes it up to 720x576 for the PAL D1 "container".



If you broadcast an output from FCP with graphics set to 720x576 and not 702x576 (within a 720px wide screen) then your graphics will be wider than they should be by 18px.

As explained earlier it is similar for ATSC/NTSC albeit with a few different sizes to accommodate 480 and 486.


The reason Adobe say that D1/DV is 1.46 is to account for borders and the widescreen "stretch" to 1050px giving a 'truer' 16:9 representation of the 702x576 (to 1024) image that you are 'supposed' to use for Broadcast and PAL D1 delivery.

Apple just have not implemented broadcast standards for 702x576 on 720x576 is all.

I'm not sure why Apple was not reading broadcast spec sheets and properly explaining it to customers or allowing for it in software. But then version 1 of FCP didn't work with PAL without a hack!

In practice this makes for problems in horizontal detail and for correct placement of text and action safe GFX if not handled correctly.

Hopefully they will change this in the new version of FCP or at least explain it better!



For instant answers to more than one hundred common FCP questions, check out the LAFCPUG FAQ Wiki here : [www.lafcpug.org]

Just to confirm Ben -- he is totally right.
One thing to mention is that from history (and still with some hardware) the border is white. That can cause some white line either on the left or right side when you are watching a 4:3 program on a 16:9 TV set. The white line (or black line) depends on the so called Kell Factor which describes the signal transfer/process speed

Andreas

Quote

One thing to mention is that from history (and still with some hardware) the border is white.

Careful Andreas... you are in danger of showing your age!



For instant answers to more than one hundred common FCP questions, check out the LAFCPUG FAQ Wiki here : [www.lafcpug.org]

Ben you're right again.
Imagine, last week - after 30 years - I bought a cheap new TV with all the fancy stuff except 3D. And first time ever I saw these problems I know from theory (and where I tell the people to be aware of) in reality.

Andreas