Restore24 revisited.

[scharfis_brain]

remove all avisynth plugin dll's from your system folder.

create separate folders like c:\avsplugins and c:\avsCplugins
for your plugins

[nanga parbat]

there aren't any avs plugins in my systemdir. just avisynth_c.dll. really, i just looked through.

it isn't that much of a problem, really. i'll see when i'm finished with that encode.

nanga

[scharfis_brain]

pushing to top.

I've made an update. See first post.

[Stan64]

Ok really good work. But I still end up with some blended frames. But I loose very many too. =) What can I modify?

[Didée]

No clue

Depends on what's going on exactly. It could be that Restore24 indeed is making some wrong decisions.
But ... I've come across many glitches on Paramount (C)rap stuff, where the field-blending is accompanished by some (rather poor) motion compensation. In these cases, the fields that should be fully blended are only *partially* blended, and the neighbors (which should be blend-free) contain some blending in exchange
Moreover, scenechanges are currently not fully safe, and I can't tell for sure if they'll ever be.

[Stan64]

Ok. Why don't make a scene fade change detector? That ignores them. Or deblend in a special way?

[Didée]

Yeah.

By the time you have implemented that, please inform me.

I see no clean and proper way to implement a special-case scenechange treatment within that tricky framework of ConditionalEnvironment + SmartDecimate.

Detection of blended scenechanges is trick enough since the change then is two frames long. Of course there are methods - but they're probably too complicated to additionally burden this already *complex* script with.
No, no ... scenechanges should naturally be treated correct, directly out of the metrics. I had some things under examination that seemed to work better, but ... currently, its senseless to wait for me to script anything. Don't hold your breath.

Is your problem indeed related to only scenechanges and nothing else? If so, you should look around for one of those "replace frame before/after scenechange" scripts, and try if you can use it as postproc for Restore24.

[Stan64]

No. That was just an idea.

The bproblems lies with this:

C = clean frame
B = blended frame

C C C B C C C B C C B C C C

A natural pattern with blended frames. And it can't handle them. =/

Look here.

http://stan64.ath.cx/after_restore24.jpg

It is a good filter and takes away around 60-80% of my blended frames. But there is many of them left.


EDIT:

If I append my smooth sharp filters from vdub before it takes away blended files. Would it be better then? It maybe detects them finer?

How do I do that? Where should I put the plugin codes?

http://stan64.ath.cx/pkmn_postprocessing.png

[Didée]

Hrmh. It misses such blends?

Sometimes there can be problems when suddenly motion appears, after several frames of no-motion. I guess that's pretty common with animee - but that's not my world ...

If possible, make an unprocessed sample of the source available. The more frames, the better - but please try to keep it < 10 MB.


EDIT: (To your edit above)

Yes, that makes sense. The better the "definition" (sharpness) of the source, the easier life is for Restore24. After all, the strength of edges is what it evaluates.

[Stan64]

Ok, but where should I write those calculations. It must be done after bobbing it to 50 frames and before the blenddetector takes things away? (yes I am lazy).

And, you seem to have right but this scene have a constant panning so it isn't the case. It works very well otherwise. =)

EDIT:

Here is onewhy not make it smooth/sharp all areas look for blending and then discard and then work? That would be slow but really great.

[Didée]

Of course you can let the function evaluate a sharper source than the one that gets actually processed. Syntax is still "Restore24(analyse,render,...)", and both clips have to be bobbed sources.

So, you can start with a simple
analyse=XYZbob().sharpen(1),
and can go up to
analyse=XYZbob().mftoon().iiP()._VD_SmartSharpen(...)
if you really feel the need ...

[Stan64]

As you saw I need it. But I'm not soo good at you think I am. Where in the restore24 script do I implement that. And the SmartSharp script you use isn't supported in the vdub avisynth addon. =/

[Didée]

Okay then.

In the package of scharfis_brain, there is "example.avs", which demonstrates the basic usage.

In the second half, there are those "a1|a2|a3" and "b1|b2|b3" defined. The a's are the clips meant for analyzing, the b's those for final rendering. The higher the number, the better, but slower.

So, if you're going to call Restore24(a2,b2), then you should apply additional sharpening to the a2 clip, as that's the analyzing clip you've specified to use:

...
a2=R24KernelBob()
...
a2=a2.WhateverSharpen()
...
Restore24(a2,b2)
...

Since the sharpening here is only applied to the analyze clip and has nothing to do with final rendering, you need not necessarily use a slow hi-Q sharpener here. A simple sharpen(1) eventually could suffice - you just have to try out what works best. (If that's not enough, perhaps LimitedSharpen could be an option, too. Speed is reasonable, and with Smode=3/Lmode=2 stronger sharpening is possible.)

[Stan64]

Nope, no effect. =/ Great idea but didn't work very well on my source. I will leave it as it is. =/

[Audionut]

With this script, i get the error

edit: still working on problem myself for the moment.

[scharfis_brain]

3rd update of that package!

please read the first post for further detail.

[Didée]

Originally posted by scharfis_brain
this means, in the final output, there will be up to 7 of 24 frames, that have maximum quality (they are weaved)

Are you sure that's a good idea? While fiddling with pattern guidance, I also had the option to prepare the bobbed stream accordingly. However, my decision was to use only one field from those clean full frames, too. Isnt't there a noticeable "quality jitter", when the series of interpolated frames is periodically interrupted by two full-resolution frames?

[scharfis_brain]

huh, completely missed that post.

I think, this quality jitter is negligible.
1) the eye doen't follow it that fast
2) it marks the best possible resolution -> reduced flicker for that frame, i think

but the best thing is: it runs faster!

now, what I really wanted to wrote here:
currently smartdecimate has a BUG, as found here:
http://forum.gleitz.info/showpost.ph...1&postcount=23 (german)

when doing a restore with 25i PAL sources, you might get this error message by restore24:
log2(num-frames*numr*4)>31

there are two possible workarounds jet:
1) set the decimation ration of r24 to 24,50:
restore24(a,b,24,50)

2) trim the video down to max. 179111 Frames (nearly two hours of video)
trim(0,179110)
directly after loading the video

divide your video in parts and restore them separately.

[CrazyCow69]

Hmm I tried to get this script working for several times but I keep getting an odd error wich I can't seems to fix.
The old vesion of restore24 works fine do..

I already tried all suggestions & tips in this thread ( used different dirs for plugin & cplugins etc etc) but still gives me the error.


now this is the thing wich happens always when loading it :
1)I open avs file in VD , loads fine, shows me the preview etc
2) when I press refresh , I get this error message ( same error message if I would try to encode) :


Avisynth open failure:
Parse: Unrecognized exception!
C:\#RIP\AviSynth\plugins\restore24.avs, line 69 column 0
E:\DVDVolume\VIDEO_TS\r24-cf.avs line 7


what I noticed is that "line 69" could be some other number too depends; 68, 69 ,83 ,... it's some kind of a random error

but it's fact that all those error lines are located under the part of ###### INITIALIZING MORE VARS ###### in the restore24.avs file

When I press ok, and then try to refresh again, VD just quits(crashes)


below my avs file:


setmemorymax(384)
import("C:\#RIP\AviSynth\plugins\restore24.avs")
loadplugin("C:\#RIP\plugins\masktools.dll")
loadplugin("C:\#RIP\plugins\tdeint.dll")
loadplugin("C:\#RIP\plugins\kerneldeint.dll")
loadplugin("C:\#RIP\plugins\decomb.dll")
loadplugin("C:\#RIP\plugins\dgdecode.dll")
loadplugin("C:\#RIP\plugins\avisynth_c.dll")
loadCplugin("C:\#RIP\cplugins\smartdecimate.dll")
loadCplugin("C:\#RIP\cplugins\ibob.dll")
mpeg2source("E:\DVDVolume\VIDEO_TS\sample.d2v",cpu=4,iPP=true)
AssumeTFF()
a2=r24kernelbob(0)
b2=matchbob()
restore24(a2, b2)
crop(0,2,-2,-4)
lanczosresize(640,480)



Any idea what could cause this problem or even better how it could be solved ?

[Didée]

Oh yeah ... that's one of the quirks that I've once experienced, too. I got it fixed for me, but alas no "general" solution has been found so far.

Somehow the C-plugins are always prone to give errors, especially when used in complex scripts.
My solution was to move the avisynth_c.dll out of /Windows/system32 (it's placed there during Avisynth installation), and to try manual loading of different avisynth_c.dll versions until I found one that made things work smooth again.

Try it both ways: like written above, but also the other way round: put avisynth_c.dll in /system32, and do not load it manually at all (!), relying on the one in /system32 to be autoloaded (better: auto-provided by Windows).

After all, if the script loads and works correctly when opening it once, then it's at least usable. (There were times when I could not use my own script at all, because it bailed out immediately when loading it...)

BTW, what Avisynth version are you using? I think I remember that I never got R24 to work under AS v2.54. With the initial v2.55 release, everything was smooth and fine. And for the later versions I don't know ...