import sequence does the amount of time that each frame should be there I take it?

maybe it's something I missed
- I'll take another gander and see.

Dave

When importing as an image sequence... each image... gets it's own frame. As long as that was what you meant to have happen.. there is nothing more needed.

Thanks alot guys - good to know that when I've got OT (on topic) questions, I don't have to wait long to get the answers.

Dave

Here's the NTSC wierdness. 1 second of defualt duration =29.97 frames. Not quite a whole number, is it?

In Vegas prefs-editing tab, set your new still image length to some multiple of 1.001 seconds. The basic idea here is to increment the number in the box until the "number of frames at 29.970" changes. Vegas does NOT automagically quantize imported stills to whole frames so to save yourself any potential trouble later on, get this setting right before you start.

I think that this setting shouldn't even be there in the global preferences because if you switch a project from NTSC to anything else your stills will go from being whole frames in length to fractional frames in length. And, yes, Vegas WILL snap to frame 149.850 on the timeline. Maybe the solution is for Vegas to ALWAYS snap to frames. Currently, it doesn't.

Rob Mack

By importing as a still image sequence you get beyond any such issues... just specifiy the frame-rate you want (it will default to the project settings I think) and each still will take up exactly one-frame.

That's not to take away from your post at all... very intriquing

Doh! You're right. Image sequence as opposed to set of images. I was assuming this was about slide shows.

Image sequence imports each image as a frame. each image then is one frame long. There's no way to adjust the duration of each frame. If what you want is more like a slide show, go back into prefs and do what I suggested first. In fact, if you're working in NTSC, do it just on principle.

Rob Mack

only thing that MIGHT go wrong is the pixel aspect ratio. For some reason, all imported image sequences seem to default ot 1.0. Change it to 0.9 & you're all set.

Only if your images are actually saved in that pixel aspect ratio. If the original images are created as 1.0 pixel aspect.. then don't make any changes. This is about the Image source pixel ratio.. not the ratio of the project.

Rob, actually you can set the frame rate when importing an image sequence. Type in 0.2 and each image will last 5 seconds. However, you can't set transitions between them. The default behavior is "smart resample" which will effectively create a linear fade for each picture that lasts it's entire duration. Disabling reampling will have each picture cut to the next one.

Very true, it just depends on what they are to start with. If it's an image sequence that was really a frame by frame sequence, it's pretty likely they're in 0.9091 but you have to check. The biggest clues are 1) was it an exported image sequence from an NLE or compositer 2) are they all 720x480.

If so, there's a way to set Vegas up to treat everything of a certain type as 0.9091. For instance, I could make all .tga files import that way. It's a little obscurred but definitely do-able.

If the intent is to take stills from a digital camera and make a slide show then you almost certainly won't want to change the aspect ratio.

Rob Mack

Hmmm...the dialog I'm looking at is simpler than that so I must be in the wrong spot. I'm looking at "file/Import Media..."

Time passes...I found it. Right-click on the clip in the media pool and select properties. Change the frame rate to .2 and you've got longer durations.

Here's something funny about that, though. I imported a 4 frame sequence and then changed the framerate to .2. Next I drop it on the timeline and doubleclick to select the whole event. Finally, I switch the ruler to Absolute Frames. Now I see that my event is 599.401 frames long.

I'm not in favor of this. But the idea is interesting. I suppose if you want to use this method you'd divide the project frame rate by a whole number and then enter the result as a frame rate. so rather than .2, you might use .29970

More time passes...if I enter .29970, Vegas rounds it to .3. That makes the event 399.600 frames long. 2.997 works as a frame rate but the clip is only 40 frames.

Rob

Oh well. I only said you could change the frame rate. I didn't say it was a useful thing to do. ;)

Besides, in the long run, as long as the images come close to matching the musical cadence, will anyone even notice if they are up to half a frame off on timing? That's the closest you can come anyway. When all is said and done, a few decimal points of error in frame length isn't going to matter to the person watching the video. The only time it makes any difference is if you are using hard cuts between images; if the images change in the middle of a frame Vegas will combine them for that frame creating single-frame crossfades that may or may not be noticeable.

Sorry to chirp in here, single frame cross fades could be the sort of thing to spin out an mpeg-2 encoder. I believe the encoders may be smart enough to detect a cut and put a new I frame at that point however what would it do when the two fields that make up a frame are very different?
Bob.

Well, the frame in question is basically a composite of the pictures before and after. The mix depends on where in the time boundry of the frame the switch occurred, but it's probably useful to assume the frame is half and half. I don't see this as being different from any other motion. Either there are enough bits to keep up with the change or there aren't. It may put in a new I frame at the crossfaded frame, in which case it has to gradually build up to the new picture over the next few frames, or it doesn't, in which case it has to gradually build up to the new picture anyway.

Since the still pictures making up the video are probably progressive, i would think that the new frame would consist of two identical fields rather than one field being the previous picture and the other field being the next. Experimentation and study are needed.

OK, experimentation results for your study:

Setup: butt up two progressive images with the boundry being haflway between frames, render to new DV .avi file.

Test 1: project properties interlaced, render to interlaced.
Result 1: As Bob suggests, field 1 contains lines from the first image, field 2 contains lines from the second. There was no crossfade.

Test 2: project properties progressive, render to progressive
Result 2: The frame in question contained entirely the first image and none of the second. The next frame contained image 2.

So, not quite what we thought after all. It looks like for progressive rendering lining up the images with frame boundries is moot. For interlaced rendering there can be an inbetween frame made up of the two images, which may trip up MPEG (or other temporal compression) encoding.