Back To Listings RSS Print

PAR for the Course

Working with the new pixel aspect ratios in CS4.

By Chris and Trish Meyer | July 02, 2009

The Birth of Non-Square Pixels



At this point, I imagine the engineers were quite proud of themselves: Despite having to design for two different video standards with different frame rates, they managed to use a common master clock, and end up with a common image width. And of course, standard definition NTSC and PAL have the same image aspect ratio: 4:3 (we'll deal with widescreen later).

Just one problem: NTSC and PAL frames have different heights - 486 lines versus 576 lines. How can we use the same number of horizontal pixels for both, and still end up with the same image aspect ratio? The answer: fudge how wide the pixels are drawn. NTSC has fewer lines than PAL; therefore, their pixels will need to be drawn skinnier than PAL in order to end up with the same image aspect ratio. And thus, non-square pixels were born.

What? You're not cheering?

Of course, you were never supposed to see any of these machinations; it was all supposed to happen underneath the hood. Everything was corrected for by the time it was displayed on analog video (for example, NTSC pixels are squished horizontally at the digital to analog conversion stage). But when we started capturing video into the computer - using the 601 spec, of course - the implications of this tortured math became revealed: A digital NTSC frame looked fat on a square pixel computer monitor (which didn't know it was supposed to be drawn skinny); a PAL frame looked skinny (the computer didn't know it was supposed to be drawn fat):

Normally, circular objects are supposed to be drawn as circles (left). But when non-square pixel content is displayed on a computer, NTSC frames look fat (lower left) and PAL frames look skinny (below).




A Honest Mistake



When people originally thought that the earth was flat or that the sun revolved around the earth, it's not because they were either stupid or evil; it's just that they made some assumptions without having all of the facts. Such is the case with how many derived the pixel aspect ratios that most of us have been using for years: They make sense given what we thought we knew, but nonetheless, they're wrong.

For example, it's perfectly reasonable (although ultimately wrong) to use the following logic:

  • the frame's aspect ratio is 4:3


  • an NTSC frame is 486 lines high


  • 486 x 4 / 3 = 648 pixels wide for a square pixel frame


  • 648 square pixels / 720 non-square pixels = 9/10


  • therefore, the pixel aspect ratio (PAR) for an NTSC pixel must be 9/10


It's also perfectly reasonable to follow the same logic chain for PAL: 576 lines x (4/3) = 768 square pixels across; 768 / 720 = 48/45 for PAL's pixel aspect ratio.

Too bad that the people who used that logic when designing desktop digital video gear didn't have all of the facts.

Production Aperture vs. Clean Aperture



There's one flaw in the above logic: Those 720 pixels contain more than the entire image we're supposed to see. The original engineers knew that in video, sometimes the details along the left and right edge of the frame can get altered - such as by electronic "ringing" (overshoot and undershoot of the voltage level which describes the corresponding luminance and color) induced by substandard analog circuitry. So they built a safety margin into the spec, expecting the damaged extra pixels on the left and right would be cropped off later.

Those 720 pixels are know as the Production Aperture - in other words, every pixel that was supposed to move down the production chain. However, inside of those 720 pixels is a smaller Clean Aperture, which contains the "actual" image for display purposes. When you calculate how big the final image is, you're supposed to use the Clean Aperture.

But early desktop digital video engineers didn't know that, and used the Production Aperture instead. The result is a slight math error in the resulting pixel aspect ratios. Oops...



The entire captured image is considered the Production Aperture; the thin vertical lines along the left and right edges indicate the cropping that is supposed to take place to create the Clean Aperture - the final "real" image.


The "Real" PARs



So, what are the correct PARs, taking into account the Clean Aperture rather than the Production Aperture? Honestly, the history is murky, and there has been numerous false starts (click here if you really want to know the gory details), but about a decade ago, consensus among video engineers settled around the following PARs which were derived from the clock frequencies used in digital video capture cards and the such:

  • NTSC 4x3: 10/11 (not 9/10)


  • NTSC 16x9: 40/33


  • PAL 4x3: 59/54


  • PAL 16x9: 119/81


Just how large is the difference between the old and new PARs in the real world? The two images below show the difference in how a perfectly round wheel would ultimately be displayed on a properly calibrated television:



The old PARs were used to correct the DV footage on the left; the new PARs were used for the footage on the right. Can't tell the difference? Neither can your viewers, frankly. But if you cut these two images together, you will indeed see a "pop" in size. Those with really sharp eyes might have noticed that the wheel on the right - from CS4 - comes ever so slightly closer to the left and right edges of the square box than the image on the left, from CS3.


next page: Clean Aperture and square pixel sizes

Page 2 of 4 pages « Previous 1 2 3 4 Next »

Editor's Choice
PVC Exclusive
From our Sponsors

Share This

Back To Listings RSS Print

Get articles like this in your inbox: Sign Up

Comments

Thomas Craul: | July, 07, 2009

>> I wouldn’t be surprised if other companies eventually followed Adobe’s lead and started using the correct values in their own applications. <<

And especially that’ll take a longer jurney, especially for ignorants like apple.

Even their bloody Quicktime Player Pro is capable of display the right apertures, even not with anamorphic flags nor anything.

Sorry for swearing and THANK YOU! for the brilliant 4 pages of information which unfortunately cannot be explained with a few phrases.

Philip: | July, 09, 2009

Does this mean all frame aspect ratios for webvideos encoded from PAL or NTSC video (which i always encode with a square par) are no longer 1.33 or 1.78 and will become 1.37 and 1.82?

Chris Meyer: | July, 09, 2009

Only if you don’t crop off the difference between production and clean aperture. (Personally, I think video should be cropped down to the action safe area before scaling down to web size; after all, this is all the active image area that the creator was expecting the viewer to see.)

Eljay: | August, 15, 2009

Clean aperture for DV-NTSC is 704 x 480, at 10:11 pixel aspect ratio.  It is not 712.8 x 480.

Clean aperture for DV-PAL is 702 54/59 x 576, at 59:54 pixel aspect ratio.  (Premiere Pro truncates the fractional pixel: 702 x 576, at 128:117 pixel aspect ratio.)

Chris Meyer: | December, 31, 2009

“Clean aperture for DV-NTSC is 704 x 480, at 10:11 pixel aspect ratio.  It is not 712.8 x 480.”

I beg to differ, but am completely sympathetic as to where the confusion comes from.

NTSC DV is a special case: it’s NTSC D1 with 6 horizontal lines missing, and it should be treated as such. Thus it has clean ap size of 712.8 x 480. And this isn’t my speculation or pontification; this is “The Word” from people a lot smarter and more respected than me.

However, there are other formats - such as ATSC digital standard definition - which are defined as having a true 480 lines. _These_ formats have different math, and 704x480 is the correct clean ap size for them. (So, I guess if you want to redefine what DV is for - not a budget version of D1, but instead a format onto itself for acquiring SD ATSC material - then you can think of DV-NTSC’s clean ap as being 704 x 480. It’s revisionist history, but works as a workflow. As long as you treat the underlying PAR as 10/11.)

I know - messy. Remember that DV was never intended to be professional production format; it was supposed to be the consumer replacement for Hi-8. We weren’t supposed to have to deal with all the ugliness that exists under its hood. But, here we are.

Chris Meyer: | January, 15, 2010

BTW, I’ve just read that FCP 7 now uses the new/correct PARs as well:

http://blogs.adobe.com/toddkopriva/2010/01/final-cut-pro-7-using-correcte.html

So, less tripping while round tripping! (Although it wasn’t as big of a problem as many feared in the first place.)

Please login or register to comment