another restore function

[MOmonster]

Bad telecined sources with blended fields seems to be normal in my country. The possible solutions for this problems are really rare. For example tdeint(mode=1, tryweave=true) with unblend and a decimater or the the great but really complex function restore24.
That's why I have written the function srestore (18.11.2009) (http://forum.gleitz.info/attachment.php?attachmentid=95810&d=1258566239).
You can download the necessary plugin, Masktools v2 (latest version), here (http://manao4.free.fr/).

For more informations please read the readme or take a look at the wiki (http://avisynth.org/mediawiki/Srestore).
I hope this is a helpful function. Nice tryout. :p

[yaz]

No posts....? It seems that nobody need such a function. Hmm.sorry for my late reaction but my spare time is very limited. i tackle with a very bad source for a long time (see here (http://forum.doom9.org/showthread.php?t=95964) ) yesterday i found some time to give your function a go and i must say i was amazed. your script has given me far the best result so far. it cleared most of the banding and most of that funky ghosting.
would it be possible somehow that u have a look at on that dvd. it's not my plain selfish ;) i bet u will find some more ideas how to improve your script further.

i noticed u dropped further versions of cdeint but i had no time to test that, but sure i will.

some questions :
- if i get it right the noise parameter (nlv) is very important but the way u suggsted prompts nlv=20 which i find too high. so, i tried nlv=0-20 stepwise but, amof, i couldn't have seen any difference. how's it possible ?
- what if i get nlv too high or too low ?
- i compared the 'cdeint'ed stream to the 'tfm'ed one but i found (almost) no difference. why this two step process ? isn't cdeint enough alone ?

pretty good job, man! pls, go on ! if u need a tester (and a propagator ;) ) just call me !

thx
y

[Mug Funky]

hehe... lack of replies does not equal lack of interest :) i haven't had much use for a deblender of late because i tend to do more in the direction of creating the problem than solving it :)

i think i could probaly use it on some old telecined (the peculiarblend method) footage in the coming few weeks. apart from that my sources are all clean, just waiting for me to blend them.

[Didée]

because i tend to do more in the direction of creating the problem than solving it :)
:) What a traitor you are ;)

[yaz]

@mug funky
hah ... now i know whom to bless for this (http://forum.doom9.org/showthread.php?t=95964) masterpiece. (would u, pls, drop your address) :D

[MOmonster]

@yaz
Nice to read some replies. The new version works a lot better on bad quality sources. The bmode is really helpful for it. Yes the nlv parameter should be used to tweak the blend detection, but this parameter is only helpful for static noise, for example from analoge materials or DV-sources. Useful values are between 0 and 4, anything higher effects the opposite. So it´s not a useful parameter for dvd-sources, keep it 0. (really 20, and you took a scene without any motion?)
In your thread you wrote, that your source looks strange also after using separatefields. Maybe this is a yv12 problem. Use converttoyuv2(interlaced = true) before the deinterlacing. Does this help. If not maybe you can send me just 5mb (a motion scene with problems). You can uploud it for example this way.
http://rapidshare.de

If you use Cdeint alone, please use the modified Version. You would lost some clean frames if you do it with the other version. The combination with tfm, first is faster than using it alone, but the more important advantage is the matching process, because Cdeint itself can´t weave the fields. So for maximum resolution use it this way or the modified version with tdeint(mode=1, tryweave=true) (much slower). Cdeint just choose the right frames of the inputed bobbed source, not more.

[yaz]

@momonster
sorry but i didn't go further. maybe on the weekend
The new version works a lot better on bad quality sources. The bmode is really helpful for it.when u say 'new' what version do u mean ? 'cdeintmod' or the silent mod of the 1st version ? nevermind. i will try all :)
Useful values are between 0 and 4, anything higher effects the opposite. So it´s not a useful parameter for dvd-sources, keep it 0. (really 20, and you took a scene without any motion?)maybe i was dumbass but instead of scrolling thru the movie chasing for 'real' static scenes i just checked a 'plain black' part having 15-20 frames. however, the very high value seems to be realistic as the noise (a kinda vibration) is clearly visible. now i'm musing about to make a lowpass filtering before 'deblending' as this way i loose too much 'clear' frames.
In your thread you wrote, that your source looks strange also after using separatefields. Maybe this is a yv12 problem.maybe or maybe not. i'm sure this dvd was prepared by people being as incompetent as just can. like me :D
... maybe you can send me just 5mb (a motion scene with problems)ok. i try to do sg. would someone suggest a reliable vob cutter, i've never used such stuffs before.

anyway, isn't a dvd rent there around. it'd worth to have a thorough look on that source.

thx
y

[MOmonster]

@yaz
I mean both versions. I also updated the first. The modifield version just have some more conditions, that it can be used as standalone function.
You can use mpegtools from tmpgenc for example to demux the m2v videostream from the vob and then use cutterman to cut the videostream.

[yaz]

thx, but i think i can do it in a way w/dgdecode. however, u must wait till the next week (i'm banned again at my 'private ip'; 'limit exceeding, use of undue authority, aso aso'; what a bad guy i am). in the meantime, i hope, i can make some further experiments. i'm about it.
thx
y

[scharfis_brain]

MoMonster, I didn't test your unblender due te lacking time :(

So I have one question: how does it handle the Starship Voyager Intro video?
Is it able to deblend the nebula scene without jerkyness?

[Didée]

I gave it a quick try on CDeintMod yesterday. Seems to work pretty good, overall.

While the blend removal was quite successful (perhaps even better than R24 - I didn't count the misses for both), it produced yet too much skipped frames on scenes where motion happens only in small areas.

Though I don't get fully get the mechanism behind it, the function shows good potential for sure. Good work, Momonster!

Note: Work on R24 resumed ;)

[MOmonster]

I work on a better condition function for Cdeintmod, that should save more clean frames, but ofcourse it would never save the clear frames as good as restore24, because it just take the bobbed input and choose one of two frames to output. That mean that the bobber you choose give two frames for one original frame. My function just try to find out what is the blend and give back the clear field. For my sources, everytime when tfm is not able to find a match it´s because a blend, that´s why this simple way works that way (till now smoother and better than the mod version, but there will be further tweaking).
The mod version I created to save more clear fields. So it looks to some more conditions, but there is still some work necessary.
@Didee
Ok, I try to explain short, how the blenddetection work.
The condition is that the blend is the product of the two clear fields around. The blenddetection use a smart bobbed clip, this makes the test easier. I found out, if the blendlevel (the level, the clear fields around are merged together) is 50%, the differences between the blending to the field before and the field after are nearly the same. If the blendlevel is 20%, the difference to the field after is smaller than the difference to the field before.
And this seems logical. So my function try to create the blend with the both differences to the clear fields around. Then it compares the created blend with the original field. If they match, we know, this is a blend.
To make this process more accurate, the function compares the result of the first blendtest with the results of the next blendtest.
I also tried to make it more accurate by using the total difference, but it only slows down things a little bit, and don´t really help, the lumadifference seems to work quite well. In your restore24 thread I posted my first basic function, maybe this is easier to understand.
If there are more questions, just ask me. :)
@scharfis_brain
If you could upload a small part of the intro, I could work a little bit with that source to tweak my function.

[yaz]

@momonster (and other gurus interesting)
i've uploaded two short examples. link and comments are here (http://forum.doom9.org/showthread.php?t=95964). sorry for crosslinking but i think the files belong there even if we discuss the problems here (hopefully). and i don't want to crosspost.

@momonster
'man proposes God disposes' ... of course, i had time far less than i expected but i'd made some further short tests w/the modded versions. i must confess, i found no difference betw them. however, the results were amazing. most of the blended frames were recovered or cleared significantly. what remained is that strange ghosting i outlined in the other thread.
further, i felt as if i had lost 'too much' clear frames while decoming was defective on frames where it'd been needed only on small regions. however, i haven't checked these more throughly but, imho, they are not 'fatal', so, i could live w/them happy.

a short question. you, and other gurus too, recommend to restore fps24 ? why do u think it's beneficial ? i see that wout some decimation the stream gets jerky but i want to keep fps25. any ide how to do so ? (other than fps25 is hella jerky on a pal tv)

thx a lot
y

[Mug Funky]

field-blends use up buttloads of bitrate and require bobbing on playback... that's the main reason to restore the non-blended source. also if you plan on standards-converting it a second time and don't want to have blurry crap as an output.

if you have bitrate to spare, you can easily encode an interlaced xvid and play back with on-the-fly bobbing. it's quite a good solution for anime, where there's lots of static scenes.

[MOmonster]

@yaz
Ok, I dowloaded your clips. What a strange conversation, a soft picture, but no analoge noise and not to heavy artefacts. I´ll take a closer look, if I have a little bit more time.
Why decimating to 24fps?
In most cases the original has 24fps and than converted with strange conversations like temporal fieldshifting fielddoubling and of course fieldblending to 25 or 29,976fps. You see it shouln´t be 24fps, but 23,976fps. Sometimes the original has only 17fps and one time I have a source, that was already speed upped to 25fps before the strange conversation. So we can´t say that it is general right to decimate the clip to 24fps. So you have to decide, if the 25fps output looks already smooth enough for you, there is no need to decimate. If the 24fps decimated clip have a smoother motion for you, than you can decimate and than speed up the source to 25fps, that you have your pal standard.

As I said before the modded version works not so good till now. I already have another condition function for Cdeintmod. It works better than now and with the right settings already better than the silent Cdeint with tfm. I will update the function, if I have a little bit more time, till now it´s recommed to use the non modded version.

I also think about another modified version that is not only able to use one of two, but is able to use one of three frames to save more clear fields, but I have no such strange sources. We´ll see, what brings us the future. :)

[MOmonster]

@all
Once more, I updated the functions. The bmode 2 no longer needs the unfilter and the functions have a better handling. The modded version no longer has the nlv value, but a very important motion level value (please read the updated text at the beginning).
I added a new configurable parameter to tweak the blend detection, but in general I wouldn´t touch this parameter, called "hv". This parameter is used for the internal calculation ot the blendtest. Useful values are between 0.6 and 1,4. Normally, higher values help to find the blendings better, so for the silent Cdeint you can use for example 1.0 (default is 0.9). For A clean, sharp (not oversharpened) source set smaller parameter. For worse sources use higher values. If you see that there are blends with factore under 20% are left the default value is maybe to less. For the modded version this value should be set more accurate (default is 0.8), because of the updated internal condition function, it have to recognize really clear.

@yaz
Like you can see it, because of the posts in your thread, I also see no way to restore this nicely. Now I know why my function works better for your source (because of the many blends that stays together). But won´t help you much. If we just take all the clear fields the source look not so bad, a little bit soft, but no strange artefacts because of the compression. It looks like a bad conversation from Pal to Ntsc and another bad conversation back to Pal or somthing like this.
The big probleme, that some clear fields between two blends are totally missed. So to get not a to strange motion, we have to took one of the blends. Ok some blends left won´t be the probleme I think, but the strange dark stripes, we can see in every blend. This looks to bad. I don´t think that you get better results than using Cdeint with tfm (or to save some more clear fields the new modded version, but this won´t make the difference) on it.
Maybe sharfis_brain or Didee know what to do against this strange artefacts, but killing more blends won´t be good for the motion. Only theoretical it is possible to restore this missing clear fields by adding the two blends together and than substract the blend of the two clear fields around. If we exactly know the blendlevel, it is possible to restore also this cases. But sorry this is just to rare and the function really to complex and would only work with really good compressed material, so I think I won´t try something like this in near future. Maybe it is the best to buy the ntsc version. I don´t believe that it will also be that bad. :o

[Didée]

Screenshot of those "dark stripes", please (can't get yaz' samples, currently) ?

Some time ago, scharfis_brain had a source with something he called "negative blending", and this here sounds similar.
For scharfi's sample, I fiddled a spatio-temporal repair function that seemed to work sufficiently. Perhaps it can be applied on yaz' source, too.

[yaz]

Screenshot of those "dark stripes", pleasehere you are (http://rapidshare.de/files/2654995/musa01.jpg.html)
(can't get yaz' samples, currently) ?naah ... what to say ... :D
thx
y

[MOmonster]

I know the strong limitations of this server. I uploaded the clip on another server. Download it here:
http://www.megaupload.com/?d=22K8DY2Z

[vcmohan]

When I click on the link it takes to megaupload.com. What to do next to get the image?

[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. :D

[Didée]

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 :confused: ) would u, pls, give some more details.
(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 :D

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]

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 :confused:

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.

[MOmonster]

@yaz
I had some time to work on my functions the last night. My next just better Cdeint version I´ll offer next week. But I also created the function for your use.
So here is my motion_interpolate_deblend function:

crop(8,8,-8,-8)

ord = last.getparity() ? 1 : 0

a = tdeint(mode=1)

c = leakkernelbob(order=ord).BilinearResize(480,288)

motion_interpolate_deblend(a, tclip=c, thresh=45)



Function motion_interpolate_deblend(clip input, clip "tclip", float "thresh")
{
###### PREPARATION ######
e = input.selecteven()
o = input.selectodd()
tempe1 = e.MVAnalyse(isb=true, sx=4,sy=4, lambda=4000)
tempe2 = e.MVAnalyse(isb=false, sx=4,sy=4, lambda=4000)
eout = MVInterpolate(e, tempe1, tempe2, nb=1, bl=0.5, el=0.5, fbw=4).trim(1,0)
tempo1 = o.MVAnalyse(isb=true, sx=4,sy=4, lambda=4000)
tempo2 = o.MVAnalyse(isb=false, sx=4,sy=4, lambda=4000)
oout = MVInterpolate(o, tempo1, tempo2, nb=1, bl=0.5, el=0.5, fbw=4)

global intout = interleave(oout,eout)
global diffval = default(thresh,50.0)/100.0 + 1.0
global output = input
global blendclip = tclip

###### FRAMES FOR BLENDPARAMETERS ######
global frame_c0 = blendclip
global frame_c1 = blendclip.trim(1,0)
global frame_c2 = blendclip.trim(2,0)

###### VAR.. ######
global diff_c2 = 1
global btest1 = 1
global btest0 = 1

###### Conditional Function Chain, evaluated from bottom to top (!) ######
b99=scriptclip(input, "(btest0 / btestb + btest0 / btest1) < diffval ? intout : output")

b4=FrameEvaluate(b99, "global btest1 = LumaDifference(MergeLuma(frame_c0,frame_c2,blendl), frame_c1) /
\ (diff_c1 < diff_c2 ? diff_c1 : diff_c2)")
b3=FrameEvaluate(b4, "global blendl = diff_c1 < diff_c2 ? 0.5 * Exp(0.85 * Log(diff_c1 / diff_c2)) :
\ 1 - 0.5 * Exp(0.85 * Log(diff_c2 / diff_c1))
global btest0 = btest1")
b2=FrameEvaluate(b3, "global diff_c2 = YDifferenceToNext(frame_c1)
global btestb = btest0")
b1=FrameEvaluate(b2, "global diff_c1 = diff_c2")
return(b1)
}

It use the newer simpler and better Cdeblend, but it doesn´t double the frames, it interpolates the motion.
I don´t like the results of mvinterpolate too much, just to blocky for my eyes. But of course better than your strange blends. :)
Higher thresh values mean detecting more blends (everything higher than 75 is too heavy I think).
Just try it out. I don´t tested it till now together with Cdeint, but you can try if they run together. Alone it just runs stable for me.
I hope this help you a little bit.

ps: I don´t know much about the mvtools parameter. If you want to tweak them, therefore you should ask anybody else. :sly:

[MOmonster]

@all
Ones more I updated the my function. It has many big changes, not only the change of the name.
I wrote a readme and created a package that includes Cdeint, Crestore and Cdeblend.
The bthresh value and with it the blenddetection work different from the last version. The motion is now much better and many other changes applied to the function. It is really worth a try. ;)
Originally Posted by scharfis_brain
how does it handle the Starship Voyager Intro video?
Is it able to deblend the nebula scene without jerkyness?
Yes on my test, the newest version really seems to handle this hard stuff. :p

[Didée]

Oh, the attachment has appeared ;)

Could only do two small tests so far on Crestore. Judging from these, the new routine seem to do a darn good job. Very well done, MOmonster!


And yes, even the VOY intro is almost perfect now. Small problems detected:

1) In the beginning, from ca. 0:06 to ca. 0:14, there was a slight "pulsing" in the motion - not jerky, just a very small speed difference in the flow of motion. However the effect was not very easy to spot.

2) A clear jerk (dup) was produced around approx. 0:37 (floating blue nebula scene), but this could also have been caused by decimating to 24fps instead of 23.976. (Should be re-tryed with another decimator.)

3) The blended scene transition at 0:49 was definetly jerky - the flying rock was appearing in a bonanza style ...


No. 1) is rather minor - I just noticed it on 3rd view. No. 2) could be an issue of the decimator, so it doesn't count for now. This leaves us with 3) as the only noticeable error in the whole sequence. This is a very good result indeed.

In relation to No. 2) , I'd suggest to switch to another decimator than decimate() - either TDecimate or FDecimate. In the most common standard case, for each 1000 PAL frames there *are* only 959 FILM frames available to restore. Decimating to 24fps tries to restore 960 FILM frames instead, so one jerk (duplicate) is preassigned. There's no guarantee to avoid these by decimating to 23.976 fps, but the chances are much better.

[MOmonster]

Thanks for the testing Didee,

the first and the second point I know very well. The first is because it don´t find the pattern so accurate, it need some seconds or better a high motion scene (with clear fields) to find the pattern offset more accurate. And yes the second point is because of the decimation process. Theoretical tdecimate should give better results with the right settings, but I don´t get it running together on my pc (not enough ram I think or something similar). Fdecimate doesn´t create good results, that´s why decimate is recommed.
Because of the third point, I´ll have a closer look on it. Maybe it´s just a point of the bthresh. We´ll see.
I already think about the next version, but mainly to get it more stable and maybe a little bit faster. ;)

MOmonster

[MOmonster]

@all
I just updated my Crestore function. Ones more there are big changes.
I still don´t get the voyager intro fully dup free, but the third point Didee spokes about doesn´t happens anymore. The new function is more flexible because of the range parameter. The blend detection core is updated and it doesn´t need anymore a decimater. There are two Crestore functions that output 23,976 or 25fps. Crestore_pal wasn´t tested till now, because I have no sources with such a conversion. :o
If you use leakkernelbob for the bobbed input the speed increase significantly compared with my last version. If I use tdeint the speed decrease very strong, I think this is a memory problem (256mb ram has my pc). Maybe somebody with more pc performance could test the speed difference. For more informations, please read the updated readme.

So or so, the new functions seems to do what I want. The development of this package will slow down a little bit in the next time, because I don´t have much more ideas for this function and there are other projects, I want to do.

For the near future I plan to test a totally different simpler and faster blend detection, maybe the next version will ones more have a small speedup.
Also the missing mnv & mlv parameter give me the idea for a new function. :D

Cu, MOmonster ;)

Edit: There was a small bug in the blend detection, I had fixed. Please download the newest version for tryout.

Edit2: I find out where this big slowing down came from. Its the range parameter. Set it smaller (down to 2), if you have this speed problems.

[MOmonster]

Ok, ones more a new Version (v0.9b) of Crestore is out. Also Cdeblend is updated. The speed problems are solved. This version is the fastest Crestore till now, also the dup problem seems to be solved. I really like the output. :)
The readme is updated, there are some new parameters, so please read it.
At this point I think, that it is a real alternative for restore24. Also the quality fanatics should have a look on it. ;)

[Didée]

I would give applause, but ... try processing the Voyager Intro with an additional "trim(8,0)" before doing anything else, and prepare for an :eek: effect.

BTW, somehow the flying rock is still riding bonanza for me?

[MOmonster]

@Didee
So I use trim(8,0) before the script. No problems. It makes no difference for me. Or did you use it only on the bobbed inputs?
I switched framewise the first 1800 frames and there were no dups, but how fluency the motion is I can´t say you, because on my 60 hz monitor the whole intro doesn´t looks that smooth. I try to make it better in my next version. :sly:

I know what you mean with the motion of the rock. No dups, but bad motion, because there are too many blends left. I think with the right settings it should be possible to make it better. I will play a little bit with the parameter this evening. :cool:

[Didée]

Oh, indeed. My apologies. In fact I was testing the version you PM'ed me, and that one showed the behaviour I mentioned. And since you said apart from some minor thingies it were practically the same, I drew my conclusion.

Still, I think your used method is not correct, and don't understand why it seems to work nonetheless:
Basically, Crestore_xx is producing a de-blended stream @ input framerate, and you're simply calling a "changeFPS(x.xxx)" on that, at the end. This seems more than risky to me, since the source can contain the blends in arbitrary positions, where ChangeFPS works its way through in a fixed pattern.

Or did I miss something, and ChangeFPS has bacome a smart decimator that chooses the least-difference frames for dropping? :confused:

[MOmonster]

@Didee
I pm'd you to explain how my function does it.

@all
A smaller update of the package. A small improving of the blenddetection should give better results (also for the rock scene, but still far from perfect). Crestore and Cdeblend don´t have any longer a nlv parameter.