will the real Aspect Ratio, please stand up!

TeeJay wrote on 5/11/2006, 10:10 PM
Hi, just a little confused with the Aspect Ratio differences between App.

For eg. In Vegas when setting properties to PAL Standard, the Pixel Aspect Ratio is 1.0926. When I open a clip from Vegas into Bauhaus's Mirage, the default PAL 4:3 PAR is 1.067. It opens with a horizontal line at the top where it's visibly not the same size.

I can bring it into Mirage and tell it to correct aspect, but then export it out again, back into Vegas and it is obviously different again. Is all this stretching/matching aspect stuff degrading my clip?

Those of you who do use different Apps for different tasks, how do you manage this?

T

Comments

Zendorf wrote on 5/11/2006, 10:29 PM
Yes, this also caused me a lot of grief when I came to Vegas. Being primarily an animator (3d and AE work) I was as confused as yourself, since every other app uses the 1.067 par for PAL except for Vegas. Bottom line is that Vegas does have the technically correct PAR (there are many other old threads on this). The Myers book on AE goes into this in detail and actually provide a way of bringing this in as presets for AE...which I did initially.

These days, I just tend to render from my 3d apps or AE at the usual 1.067 PAL (or 1.422 for widescreen) and then use the vegas standard of 1.0926 for my Vegas project. Everything seems to work out fine. The only time I noticed a discrepancy was when I had a filmed circular cutout in a wall that I used a Vegas circluar cookie cut on...and then my generated circle in AE didn't match up. But this an extreme case where you would notice the difference in PAR's...
TeeJay wrote on 5/12/2006, 3:04 AM
There has been instances whereby I have taken Clip, ( a 3D Text Object created in Lightwave) from Vegas to Mirage to do specific things like adding a Volumetric Light effect, and then when i bring it back in to Vegas, the Text that has the Volumetrics no longer lines up with the Non Volumetric affected Clip. This annoys me greatly because I have to then resize it with Pan/Crop.

There simply has to be a better way of ensuring things stay the right size.........
Chienworks wrote on 5/12/2006, 4:46 AM
You could create new project templates in Vegas to match the other software, then start all new projects with these templates.
farss wrote on 5/12/2006, 6:31 AM
Accept wouldn't that cause a problem with standard DV. I suspect that then you'll loose the 1 to 1 pixel mapping and all your DV will be recompressed?
TheHappyFriar wrote on 5/12/2006, 9:45 AM
I normally render at the same resolutions... forget what PAL is but when I go between different apps I try to keep itat 720x480. This helps.. But you do get wierd results some times, just like any other way.... don't know where some people get their aspect ratio's from. I didn't know it was so hard to go X/Y = A. :)
rmack350 wrote on 5/12/2006, 11:09 AM
The problem is in what people use for X and Y. Most NLE coders assumed that the picture was 4:3 and did the math from there. (It isn't really 4:3 is the problem.)

Sonic Foundry, being audio guys, took the sample rate and the sample time and got the right numbers. A+ for doing the math right but unfortunately it doesn't match everyone else in the biz.

If you stick with the unadjusted frame size thoughout your apps you ought to be okay (I'd think) but there'll be a difference from app to app as far as what each assumes is a perfect square or circle.

Rob Mack
farss wrote on 5/15/2006, 4:58 PM
All that's kind of OK, until you get into CGI and/or real compositing, maybe no will notice if your circles aren't 100% round, probably don't end up perfect on many display devices anyway but they'll sure notice if a mask doesn't line up properly.

rmack350 wrote on 5/15/2006, 6:12 PM
True. I think that no one has ever really been able to notice that circles weren't really being drawn round in AEFX. It's a pretty small difference and if someone in authority tells you it's a perfect circle you'll probably believe it.

Masks ought to stay in line if you just don't try to do square-nonsquare conversions. Personally, I think it's a little foolish for Vegas to be saving stills at 654x480. If the still is going back into Vegas it makes more sense to keep it at 720x480, or whatever the PAL size is (720 x something taller than 480)

As a little experiment, export a still from vegas at square pixel size, then put it on the timeline and keep repeating. You'll see it start to creep in on the sides. The lesson seems to be that you shouldnt do that. Export at non-square size and draw your masks over that.

Rob Mack
Marco. wrote on 5/16/2006, 12:10 AM
>> A+ for doing the math right

Yessss!

>> As a little experiment, export a still from vegas at square pixel size, then put
>> it on the timeline and keep repeating. You'll see it start to creep in on the sides.
>> The lesson seems to be that you shouldnt do that. Export at non-square size
>> and draw your masks over that.

This had been on PAL systems for a long time with Vegas - since 6.0d. Before freeze frames were exported with 786x576. But when importing the freeze frame into Vegas - Vegas expected 787x576 (what is exactly right).
Now (with version 6.0d) Vegas also exports at 787x576 and everything is fine. You can do that circle described above (export a still - import it - place it on the timeline - export it ...) a hundred times and it will perfectly fit. This was one of my long time desired bug fixes and I'm glad this works now.

Try other NLEs like Premiere and you'd end up rather crappy. Vegas does a perfect job here.


Marco


Chienworks wrote on 5/16/2006, 2:06 AM
If you use the copy to clipboard function rather than save to file function you will get a 720x480 (NTSC) image. It is possible (or even likely) that whatever program you paste into will save the image with a PAR of 1.0, so when importing back into Vegas you'll have to manually set the PAR back to 0.9091 to get Vegas to display the image properly.
rmack350 wrote on 5/16/2006, 2:28 PM
It doesn't matter what the other program thinks the PAR is. Vegas doesn't know about it. It just automatically treats stills as having a 1.0 PAR. As far as I know, programs like photoshop (the CS versions) are just applying a tag to the file. Vegas doesn't recognize the tag, as far as I know.

You can get Vegas to apply a default non-square PAR to stills based on file type. It's not real obvious but it's doable.

I certainly agree that copying to clipboard is the better way to go. If Vegas ever starts to support 10bit they're going to have to rewrite all of that, though. Currently they're pulling the image out of the frame buffer, which is fine for 8-bit images, but won't work for 10-bit. Good riddance to that method anyway, because your exports are tied to the preview window's settings. Duh!

If you are bringing stills into Vegas (as opposed to making a round trip out and back in) Vegas does a great job with stills that are 720x528x1.0PAR (for NTSC projects). No rounding is involded to get it to fit to frame, as far as I can see.

Rob Mack
Chienworks wrote on 5/16/2006, 3:11 PM
720x528 has to be resampled to 720x480, so some image fudging still happens.
rmack350 wrote on 5/16/2006, 3:55 PM
Yeah, you would think so. I can't remember how I checked this, just that I was pleased with what Vegas was doing.

Here's what I was concerned about at that size. We know Vegas automatically sizes an image to fit inside the frame, and also that it will assume a still has a 1.0 PAR and that Vegas will resample it to a non-square PAR.

What I was wondering was what order vegas does it in. Does it resize and then resample, or resample and then resize. If it resized first it'd drop the image down to 654.5x480 and then resample it out to 720x480. It'd be throwing out image data and then resampling.

It appears that it resamples first. I was using photos of motherboards and the CPU sockets are a good indicator because they are a grid of dots (for ATH64, anyway). You can see if columns of dots a getting lost, and they aren't. A still that starts at 720x528x1.0 ends up looking a bit better than one that started at 654x480x1.0. Vegas preserves more detail when you start at 720x528.

I also used a set of images with arrays of vertical and horizontal lines. Again, things fared much better when starting at 720x528 (which is just a multiple of 654.5x480)

This is all different from round-trip processing of still frames out and then back into Vegas. In that case the best choice would be to output at 720x480 and then work on the image at that image size.

The only reason I can see that Vegas defaults to working with stills at 1.0 PAR is that it's a heck of a lot easier for new users to understand. It would have been a support nightmare otherwise.

Rob Mack
Chienworks wrote on 5/16/2006, 5:20 PM
It probably resizes while resampling. There would be no reason to do these operations separately and no benefit whatsoever. It would be faster, more efficient, and easier to code as a single operation.

Probably the other reason that Vegas assumes stills have a PAR of 1.0 is that just about every digital camera, scanner, photo editing/graphics program, and user out there uses 1.0 as the default PAR for stills. Why would anything other than a video editor use anything other than 1.0?

Heck, why does video use something other than 1.0?
rmack350 wrote on 5/16/2006, 5:57 PM
Exactly. Imported stills would always be 1.0 unless you are preprocessing them specifically for video.

Vegas is a prosumer application and is designed to make life pretty easy for new users. Generally, that's a good thing. It's just that in the process, they didn't make it very easy to follow "best practices" (which would be to export stills at actual pixels and then import them that way later)

Why does video use something other than 1.0? That's a really great question. The main factor seems to be that the standards group wanted to pick a sampling rate that could be the same for both PAL and NTSC. They settled on one, but the sample rate doesn't yield a square pixel aspect ratio. Had they chosen a sample rate that yielded "square samples" then they would have had to use two different rates.

It's all too much to belabor here, but here are a couple of links to articles on the subject:

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

<time passes...> Hey Kelly, we've had this converation before:
http://www.sonymediasoftware.com/forums/ShowMessage.asp?MessageID=339230

Rob


lwx wrote on 6/7/2006, 8:45 AM
I'm not really sure what standards Vegas expects or imposes for PAL, but regardless - for the purpose of import into Mirage, you have several alternatives that will not modify the original pixel aspect, image aspect, or resolution.

The simplest might be to simply open the (Vegas standard) Pal format clip as a new project, rather than loading it into a layer of an already open one.

In this case, Mirage should pick up resolution, field dominance and frame rate from the file header, and create an appropriate new project to receive it. Mirage may or may not 'see' the pixel aspect in the file header. Probably it will default to "1" (square pixels). This really doesn't matter for most purposes (the only significant impact of having the pixel aspect set 'correctly' in Mirage is that the Rectangle and Circle drawing tools can be constrained to a perfect shape with the Shift key.)

(There are several other approaches, but I'd need to know original the specs of the PAL clip to be more specific.)