another restore function

[MOmonster]

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.

[Backwoods]

www.uploadhouse.com

www.imageshack.ws

For instant free image hosting.

[MOmonster]

Thank you for your links. I´ll delete the image after a week or so. This should be not the content of this thread.

[yaz]

@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

[MOmonster]

@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.

[MOmonster]

@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.

[Didée]

Originally Posted by scharfis_brain

how does it handle the Starship Voyager Intro video?
Is it able to deblend the nebula scene without jerkyness?

As far as I tried, it fails big time on this clip. But it must be admitted that this intro is very difficult indeed, and probably I didn't know how to tweak CDeint's setup correctly.

(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.

[MOmonster]

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.

[MOmonster]

@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.

[yaz]

@momonster
thx for the improvements! i'll try to give it a go at the weekend. (i'm still fighting w/the same source )

thx
y

[MOmonster]

@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.

[Didée]

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)

[yaz]

@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.

Originally Posted by Didée

(Do I remember correctly that the good fields are always missing where two consecutive blends are occuring?)

dunno, really. when i watch the separated fields i always know what would i select. in most instances the clear fields are there and your scripts act pretty good on them.
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

[Didée]

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.

the main problem now is the jerkiness left behind.

Indeed. That's the funny lession I learned rather quickly when I started out with Restore24: At first you think removing the blends is the hard part - but isn't. Removing the blends is relative easy. Producing a smooth and fluid result, *that* is the hard part. Blends are not nice ... but broken motion is what can really drive you insane (me, at least). By now, even I hardly care anymore if a restauration script accidentially chooses a 15% weighted blend instead of the clear field ... this minor blending tends to get lost in display's luminescence anyways, one would hardly be able to spot it during playback. For me, jerkiness of motion is what must be avoided by all means.

And in this respect, the upcoming Restore24 will come across pretty well.

[MOmonster]

@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

[MOmonster]

@yaz
so, here is my deblend function:

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)
}

You can use Cdeblend in one script together with Cdeint. I changed the internal names and tried to make it simple, but I don´t know how stable it is.
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.

[Didée]

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.

[MOmonster]

Originally Posted by Didée

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.

Last night I didn´t thought of this problem. Now it outputs a blankclip. Do you know, how I get the color white?

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.

This is what I thought. Also the combination of Cdeint Cdeblend seems to be not that stable. Trying to run it with another big function I think won´t be the best way. But maybe I could use the function direct in Cdeblend. I´ll search for the thread, but before weekend I wouldn´t have the time for it.
I think sharfis_brain has created such a function. I never used the mvtools before. We´ll see.

[Didée]

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 ...

[MOmonster]

@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.