Suggestions for processing this with NeatVideo?

[brassplyer]

I would have thought cleaning this with NeatVideo would be straightforward - beach/sky shot on a tripod shot with a Digital8 camcorder, but it's proved to be problematic. The big problems are a very uneven look to the noise reduction and this sort of jumpiness in video. I've tried NV on this before and after deinterlacing with QTGMC via Avisynth, doesn't seem to make any difference.

Attaching a 3 sec 10 meg section of the original DV avi.

Any suggestions?

Thanks.

[smrpix]

Your biggest issue isn't noise -- the stuff that neat video is good at, it's exposure flicker caused by the camera's auto exposure and/or auto focus.

Here's your sample with BCC flicker fixer applied. msu deflicker may work as well in virtualdub. Then try neat video on top of that if you still feel it's too noisy.

http://www.compression.ru/video/deflicker/index_en.html

[manono]

What's BCC flicker fixer? I can use something like that.

[smrpix]

Boris Continuum Complete. It's a filter plug-in package for Vegas Pro, Premiere Pro, Avid Media Composer and others. msu deflicker is a decent alternative.

http://www.borisfx.com/

[manono]

Good, thanks.

[sanlyn]

Needs more.
Avisynth(IRE correction + ContrastMask) + DeFlicker.vdf + Low-power NeatVideo

[sanlyn]

Or this, with a more naturalistic look using contrast masks. Lots of ways to address a scene like this, including leveling the horizon with the Rotate() plugin.
Basically, the original sample you posted is overexposed.

[_Al_]

banding could be really a nightmare after denoise, but in this case I did not get much banding at all, if there are tiny spots, they are not moving, like your first sample:

[_Al_]

But now I'm looking at it, that wave lost a lot of detail in my sample as oppose that Beach_02Knva.mkv. Is the order important deflicker and then denoise? Because I did it the other way denoise first, then deflicker. Or this is result of video>RGB>YUV conversion using Vegas and frame server export?

EDIT, so: I turned off denoise in Vegas and details are back, wow so one have to take it easy, no default values for sure

[sanlyn]

But now I'm looking at it, that wave lost a lot of detail in my sample as oppose that Beach_02Knva.mkv.

The bitrate in your sample is too low to maintain detail or motion. Might work for 320x240 pogressive on Utube, but not for full-frame or TV.

[sanlyn]

Say, _Al_, thanks for mentioning....I reviewed my processing and found a dumb mistake on my part. On correcting it I noticed a few things. Will post some peculiar findings a little later today.

[jagabo]

The function mentioned by MattiasN in this post worked pretty well for deflickering this video:

https://forum.videohelp.com/threads/360004-Using-Avisyth-Overlay-for-Contrast-Masking?p...=1#post2282040

Increase the radius argument in temporalsoften to ~4. Removing the Merge() may work even better.

For those who've never used VitualDub filters in AviSynth, Donald Graft's Deflicker filter works fairly well with something like:

LoadVirtualDubPlugin("g:\Program files\VirtualDub\plugins\deflick.vdf","DeFlick") 

AviSource(...) 

ConvertToRGB32(matrix="PC.601")
#DeFlick(window size, softening, interlaced, scene change threshold, show scene change)
DeFlick(12, 0, 0, 10, 0) 
ConvertToYV12(matrix="PC.601") # back to YUV if necessary

[sanlyn]

For those who've never used VitualDub filters in AviSynth, Donald Graft's Deflicker filter works fairly well with something like:

LoadVirtualDubPlugin("g:\Program files\VirtualDub\plugins\deflick.vdf","DeFlick") 

AviSource(...) 

ConvertToRGB32(matrix="PC.601")
#DeFlick(window size, softening, interlaced, scene change threshold, show scene change)
DeFlick(12, 0, 0, 10, 0) 
ConvertToYV12(matrix="PC.601") # back to YUV if necessary

It does work, but the syntax as posted in most examples is confusing . This was covered in an earlier post from you and poisondeathray (which, of course, I still can't find). The parameter order is shown correctly, but the number sequence works out this way:

Window size 0, softening 10, non-interlaced, scene change detection disabled:

#DeFlick(window size, softening, interlaced, scene change threshold, show scene change)
DeFlick(0, 10, 0, 256, 0)

Window size 0, softening 10, interlaced, scene change detection disabled:

#DeFlick(window size, softening, interlaced, scene change threshold, show scene change)
DeFlick(0, 10, 1, 256, 0)

Window size is the first number in the sequence, softening is second. I usually set window size to 0.

[poisondeathray]

For tripod shot scenes, another option is TimelapseDF .
http://www.zhitenev.com/avisynth/TimeLapseDF/

eg.
TimeLapseDF(mode="CDF",gradient=true)

[sanlyn]

I only used a contrast mask + deflick + NeatVideo + gradation curves. But as I mentioned I made a stupid mistake (what? moi?) in beach_01Lnva.avi in post #7. In my script I accidentally commented-out the line for QTGMC. No wonder I kept losing some detail and intensity.

So I corrected that and ran a new mkv, but I noticed something. In the attached and corrected beach_03.mkv notice the heavy grain in the sky, which softens and evens out over the next several frames. This must be some of the grainy stuff brassplayer referred to. It apparently takes the temporal filters a few frames to get underway full blast.

So in the attached beach_03A.mkv I inserted copies of the first 15 frames during processing, then removed them before encoding. Thus, beach_03A.mkv doesn't have the startup grainy effect. With deinterlaced processing and re-interlace later, you also get at least a glimmer of some kind of subtle textures in the sky. Unfortunately the brighter original has washed out a lot of it.

The clip might not be worth all this trouble, but it was an interesting exercise. When I cut up a video to process separate clips, I usually leave a few leading and trailing frames. Temporal filters usually have less effect on the first few or last frames.

[poisondeathray]

What is the reason for deinterlacing , reinterlacing ? This is a progressive DV clip ...

[sanlyn]

MediaInfo sez it's interlaced BFF. It might have been played that way, but SeparateFields sez it's progressive (OK, I shoulda tried that first instead of taking MediaInfo's word for it). In that case, skip the QTGMC.

If the O.P. wants SD BluRay or DVD, it will play smoother if encoded interlaced. If he just wants to play it on a PC, leave it progressive. Thanks for checking that.

I got cleaner results with QTGMC, probably because QTGMC cleaned up some of the shimmer on highlight edges. It also looked cleaner after using Rotate() to straighten the horizon. Otherwise, there's some annoying "sparkle" from the sun and waves, the kind of stuff often seen on interlaced analog source.

[2Bdecided]

If it's progressive, why on earth would you encode it interlaced for DVD? Not that it really matters either way (apart from slight chroma degradation, and potentially reduced encoder efficiency if you use interlaced) - but there's no advantage to encoding interlaced is there?

I, and Hollywood, often encode 25fps progressive for "PAL" DVD. I doubt 29.97fps progressive is very common for "NTSC" DVD, but is it really inferior when the source is progressive?


Cheers,
David.

[jagabo]

NTSC DV is always flagged interlaced, even if the frames are progressive.

[sanlyn]

The avi looks kinda soft for DV source. I'm betting the source was interlaced.

I have about 350 retail NTSC DVD's. Over the years I've watched every one of them, on a PC, a TV, and often on both. They are all either interlaced or progressive/pulldown. If I start with interlaced or progressive/telecine source for VHS transfer and restoration, I encode it the same way it was encoded as source. It plays smoother that way on old and new set top players IMO.

I erred in taking MediaInfo at face value when I should have checked for myself. My bad.

[2Bdecided]

If I start with interlaced or progressive/telecine source for VHS transfer and restoration, I encode it the same way it was encoded as source. It plays smoother that way on old and new set top players IMO.

This is the bit I don't get. I'm not trying to be an arse, I'm just trying to understand it.

Progressive content can be 23.98, 25, or 29.97 fps. 23.98 needs pulldown flags on DVD, 25 and 29.97 can be encoded as-is on "PAL" and "NTSC" DVDs respectively. In all cases, the frames are stored as progressive.


For 25 and 29.97fps content, encoding it as interlaced rather than progressive means the chroma may be treated slightly differently, and certain DCT grouping and quantisation decisions may be made differently (in both case, differently = worse). I can't see anything that would make the motion smoother. The player will still output the same video, just at fractionally lower quality, won't it?


For 23.98fps content, encoding hard telecined / "interlaced" fields/frames rather than progressive frames causes a radical drop in encoding efficiency and/or quality. However, I can't see anything that would make the motion smoother. Again, the play will still output the same video, just at a lower quality, won't it?


BluRay doesn't support 25p or 29.97p, so for BluRay such streams must always be encoded as interlaced, or 1280x720p50 or 1280x720p59.94 with appropriate scaling and frame repetition.


What player, connection and TV are you using Sanlyn?


Cheers,
David.

P.S. If I have a 25p-in-50i source (some DVDs, all films on VHS), I'll get it back to 25p and work with it that way. Various plug-ins fix any minor interlacing-like artefacts as a side effect (e.g. degraining). QTGMC is useful if things are very bad. I can't see the point in keeping it interlaced - working with 25p as interlaced can introduce a huge quality hit even before you've left AVIsynth.

[manono]

Again, the play will still output the same video, just at a lower quality, won't it?

That depends partly on the player. A flag-reading player has to deinterlace, as that's the way it was encoded. The vast majority of players are flag readers and, yes, the quality will be lower than had the movie been encoded as progressive 23.976fps with 3:2 pulldown. A cadence-reader, on the other hand, can perform an on-the-fly IVTC to return the original progressive frames. The quality might still be lower, though, as compared to doing it right in the first place, because interlaced encoding of hard telecined 29.97fps material where 40% of the frames are interlaced just isn't very efficient.

Like you, I guess, I'm not entirely sure what sanlyn was getting at with the statement you quoted.

I don't much care about the progressive 25fps and 29.97fps. They're both almost always encoded as interlaced on retail DVDs. Progressive 29.97fps content is pretty rare, though.

[sanlyn]

I'm the first to admit I misread the MediaInfo data and made assumptions I shouldn't have made. But the results were better with QTGMC, likely because it did some cleanup and tweaks (which of course could have been done in other ways). The O.P. hasn't told us whether the avi sample has been processed in some way or if it really is a straight cut from the original capture. If this is the original, it's a bad exposure with burned-out detail in the bright sunset.

[_Al_]

After poisondeathray mentioning about video being really progressive,.., I have no idea what brassplayer actually is going to do with that footage, is he aware o that?, perhaps not, was it processed before ?, is he going to interpret footage to progressive in Vegas or not?, after that adjust interlace or progressive in NeatVideo settings also, ..., what is the outcome, BD?, or is it that upscale for BD to 720, because in the past it was his topic, ? , To double frame rate, because QTGMC seams to do some clean up, or just regular interlace? ... so might just use deflick but has he some deflick plugin for Vegas?, because to do it outside within script just before encoding he might fix all his video that way, maybe other clips do not need fixing etc ....

too many variables here, his input would be needed what are actually his intentions

[sanlyn]

too many variables here, his input would be needed what are actually his intentions

No one knows. Akin to a ship passing in the dark. You seldom know if he's been helped or not. In this case it was just an experiment with a short clip to check possible interpretations. Other than that, it's anyone's guess.