Or just adapt your project settings to what you want to ouput (sqare pixel and desired resolution).

Marco

If the video bitmap is 720x480, as SD DVD is, then exporting to a 720x480 still image is what I would expect from still image export, and that is what almost all other programs do. Of course I am aware of the pixel aspect ratio, but it doesn't matter to me if my circles are ovals on a PC screen if I don't set my preview to correct for that, but it does matter to me if I'm throwing away original image data.

The video actual pixels is 720 x 480. 655 x 480 is the display. Any other video program, image sequence or video, is going to want 720 x 480. It should export image sequences as 720 x 480.

Dave T2

> ...but it does matter to me if I'm throwing away original image data.

Good because 655x480 doesn't throw away a single pixel. The pixels in an NTSC 720x480 are fractions of a pixel. 0.9091 to be exact. When you place the fractional pixels end to end, they take up 655 whole pixels (654.552 to be exact). So no data is lost.

To export at 720x480 PAR 1.0 would actually have to "create" pixels that don't exist thus stretching the original image. This would be "loosing" data because once stretched it must be re-interpolated to get back to 720x480 PAR 0.9091.

~jr

So JR I admit I don't know about this but if I bring a 655x480 sequence into a compositor program that is set for 720x480 wouldn't the image have to be "zoomed" in on just to fill the frame?

Erik

> The pixels in an NTSC 720x480 are fractions of a pixel.

Could you cite a source for that? My understanding is that 0.9091 is a display aspect ratio, but there really are 720 pixels in the DVD MPEG2 data.

Coded representation: MPEG-1 (SIF combo)
MPEG-2 (Main Profile @ Main Level)

Frame rate: 29.97 or 25 Hz
TV system: 525/60 or 625/50
Aspect ratio: 4:3 (all video formats)
16:9 (all formats except 352 pixels/line)

standard Coded frame sizes:
525/60: 720x480, 704x480, 352x480, 352x240
625/50: 720x576, 704x576, 352x576, 352x288
(MPEG-1 is allowed only in 352x240 or 352x288 res).

Taken from: http://www.bealecorner.com/trv900/DVD/DVD-Forum-Notes.txt
which is a copy of this newsgroup posting from the then-ongoing DVD standards forum.

From cfogg@chromatic.com
Newsgroups: sci.engr.television.advanced,alt.video.dvd,rec.video,comp.compression,alt.video.laserdisc
Subject: A Day at the DVD Forum: technical notes.
Organization: Internet
Date: Mon Apr 22 12:43:29 MET DST 1996

This is crazy-talk. of course pixels are lost when you convert your original 720x480 frame to 655x480. And some programs (photoshop, for instance) go out of their way to allow you to work in this mode and it even makes your circles and squares circular and squarular. :-)

The best solution would be to give users an option instead of trying to out-think them.

I deal with a lot of images of circuit boards and have played with this a bit. If, for instance, I were to take a 720x480 frame of a motherboard with AM3 socket, save a still of it at 655x480, and put that still on the timeline, I'd start to see the pinholes in the processor socket dissappear. That's loss.

Another example that I've tried. Export a still from a 720x480 NTSC project and then put that still on the timeline. Repeat this 10 or 20 times for each new still and you'll find that the image gradually creeps in with black on the edges. It does this because "655x480" is just an approximation. The actual dimension needs to be something like 654.54~ x 480. Vegas rounds up and keeps on rounding up for each iteration. If you did the same thing with 720x480 exports you wouldn't see this happen.

Now, this isn't a real-world situation but it illustrates some of the flaw of exporting stills with a par correction baked in.

This isn't a bug. It's just sloppy thinking.

Rob Mack

Jbeale is correct.

IF the resolution is output at 655 x 480, you are throwing out pixels. The PAR is used for DISPLAY purposes only. The ACTUAL resolution of the video ix 720 pixels by 480 pixesl. The pixels are displaye at non-square which works out to about .9091 ratio and equates to 655 x 480 SQUARE pixels. When you bring that 655 x 480 into another video program, it then has to stretech the 655 back to 720 which means it is now having to CREATE pixels, thus losing resolution.

Dave T2

rmack typed faster, but what he says is correct also.

Dave T2

> So JR I admit I don't know about this but if I bring a 655x480 sequence into a compositor program that is set for 720x480 wouldn't the image have to be "zoomed" in on just to fill the frame?

What composer program? Does that composer program know about non-square pixels? If you did this with After Effects CS4 it is smart enough to interpret the footage correctly, but not all applications can handle non-square pixels so it's always better to export square pixels.

Let's take Vegas for as the composer example. Set your project for NTSC DV. Place an NTSC DV video on the timeline. Set the Preview quality to Best (Full). Press the diskette icon above the preview to save an image to your hard drive. Now go to the Project Media tab and drop that new image back on the timeline. It looks exactly the same as the DV footage! Now right-click on the image in the Project Media and select Properties. Notice that on the Media tab under Attributes it says 655x480x24. Also note that the Pixel aspect ratio is 1.0000 (Square). Vegas is a composer that knows how to handle square and non-square pixels correctly. There was absolutely no loss in the image that you took and placed back on the timeline.

Now let's do the same test but instead of pressing the diskette icon, press the Copy to Clipboard icon which copies the image in the preview window which really is 720x480 physical pixels on your computer screen. Open your favorite image editor (I just used Photoshop Elements 3.0 because that's all I have on this laptop right now) and paste the image and save it. Now drop that image next to the first one on the timeline. You'll notice that the image does not fill the screen correctly. This is because 720x480 PAR 1.000 does not match 720x480 PAR 0.9091 and all images have a PAR of 1.000 because images can't save fractional pixels. To correct this, you must tell Vegas that this image represents non-square pixels so it will know how to display it. Otherwise it will display it incorrectly.

There are some applications that can work in non-square pixels and compensate for the fact the you exported a non-square image to a square format. In that case it doesn't matter (Photoshop CS2 comes to mind). BUT if you are working with an external program that only handles square pixels (and there are lots of them out there), you definitely don't want to export NTSC as 720x480 because the application will not interpret the image correctly.

~jr

> Could you cite a source for that? My understanding is that 0.9091 is a display aspect ratio, but there really are 720 pixels in the DVD MPEG2 data.

Yes, physically the media only records 720 pixels, but it represents 655 pixels the same way DV Widescreen with a PAR of 1.2121 represents 873 pixels. So yes, I am incorrect in stating it the way I did. The point I am trying to make (and rather poorly I might add ;-) ) is that if I wanted to export an image sequence to work in an application that only understood square pixels, then I'd want to export it as square pixels so that the image aspect doesn't change. It would be pretty difficult editing a widescreen shot which represents 873 pixels as only 720 pixels in an image editor.

I guess because you must convert from whatever the native format is to square pixels there will be some loss. In the DV case it goes from 720 to 655 so it looks like we're loosing pixels but in the DV Widescreen case it goes from 720 to 873. So are we gaining pixels? I guess not. Would you want Vegas to output DV Widescreen as a squished 720 image? I know I would want it to be 873x480.

~jr

What you want really depends on the program. Some compositors and 3D programs definitely do understand a PAR, some don't. Vegas kind of takes care of those that don't and ignores those that do. However, this is a consideration that's at least 15 years old and people managed to do their work without an NLE exporting PAR-corrected image sequences.

You're right that in some cases the fact that Vegas bakes-in a PAR correction is harmless. When Vegas adds pixels it's not as destructive as when it chops them out.

The fact that SCS went to the trouble to include the feature in Vegas but didn't provide the option of exporting actual pixels is short-sighted and, to be frank, kind of idiotic.

Rob

"There's no option to export at 720x480"

Yes, there is. Just set your project properties to square pixel and the image sequence render output will be 720x480.

Marco

Yes, that's a work around. You and I both know that you shouldn't have to do that.

The other work around is using the frameserver, but you don't get as many file type options.

Rob

The math is simple:

NTSC DV 4:3 VIDEO TO (4:3) PICTURE
Number of non-square pixels 720 x 480
Pixel aspect ratio 0.9191
4:3 picture (square pixels): 720 x 0.9191 = 655 horizontal pixels

NTSC DV 16:9 VIDEO TO (16:9) PICTURE
Number of non-square pixels 720 x 480
Pixel aspect ratio 1,2121
16:9 picture (square pixels): 720 x 1,2121= 873 horizontal pixels

PAL DV 4:3 VIDEO TO (4:3) PICTURE
Number of non-square pixels 720 x 576
Pixel aspect ratio 1,0926
4:3 picture (square pixels): 720 x 1,0926 = 787 horizontal pixels

PAL DV 16:9 VIDEO TO (16:9) PICTURE
Number of non-square pixels 720 x 576
Pixel aspect ratio 1,4568
16:9 picture (square pixels): 720 x 1,4568 = 1049 horizontal pixels

Jøran Toresen

And this illustrates that, for SD resolutions, the only format that's really harmed by baking in the PAR is NTSC 4:3.

(BTW 720 times 0.9091 = 654.552. Vegas has to round up to make a still that's 655px. These don't actually fit Vegas' SD frame which is why successive exports and imports would show black edges growing in the frame over time. Each image export distorts a little more than the last.)

SCS needed to offer a choice. Many people really do want to work with stills at actual pixel sizes.

One very big reason to do this is that not all NLE teams do their math in the same way. Some actually assume that the corrected image really is literally 4:3. SCS doesn't assume this (to their credit), so one program's corrected PAR can be incorrect in another program. Exporting at actual pixel size eliminates the discrepancy.

Rob

I have rounded all calculated numbers because the number of pixels must be integers. For example, 0.552 pixels does not exist.

Jøran Toresen

About the only consistent thing in the whole old DV mess is the number of pixels must be an even number so PAL 16:9 is 1048 wide, not 1049.

Bob.

In ths case of widescreen, you are not gaining pixels, your image is still 720 x 430, it is only being displayed as a comparable 873 wide image would be. The pixels are being stretched. But if you exported the image as an 873 x 480 image (like vegas exports as a 655 x 480 image) then the computer has to intepret and in the case it would create extra pixels. This does not increase the quality or resolution, it just interpolates, the same as going to 655. In my opinion, I would rather keep all of the 720 pixels and work in a program that displays slightly incorrect so that when I come back to a video program, I still have all of the original pixels. I don't want to gain or lose any.


The other thing we are forgetting, a computer cannot display non-square pixels, so in order to display correct aspect it interpolates the pixels to 655. It does this for the display and Vegas does it for the Still Image output. Of course on your computer, they will look identical because the interpolation is the same. But when you create your DVD or whatever, the image that has been reduced by 65 pixels now has to be render to 720 x 480, so pixels have to be created. Since the DVD player CAN display non-square pixels, Vegas is taking an image at 720 x 480 and an image at that has been at 655 x480 and making it all 720 x 480. I would bet on a big enough screen, you could see a bit of quality difference when it goes to the stills.
Dave T2

I don't think we're disagreeing. The number of pixels must be integers. Vegas must round up the dimensions of an exported image in this scenario. The effect over a couple of generations is negligible. The effect of repeatedly rounding up over 10 generations is noticeable. While this isn't a very realistic situation it illustrates the flaw in the approach.

All of this is beside the point. Rather than expecting users to find workarounds for a poorly implemented and inflexible feature, they should have provided a couple of options in the render dialog. As it stands, the feature is kind of half-a**ed.

Rob

FWIW, since all the pixel talk is getting too confusing IMHO...
Hopping in the way-back machine, when video 1st came to PCs it was 640 x 480... done. 320 x 480 worked as single field for frame doubling, & worked in many a pinch to fill a NTSC TV screen. Vertical & horizontal overage was taken care of by the electronics that converted the footage on your PC to an analog signal... remember that for TVs you were talking analog & wave theory -- something that even today is more or less emulated digitally. Now, a media hardware company came up with new models of their capture hardware that used an improved, increased scanning rate -- instead of scanning the analog signal X many times per second, it now used Y. Just like jumping from 44.1 to 48 captures more audio data & makes it sound better, this increase gave you more picture data. But What To Do?... Everything so far used 640 X 480, so how do you use, let alone account for the extra data on a PC?

They settled on the idea of non-square pixels, which is *JUST* a way of looking at it really. Skipping most of the trivia involving the actual math & scanning frequencies etc, to convert 720 to 640 requires dumping *some* of the extra data 720 offers by cropping, then resizing the frame width. Resizing the other way you got what used to be called "cropped" spec of 704, since you can't add missing data. The original idea was that you worked as long as possible in 720, then dropped to 640 for compatibility, the same way you might work with higher quality video today before final sizing/encoding. In a move to stem the rising tide of confusion & problems 704 caused, NLEs started using 655 for square pixel width, though once you downsized the frame you still lost data, you could at least go fully backwards if you needed to. 655 wasn't really a video size you used for anything, but a handy size to work with, & mathematically you could justify jumping between it & 720 pretty easily, if only you believed in non-square pixels to begin with.

The important things to remember about the 1st two paragraphs are 1) the move to 720 was made to store more data, & 2) the idea of non-square pixels was just a way of explaining how the same TV picture could be 2 different sizes on a PC -- I should add at a time when this media hardware company was trying to sell it's latest products to the video world.

Remember that at that time PCs were not the source of much TV content, & everything revolved around analog TV signals. In most all cases the hardware responsible for getting this picture on a TV still converts the digital fields back to an analog signal similar to what they've used since 640 was the only game in town. Your final video rez on your PC was/is normally whatever your output hardware wants/expects/needs, so talking about overscan is something of a side issue or discussion. Or put another way, hardware that accepted 640 filled the TV screen & worked the same as lots of hardware today that wants 720 X 480 for the same thing.

Now the debate as I understand it is: does Vegas lose data exporting a still sequence? A captured or created original 720 width frame, true to the higher scan rate that birthed it, does have more data than something narrower. It's not just how it's represented on a PC screen, but was born because that extra data needed a place to stay. Now if my NLE *showed* a square pixel frame, but worked on & exported at 720, cool. Exporting that square pixel frame, or converting to & working with square pixel video eliminates the advantage of that higher scan rate & that extra data. It can't *not* cause data loss. BTW, Most mods you perform on a frame that are pixel based, benefit from the increase to 720 from 655/640 -- even if you create a 720 frame from 655, though good original data is best.

If I have a still which I resize/stretch to blend in with 720 video, in theory if I export that still back at it's original perspective with 655 width, I haven't done anything, but I have & will... The pic's been stretched out, then in, then AFAIK out again in whatever importing application. Unless it's made on Silly Putty, not cool. Perhaps worse depending on how Vegas 9 does it's internal workflow... Earlier versions showed evidence of going through multiple sizing steps, even when the final result required *only* one resize calculation.

I know I'm skipping the part about setting rez in Vegas to get your desired still size... don't like the way Vegas handles aspect ratio in most cases so I normally turn it off, switching it on for things like DVD Menus. Rather than rant I'll just say in general I don't like the gotchas I've come across since v.2.

Vegas in general has a few problems & idiosyncrasies in my experience dealing with, importing/exporting stills, but I maybe do that more than many to get around the rather big inefficiencies of resizing & related video mods in either Vegas or Prem., working that end of things as much as possible in AviSynth &/or V/Dub. Backgrounds for DVDs can also get rather involved, needing to export clips as mpg2 just to re-import & capture stills or add overlays -- WYSIWYG alas doesn't always work as it should when creating highlight masks with text overlays etc on a still stretched anamorphic for example, but Vegas actually can render the text better than P/Shop.. I sadly suspect that if/when I need image sequences, and when I do it's rarely for an image editing app, with Vegas9 I'll still be looking to the same freeware standbys.

------------

Really FWIW, at these sizes pixels themselves are irrelevant, since with D1 they don't exist! That's why this mess was recognized as such a total mess when they developed anamorphic 16:9, where you won't find any detailed mathematical formulas, even Sony & Adobe disagree, & neither matches the actual display on a 4:3 TV!!! [In a rather nerdish moment I scanned frames from film for comparison with shots of TV displays]. A pixel is a random unit of measure, representing the smallest dot a display at whatever resolution can display according to Microsoft, & while it means something with the purely digital, with analog D1 it's just a matter of standards. You could argue on how well the scanned analog data matches the digital representation on a PC monitor, but it does roughly correspond as well as anything could back then -- you've got 240 lines per field, and at 640 approximately the correct width, & the increase to 720 being the way to put that extra data someplace retrievable. Whether you've moved to all digital or not is irrelevant, since the D1 standards were developed and exist in the analog world. You could argue about the old Amiga screens which did have odd shaped pixels if I can be allowed the slack to call them that, and were used a LOT in the old days for TV. At the end of the day though, go to 640/655 from 720 video, & there's absolutely no place to store the data you're losing. And if you captured or created that data, in software or in your cam, whether it represents all or a portion of the 720th pixel, it yours to keep or throw away.

That said, at D1 rez it probably doesn't matter all that much for a lot of people. Convert video from 720 to 640 & back by just simple resizing, and play all 3 one at a time... can you spot the differences? -- could the average viewer? Enlarging from 655/640 up to 720 can easily be handled during playback on most PCs without any strain. Again can you see the difference between the player enlarged version & the original? At HD rez it matters, but not so much here at ol' D1. By far most folks just ignore the intricacies and go with what looks right & works, so fortunately this sort of discussion is rare. While it very, VERY true that with highly detailed stills or frames the stuff you lose is very noticeable on a PC -- maybe even upscaled to HD -- on a CRT TV which D1 was intended for, good luck having viewers pick out any differences.

When it comes to exacting math, everything is based on the original frequencies AFAIK, with the figures Sony uses for example being a rough approximation. For 16:9 anamorphic as stated all bets are off... one reason I try to do most parts of a w/s motion menu in Vegas. As far as displaying a non-square pixel, since there really is no such thing as a pixel if you want to really get down to it, I guess you could say no it can't, but also claim it does as well as regular pixels. But we need pixels for coding, so oh well... Far easier to just get used to the numbers. If you want a quick hedge, slap a DVD in your PC & take a snapshot with PowerDVD -- it increases the height to maintain perspective, so it'll show you square, which you can resize to 480/576 as needed if you want. If you want to go bonkers try figuring out the math -- do the anamorphic calculations come before or after the leap to non-square?... &/or before the leap to square?... & where's the actual std., not found, reported, or assumed regarding DVD anamorphic W/S square & not?

Oh well, all just mostly trivia gathered since before Windows was Windows, & if anyone disagrees, fine -- I'm not posting pages of links for references -- I'd rather just say fine & hope someone lurking found something here useful.