all of them are correct and none of them can be fit to the TV form 4:3 or 16:9 exactly. They just follow different definitions, e.g. vegas going to ITU-R BT.601(CCIR-601 or Rec.601also).

The correct pixel aspect ratio is the one that results in the correct screen aspect ratio for the video in question.

For example, HDV 720p - 1280x720 pixels, SAR 16:9 is arrived at using PAR 1:1.

HDV 1080i, 1440x1080 pixels, SAR 16:9 is arrived at using PAR 1:1.333

For DV, only 704 of the 720 recorded pixels are used for TV display so to arrive at SAR of 4:3 requires 1:0.9089 PAR.

Vegas will display the PAR required to display the correct SAR assuming the video header information is correctly tagged.

Unless "Simulate Display Aspect Ratio" is on in the preview window Vegas Preview will assume 1:1 PAR.

- Mark
Co-Author of "HDV: What You NEED To Know"

I am also confused by this. How can a PAR of 1.4568 for PAL widescreen be correct? This doesn't give a 16:9 format... The display size with 1.4568 is 1049*576, while it should be 1024*576 to be true 16:9. This is annoying because this will stretch out the video too much. So when I render to PAL 16:9, my video will be too wide!

I do 3d animations, and I rendered my frames to 720*576pixels with a PAR of 1.4222 (so a circle will only look like a circle when the par is set to 1.4222). When I import that into vegas, and tag it as par 1.4222, I will have a black edge left and right if the project is set to PAL widescreen (with par 1.4568). Of course I can set the project to 1.4222 to, but then when I'm done and want to render to PAL DV widescreen, the edges appear again. So then I turn on the option in the render dialog to stretch the video (do not letterbox), and all is ok. But when I then play the file it is displayed at 1049*576, being 2.4% too wide :-)

I still don't understand where that 1.4568 comes from. 1.4222 is clearly the correct PAR.

Don't worry too much. It's bit more than simply math. Vegas does this job perfectly correct.

Marco

I'll also mention, since i don't see it stated in this thread yet, that 4:3 is not 4:3. It's actually 4.090909...:3. Most folks just call it 4:3 for simplicity's sake, or because most computer monitors are 4:3.

It's kinda like how the NTSC frame rate is referred to variously as 30, 29.97, or even 29. It's actually 29.9700299700299700....

Yeah but the frame is really too wide, for most video's it's not that noticable, but if you're doing 3D, sometimes you come across things like perfect spheres or circles and it becomes obvious that they are not perfect if they are stretched out by 2.5% in width.

I'm simply wondering, why this 1.4568 number is used, instead of the perfectly logical 1.4222 (=1024/720).

"I'm simply wondering, why this 1.4568 number is used"

Because this number actually isn't the PAR itself.

Marco

Adobe is wrong, Vegas is right, mainly because they were audio guys and focused on sample rates and good math. Unfortunately, most NLEs do it the adobe way, which has been to start with the assumption that a "4:3" frame is really truely 4:3, which it isn't.

It doesn't really matter if you just stay consistent with the system you're using but it can matter if you prep stills based on the wrong assumption. If you we exporting (ntsc) stills at 720x480 then it wouldn't matter as much.

When exporting stills I use the clipboard to get uncorrected 720x480 NTSC frames out of Vegas. When bringing stills into Vegas that have a 1.0 PAR, I prefer to start them at 720x528. I've decided this actually works a bit better than creating stills at 654.5x480 ;-). These are just my preferences as I don't like the fact that vegas corrects still frames before saving them.

Other systems may ask for stills at 720x534 or 720x540. This last is usually associated with what Vegas calls "NTSC Standard", or 720x486. It's also wrong, based on a 4:3 assumption.

Here are good writeups on it:

http://www.mir.com/DMG/aspect.html
http://www.lurkertech.com/lg/pixelaspect.html

Rob Mack

"For DV, only 704 of the 720 recorded pixels are used for TV display so to arrive at SAR of 4:3 requires 1:0.9089 PAR."

Yes, exactly. To put another angle on it, 704x480 represents the actual 4:3 area.

It helps to think about this as an analog signal designed for tube TVs. There aren't actual pixels in the analog signal, the pixels come from digitally sampling the signal (just as analog audio is sampled).

So, with the analog signal, when a signal reached the end of a line it was expected to fade to near zero and then the TV would reposition the beam to the start of the next line and bring the signal back up. This results in soft left and right edges of a frame but TVs masked it by physically masking the edges of the frame. People would see a 4:3 portion of the overall picture.

If you do an analog capture of a VHS tape, you'll see those same soft edges. Most electronics were not capable of (nor required to) going instantly to a full strength signal, so you see a sort of soft left and right edge.

In NTSC, 704x480 represents the 4:3 area that a viewer would expect to see (some analog TVs would show a little more, some a little less, some centered the picture a little right or left, there was room for slop). 720x480 incudes that left and right slop, 720x486 includes enough samples to represent the time required to reset a CRT from the bottom right of the frame back up to the top left of the frame.

Rob Mack

No, I don't think some of these ideas are correct.

When I first started using Vegas3 back in 2002, this board went around and around with the Vegas developers as to the "correct" interpretation.

As I recall, here's the conclusion back then:

(1) DV is NOT 4:3. It's slightly wider. That's why you get very narrow little vertical black bars on the sides of imported 4:3 stills.

(2) DV is 720x480. Every pixel is available for image. Just look at your preview window. The video delivered by your camcorder uses every pixel of the 720x480 matrix.

(3) TV sets overscan by 5-10%, so some of this discussion is moot for them, but when you view a video on a PC with something like WinDVD, you're seeing the entire 720x480 frame. I make it a rule to put in a cookiecutter frame of about 4% to cover up whatever DeShaker residual junk lies at the edges.

(4) Vegas does the pixel aspect ratios right, others have generally done it wrong, though the ratios are usually close enough that nobody cares.

Summarizing, what screwed me up back in 2002 was the assumption that DV was 4:3. It's not.

I am also confused by this. How can a PAR of 1.4568 for PAL widescreen be correct? This doesn't give a 16:9 format... The display size with 1.4568 is 1049*576, while it should be 1024*576 to be true 16:9. This is annoying because this will stretch out the video too much. So when I render to PAL 16:9, my video will be too wide!

not sure what you're reading or being taught (like said, adobe went off the deap end on this one) but it's a PIXEL ASPECT RATIO, NOT the actual resolution. You can have ANY PAR for ANY resolution you want. they're independent. That's why you can have widescreen & boxscreen all in the same resolutions. That's why monitors have multiple resolutions that aren't the same ratio of pixels wide as high. Heck, you can have a PAR of 2:1 in a 4:3 image that DOESN'T look squished if you record it that way (look at digital camera's, they have many different pixel #'s).

so, to sum it up, it's best if you don't over think these kinda of things. Only start to worry if you start switching from one PAR to another. And then it really only matters if you don't want black bars.

720x486 includes enough samples to represent the time required to reset a CRT from the bottom right of the frame back up to the top left of the frame.
I don't believe that's entirely true. NTSC has 525 scanlines, where the extra scanlines are used for the vertical blanking interval. DV doesn't bother recording these extra scanlines as they don't contain picture.

DV uses 720x480 instead of 720x486 since DCT compression works on 16x16 blocks. 480 is divisible by 16. 486 doesn't divide by 16. You can get away with knocking off those extra lines since they fall in the overscan area (all TVs will crop them off).

2- Vegas doesn't handle PAR correctly when exporting DV clips for web... it will add black bars on the right/left instead of zooming in and cropping the top/bottom.

A workaround is to de-select the letterbox option in the file-->render as dialog window. This will make Vegas fit the video to the entire frame.

It would be technically more correct to make Vegas crop the top/bottom. I think this is possible by nesting your .veg, and then going into pan/crop and making the video "fix to output aspect ratio". You could also apply the "studio RGB to computer RGB" color corrector preset if need be (Vegas defaults to decoding DV to studio RGB; most web codecs expect computer RGB levels).

3- I believe Hulk/Mark has the correct answer.

When i render for the web, if i'm feeling particularly picky that day, i'll render to 328x240 instead of 320x240. The proper dimensions for porting DV to half size would be 327.272727...x240. Using 328 is off by less than a pixel. If i'm rendering to full size frames i'll use 656x480, which is off by only about 1 and a half pixels.

I still don't understand it. I will give you a practical example of the problems I'm having since it's probably very different than what most people use vegas for in this forum.

I import still sequences into veags, not coming from a cam, but from a 3d rendering program. For my last project, I had to deliver in 720*576 for 16:9. So I have to setup my 3D app to render the frames correctly so that when they get stretched out horizontally, it results in a normal looking image.

In the 3D app, you have to set the pixel size of the frame, the image aspect ratio and the pixel aspect ratio. I need 16:9 so that means 1.7777 for image aspect (or maybe I go wrong here but this seems the most logical to me)

Method1: I render a frame with PAR set to 1.0. and image aspect set to 1.7777. These two are locked, so if I enter 576 in the height box, the width is auto set to 1024. When bringing into vegas, the width then gets squished to 720 but scaled again because of the PAR for pal, 1.4568. I get two black bars left and right...

Method2: Since 3D renders is heavy on CPU, I prefer to render to the 720*576 image and set the correct PAR for it. This saves a lot of pixels to be calculated. So like before the image aspect is locked to 1.7777, now I also lock the PAR to 1.4222. Now I can change the image size, and as before if height is 576, height is auto set to 720 because of the PAR and image aspect settings are locked. Same problem in vegas, two black borders with 1.4222. When I set the image options to 1.4568, the image fills the frame, but it gets too wide. Look here, these are supposed to be spheres and not eggs... http://www.aversis.be/vrayrhino/eggs.jpg


method3: I set par to 1.4568 is the 3d app. This way the pixel size of the frame is 703*576. Surely this can't be correct!!! Also here two black borders in vegas.


method4: I set par in 3d app to 1.4568, and I don't lock the image aspect to 1.7777. Then I change the frame size to 720*576. Then I can see the image aspect number auto change into 1.821. Also here, the client wants 16:9 so this is not it. In vegas when set to 1.4568 this gives a correct result though

So what should I do, ask the client if they use vegas or adobe or anything else?

Exactly, except that #3 is a side topic. (Yes, I was there for those V3 discussions)

4:3 can be seen as the frame aspect of the viewport but not the entire image, which is designed to overshoot to either side to allow for the signal ramping up and down as well as for variations in the TV itself.

Of course these examples are for NTSC 4:3 so they aren't directly helpful for PAL or widescreen questions.

Rob

I don't believe that's entirely true. NTSC has 525 scanlines, where the extra scanlines are used for the vertical blanking interval. DV doesn't bother recording these extra scanlines as they don't contain picture.

Exactly. You are describing the difference between DV and older non-DV systems. For instance, m100 captured everything as 720x486 using mjpeg compression. This was typical for systems designed to digitize analog video. In m100 six lines making up the top and bottom of the frame were black. Now, it may well be that even these systems didn't sample all the time in the signal. I had assumed they did.

Vegas provides a template called NTSC standard for this. What I'm saying here is that these older systems would sample that overscan time. DV skips it. Your argument citing 525 scan lines implies that there is more vertical blanking time than is covered by those 6 lines of samples, meaning thoose older systems were also skipping some of the signal time. I can't ague that one way or another.

Rob Mack

I can't remember the exact reason for those extra scanlines. I think it was to give time for the TV to send the electron beam back to the top.

Nowadays we stick closed captioning in those extra scanlines. Some broadcasters also stick a few lines of test patterns in there. In studio use, you can put VITC timecode there (vertical interval timecode).

Charles Poynton's book is a good one for this kind of stuff.

If you have taken a picture of a circle and it shows on your finished product as an ellipse then you have messed with the Vegas default setting or your display is screwed. If you set your project settings to those of your camera there will be no perspective errors. If you use a custom template where the pixel size is selectable you need have a good reason to change this.

Also, if you are displaying on a computer monitor you must have your resolution ratio in Windows Control Panel Display Properties set to correctly match your monitor. IE if you have a 16:9 monitor and a HD display, you use a display setting of 1920x1200 and not 1920x1080

Well, if there are actual lines of signal (and I'm sure there are) then the beam is probably not going back to the top during them.

Thinking some things over this weekend I realized that I was making a wrong assumption about the 480/486 point. Yes, NTSC systems digitizing or acquiring over SDI record 486 lines instead of the 480 used in DV, but I was assuming that since the extra 6 lines came up black in our Media100 systems that that represented retrace time. I'm probably wrong. In our case those lines were black because all our sources were DV25. So there's just no data there. Stupid me.

Mea Culpa, and I don't want to perpetuate my mistakes.

About beams going from the tail of one line to the head of another, or from the end of one frame to the beginning of the next, it's useful to have a picture of this in one's mind because it helps to visualize things. First off, standard definition video as delivered to a TV is an analog signal, just a waveform that continues over time. There aren't any pixels in it and so to say at this point that standard definition has a pixel dimension is a bit of a mistake. But it does have "lines", or probably more to the point, the waveform drops to a low voltage at regular intervals and the time between these drops define a line of video.

Since the signal was designed for tube TVs with relatively slow response times, there's enough time at the head and tail of a line for the signal to rise and fall. With a slow response time time, the signal at the edge of a line rises and falls gradually (making the edges of a frame seem to fade). With a fast response time the edges look very crisp. You can see this easily in video captured froma VHS tape.

Anyway, there's the signal, it's a wave, each frame lasts x amount of time with regular dips defining the boundaries of each line and a certain number of lines containing extra analog data. The dips in signal strength turn down the beam in the TV so that the gun doesn't spray the face of the CRT with rays as the beam resets.

Now, to digitize this, the signal gets sampled, just like an audio waveform would get sampled. You could sample at different rates - you could sample once per second, once per millisecond, whatever is useful. The standard for DV is to sample at a rate that gives you 720 samples/line.

We start to say "non-square pixels" because we are viewing this signal on a computer monitor that plays back at a different sample rate than what the picture was recorded at. Similar to playing back audio sampled at 48k/second on a device that plays back the samples at 44.1k samples/second. It seems a little slow, or in the case of DV, the picture seems a little wide.

And this is where we get to audio, and the reason why Madison was getting things right, at least in the SD realm (I'm not going to make claims about HD). Basically, when Vegas was developed it started as an audio application and was dealing with signals in terms of sample rates. It's pretty obvious they didn't start out by saying "Oh! the picture is 4:3 so lets use that as the basis of all our calculations."

Rob Mack