Converting PAL frames to NTSC.
A PAL frame in square pixels – an approximation of what you see on a SD TV – is 786 X 576. It’s aspect ratio is the same as square pixel NTSC at 655 X 480: 786/576 = 655/480 = ~1.365 . Both include over-scan, which is roughly the part of the picture hidden by the TV’s case covering the edges of the picture tube. In North America 640 picture width is about what you actually see on a std TV, and 640 X 480 equals the famous 4:3 aspect ratio we always read about with SD Full Screen video. In both NTSC and PAL SD video, a portion of the width [that’s used for over-scan] is typically cut off or “cropped” to get the typical square pixel video we see on a PC – 640 X 480, 320 X 240, and so on…
While the number of [scan] lines remains the same [576 or 480], captured or recorded video is usually D1 (601) spec 720 width for both NTSC and PAL. Feed D1 video to a SD TV and it will show you the correct picture – a square will be roughly square, a circle roughly circular. If you look at the frame sizes though it’s plain that PAL TVs have to stretch the picture wider to make this happen, while NTSC TVs have to shrink the width. This “magic” is taken care of by the electronics that turn digital video into the analog signal SD TVs expect.
PCs on the other hand don’t have any “magic electronics” – the video stays digital – and you work with software and monitors that pretty much insist on taking things very literally: 720 width video is 720 pixels wide, Period. This is where and why conversion between PAL and NTSC gets interesting, not because it’s hard really, but because both standards normally look wrong on our monitors. However, it’s normally the same picture – maybe bigger, maybe smaller, but the same image none-the-less.
Because it’s the same picture, re-sizing between standards is really straightforward… You can take a photo for example, and crop it to 786 X 576 getting a full size PAL square pixel frame. You can re-size that picture to 655 X 480 and get the NTSC equivalent – the NTSC picture will be the same, just smaller. Resize the 2 picture widths to D1 spec: 786 / 1.0926 [the PAL D1 Pixel Aspect Ratio] = ~ 720… 655 / .9096 = ~720. You still have the same basic pictures, but now they look quite different. Resize either D1 picture to the alternative standard [NTSC to PAL or PAL to NTSC], and it will match. To verify, open or import the 2 PAL or NTSC images into photo editing software, put them on separate layers, and set blending to “difference” – the result should be black, as if it was done properly, there is no difference.
In Vegas (and maybe most video editors) when it comes to converting frame sizes from PAL to NTSC (and vice versa) you just need to encode to the new spec.
The “Fly in the ointment” is that unfortunately re-sizing takes its toll on quality -- every resize either throws out some unneeded pixels, invents new pixels, or in some cases, both. An alternative if you had square pixel PAL, would be to simply crop an NTSC frame out of the middle – no pixels lost or gained. With D1 PAL, my tests show that this method is Very close: crop the PAL D1 frame to 600 X 480, resizing [setting the project size in Vegas] to 720 x 480. I don’t use PAL video, so I haven’t tried this over time to say it’s worth it or not, but logically I’d think it might preserve more quality by re-sizing only the width. I’d also think it would eliminate any chances of Interlace related problems...
Interlaced video is based on fields, which include every other line making up a video frame; you have first and second, or odd and even, or top and bottom, which are all just different ways of naming them. The picture on the even numbered lines normally won’t match the picture on the odd numbered lines in the next field because the camera captures movement in the fiftieth or sixtieth of a second that separates them in an interlaced frame; for SD TVs that’s a good thing, and you want to keep it that way.
Maintaining your 2 fields while changing the frame height is a bit of a problem though – often after re-sizing, part of the picture that’s on the third line for example, will only take up part of that line, or maybe it’ll take up both the third line and part of the fourth. There are different methods to handle field re-sizing that can help, but you’re usually left with some visible image degradation at the least, pronounced motion &/or panning problems at worst. The best way is to avoid it entirely, as shown by the success of 16:9 anamorphic video where only the width is stretched.
Frames per second conversions can be hard to accomplish. To convert NTSC video [not telecined film] to PAL, many [myself included] think the best method is through hardware; Snell & Wilcox have documents online that explain the wave theory used by their hardware to generate new frames – software will usually interpolate existing frames which is not as accurate. Going PAL to NTSC is much easier.
To take film at 24 fps to NTSC 29.976 traditionally extra fields were added in a telecine process. With commonly used mpg2 video, it’s easier just to add pulldown flags to the video file, which tell the player which fields to repeat rather than actually adding anything. Either method could be used with PAL’s 25 fps, though it’s much more common with film’s 24 fps; an approximately twenty-fifth of a second speed up or slow down is minor enough that many just play 24 fps at 25 fps or vice versa.
A PAL frame in square pixels – an approximation of what you see on a SD TV – is 786 X 576. It’s aspect ratio is the same as square pixel NTSC at 655 X 480: 786/576 = 655/480 = ~1.365 . Both include over-scan, which is roughly the part of the picture hidden by the TV’s case covering the edges of the picture tube. In North America 640 picture width is about what you actually see on a std TV, and 640 X 480 equals the famous 4:3 aspect ratio we always read about with SD Full Screen video. In both NTSC and PAL SD video, a portion of the width [that’s used for over-scan] is typically cut off or “cropped” to get the typical square pixel video we see on a PC – 640 X 480, 320 X 240, and so on…
While the number of [scan] lines remains the same [576 or 480], captured or recorded video is usually D1 (601) spec 720 width for both NTSC and PAL. Feed D1 video to a SD TV and it will show you the correct picture – a square will be roughly square, a circle roughly circular. If you look at the frame sizes though it’s plain that PAL TVs have to stretch the picture wider to make this happen, while NTSC TVs have to shrink the width. This “magic” is taken care of by the electronics that turn digital video into the analog signal SD TVs expect.
PCs on the other hand don’t have any “magic electronics” – the video stays digital – and you work with software and monitors that pretty much insist on taking things very literally: 720 width video is 720 pixels wide, Period. This is where and why conversion between PAL and NTSC gets interesting, not because it’s hard really, but because both standards normally look wrong on our monitors. However, it’s normally the same picture – maybe bigger, maybe smaller, but the same image none-the-less.
Because it’s the same picture, re-sizing between standards is really straightforward… You can take a photo for example, and crop it to 786 X 576 getting a full size PAL square pixel frame. You can re-size that picture to 655 X 480 and get the NTSC equivalent – the NTSC picture will be the same, just smaller. Resize the 2 picture widths to D1 spec: 786 / 1.0926 [the PAL D1 Pixel Aspect Ratio] = ~ 720… 655 / .9096 = ~720. You still have the same basic pictures, but now they look quite different. Resize either D1 picture to the alternative standard [NTSC to PAL or PAL to NTSC], and it will match. To verify, open or import the 2 PAL or NTSC images into photo editing software, put them on separate layers, and set blending to “difference” – the result should be black, as if it was done properly, there is no difference.
In Vegas (and maybe most video editors) when it comes to converting frame sizes from PAL to NTSC (and vice versa) you just need to encode to the new spec.
The “Fly in the ointment” is that unfortunately re-sizing takes its toll on quality -- every resize either throws out some unneeded pixels, invents new pixels, or in some cases, both. An alternative if you had square pixel PAL, would be to simply crop an NTSC frame out of the middle – no pixels lost or gained. With D1 PAL, my tests show that this method is Very close: crop the PAL D1 frame to 600 X 480, resizing [setting the project size in Vegas] to 720 x 480. I don’t use PAL video, so I haven’t tried this over time to say it’s worth it or not, but logically I’d think it might preserve more quality by re-sizing only the width. I’d also think it would eliminate any chances of Interlace related problems...
Interlaced video is based on fields, which include every other line making up a video frame; you have first and second, or odd and even, or top and bottom, which are all just different ways of naming them. The picture on the even numbered lines normally won’t match the picture on the odd numbered lines in the next field because the camera captures movement in the fiftieth or sixtieth of a second that separates them in an interlaced frame; for SD TVs that’s a good thing, and you want to keep it that way.
Maintaining your 2 fields while changing the frame height is a bit of a problem though – often after re-sizing, part of the picture that’s on the third line for example, will only take up part of that line, or maybe it’ll take up both the third line and part of the fourth. There are different methods to handle field re-sizing that can help, but you’re usually left with some visible image degradation at the least, pronounced motion &/or panning problems at worst. The best way is to avoid it entirely, as shown by the success of 16:9 anamorphic video where only the width is stretched.
Frames per second conversions can be hard to accomplish. To convert NTSC video [not telecined film] to PAL, many [myself included] think the best method is through hardware; Snell & Wilcox have documents online that explain the wave theory used by their hardware to generate new frames – software will usually interpolate existing frames which is not as accurate. Going PAL to NTSC is much easier.
To take film at 24 fps to NTSC 29.976 traditionally extra fields were added in a telecine process. With commonly used mpg2 video, it’s easier just to add pulldown flags to the video file, which tell the player which fields to repeat rather than actually adding anything. Either method could be used with PAL’s 25 fps, though it’s much more common with film’s 24 fps; an approximately twenty-fifth of a second speed up or slow down is minor enough that many just play 24 fps at 25 fps or vice versa.