According to my calculations, the correct Aspect ratio is 0.8889 -- So the other apps that are rounding to 0.9 are actually more accurate that Vegas. I think the .9091 number they have is due to faulty math on their side using 704x480 as the basis of their calculations instead of 720x480.

To get stills to display at the proper aspect ratio in Vegas, I must uncheck the "maintain aspect ratio" box in clip properties.
This is when I use the "snapshot to windows clipboard" in Vegas, paste into graphics program, save, load into Vegas. Otherwise there is black boarders on the top and bottom and the still is squashed compared to the original dv source.
For graphics created in other programs, 655x480 works perfect.

Craig H.

If you set the Preview window in VV to be Display at Project Size and save a still image from the timeline, it will also be saved at 654 x 480.
-----------------------------
Nope. Still Image grabbed via snapshot/clipboard from timeline at DV project size pastes into my graphics program as 720x480.
Unaltered, saved, then loaded back into Vegas shows a squashed image. Uncheck "maintain aspect ratio" and it matches the DV frame it came from perfect. It has something to do with square vs. rectangle pixels. But not a problem as my end result is perfect stills that match the source clip to a T. No difference in anyway, shape or form.
Haven't checked out the new still feature in VV3 yet, guess I should do that. Sure will be nice to cut out all those steps.
All graphics I create are 655x480, just like the text media generator does for size. Unless I want to get tricky via pan/crop, then they get much bigger.

Craig H.

I usually get psyched up about math wars, but since we're in the Vegas 3 crunch mode I will not be able to respond again on this topic. Rest assured that we are not changing our PAR values for the Vegas 3 release, because we do not need to.

We have done extensive research on this issue and our number are correct. The bug in your math appears to be that you are forcing 4:3 into the equation, which would be incorrect.

Some details in how our numbers are derived:

601 digital video is always sampled at 13.5 million pixels per second (for both 525 and 625).

If you have a 525-line analog NTSCvideo signal which you want to sample square pixel, the industry standard is to sample at exactly 12 + 27/99 million pixels per second.

Therefore, we can derive from this that:
525-line Rec.601 pixel aspect ratio = 13.5 / (12 + 27/99) = exactly 11/10 (y/x).

From there we invert, so x/y=.909090909090909090900 etc, which we round off to .9091.

One reliable source (cross verified many times): http://toolbox.sgi.com/TasteOfDT/documents/video/lurker/pixelaspect.html

Yes, unchecking the maintain aspect will appear to do the same, but as i said before, you can do that once for all your pics or use your method and always "stretch' each pic to fit DV. Some pics will also stretch and distort if not at the correct aspect to begin with.
--------------------------
Thanks GG, we are on the same page now. : )
I only used the method I talked about for DV stills that came from VV2 to begin with.
The new still feature in ver. 3 rocks. I did notice that the .png saves aren't the exact same as the source. Just alittle darker. Confirmed with a new feature that I just found, histogram. It's tagged in with the safe title/grid tool in the preview window. I guess what I'm seeing is the difference between native YUV DV and an RGB .png signal. I need to check if exporting to clipboard and importing in another format will make them the exact same.
Also, I can't seem to find a filter to lift the black levels. Broadcast Colors only clamps the upper end of the luma level. Any ideas? Not a biggie as I plan to keep using my TBC for this during dubs, less rendering that way.

Craig H.

Ok, I am responding to my own post: There is always a CHANCE that our math is wrong (not my equations previously posted, I mean that .9091 is wrong).

A free copy of Vegas goes to the person that proves we are doing the PAR math wrong. I'll need citations and peer review of course, but if we are incorrect (which I doubt) we'd love to know about it.

Anyway thanks for bring this whole thing up-it keeps us honest.

OK, you guys have me all worked up:

Adobe uses the same PAR #'s as us, although they round off sooner, to .9 as all their docs state. We use .9091, which could be rounded off to .9 if we didn't want to calculate past 10ths of a pixel.

http://www.adobe.com/support/techdocs/1809a.htm

Here's where the confusion is coming from:

"Adobe: When creating square pixel still image files to mix with your DV footage, use a frame size of 720x534 and use the Shrink to Fit command to scale appropriately."

"SF: Use 655x480 for stills you are bringing into a DV project" We stretch to fit.

What's the difference? Where the math is applied, that's all. We scale W, they scale H

Adobe: 534x.9= 480.6 (using the multiplier on height)
SF: 655x(1/.9091)= 720.5 (using the multiplier on width)

so, going back to the SGI article which uses 11/10 (or 10/11 depending on whether you multiply H or W), then numbers are very close- they both certainly round off to .9, so we are both right, right?

------------------
The simple test to prove our #'s work:

Open a DV project.
Add a color bar event, notice that it fills the DV frame perfectly.
Check the properties of those color bars: 720x480, PAR .9091
Now capture that still from the full sized (720x480) video preview window, save it.
Drag that still from the media pool back to the timeline. It will fill the frame.
Now check the properties of the still: 654x480, PAR 1.0

Overlay the original bars over the still, and adjust opacity of the top event- no mismatch. Set composite mode on top track to subtract and you'll see the .5 pixel roundoff.

*I did notice that our still captures at 654, and our text generator uses 655, but it is just as accurate to round of either direction from a pure 720.5
---------------------------------

Should a program adjust pixel H(Adobe) or Pixel W(SF)? Maybe some room for debate there, but I do know that if you calculate further past the decimal (like we do, to 4 places) we should be more precise in terms of subpixel accuracy.

Squashing vertically: this could negatively impact scan lines, so it seems like this should be avoided. Not so much of an issue with stills though. Gotta research that one-

------------------------------
The real issue at the root of all this is:
what size stills should one create for use in AE or Vegas? Those ARE different because of the stretch directions.

Adobe wants 720x534
Vegas wants 655x480

...and I think that's all you need to worry about.

If i may be permitted a neophitic question ...

Why aren't the pixels all square to begin with? Is there any reason
besides "because" ? ;-)

Right. So why aren't digital video files and stills 640x480 pixels as a
standard for all 4:3 formats? Why the 720x480 and 655x480?

Great Response.

What I don't understand is this:

A computer monitor is has a physical ratio of 4:3 and a 640x480 image fits perfectly in that ratio, hence a PAR of 1.00

So, is a TV screen really not 4:3 exactly? Is a 20" wide TV screen not 15" high? If it is truly 4:3, and you have a video frame data array of 720x480 to fit in a 20"x15" screen, then my logic would make sense (a 8/9 PAR). I think this may be the cause of confusion. If a TV screen isn't indeed 4:3, then I understand why my logic is faulty.

The reason why this is important is that in order to do correct calculations for importing stiils or multimedia clips, I need to better understand how to make the conversion. This is even more important when trying to decide what PAR I should use when importing a clip from DVD stored anamorphically 720x480 but final output should be 16:9 or 2.35:1

Another point of note is that my Sony DCR-PC100 Mini DV camcorder can take stills off of a DV tape. Those stills, snapped from a 720x480 frame are captured at 640x480. I have checked the edges of the snapped frame and the source, and it seems as if nothing was cropped. It seems that the camera is simply resizing the frame to 640x480. Based on your explanation, this would be an innacurate still, the PAR would be incorrect. If this is wrong, it is a direct contributor to my faulty logic.

Please help me understand this!!!

Finally, on your last question on which way to resize, resizing larger is always better, as you don't lose any data (just gain some useless interpolated data). If you resize down to 480H, you're compressing my horizontal data, resulting in a lower quality image to manipulate and re-import. On this point I agree with Adobe's method.

i'll take a stab at it... aren't the pixels on a TV screen rectangular? as opposed to the square pixels on a monitor? am i on the right track here?

You mention that adobe uses the same PARs as SF, but they just round off sooner to .9 -- I disagree, I think they're rounding UP from .889

Why?

I checked out premiere 6, and here are the PARs they use for PAL video (which aren't rounded like the NTSC ones):

Standard PAL: 1.067
Widescreen PAL: 1.422

If you reference my original post, this is exactly what I calculated them to be.

VV uses the following PARs:

Standard PAL: 1.0926
Widescreen PAL: 1.4568

So, which is correct?

Also, here's a doc I found that supports my calculation (search for 1.185)
http://www.irnet.ru/axel/ARTICLES/dvdfaq.txt

- Jon

This is the site with the answer:

http://www.mir.com/DMG/aspect.html

Mir