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
Get articles like this in your inbox: Sign Up
editblog - Tue, May 21 2013 - 7:54 am
@videoaaron @tstrachanedit Great keyset … I need to update the Keyboard Manifesto for @AdobePremiere Don't really think it'll work for FCPX
editblog - Tue, May 21 2013 - 6:46 am
@amyfame Reading into the comments on an article like that is always fun too. overall not a happy article for our generation to read