View Full Version : Removing low-light noise/grain from DV
nhope
30th June 2011, 21:10
I have quite a lot of underwater footage shot in low light with my Sony VX2000 3-CD DV camera with a lot of gain and so lots of noise/grain.
Here is a typical sample DV .avi file (http://www.mediafire.com/?bqcc8wyc991km5m).
Any suggestions for dealing with this? I tried a few things such as MCTemporalDenoise(settings="medium", interlaced=true) and the result was promising but I'm wondering if I'm on the wrong track, or if this degree of noise is a bit of a lost cause.
poisondeathray
30th June 2011, 21:16
I think zip file is corrupt , CRC errors. And there is no recovery record
johnmeyer
30th June 2011, 22:50
Yup, zip is corrupt.
nhope
1st July 2011, 05:23
Really sorry about that. I've posted the .avi file without zipping and the link in the first post now works.
Taurus
1st July 2011, 18:25
@nhope:
:pHeavy fights need heavy guns :p
In a ten minutes exercise in degraining.
Temporaldegrain was the winner...
Here is the simple sample script:
avisource("LIBbatfish-orbicular1a.avi")
tweak(sat=1.25)
temporaldegrain()
LSFMod()
Here is a mpeg sample:
http://www.mediafire.com/?cquz8qcf4sppdxv
Sorry, could'nt resist in a little colour tweaking.
Decoder: Cedocida
Encoder: HCEnc
Just a suggestion.
Didée
1st July 2011, 18:32
@Taurus: you forgot that the source is interlaced.
johnmeyer
1st July 2011, 18:52
Nick,
I have had pretty good luck with MDegrain2, using settings right out of the "cookbook."
I played around a little, trying all the block size, overlap, and dct settings. After I tweaked those, I changed the thSAD setting. If you go too high, you begin to get an artifact where the residual noise in the flat shadow areas (under the coral in the bottom center of the video) begins to act coherently, which is really distracting. I often prefer a little residual noise, as long as it looks "natural," if that description makes any sense.
I also tried to do some things with fft3Dfilter, both on its own, and within a motion compensated setting. I played around with the separate sigma settings, but never could get anything that looked good. I also tried to use it as a post filter.
Here is a link to the result:
Desnoised Fish (http://dl.dropbox.com/u/1561578/LIBbatfish-orbicular1a%20%28Denoised%20by%20johnmeyer%29.avi)
I rather like the way the script maintained the details on the dorsel fin of the fish in the foreground.
I thought the result looked a little soft. Rather than sharpen in AVISynth, I put it in Vegas and used the Unsharp Mask fX with an Amount of 0.2 and a radius of 0.02.
And here is the script I used. This is pretty much straight from the documentation, except for my choices of block size, overlap, and thSAD. If I were a masking guru, like Didée, I would be tempted to try to figure out a way to apply heavier denoising in the shadows, especially if I could only apply the mask to shadows that are large, and mostly "flat" (without much high frequency detail).
#Denoiser script for interlaced video using MDegrain3
#July 1, 2011
loadPlugin("c:\Program Files\AviSynth 2.5\plugins\fft3dfilter.dll")
Loadplugin("C:\Program Files\AviSynth 2.5\plugins\MVTools\mvtools2.dll")
SetMTMode(5,0)
#Modify this line to point to your video file
source=AVISource("E:\frameserver.avi").killaudio().AssumeBFF()
SetMTMode(2)
denoised=MDegrain2i2(source,8,2,0)
#Possible post-filtering and sharpening
#denoised=fft3dfilter(denoised, sigma=1, sigma2=1, sigma3=1, sigma4=1, sharpen=0, interlaced=true)
#stackhorizontal(source,denoised)
return denoised
#-------------------------------
function MDegrain2i2(clip source, int "blksize", int "overlap", int "dct")
{
overlap=default(overlap,0) # overlap value (0 to 4 for blksize=8)
dct=default(dct,0) # use dct=1 for clip with light flicker
fields=source.SeparateFields() # separate by fields
super = fields.MSuper(pel=2, sharp=1)
backward_vec2 = super.MAnalyse(isb = true, delta = 2, blksize=blksize, overlap=overlap, dct=dct)
forward_vec2 = super.MAnalyse(isb = false, delta = 2, blksize=blksize, overlap=overlap, dct=dct)
backward_vec4 = super.MAnalyse(isb = true, delta = 4, blksize=blksize, overlap=overlap, dct=dct)
forward_vec4 = super.MAnalyse(isb = false, delta = 4, blksize=blksize, overlap=overlap, dct=dct)
# MDegrain2(fields,super, backward_vec2,forward_vec2,backward_vec4,forward_vec4,thSAD=400)
# Eliminate next three lines and uncomment above line to use MDegrain2 instead of MDegrain3
backward_vec6 = super.MAnalyse(isb = true, delta = 6, blksize=blksize, overlap=overlap, dct=dct)
forward_vec6 = super.MAnalyse(isb = false, delta = 6, blksize=blksize, overlap=overlap, dct=dct)
# Added thSCD1=550 parameter after posts below pointed out script doesn't work when reading video file directly (I was frameserving)
MDegrain3(fields,super, backward_vec2,forward_vec2,backward_vec4,forward_vec4,backward_vec6,forward_vec6,thSCD1=550, thSAD=600)
Weave()
}
Taurus
1st July 2011, 19:30
@Taurus: you forgot that the source is interlaced.
Da..it, I always forget to think about it :mad::p
Didée
1st July 2011, 20:25
@johnmeyer
Something can not be right. The script you posted does ZERO denoising on this clip. You must've used another script, or vastly different settings.
(The noise triggers MVTools' scenechange reckognition, and consequentially MDegrain does *nothing*at*all*.)
johnmeyer
1st July 2011, 20:39
@johnmeyer
Something can not be right. The script you posted does ZERO denoising on this clip. You must've used another script, or vastly different settings.Well that is disturbing ...
To "check my work," I just copied the text from the code section of my post above, put it in Notepad and saved it, and then opened the result in VirtualDub. The script is most definitely working on my computer.
I looked at the MVTools2.dll and got this version info: 2.5.11.2. It is dated March 20, 2011. I made a version call and got "AviSynth 2.60, build: Aug 13 2009 [15:07:40] (c) 2000-2007 Ben Rudiak-Gould, et al."
Those are the only two dependencies I can think of that would be different between your computer and mine.
johnmeyer
1st July 2011, 20:52
I just did a little more work on this, and explicitly included both the thSCD1 and thSCD2 parameters. The default for thSCD1 is 400. I experimented and found that around 300, the denoising stopped, as it apparently is doing on your computer.
I then looked at the MVTools2 documentation and found this under the change log for version 1.4.1:
"Chanded thSCD1 default from 300 to 400."
So, if you are using a really old version of MVTools2, that would explain it, or if you have some set of defaults stored somewhere in order to maintain consistency with the older version, that would also explain it.
As far as the OP is concerned, it might make sense to include this parameter and raise its value to 500.
Taurus
1st July 2011, 21:11
@johnmeyer
Something can not be right. The script you posted does ZERO denoising on this clip. You must've used another script, or vastly different settings.
(The noise triggers MVTools' scenechange reckognition, and consequentially MDegrain does *nothing*at*all*.)
I can confirm Didée's error observation.
There is no call for a denoiser.
Tested with mvtools2/2.5.11.2
Didée
1st July 2011, 21:17
@johnmeyer: No. I am using exactly that version of MVTools2, and of Avisynth 2.6 too. "Change of Defaults" would require a re-compiling of the plugin. Which I surely did not do.
And when I run *literally* your original script, then the final difference between "source" and "denoised" is absolutely zero. The difference screen is flat 128.
I rather assume you applied some pre-denoising before using that script. This would explain that the MDegrain worked (because the predenoise made the SADs in MVTools small enough). And it would explain why you used post-sharpening (because the predenoise did some blurring, which would not be the case [or only very little] with only MDegrain.)
johnmeyer
1st July 2011, 21:39
Well, this is curious.
You said "I rather assume you applied some pre-denoising before using that script." I didn't do anything like that, but I did frameserve the footage out of Sony Vegas and into the AVISynth script rather than reading the AVI file itself. So, just to make sure I was doing the same thing you were doing, I instead opened the OP's original file directly in AVISynth.
This time I got the same result as you.
I am totally clueless as to why this is happening. The frameserver doesn't alter the video in any way: I can do an A/B comparison with video frameserved into AVISynth scripts and then rendered or served back into Vegas, and they always look identical (in terms of resolution, levels, sharpness, and color). There is definitely no filtering of any kind going on.
It is a mystery.
As for helping the OP, I found that the threshold for thSCD1 when reading the file directly was somewhere around 450. So, if you add this parameter and set it to something between 500 and 550, I think the script should work. I have edited the script in my post above to add this parameter, and have noted in that post that I made the alteration.
nhope
1st July 2011, 21:49
Thanks folks.
@Taurus: you forgot that the source is interlaced.
How should such a script be modified for interlaced source?
Actually all my projects with PAL interlaced source are going to get bobbed with QTGMC. DVD projects will then be re-timed to 60p, downscaled to 640x480, then reinterlaced. YouTube projects will be upscaled (with pillarboxing) to 1280x720. So perhaps denoising of noisy clips could be done further down the chain? Or better to do it straight away on the interlaced PAL footage?
johnmeyer
1st July 2011, 22:06
How should such a script be modified for interlaced source?You've spent a lot of time on this with your re-sizing "quests," so you probably know most of the answers, and many of the issues. The method you choose to use depends a lot on the nature of the functions your script runs.
I grabbed the following code from somewhere in this forum (from years ago). It is a quick & dirty way to make many functions, which were originally designed only for progressive footage, work well for interlaced footage, without having to do a lot of new coding:
function ApplyInterlacedFilter(clip v1, string filter)
{
v2 = separatefields(v1)
selecteven(v2)
even = Eval(filter)
selectodd(v2)
odd = Eval(filter)
interleave(even,odd)
return weave()
}
I used this earlier today when I was trying out various approaches to your noise problem. Here is one script that I used. It was based on code I got from somewhere else, and didn't want to re-write. This shows how the above function can be used.
source=AVISource("E:\frameserver.avi")
ApplyInterlacedFilter(source, "MotionCompDenoise")
function ApplyInterlacedFilter(clip v1, string filter)
{
v2 = separatefields(v1)
selecteven(v2)
even = Eval(filter)
selectodd(v2)
odd = Eval(filter)
interleave(even,odd)
return weave()
}
function MotionCompDenoise(clip thisclip)
{
super = MSuper(thisclip)
backward_vectors = MAnalyse(super, isb = true)
forward_vectors = MAnalyse(super, isb = false)
forward_compensation = MFlow(thisclip, super, forward_vectors, thSCD1=400) # or use MCompensate
backward_compensation = MFlow(thisclip, super, backward_vectors, thSCD1=400)
interleave(forward_compensation, thisclip, backward_compensation)
fft3dfilter(sigma=2, sigma2=10, sigma3=15, sigma4=8)
selectevery(3,1) # return filtered central (not-compensated) frames only
}
As for when to do denoising, I always do it before everything else, because just about any operation on noisy video is not going to do good things to it.
nhope
1st July 2011, 22:06
...The frameserver doesn't alter the video in any way...
The DV clip is YUV. Vegas converts to RGB, which it uses internally. Then the Frameserver converts to YUY2 (assuming you have it set to that, and not RGB; I assume so as there is no conversion to YUV going on in your script). So there are a couple of conversions going on there.
johnmeyer
1st July 2011, 22:38
Yeah, I didn't want to burden this thread with all of that. It is surprising, since the levels aren't detectably changing that it would make that much difference.
Did you download the PAL DV AVI file that I posted which shows the result? Did you like it, or did you find it lacking? I'm always open to suggestions or criticisms (I guess that's why I post here :) )
TheSkiller
1st July 2011, 22:44
YouTube projects will be upscaled (with pillarboxing) to 1280x720.Pillarboxing to 1280 width is not necessary for YouTube. You should simply omit the pillarbox which leaves you with 960x720 in case of 4:3 video. YouTube will perfectly accept this as 720p HD like it does with 1280x720 video. Now you might say it doesn't really matter, well, if you pillarbox 4:3 content for YouTube then it'll make the video appear in a small window in fullscreen mode on non-16:9 displays, in other words windowboxing on all non-16:9 displays in fullscreen mode, not nice at all.
Just curious, why would you convert the framerate of a PAL source to 60p instead of leaving at 50p or reinterlacing it back to 25i (50i as some would say).
Edit: @johnmeyer I had a look at the source and your filtering. Honestly, but that's just me, I found it to be slightly overfiltered/blurry. I would rather leave some more faint grain as it is giving the illusion of detail. The stones in the background have noticeably lost their sharpness.
johnmeyer
1st July 2011, 22:59
@johnmeyer I had a look at the source and your filtering. Honestly, but that's just me, I found it to be slightly overfiltered/blurry. I would rather leave some more faint grain as it is giving the illusion of detail. The stones in the background have noticeably lost their sharpness.{sigh} ... yes, looking at it now, I think you are probably correct, although as I noted in my original post, I did sharpen the result later, in Vegas. The result I posted was the result of the AVISynth script, before the sharpening in Vegas.
Thinking back to this morning, I think the reason I dulled it that much is that when I used a less aggressive de-noising setting which retained more detail, the noise looked less "normal." What I mean by this is that noise, while annoying, is something that you sort of get used to, but only if it is uniform and invariant over both space and time. However, when it comes and goes, or "clumps" and then un-clumps, or does something else to call attention to itself by not being uniform, then the de-noised version is sometimes worse than the original.
nhope
2nd July 2011, 14:37
Pillarboxing to 1280 width is not necessary for YouTube. You should simply omit the pillarbox which leaves you with 960x720 in case of 4:3 video. YouTube will perfectly accept this as 720p HD like it does with 1280x720 video.
TheSkiller, that is a brilliant tip! Thank you very much. If you hadn't told me that I would have blindly uploaded all my 4:3 videos with unnecessary pillarboxing to 16:9 which I had thought would be necessary for "fake HD".
Just curious, why would you convert the framerate of a PAL source to 60p instead of leaving at 50p or reinterlacing it back to 25i (50i as some would say).
So I can offer just one version of my DVDs. Been offering PAL and NTSC for years. The original footage is PAL, which won't play correctly worldwide. But now, thanks to QTGMC and MVtools enabling a quantum leap in the quality of PAL=>NTSC, I'm going to start just offering NTSC.
Did you download the PAL DV AVI file that I posted which shows the result? Did you like it, or did you find it lacking?
I tend to agree with TheSkiller, I also found it a bit overfiltered. Same for taurus' contribution. This will be in a project with some clips that are less noisy, that I will allow to pass without denoising, so it needs to roughly match with those.
As soon as I turned off my computer last night, it struck me that I should be using QTGMC's in-built options to do this, concurrently with deinterlacing, since all my future videos are going to go through QTGMC prior to DVD or YouTube delivery. The following script is a pretty good start (it includes the conversion to 720x480-60p that I'm going to use for assembling processed footage on my timeline prior to reinterlacing and MPEG2 encoding):
#720x576 interlaced PAL source
QTGMC( Preset="Slower", EZDenoise=20.0, NoisePreset="Slow", SubPel=2 )
super = MSuper(levels=1, pel=2)
MFlowFps(super, QTGMC_bVec1, QTGMC_fVec1, num=60000, den=1001)
Spline36Resize(720,480)
Incidentally I am aware that the red level in that clip is too high, which was due to my manual white balancing technique at the time.
Didée
2nd July 2011, 14:48
Played a little with this, too. While at it, it struck me that the detail level of this sequence can be noticeably enhanced. However, I didn't manage to fully avoid the "static grain" phenomena that arises due to the enhancement.
Sample (http://www.mediafire.com/?bu7u9q5g1bb7dip) (MediaFire, ~17MB]
Granted, it's a bit overdone. But shows quite some potential, doesn't it ...
nhope
2nd July 2011, 18:47
...Granted, it's a bit overdone. But shows quite some potential, doesn't it ...
Impressed by the lack of noise, especially in the dark triangular shadow under/behind the fish. But there's too much sharpening/contrast for my liking. How did you do it?
Here's my effort (http://www.mediafire.com/?iuk5tqs9m5da3n6) with milder denoising using the script at the bottom of my last post (convert to 720x576-60p with EZDenoise=20.0), then rendered in MeGUI.
johnmeyer
2nd July 2011, 21:27
It is clear that everyone here prefers video that has a little more contrast and sharpening, and therefore a little more "snap." Since this forum has a rule about not asking for, or discussing, what is "best," I will avoid any opinion about what I think is better or appropriate. Indeed, when it comes to any form of restoration, not only is there no single way to do things, and peoples' opinions of the result are not going to converge around any single result.
With that disclaimer, I thought I would try one more time to make my initial attempt come closer to what I now understand people here are looking for, namely something that has more "snap." Since the result I uploaded in my earlier post merely had noise reduction applied, without any post-processing sharpening, I thought I should upload the results of applying, in Sony Vegas, a fairly aggressive unsharp mask (amount=0.374, radius-0.028) to that clip I uploaded before. Here is a link to that result:
Denoised and sharpened (http://dl.dropbox.com/u/1561578/LIBbatfish-orbicular1a%20%28Denoised%20by%20johnmeyer%2C%20with%20unsharp%20mask%29.avi)
I spent a lot of time (well, a minute or two) doing A/B tests, between the original and the de-noised clip, both with and without the sharpening. I see no loss of detail, even without the sharpening. However, the increased contrast provided by the sharpening is undeniably more pleasing.
Finally, one thing I should mention is that, IMHO, noise can sometimes impart the illusion of sharpness and detail that actually isn't there. Therefore, when you remove that noise, there is a tendency to want to "add" back the loss of apparent detail. However, as I did my A/B tests before I added sharpening, looking at various reference points -- especially those that are relatively stationary, like the coral -- I did not discern any reduction in the ability to resolve anything.
I only mention this because I have so often found -- in my ten years of restoring audio, photos, movie film, and video -- that I initially really like the results of using some tool to "improve" something, but that when I look at it again some weeks later, I found that I over-did the corrections.
poisondeathray
2nd July 2011, 21:49
jonhmeyer - maybe I downloaded a corrupt version, but does your video have a strange artifact on the lower border ? almost as if those pixels weren't processed ?
didee - how did you do this enhancement of details? would you mind sharing ?
nhope
2nd July 2011, 21:55
@johnmeyer - That method has left a band of noise along the bottom and right edges. Don't know if you'd noticed that. The sharpening is what made me notice it.
edit: lol, poisondeathray got there first
johnmeyer
2nd July 2011, 22:54
Nice catch, both of you. I had my preview window blown up large so I could see details and noise, but that cropped the edges of the preview window, so I didn't see the problem.
It turns out to be a minor glitch in MVTools2. I was using a block size of 8 with an overlap of 2. Using any other overlap eliminated the problem. Since the clip is short, I changed it to an overlap of 4, and the problem goes away. Here's a link to the video without the problem:
Denoised and Sharpened (revised with overlap=4) (http://dl.dropbox.com/u/1561578/LIBbatfish-orbicular1a%20%28Denoised%20by%20johnmeyer%2C%20with%20unsharp%20mask%29_rev2.avi)
I prefer this result to some of the other posted results simply because the residual noise is smaller diameter and not so "clumpy." Also, there is less of what I call the "screen door" effect, where it looks like you are viewing the video through a window or door screen. I still don't like the results in the shadows under the coral, and would love to get a hint as to how I could create a mask so I could apply more aggressive settings to that area.
Here's the revised script, including the scene detection parameter to keep MVTools from detecting noise as a scene change:
#Denoiser script for interlaced video using MDegrain3
#July 1, 2011
loadPlugin("c:\Program Files\AviSynth 2.5\plugins\fft3dfilter.dll")
Loadplugin("C:\Program Files\AviSynth 2.5\plugins\MVTools\mvtools2.dll")
SetMTMode(5,0)
#Modify this line to point to your video file
source=AVISource("E:\Documents\Dnload\UNPACK\LIBbatfish-orbicular1a.avi").killaudio().AssumeBFF()
SetMTMode(2)
denoised=MDegrain2i2(source,8,4,0)
return denoised
#-------------------------------
function MDegrain2i2(clip source, int "blksize", int "overlap", int "dct")
{
overlap=default(overlap,0) # overlap value (0 to 4 for blksize=8)
dct=default(dct,0) # use dct=1 for clip with light flicker
fields=source.SeparateFields() # separate by fields
super = fields.MSuper(pel=2, sharp=1)
backward_vec2 = super.MAnalyse(isb = true, delta = 2, blksize=blksize, overlap=overlap, dct=dct)
forward_vec2 = super.MAnalyse(isb = false, delta = 2, blksize=blksize, overlap=overlap, dct=dct)
backward_vec4 = super.MAnalyse(isb = true, delta = 4, blksize=blksize, overlap=overlap, dct=dct)
forward_vec4 = super.MAnalyse(isb = false, delta = 4, blksize=blksize, overlap=overlap, dct=dct)
# MDegrain2(fields,super, backward_vec2,forward_vec2,backward_vec4,forward_vec4,thSAD=400)
# Eliminate next three lines and uncomment above line to use MDegrain2 instead of MDegrain3
backward_vec6 = super.MAnalyse(isb = true, delta = 6, blksize=blksize, overlap=overlap, dct=dct)
forward_vec6 = super.MAnalyse(isb = false, delta = 6, blksize=blksize, overlap=overlap, dct=dct)
MDegrain3(fields,super, backward_vec2,forward_vec2,backward_vec4,forward_vec4,backward_vec6,forward_vec6,thSCD1=500,thSAD=600)
Weave()
}
poisondeathray
2nd July 2011, 23:12
johnmeyer - by "screen door" effect, you mean the "stuck pixel" effect in didee's video? I personally don't like that effect either . The fine grain random pattern is more natural in your video
Do you think maybe you adjusted levels & contrast too aggressively? some whites are blown, like the white corals(?) on the background rock with loss of detail . Although the contrasty look is overall more appealing IMO
I'm wondering if didee's detail enhancement could be modulated down a few notches, it's too strong for my tastes but I'm curious as to the method used
johnmeyer
2nd July 2011, 23:43
Do you think maybe you adjusted levels & contrast too aggressively? some whites are blown, like the white corals(?) on the background rock with loss of detail . Although the contrasty look is overall more appealing IMO.I was just getting ready to shut down and, before I read your post, noticed that on the middle fish, all the detail above the eye is blown out.
I need help figuring this one out.
To track it down, I dropped Nick's original PAL DV AVI file onto VirtualDub. The highlights were correct.
I then modified my AVISynth script to simply return the "source" line, and the highlights were blown out. So, the issue has nothing to do with any of the plugins, but simply how AVISynth is handling levels. Put another way: the problem is that when reading the DV AVI file, AVISynth is changing the levels.
I then went ahead and tried several earlier versions of AVISynth (I'm using 2.6) because I've had some color and levels issues with 2.6. However, the earlier versions did the same thing.
I am stumped and a little disturbed by this. Any help would be appreciated. I can't believe I wouldn't have noticed clipped highlights before this.
I tried every Levels setting in the documentation, including the two that are equivalent to ColorYUV(levels="TV->PC")
and ColorYUV(levels="PC->TV"), but none of them got me back to the original.
[edit]This script makes the levels display correctly:
AVISource("N:\temp FUHS\Video\FUHS 2010-0064.avi")
ConvertToRGB()
but any attempt to convert back to YV12 or YUY2 blows out the highlights.
I suddenly feel like a total noob ...
poisondeathray
3rd July 2011, 00:16
Are you using avisynth only? Earlier you mentioned vegas, were you using vegas anywhere for this latest one ? RGB conversion anywhere ?
I assumed you adjusted levels in vegas? There is nothing in the script that should change levels, and the script posted above doesn't change any levels here.
Maybe decoder is outputting different levels ?
What VFW decoder are you using for DV ? and what decoder is vdub using? use file=>file information with the native file open in vdub
What happens if you use a different source filter / decoder ? e.g. FFVideoSource()
johnmeyer
3rd July 2011, 00:28
Problem solved, ...
edit: problem not solved ... pixel_type="RGB32" simply reads the video as RGB32, but any subsequent attempt to convert to YUY2 or YV12 makes it bad again.
Here's the AVISynth documentation that perhaps hints at the problem, but doesn't really give a solution for when the conversion to YUY2 or YV12 is done:
Some MJPEG/DV codecs do not give correct CCIR 601 compliant output when using AVISource. The problem could arise if the input and output colorformat of the codec are different. For example if the input colorformat is YUY2, while the output colorformat is RGB, or vice versa. There are two ways to resolve it:
1) Force the same output as the input colorformat. Thus for example (if the input is RGB):
AVISource("file.avi", pixel_type="RGB32")
2) Correct it with the filter ColorYUV:
AVISource("file.avi").ColorYUV(levels="PC->TV")
poisondeathray
3rd July 2011, 00:32
Problem solved, ...
edit: problem not solved ... pixel_type="RGB32" simply reads the video as RGB32, but any subsequent attempt to convert to YUY2 or YV12 makes it bad again.
That doesn't make any sense, why would you output RGB ?
DV is Y'CbCr, internally 4:1:1 subsampled , and most the filters you are using work in Y'CbCr .
Maybe you should use a different decoder ?
poisondeathray
3rd July 2011, 00:34
Some MJPEG/DV codecs do not give correct CCIR 601 compliant output when using AVISource. The problem could arise if the input and output colorformat of the codec are different. For example if the input colorformat is YUY2, while the output colorformat is RGB, or vice versa. There are two ways to resolve it:
1) Force the same output as the input colorformat. Thus for example (if the input is RGB):
AVISource("file.avi", pixel_type="RGB32")
2) Correct it with the filter ColorYUV:
AVISource("file.avi").ColorYUV(levels="PC->TV")
You can try a decoder that outputs Y'CbCr like cedocida. Input = Output levels. At least you have more control , and if you need to frameserve to other applications you can control colorspace conversions in the script
IIRC, Panasonic's DV decoder was know for problems with levels
johnmeyer
3rd July 2011, 00:39
That doesn't make any sense, why would you output RGB ?
DV is Y'CbCr, internally 4:1:1 subsampled , and most the filters you are using work in Y'CbCr .
Maybe you should use a different decoder ?I was editing my post as you were submitting yours. Sorry about that.
I have tried DirectShowSource, but that didn't do anything differently. Merely reading as RGB32 didn't get me anywhere, because I still have to convert back to YUY2 or YV12 for most of the AVISynth filters to work.
I'm trying to think what I might have set up on my computer, "under the hood" that might be causing this to happen. I really try hard not to have anything exotic or odd installed.
I just tried the same two line script and test DV AVI file on another computer and got the same bad result.
poisondeathray
3rd July 2011, 00:43
AVISource() relies on VFW framework . If you have a DV decoder installed, you can usually identify it with vdub (open the native dv-avi file, and use file=>file information, it will list the decoder) . Vdub relies on VFW framework
If you use:
AVISource()
Info()
It will report the colorspace from the output pin of the decoder
Directshow codecs are rely on different framework than VFW codecs. Directshowsource() uses directshow codecs. You might have a different DV directshow codec, and different VFW codec installed
FFVideoSource() will be independent of system installed filters/codecs, so I would try that, and it's useful for debugging
You can use vcswap to manage your VFW codecs, and graphstudio or radlight filter manager to manage directshow codecs
johnmeyer
3rd July 2011, 00:59
OK, I could have saved lots of forum bits by spending the full hour figuring this out before I posted. Here's the problem:
VirtualDub version 1.9.11.
I installed this at 1:40 p.m. on June 30. I almost never upgrade anything on any computer, but I had a recommendation from someone two days ago that I needed to upgrade VirtualDub. As soon as I remembered that I had done this upgrade, I immediately went to the VD 1.9.11 options and preferences, but nothing I changed fixed the problem (although one clue is that the left hand preview pane has the wrong levels, and the right screen has the correct levels).
So, I grabbed the old VD version from my backups, copied over the files, and all is now well.
I am breathing a BIG sigh of relief because none of my hundreds of past projects were compromised (at least not by this). Even though I didn't pick up on the problem during this little task (I obviously wasn't paying the same attention to this as I do to my own projects -- sorry Nick!), I'm sure I would have discovered it pretty quickly.
I'll upload another, hopefully corrected version, and then provide one more link. It is amazing how many ways I can find to screw things up, although I really don't feel like this one was entirely my fault ...
poisondeathray
3rd July 2011, 01:04
I wonder what caused it then? Nothing should have changed in the background that would cause that. I'm using vdub 1.9.11 too.
I think the newer versions of vdub have directx disabled for preview by default, but that doesn't affect the actual video , only the RGB conversion done for the output preview pane. If you have it enabled, then the graphics card overlay settings will control the preview
johnmeyer
3rd July 2011, 01:27
I wonder what caused it then? Nothing should have changed in the background that would cause that. I'm using vdub 1.9.11 too.I have no clue. All I know is that I rolled back to the previous VD version (1.8.8), and all is now working. I should point out that to get everything just right, I did have to add the ColorYUV(levels="PC->TV") adjustment.
I am finished with this now. It was worth the journey, however, because I fixed a major problem before it hurt my real work, and I found that I need to pay even more attention to levels than I already was doing (and Nick is actually the person who made me much more aware of all the ways levels can get screwed up).
So, one last time ... here's the final version of the swimming fish (from me). They sure look pretty now:
Fish Video (PAL 50i) (http://dl.dropbox.com/u/1561578/LIBbatfish-orbicular1a%20%28Denoised%20by%20johnmeyer%2C%20with%20unsharp%20mask%29_rev3.avi)
And here's the last version of the script, complete with a little revision history that reflects the last ten posts:
# Denoiser script for interlaced video using MDegrain3
# July 2, 2011
# Revision history since 1.0
# Went from MDegrain2 to MDegrain3 because of slightly better denoising
# Added thSCD1=500 because MVTools2 scene detection was being triggered by high noise level
# Changed MDegrain overlap from 2 to 4 because bug in MVTools2 caused border pixels to not be processed.
# Reverted to using VirtualDub 1.8.8 instead of 1.9.11 because of levels problems
# Added PC->TV levels shift to fix DV import levels problem (this is a separate levels problem from the 1.8.8 -> 1.9.11 version issue)
Loadplugin("C:\Program Files\AviSynth 2.5\plugins\MVTools\mvtools2.dll")
SetMTMode(5,0)
#Modify this line to point to your video file
source=AVISource("E:\Documents\Dnload\UNPACK\LIBbatfish-orbicular1a.avi").ColorYUV(levels="PC->TV")
SetMTMode(2)
denoised=MDegrain2i2(source,8,4,0)
return denoised
#return stackhorizontal(source,denoised)
#-------------------------------
# Interlaced version of MDegrain2 (more or less copied from MVTools2 doc)
function MDegrain2i2(clip source, int "blksize", int "overlap", int "dct")
{
overlap=default(overlap,0)
dct=default(dct,0) # use dct=1 for clip with light flicker
fields=source.SeparateFields() # separate by fields
super = fields.MSuper(pel=2, sharp=1)
backward_vec2 = super.MAnalyse(isb = true, delta = 2, blksize=blksize, overlap=overlap, dct=dct)
forward_vec2 = super.MAnalyse(isb = false, delta = 2, blksize=blksize, overlap=overlap, dct=dct)
backward_vec4 = super.MAnalyse(isb = true, delta = 4, blksize=blksize, overlap=overlap, dct=dct)
forward_vec4 = super.MAnalyse(isb = false, delta = 4, blksize=blksize, overlap=overlap, dct=dct)
# MDegrain2(fields,super, backward_vec2,forward_vec2,backward_vec4,forward_vec4,thSAD=400)
# Eliminate next three lines and uncomment above line to use MDegrain2 instead of MDegrain3
backward_vec6 = super.MAnalyse(isb = true, delta = 6, blksize=blksize, overlap=overlap, dct=dct)
forward_vec6 = super.MAnalyse(isb = false, delta = 6, blksize=blksize, overlap=overlap, dct=dct)
MDegrain3(fields,super, backward_vec2,forward_vec2,backward_vec4,forward_vec4,backward_vec6,forward_vec6,thSCD1=500,thSAD=600)
Weave()
}
poisondeathray
3rd July 2011, 01:58
I have no clue. All I know is that I rolled back to the previous VD version (1.8.8), and all is now working. I should point out that to get everything just right, I did have to add the ColorYUV(levels="PC->TV") adjustment.
It's very likely your DV decoder is configured to expand the luminance , if you needed to reduce it with coloryuv .
I think vdub is a red herring. If you applied ColorYUV(levels="PC->TV") to your 2nd video it would look the same as your 3rd. This still looks different than applying the same script (but without ColorYUV), using a decoder that preserves levels.
johnmeyer
3rd July 2011, 02:29
It's very likely your DV decoder is configured to expand the luminance , if you needed to reduce it with coloryuv .
I think vdub is a red herring. If you applied ColorYUV(levels="PC->TV") to your 2nd video it would look the same as your 3rd. This still looks different than applying the same script (but without ColorYUV), using a decoder that preserves levels.I did some testing and apparently, because I have the MainConcept DV codec installed, it is being used by VD to read the PAL DV AVI file. If this turns out to be the problem, I am fortunate because 99% of all my work is done by frameserving out of Vegas rather than reading the DV files directly. This is why I haven't seen this problem before. It was only when Didée had the MVTools2 threshhold problem, and I didn't, that I changed the script to read the file directly, in order to make my workflow match his. That then led to one problem after another, as documented above.
I'll keep trying to fix the problem in the manner you suggest because I think that your analysis is essentially correct.
Here's the MainConcept DV configuration dialog:
http://i177.photobucket.com/albums/w208/johnmeyer/MainConcepDVConfigurationDialog.gif
I don't have time now, but all but two of the decoder settings could have an impact. I did try enabling the 16-235 setting, but by itself, it didn't do anything. I don't have time to go through all the permutations right now.
The fact that not everyone has this codec installed may explain why others may not see this same problem.
So, thanks for your advice and help. I think your instincts are correct. I now just have to figure out how to put them to good use.
nhope
3rd July 2011, 09:00
John, I'm pretty sure the problem must lie in those MainConcept RGB 16..235 settings. I'm not getting a problem here when using that type of script. I don't have the MainConcept DV installed. I'm using DirectShowSource (AviSource won't read the file and I don't have FFVideoSource installed) and I'm not needing to use ColorYUV(levels="PC->TV").
(p.s. Curious what Didée might be cooking up)
johnmeyer
3rd July 2011, 15:37
Yes, all I needed to do was check the RGB 16..235 box in the decode section. As I said, I always put the video into Vegas and then frameserve out of that into AVISynth and open the result in VD. When I get that working, I use VFAPIConv to serve back into a second instance of Vegas. I haven't opened a DV AVI file directly in AVISynth or VC for a long, long time. It was useful, however, to get this fixed. Once upon a time, I'm sure I had it set correctly (on my previous computer).
johnmeyer
4th July 2011, 20:52
Nick and I also post over in the Sony Vegas forum. I started a thread there to get more input on this. Here is a link to that thread:
My Latest Denoising Tests (thanks Nick!) (http://www.sonycreativesoftware.com/forums/ShowMessage.asp?MessageID=768850&Replies=10)
As a result of the feedback I got there, I eventually came up with this result:
MDegrain3, LimitedSharpenFaster, Sony Vegas Color Curves (http://dl.dropbox.com/u/1561578/LIBbatfish-orbicular1a%20%28Denoised%20by%20johnmeyer%2C%20with%20limited%20sharpenfaster%2C%20interlaced%2C%20strength%3D500%2C%20color%20curves%29_rev6.avi)
This is the result of using MDegrain3, exactly as I already posted here, but then taking that result and using LimitedSharpenFaster with an aggressive strength of 500. Since this is interlaced video, I did a separatefields() - filter -weave(). I then took that result and used the "Color Curves" filter in Vegas to slightly darken the shadows. I did this because I realize that when you denoise, the result is some sort of average of the noise and the real scene. Thus, if you have noise on top of a pure black shadow, the averaged result is not going to be black. I suppose that a similar statement could be made about highlights, but the sharpening seems to handle that on its own.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.