Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
29th November 2004, 07:51 | #41 | Link |
Registered User
Join Date: Jan 2002
Location: France
Posts: 2,856
|
http://manao4.free.fr/MVTools-v0.9.8.4.zip
I also added a 'mode' parameter to Corrector, which, if set to 1, change the behavior of Corrector from making the mean to choosing the closest, as asked by scharfi here. The chroma ME isn't tested thoroughly, but it worked ok on the samples I tried. There's no way to disable it yet ( hence, experimental build ) |
19th January 2005, 20:41 | #42 | Link |
Registered User
Join Date: Jan 2002
Location: France
Posts: 2,856
|
http://manao4.free.fr/MVTools-v0.9.9.zip
New release, here is the changelog : Code:
* Filter added : Corrector * Filter added : MVIncrease * New available blocksize : 16 * New parameter in MVAnalyse : chroma * Changes in the core |
20th January 2005, 15:11 | #43 | Link |
brainless
Join Date: Mar 2003
Location: Germany
Posts: 3,653
|
AVISynth rejects mvtools 0.9.9 .
It says: AVISYnth open failure Loadplugin: Unable to load "D:\x\mvtools099.dll" (I always rename mvtools.dll to mvtools0.version.dll) I am using an AthlonXP with WinXP.
__________________
Don't forget the 'c'! Don't PM me for technical support, please. |
20th January 2005, 15:52 | #44 | Link |
interlace this!
Join Date: Jun 2003
Location: i'm in ur transfers, addin noise
Posts: 4,555
|
wow, thanks for the update
[edit] i seem to need stlport_vc7146.dll
__________________
sucking the life out of your videos since 2004 Last edited by Mug Funky; 20th January 2005 at 15:54. |
20th January 2005, 19:15 | #45 | Link |
Registered User
Join Date: Jan 2002
Location: France
Posts: 2,856
|
To those who succeed / fail to use the version 0.9.9 : do you have WinXP SP 2 ?
Edit : I just saw Mug Funky's edit : I'll correct that tonight, it shouldn't be necessary. Last edited by Manao; 20th January 2005 at 19:18. |
20th January 2005, 22:04 | #46 | Link |
Registered User
Join Date: Jan 2002
Location: France
Posts: 2,856
|
Corrected : http://manao4.free.fr/MVTools-v0.9.9.1.zip
|
21st January 2005, 04:46 | #47 | Link |
interlace this!
Join Date: Jun 2003
Location: i'm in ur transfers, addin noise
Posts: 4,555
|
cool. it works now.
[edit] just a bit of warning: i got an access violation on frame 32 while playing back in VDM, using blksize=16. couldn't make it happen again though. possibly a problem at my end, but these kinds of problems tend to make long encodes unreliable. if there's nothing immediately wrong, then just put it down to my 5 year old computer
__________________
sucking the life out of your videos since 2004 Last edited by Mug Funky; 21st January 2005 at 04:53. |
21st January 2005, 06:38 | #48 | Link |
Registered User
Join Date: Jan 2002
Location: France
Posts: 2,856
|
I made the mvtools run 24 hours straight with a complicated script and i didn't get any access violations These are very hard to found & reproduce.
However, blksize = 16 is largely untested, so I'll check here and there to see if I didn't left any obvious wrong code. |
21st January 2005, 16:07 | #49 | Link |
brainless
Join Date: Mar 2003
Location: Germany
Posts: 3,653
|
manao, could you take a look into corrector?
especially for copy&paste mistakes. somehow the analysis clips are passed through to the output. addtional I would like to request separated thresholds for luma and chroma. also many thanks for the larger blocksize of 16px! it made the motioncompensation more stable in general, but small moving objects and borders aren't as precise as they waere before with blocksise 8 or 4.
__________________
Don't forget the 'c'! Don't PM me for technical support, please. |
27th January 2005, 15:00 | #51 | Link |
Registered User
Join Date: Nov 2003
Posts: 148
|
Hi manao,
i still prefer the 0.98.5 version of your mvtools for mvdenoise. i used both on a 3 hour video and the result of the 0.98.5 version is clearly visible cleaner especially on motion parts. The 0.99.1 version works too, but the result is not as good. script used: LoadPlugin("C:\Programme\AviSynth 2.5\plugins\MVTools_0985.dll") function mvdenoise2(clip) { bw_v2=clip.MVAnalyse(isb=true, blksize=4, lambda=1000, delta=2, pel=2, idx=1) bw_v1=clip.MVAnalyse(isb=true, blksize=4, lambda=1000, delta=1, pel=2, idx=1) fw_v1=clip.MVAnalyse(isb=false, blksize=4, lambda=1000, delta=1, pel=2, idx=1) fw_v2=clip.MVAnalyse(isb=false, blksize=4, lambda=1000, delta=2, pel=2, idx=1) return clip.MVDenoise(bw_v2, bw_v1, fw_v1, fw_v2, thT=10, thSAD=64, thmv=90, thSCD1=64) } ---------- the examples for mvdenoise in your documentation still use 2 x "forward_vectors1" and doesn't use the computed "forward_vectors2" at all. ---------- b.t.w. the following mvdenoise2() function script works imho already better than pixiedust(6..8) (!) --- LoadPlugin("C:\Programme\AviSynth 2.5\plugins\MVTools_0985.dll") function deblock2(vec,clip) { comp=clip.MVCompensate(vec, mode=0).Deblock(quant=16, aOffset=5, bOffset=5) return vec.MVChangeCompensate(comp) } function mvdenoise2(clip) { bw_v2=clip.MVAnalyse(isb=true, blksize=4, lambda=1000, delta=2, pel=2, idx=1).deblock2(clip) bw_v1=clip.MVAnalyse(isb=true, blksize=4, lambda=1000, delta=1, pel=2, idx=1).deblock2(clip) fw_v1=clip.MVAnalyse(isb=false, blksize=4, lambda=1000, delta=1, pel=2, idx=1).deblock2(clip) fw_v2=clip.MVAnalyse(isb=false, blksize=4, lambda=1000, delta=2, pel=2, idx=1).deblock2(clip) return clip.MVDenoise(bw_v2, bw_v1, fw_v1, fw_v2, thT=16, thSAD=100, thmv=90, thSCD1=72) } --- maybe we still need some kind of adaptive thresholding and your mvdenoise is clearly the best avisynth filter at all... ! many thanks for your great work! greetings. Last edited by Heini011; 27th January 2005 at 15:11. |
29th January 2005, 16:02 | #52 | Link |
Registered User
Join Date: Nov 2003
Posts: 148
|
Hi!
@manao, please test the script above with noisy film-material just after a scenechange. it seems, that mvdenoise from movtools 0.99.1 doesn't use all off the referenced frames. (maybe only the first ??) greetings. |
1st February 2005, 12:52 | #53 | Link |
Registered User
Join Date: Oct 2003
Location: Germany
Posts: 377
|
I have a problem, that MVTool can not find the right motion. Still in "no-motion" it shows me results like this (this is extremly):
This is Frame 8003 of the movie. I will show you the real Frames before and after: Frame 8002: Frame 8003: Frame 8004: here the script, which i used for showing the vectors: Code:
source=last vectors = source.MVAnalyse(isb = false, pel=2, blksize=4) return source.MVShow(vectors) A new thing i tried help: Code:
source=FineEdge(5).Levels(20,1,80,0,255,false).inflate v1=source.MVAnalyse(isb = false, pel=2, blksize=4) 1. What can i make that MVTools give me the right results. 2. Why MVDenoise use source (in the second example) to denoise, when i call him with an other movie (not source)? Should it not only use the vectors, which were given by source und MVAnalyse? If you want i can give you a little example of the movie, for testing... |
1st February 2005, 13:17 | #54 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
You did use 2 sets of vector clips? The other filters have to be provided with backward *and* forward vector clips (iirc - didn't touch that stuff for a while. Alas.)
Please post the complete related parts of the script. All generated vector clips, and the calls where they get used.
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
1st February 2005, 13:43 | #55 | Link |
Registered User
Join Date: Oct 2003
Location: Germany
Posts: 377
|
I guess you mean this script:
Code:
source=last vectors = source.MVAnalyse(isb = false, pel=2, blksize=4) return source.MVShow(vectors) Code:
vectors = source.MVAnalyse(isb = false, pel=2, blksize=4) vectors = source.MVAnalyse(isb = true, pel=2, blksize=4) vectors = source.MVAnalyse(isb = false, pel=2, blksize=16) vectors = source.MVAnalyse(isb = false, pel=2, blksize=4, lambda=1000) vectors = source.MVAnalyse(isb = false, pel=2, blksize=4, lambda=40000) vectors = source.MVAnalyse(isb = false, pel=2, blksize=4, lambda=1000, delta=2) vectors = source.MVAnalyse(isb = false, pel=2, blksize=4, lambda=1000, delta=4) The problem of this movie is, that it has "part-flickering". This means, that there are parts in every frame, which go in every frame. I you look at the frame 8002 above you can see that dark area. And so it goes the hole movie... This is, i gues the problem. I put in 2 hours a sample-movie for testing... I must away |
1st February 2005, 13:49 | #56 | Link |
Registered User
Join Date: Jan 2002
Location: France
Posts: 2,856
|
krieger2005 : The sky changed a lot between frames 8002 and 8003. That explains why the vectors are so chaotic. There's nothing you can do about it ( there could be a way, but it would be slow, so no way ( yet ? ) )
MVDenoise not only uses the vectors, but also the motion compensation stored with the vectors. This is done in order to improve the speed ( motion compensation could be computed in MVDenoise, but the data is already in the cache when the vector is computed in MVAnalyse, so it's computed there ). You can change the motion compensation using MVChangeCompensate. You can't (yet) apply vectors to source to create a new compensation, but the code to do that is already written, so it will be available in the next release. However, there again, it will be slow heini011 : sorry to have taken so much time to answer. I haven't yet tested your script. However, IIRC, I changed the way the relative strength of the thresholds between 0.985 and 0.991 ( i tried to make the parameters less dependant of the blocksize ). That should explain the differences between 0.985 and 0.991 ( because the denoising is exactly the same ) The filter doesn't take into account frames that are in the other side of what is detected as a scene change. That behavior is expected, and wanted. The filter often detects very noisy frames as scene change, so if you're handling noisy material, raise the SCD thresholds ( and prevent artifacts with thSAD / thMV / thT ). The example in the documentation is wrong, indeed, it will be corrected. Finally, i would recommend not to use blocksize = 4, because it slower and imho less efficient than blocksize = 8 or 16 ( vectors are too sensitive to the noise ). Edit : krieger, i just saw your post : indeed, the vectors are wrong because of the flickering. Either deflick the clip, or don't plan to flicking areas. Anyway, there are enough thresholds in MVDenoise to prevent artifacts from appearing in such areas, so even if the vectors look like s**t, you can safely use the filter. And finally, event if it try to denoise, it will compensate for the mean luma variation it observed. I'll finally implement a flickering safe motion estimation, it won't be that hard. Last edited by Manao; 1st February 2005 at 13:53. |
1st February 2005, 16:53 | #57 | Link | |
Registered User
Join Date: Oct 2003
Location: Germany
Posts: 377
|
You are right. The sky changed very hard but i used to get the vectors for "source" something like that:
Code:
source=temporalsoften(3,25,25,10,2) vectors = source.MVAnalyse(isb = false, pel=2, blksize=4) return source.MVShow(vectors) PS: Does someone hear about this (hs-art restoration tool for standard PC)? I want know how good it is... Quote:
PS: The deflicker-plugin of Fizick the antiflicker of "Sorry, does not find your name" can't repair this flicker, because it is local and not global, this means it is only on parts of frames and not on the hole frame. These filters make the frames only darker or lighter but this does not help... Last edited by krieger2005; 1st February 2005 at 22:40. |
|
9th February 2005, 16:51 | #59 | Link |
brainless
Join Date: Mar 2003
Location: Germany
Posts: 3,653
|
Hello Manao.
When you (hopefully) bring back mvconvertfps and mvinterpolate to us, would it be possible to include some error checking into the internal compensation routines to avoid motion artifacts? (cross checking of back- and forwards compensated frames to their originals) All detected areas should then replaced with simple blending instead of the wrong motion-blocks. That's the way, the commercial mv-enabled converters seem to work! Hard to estimate areas (clapping/shaking hands etc.) are blended, while pans and large moving objects are motion compensated.
__________________
Don't forget the 'c'! Don't PM me for technical support, please. |
10th February 2005, 22:56 | #60 | Link |
Retired AviSynth Dev ;)
Join Date: Nov 2001
Location: Dark Side of the Moon
Posts: 3,480
|
I just love this filtercollection. I'd like to find the time and put in an improved MVConvertFPS. My main issues are soft block appliance and a blended frame scbehaviour and border mv-interpolation/guessing.
__________________
Regards, sh0dan // VoxPod |
Thread Tools | Search this Thread |
Display Modes | |
|
|