Two more things to try.
#1. Run Reduce Interlace Flicker on them. Right-click on the image. It's under Switches.
#2. If necessary, apply a very light Gaussian Blur FX to the stills
horizontal @ 0.000
Vertical @ 0.001 or 0.002

Mike

craftech's advice is all quite sound. However, while all those things will help get the best performance, not all of them directly relate to flicker (such as JPEG vs. PNG). Of the things mentioned, the Best setting is the one that will do the most to reduce flicker. Also, try not to scan at too much more than the resolution of your project setting, multiplied by the maximum zoom you plan to do for that photo.

The other critical setting is, for each photo, you should enable the "Reduce Interlace Flicker" setting. This is so important that there are many scripts -- including the Ultimate S and Excalibur commercial programs -- that will do this for all your photos in one click.

For more discussion of this topic, refer to this thread:

Still photo flicker reduction

Actually, if you're making 655x480 images then the PAR of the image should be 1.0. Only use .9091 if you're making the image 720x480. Even then, don't just simply crop or resize an image to 720x480 and set it to .9091 or it will end up looking tall'n'skinny in the video. Unless you really know what you're doing and know how to have the photo editing program resize by PAR or in one dimension only, all still photos should be set to a PAR of 1.0. Vegas will know how to handle it best if you don't muck with it.

You have scanned in photos which presumably will surely be of of a much higher resolution than 740X480 (i.e., the jpgs you made could well be [e.g.] 2000x1500 [or much higher], depending on your scanner settings). You are zooming into and/or out of them (as i gather from your post). You should also remember these basics: when you use pan/crop you must set your properties (File>properties) to Progressive Scan, Interpolate fields and, on your monitor properties to best-full. Whether this will help your flicker problem...? It's just basics for using a still image and zooming/panning it.

I disagree with johnmeyer when he said "try not to scan at too much more than the resolution of your project setting". My opinion: scan at the highest resoluton that gives you the best detail of your photo. Especially if you are planning on zooming or panning. If you want to use the entire rendered photo this can easily be done with pan/crop and nothing can be gained by scanning at a lower resolution.

I disagree with johnmeyer when he said "try not to scan at too much more than the resolution of your project setting". My opinion: scan at the highest resoluton that gives you the best detail of your photo. Especially if you are planning on zooming or panning.

Go back and read John Meyer's post again.
He said
Also, try not to scan at too much more than the resolution of your project setting, multiplied by the maximum zoom you plan to do for that photo.

Mike

scan at the highest resolution that gives you the best detail of your photo.

If you read the post I linked to, you'll find that if you do this, it doesn't give you any better quality (assuming you allow for the zoom factor), but it will definitely increase render times, and it will definitely increase the flickering artifacts that sometimes occur when panning the photo. However, I agree that it is the simplest way to go.

Also make sure they are 8-bit per pixel images (24bit). I usually scan at 16-bit per pixel (48bit), but convert prior to loading in Vegas. Vegas can behave a bit strangely when using 16-bit per pixel images.

rs170a: 4/28/2007 5:36:27 AM: (quoting John Meyer) "Also, try not to scan at too much more than the resolution of your project setting, multiplied by the maximum zoom you plan to do for that photo."

I hope I did not infer advice on the flicker problem. Before making your project do you really figure out the probable maximum zoom you're going to use on every or any photo? Surely you will save these scanned images anyway. It's not common sense to digitize them at max resolution? And then resample if this really affects the flicker problem?

johnmeyer: 4/28/2007 8:35:13 AM: "if you do this [scan at the highest resolution that gives you the best detail of your photo] it doesn't give you any better quality (assuming you allow for the zoom factor)..."

Okay, you can't get any better resolution than that of your rendered video.

"it [scanning at the highest resolution] will definitely increase render times, and it will definitely increase the flickering artifacts"

It seems completely counter-intuitive that the size/resolution of the digitized image imported into the Vegas project would affect render time. Is there a technical explanation? I ask just in the hope of being informed.

I think there's a lot of urban legends mixed in these threads.

It has been a while since I have been here but I see this thread that covers the same issues I was having a few years ago and feel compelled to add my two cents. John Meyers advice and the link he mentioned nearly always helped me solve some probs w stills. Seems there were occasional anomalies but a little t & e usually solved them....

"It seems completely counter-intuitive that the size/resolution of the digitized image imported into the Vegas project would affect render time. Is there a technical explanation? I ask just in the hope of being informed. " "urban legend"?

Higher rez - more data - more crunching - more time ....... technical enough ?
Try it -- render a still and then again with a lower rez version . . . . .

"It seems completely counter-intuitive that the size/resolution of the digitized image imported into the Vegas project would affect render time. Is there a technical explanation? I ask just in the hope of being informed. " "urban legend"?

Boy, you hit me where I live with that one. I HATE the perpetuation of urban legends (like disk fragmentation) and therefore sure don't want to be guilty of perpetuating one.

So, I went ahead and put four 3000x2000 stills from my D70 on the timeline. I set Match Aspect for all four using a script. I then set a keyframe at the end of each and panned each one (no zoom). I then rendered using the Best setting, as one should for stills.

Render time on my old P4 2.8 GHz: 2:53.

I then created reduced versions of each photo, at 992x660 (1/3 original resolution) and saved in the identical (JPEG) format. I then added each of these as a take, so that each photo was panned identically. I rendered, at Best.

Render time: 1:36.

Thus, the render time was faster. No urban legend.

I did a few other tests and did uncover one thing I wouldn't have expected: If you zoom in far enough so that the resulting resolution is less than 720x480, the render time shoots up. Apparently UP-sampling takes a LOT more time than downsampling.

Finally, if you have an older version of Vegas, especially some of the early versions of 6.x, they had bugs that would actually cause renders to hang if you had large numbers of high resolution still photos on the timeline. I am pretty sure that this has long since been fixed.

fultro: 5/1/2007 6:52:35 PM: “Higher rez - more data - more crunching - more time ....... technical enough?”

The rez of the rendered file can never be more than 720x480 (assuming SD), so what difference can the size (i.e., rez) of the original jpg make? That is, Vegas only renders that part of the image that appears in the project veg and ignores the rest no matter how big/hi-rez the source jpg is.

johnmeyer: 5/1/2007 8:36:56 PM: “…did uncover one thing I wouldn't have expected: If you zoom in far enough so that the resulting resolution is less than 720x480, the render time shoots up.”

But If it takes *longer* to render a panned image that has a resolution less than 720x480, doesn’t this argue for scanning at such resolution that gives you the most detail in your digital file (i.e., more likely not to be less than 720x480 when imported into Vegas)? You get better resolution and yet less rendering time.

Re your pan test: I am not technically sophisticated enough to know from your description if the lower resolution fotos you panned still resulted in the same resolution in the rendered video as it did with the high res fotos. I assume that's true: then this suggests the less “resampling” Vegas has to do to bring the image to 720x480 results in lower render times (but yet it takes more time to “up-sample” them. Life is strange.)

Well, there you go, mostly just like your linked-to post said…

So no urban legends, I guess.

The rez of the rendered file can never be more than 720x480 (assuming SD), so what difference can the size (i.e., rez) of the original jpg make? That is, Vegas only renders that part of the image that appears in the project veg and ignores the rest no matter how big/hi-rez the source jpg is.

This sounds right but strictly not true.
For one thing at 1:1 PAR the video image isn't 720x480 so Vegas is resampling and more res always helps when resampling.

But there's another trick to this. If you want to get more apparent res out of video a very slow zoom or pan works wonders, even the smallest amount of motion of the camera can make a difference. With digital video the pixels are discreet, moving them over a high res image reveals more detail that the brain build up to form a higher res memory of the scene.

Bob.

Well, there you go, mostly just like your linked-to post said…

Huh??

johnmeyer: 5/3/2007 7:58:01 AM

>>Well, there you go, mostly just like your linked-to post said…

>>So no urban legends, I guess.

>Huh??

Just an off the cuff remark. I meant that everything re this question was pretty well explained, ergo in this case there were no "urban legends.