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 June 2005, 07:03 | #21 | Link |
Registered User
Join Date: May 2005
Location: Germany
Posts: 495
|
There is a small button "please wait ... seconds". Wait the time and then click on the link.
Maybe you need the macromedia flash plugin to see the button. If you don´t want to install just try the link of yaz. I don´t want to upload the clip once more on another server. Last edited by MOmonster; 3rd July 2005 at 01:46. |
29th June 2005, 11:20 | #24 | Link |
n00b ever
Join Date: May 2002
Posts: 627
|
@momonster
thx u for bothering w/my source ! ... and sorry for hijacking your thread (i'm sure i'll get banned soon) i made some quick tests w/the renewed functions. u were right - no improvements on my source compared to the old ones - using cdeint as a prepocessor gave better results. when bobbed w/tdeint and processed w/tfm (as u suggested) i can get rid of most of that blending (say, 7 out of 8 frames got cleared) which is pretty good. what now i see is a kinda blocking on the deinterlaced high motion parts. is it a native consequence of the process or would i tune the parameters to avoid it ? (i used your script from the 1st post wout any change) would u please explain a bit more the new parameters u introduced. again, i don't know how to tune them, and the 'blind-flight' gave no difference. thx y Last edited by yaz; 29th June 2005 at 11:23. |
29th June 2005, 12:46 | #25 | Link |
Registered User
Join Date: May 2005
Location: Germany
Posts: 495
|
@yaz
The kinda blocking is a probleme of the bobbed input and has nothing to do with Cdeint. Play a little bit with the thereshold (for tdeint I think it is the mThreshL parameter). Higher values could solve the probleme (I think), but to high values will result in deinterlacing artefacts. Yes no improvments for your source, but you should use the new version. It no longer needs unfilter for bmode=2 and there are some little internal parameter tweaks. The parameter you know, just use like before (don´t use the nlv parameter for your source, it is only useful for analog noise in your source. Bmode=1 is the right choose for you. New is the hv parameter (hidden value). Hidden, because mostly it is better don´t touch this parameter. Set it between 0.6 and 1.4, never and I mean never higher or less. The blends I see in your clip have no blendlevels (percentage how the clearfields are mixed together) under 20% so keep it like it is. This parameter is only useful, if you have problems with such less blendlevels. Set it like I wrote it in my first post. The new modded version works better than the old, also for your source, maybe you can save some more clear fields with it. But you won´t see the difference by playing the output. Maybe for your bad source it is only a waste of time. A big influence to the modded version has the mlv parameter (motion level value). You get this parameter similar like the nlv (see the first post, use bilinearresize). If the fields are the same, the matcher will match them. You can look to the differences in the log file and compare the fields with your eyes. Try to find a value for that you could never find a motion and for that the matcher would match the fields. Read my second post, I also said something for this parameter. You should choose the bobber you like most, the tryweave option is not necessary for the modded version, you can also get good results with a simple bobber. Maybe you like dgbob more or want to use leakkernelbob with sharp=false. Or nearly the same as tdeint(tryweave=true), but slower, the matchbob function from scharfis_brain. It depends on your eyes. Maybe Didee can help you with this dark stripes. Till now, there is no solution for the many blends. Sometimes there are three blends together, that mean two lost clear fields. My function kills two of it. This already gives a bad motion. If you kill all this would have a cruel effect on the motion. Last edited by MOmonster; 29th June 2005 at 12:49. |
3rd July 2005, 10:21 | #26 | Link |
Registered User
Join Date: May 2005
Location: Germany
Posts: 495
|
@all
I updated the modded Cdeint version. I realize some ideas like choosing between three fields or taking the fields with better quality, if possible. The big condition is, that every blend is surrounded from the both clear fieds it consist of. I think for stranger conversations the older version is better. The mlv parameter is default 1.5 and could be choosen I think between 0.75 and 5.0. Conditions for this parameter are: 1. The lumadifference between a blend and a clear field, also if the blendlevel is less than 15% should be higher than the mlv. 2. The lumadifference between two fields, where there is no motion, also if one has some blocks or other artefacts should be less than 1.6*mlv. 3. The lumadifference between two fields of the same original frame should be less than the mlv. Maybe for the next update, I´ll explain it better. With the right mlv the function works a lot better. The motion is smooth, there are less blends and it tries to choose the fields with better quality. This is the first time I can say also the quality of my function is comparable with restore24, not same good, but comparable. Just try it out. |
6th July 2005, 22:19 | #27 | Link | |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,391
|
Quote:
(MOmonster - if you're still interested in Voyager's intro, drop me a PM.) What I noticed with the latest CDeintMod: it seems to mistreat chroma planes when it is fed with YV12 sources, as CDeint's output shows chroma interlacing, then. When converting to YUY2 beforehand, it's clean.
__________________
- 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!) |
|
6th July 2005, 22:35 | #28 | Link |
Registered User
Join Date: May 2005
Location: Germany
Posts: 495
|
Also Cdeintmod only choose the right frame of the bobbed input, so I can´t understand this chroma problems. I´ll take a closer look on the next version.
I don´t any longer recommed fdecimate after cdeint. It has a strange behaviour in some scenes. Decimate works fine. I don´t tested Tdecimate. I just finished a newer and better version, that give me sometimes better results than restore24, but I have to make some more tests with this version. I´ll send you my emailadress soon. Last edited by MOmonster; 6th July 2005 at 23:26. |
13th July 2005, 00:05 | #29 | Link |
Registered User
Join Date: May 2005
Location: Germany
Posts: 495
|
@all
Once more I updated the modded version (not the silent - will come soon). There is many new in this version. Now it works much more fluid, also for the Starship Voyager Intro video. It has some other parameters and runs more stable than the last both versions. Like the first you can also use it together with fdecimate, but it is recommed to use decimate. For more informations please read my updated second post. |
13th July 2005, 09:48 | #31 | Link |
Registered User
Join Date: May 2005
Location: Germany
Posts: 495
|
@yaz
It´s worth a tryout, but it wouldn´t delete more blends, but will give a better motion and runs maybe more stable. Have you found a solution for the dark stripes? I´m interested in. I still don´t see a nice solution for your source, because there are some clear fields totally lost. Maybe I could create a function that is able to delete all blends, but this would be to cruel for the motion, but if you can live with 12 fps I could try it for you. |
13th July 2005, 12:04 | #32 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,391
|
MOmonster - I could only give a quick try on yesterday's preview version. Overall fluidity was indeed better than before, you're on a good way.
Still, there were noticeable problems when motion appears only in small areas of the frame. In a scene where nothing moved but the mouth of the actors speaking, it reminded somewhat of an animation @ 8fps or 12fps - the mouths were "hacking". However, small motion is always problematic. Have been fighting with that long enough @ yaz A solution I don't have for you. But a strategy. One would have to 1) make a basic restoration by either CDeintMod or R24. After this, most blends have gone. Theoretically, in ideal case, all of the remaining blends are in the places where the good original fields are missing in the source already. (Do I remember correctly that the good fields are always missing where two consecutive blends are occuring?) 2) Run a 2nd pass, where all blends are replaced with the previous frame. This turns the remaining blends into dup's. 3) run a 3rd pass, with a routine that replaces duplicates with motion compensated frames, computed from N+1 and M-1. Step 1 is obvious, and both Restoring functions should be able to deal with it. Step 2 is the problematic one, of course. R24 can not do that, but CDeint should, or should be possible to be changed so that it can. Step 3' s function does not yet exist AFAIK, but wouldn't be that hard to do. (I wonder why nobody did it, yet)
__________________
- 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!) |
13th July 2005, 14:51 | #33 | Link | |
n00b ever
Join Date: May 2002
Posts: 627
|
@momonster
dunno, man ... one of your last scripts removed most of that funky black lines (sorry, can't recall which one). what remained is ok for me. anyway, call me if u have any better solution the main problem now is the jerkiness left behind. most of that annoying ghosts turned to that. i want to see what your improvement on the 'smooth motion' field can do w/it ... but i have no time at the moment. maybe, at the weekend (or maybe later) @didée yeah ... it's almost that what i'm tampering with (just on my noobish way) ... i've spent some fragmental time w/making a good blend mask but no success so far. your idea; 1. and 2. seems quite reasonable to me, but 3. i can't even understand. (sorry ) would u, pls, give some more details. Quote:
earlier, i've attached the most problematic parts, and thus u think the whole movie looks like that. it's not true. only some special scenes are so horrific (other parts are simply ugly, in the usual way ) however, a strange idea came to my mind. it seems as if there were some intentional artifacting on that scenes. i don't know the 'terminus technicus' for that but it's sg like a blurred ghost whirling around the object. maybe, u've seen sg like that before. it's used for making feel that the hero has fatal hot, or 'it's the last glance before death', or 'ohh, i'm so dizzy/drunk/tired' aso aso ... (quite cheap effect, anyway) if so, it's sure, that parts get blended as they are the most moving parts, right ? thus, the moving object and its whirling ghost get blurred at once. on the overlapping parts there come that blended blends. imho, that black fields are double blended ones. imho, that's what's seen as 'blends' on the separated fields. i hope u get what i mean. sorry, i'm complete noob on this field (too). my other idea is that it's the effect of a careless and fatal resizing before(!) blending. (maybe, they tried a smooth resizer) any opinion ? thx for your help y |
|
13th July 2005, 16:05 | #34 | Link | |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,391
|
Of course it is possible that those strange effects originally have been an artistic effect, that later on has been destroyed during the standard conversion ... and if these "consecutive blends with missing clear field" exclusively occur in a few scenes only, then it's even more likely to be so.
But that doesn't help much ... the dark stripes surely were not intended, and if it looks bad, then it looks bad. To that point 3) : Thanks to Manao's MVTools, we can create intermediate frames between two given frames. E.g. one can make "true" 50fps from a 25fps source, without blending, by creating new intermediate states of motion between two frames. The result is not always perfect, but usually pretty good. So, for Dup (or Drop) repairing, one would first create a 2nd stream, where every frame is replaced by a frame that has been motion-interpolated from its two neighbours. Then we scan the original stream for dup frames, and replace them with the according frame from the created 2nd stream. That's all. Quote:
And in this respect, the upcoming Restore24 will come across pretty well.
__________________
- 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!) |
|
13th July 2005, 21:00 | #35 | Link |
Registered User
Join Date: May 2005
Location: Germany
Posts: 495
|
@Didee
That´s the problem by using lumadifference for these cases. For such motion you should use a much smaller value for mlv. Helps it if you use mlv=0? This value is only useful if you want avoid frames with bad quality. To optimize the function play a little bit with the btresh parameter. If this also didn´t help, please could you send me a small scene with this problem. For my examples it helps just lowering the mlv parameter and maybe higher (could result in blends) the btresh. Lowering the mnv parameter could also help, but I don´t think that it really will. @yaz It´s not a big problem to create a good deblender that work similar like my Cdeint, but I don´t know if it will be able to detect blends, through there are missing clear fields and don´t destroy clear fields, where the first pass give already good results. If you want to try it this way, I´ll create you the deblender Last edited by MOmonster; 13th July 2005 at 21:02. |
13th July 2005, 23:15 | #36 | Link |
Registered User
Join Date: May 2005
Location: Germany
Posts: 495
|
@yaz
so, here is my deblend function: Code:
c = last.BilinearResize(480,288) Cdeblend(tclip=c, thresh=20) Function Cdeblend(clip input, clip "tclip", float "thresh") { ###### PREPARATION ###### global diff = default(thresh/100 + 1,1.22) global output = input global blendclip = tclip ###### FRAMES FOR BLENDPARAMETERS ###### global combingc1 = blendclip.trim(1,0) global combingc2 = blendclip.trim(2,0) ###### VAR.. ###### global comblc2 = 1 global comblc1 = 1 global btestc1 = 1 global btestc0 = 1 ###### Conditional Function Chain, evaluated from bottom to top (!) ###### c99=scriptclip(input, "Outputer()") c9=FrameEvaluate(c99, "global isblend = (btestc0*diff < btestcb) && (btestc0*diff < btestc1) ? true : false") c8=FrameEvaluate(c9, "global btestc1 = LumaDifference(blendmadec1, blendpicc1) / (comblc1 < comblc2 ? comblc1 : comblc2)") c7=FrameEvaluate(c8, "global btestc0 = btestc1") c6=FrameEvaluate(c7, "global btestcb = btestc0") c5=FrameEvaluate(c6, "Evaluatec1()") c4=FrameEvaluate(c5, "global blendlc1 = comblc1 < comblc2 ? 0.5 * Exp(0.8 * Log(comblc1 / comblc2)) : \ 1 - 0.5 * Exp(0.8 * Log(comblc2 / comblc1))") c3=FrameEvaluate(c4, "global comblc2 = LumaDifference(combingc1, combingc2)") c2=FrameEvaluate(c3, "global comblc1 = comblc2") c1=FrameEvaluate(c2, "global comblc0 = comblc1") return(c1) } # (running inside of the Conditional Environment) function Evaluatec1() { vid0 = blendclip vid1 = blendclip.trim(2,0) global blendmadec1 = MergeLuma(vid0,vid1,blendlc1) global blendpicc1 = blendclip.trim(1,0) } function Outputer() { (isblend == true) && (comblc1 < comblc0) ? output.trim(1,0) : (isblend == true ? output.duplicateframe(0) : output) } And yes, it do it´s job on your source not to bad. You should save the video output once before you try to realize the third point. The thresh parameter is most important for the results. Lower values mean a stronger blenddetection. Tclip is like the bclip for Cdeint. Nice tryout Edit: Please set the mlv=0 (and the mnv) for Cdeint, that makes the third step easier. Last edited by MOmonster; 13th July 2005 at 23:31. |
14th July 2005, 00:13 | #37 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,391
|
Halt, full stop. Does CDeblend replace the found blends always with the previous frame, always with the following frame, or is this mostly random? That's important! Because, for a selfmade dup repair function we should know if we must replace the first or the second of the produced duplicates ... this can be controlled on creation time, it makes no sense if the 3rd pass must start guessing which is which.
Or even better, if your blend detection is that good: instead of producing duplicates, replace the blends with full-white frames. Then, later, the prepared input clip itself can be used as a mask to overlay the interpolated frames. Easy as cake, no dup detection is needed in the 3rd pass. Theoretically it could be also done in one go, putting the mv-interpolator directly into CDeblend. But ... applications of MVTools sometimes tend to use much memory, sometimes *very* much. Not a good partner for using AviSynth's Conditional Environment at the same time. Probably it's safer to keep them apart.
__________________
- 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!) |
14th July 2005, 07:07 | #38 | Link | ||
Registered User
Join Date: May 2005
Location: Germany
Posts: 495
|
Quote:
Quote:
I think sharfis_brain has created such a function. I never used the mvtools before. We´ll see. |
||
14th July 2005, 12:09 | #39 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,391
|
Regarding CDeintMod:
Yesterday evening I made a few quick & nosey tests with the new version. Sorry to say, but the motion smoothness was worse than with the preview version (for Voyager's intro) you PM'ed me the day before. I didn't test with that VOY intro, but with some scenes from ENT NX-01, Star Trek TNG, and with a strange music video*) . No matter what I tried (mlv: 0.5|1.0|1.5|2.0 / bthresh: 10|15|22|25|30 / in different combinations), the new version gave me more of that micro-stuttering, and also let some more blends slip through than the tweaked version did. That's just what the naked eye saw. For the causes "why", I've no clue. *) "Broken" from Seether + Amy Lee. This one is driving me nuts. It basically follows the usual pattern, BUT the converter box seemingly was set up to use blending only for the weights close to 50% - there are less than half as much blends as "should" be there ... instead, there are duplicate fields. PLUS, the source contains pretty much mpeg artefacts like dct noise and the beloved "texture jitter". Both CDeintMod and Restore24 fail big time on this one ...
__________________
- 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!) |
14th July 2005, 17:04 | #40 | Link |
Registered User
Join Date: May 2005
Location: Germany
Posts: 495
|
@Didee
Worse than your preview version? If you set the mlv and mnv to zero and and the bthresh to 22 the output should be absolute the same. Would be nice, if you can send me also another footage my function has this big problems with. I´ll change the behaviour of my output function soon, but this won´t solve the big problems Eidt: With this micro-stuttering do you mean a stuttering every second (for pal) or also inside the pattern? Edit2: I get what you mean in some more test. I´ll work on it. Last edited by MOmonster; 14th July 2005 at 17:42. |
Tags |
mrestore, srestore |
Thread Tools | Search this Thread |
Display Modes | |
|
|