Now that you mention it, Bob, I think the one-frame offset was to reduce interlace artifact in a video clip. I was going from vague memory. This flicker only happens on a few visually busy images (pictures of many buildings -- but less so on those of cumulus clouds) and all have pan/zoom, incl. center-offsets (blue dot not in default position).

Doing this 'pauper's faux video" approach to using stills for the illusion of a vieo has its drawbacks... :) So it could be a variety of factors contributing to this. Masking out offending parts wouldn't work and be tedious, in part because too much of the image is doing it.

Anyway, I'll try your suggestion.

Here's a link to a plug-in that, according to the link, removes flicker. http://www.granitebaysoftware.com/Products/ProductAll.aspx

Nothing listed for Vegas but the fellow who wrote the software has been responsive to my questions about his other products.
I have not used this particular product, but I have used the GBTimelapse product. http://www.youtube.com/user/thedennischannel#p/u/7/Uu5Q77HpXiM

Maybe I'll go back and look at reducing flicker, too.

That kind of flicker caused by variations in light or exposure levels is a quite different beast. Before you part with your money you can do that for free using VDub and a filter.

Bob.

This bugs me too...I'm going to try scanning the pic at a much lower resolution and see if I can find a medium..at least for the problematic pics...I know it's not the best solution out there..

What kind of "flicker" are we talking about here? Is it the flutter you get in highly detailed areas with fine lines?

I've done quite a few slideshows and prefer to deal with the interlace flicker problem before adding images to the timeline. Using the batch tool in Photoshop (I'm sure other photo-editing tools have similar capabilities), I add a .5px gaussian blur to all images, which has little effect on the sharpness of the final video image but reduces the high frequency content and thus reduces the resulting "flicker". Inevitably, there will still be images which produce "flicker". At that point, you can increase the gaussian blur for the offending images. Alternatively, there is a "reduce interlace flicker" action in photoshop which can be customized to change its strength. Essentially, it attempts to apply vertical motion blur. In some cases, there will still occur flicker, especially if there are very hard horizontal edges, like in buildings, rooflines, etc. If I "really" want to do apply some vertical pan to that image, I will apply a 1px (or stronger) gaussian blur "only" to the offending edges in the image using one of Photoshop's "selection" tools. At this point, it becomes tedious. An alternative, is to apply only a horizontal pan to those images with a lot of horizontal edges. I then "test" the slideshow on a 65" RPTV and if its "OK", I can be pretty confident the images on a smaller screen size or newer LCD will look fine. Just my approach.

wwaag

Here is an excerpt from an old post (sorry, I don't remember who authored it) that has realy resolved the issues I've had with flicker. They are in order of effectiveness:

1. Reduce resolution before importing into Vegas. This helped the most. My original file was a 1536 x 2048 JPEG image. I used "Match Output Aspect Ratio" in the pan/crop which gave me 1536x1126. If I hadn’t zoomed, then I could have reduced the resolution, using PhotoShop, by 50% and still have had enough pixels. However, since my pan/crop movements included a zoom of about 30%, I needed an image with about 30% more resolution than the 720x480 of my NTSC final output. By reducing the image to 61% of its original size (in Photoshop), I ended up with a 937 x 1249 image. This left just enough resolution to zoom in 30% and not end up with an image that had fewer pixels in either direction than 720x480.

PS - I should have added that the original author had done considerable testing to come up with these conclusions.

/jerry

Thanks for more responses.
I can't get to the actual in-project tweaking/fixing for a bit, but figured I'd add some more info.
--------------------------------
Part of the problem (may or may not be) that I'm reworking an older project before I read here that using .bmp instead of .jpg = not good idea (true/false?)

I'll try with 1:1 .jpg replacements, then consider down res--which may or may not be that necessary--though these three problem ones are definitely inconsistent: 3888 x 2916, 3408 x 2665, 2400 x1800. Project size is an HD variation: 1440 x 960.

As to type of flicker, it occurs when pan/zooming over images that have much vertical and horizontal information and contrast -- stacked apartment buildings in particular (slums in Venezuela and Brazil in this case). Horizontal data gets wavy/flickery of sorts.

Now, the images with rounder, softer data such as long-shot landscapes and clouds & sky don't do the flicker. So this definitely has to do with processing harder edge pixels.

And again, I am doing mostly diagonal pan and zoom so it's doing a lot, i.e. start in left bottom of image showing about 1/5 or so of total image to finishing with as much as the Match Output Aspect can show of the image (almost total or total width).

On the forum there does seem to be a consensus around .jpg or .png (if you need transparency). There is little reason to have a photo that much larger than the final output pixel dimensions unless you intend to pan around in a photo.

" Is it the flutter you get in highly detailed areas with fine lines?"

I believe that's what we're talking about. Better known as line twitter however there may also be aliasing issues.

Bob.

1) It is irrelevant what format the image is in. Take your pick, jpeg, tiff, bmp, tga, dpx or dng it simply does not matter. Yes some of them may pose a challenge for Vegas when it comes to decoding them but that's another issue entirely. Vegas will if it can simply decode all of them into the same thing in memory and from then on is when the problem arises.

2) The problem is quite simple, it's a fundamental of sampling theory named after the guy who first discovered it, Nyquist. A quick Google of "Nyquist Limit" will find a wealth of information about this problem.

3) The size of the image is also irrelevant. I've turned 5,400 35mm slides into slide shows and they were scanned at 4K and no once was there a problem. The reason is fairly simple, film doesn't add detail (edge enhancement) and all of these were taken through old "soft" lenses. As Glenn Chan pointed out it a recent thread "detail" once added to an image is basically impossible to remove without doing some damage.

4) The most common problem with stills in video is too much vertical resolution causing the Nyquist problem to kick in. This is a much bigger problem with interlaced displays than progressive as the frame rate is also an issue. I had one really nasty image from a DSC that would simply blink at around 2Hz. Same video looked pristine on a LCD display.

5) To some extent some aliasing is impossible to avoid. Back in the days when people really worried about how televsion looked you could be sent for a quick trip to wardrobe if you turned up wearing clothes with nasty patterns in them. Today I see shimmering shirts and ties quite a lot on TV.


Bob.

"Is it the flutter you get in highly detailed areas with fine lines?"

Indeed, the best description of what I'm referring to. If you had just showed up earlier, Bob, you could have saved me and the readers here from the torture of my long-winded 'splanations and attempts at description :)

FWIW, this is exactly what the 3 tips in my post has eliminated for me.

/jerry

One thing that I didn't mention that is vital is the order in which things are done.

In your post you mentioned that applying Gaussian Blur at 0.001 made the images too soft. I suspect that's because you applied the FX after the image was downscaled, applying 0.001 to a 4K image and THEN scaling the image to SD would be impossible to see.
In general you can control the order in which things happen in Vegas with that little triangle however with mutliple FXs and scaling / moving going on it can be impossible to get it to do your bidding.
My best solution is to do the project in HD or even higher resolution. Make certain your project properties specify Full Resolution = Best and then apply the GB FX to the video buss and nest that project into a SD project and render from there. I've found GB values of around H = 0.001, V=0.003 pretty reliable at wrangling the problem but those values may need fine tuning.

For some still images such as graphics with fine lines I've used GB followed by Unsharpen Mask. That 'fattens up' the 1 pixel lines so they don't get lost in the downscaling.

Bob.

have u tried using video supersampling the problematic areas with a setting of maybe 3 or 4? (300% or 400%)

takes longer time to render (likely 3 or 4 times longer with those settings) but sometimes does great stuff with still images if scaling or 2D camera moves are happening... then again sometimes i just get a render that ended up taking 3 or 4 times longer with no significant difference.

not sure it'll help u in this case, but thought i should mention it as an option.

Thanks to all for further information. Most likely have enough aggregated info to find some kind of solution, one way or another :o)