Help with Srestore()

[mantis2k]

Please could somebody provide an example line of code to get me started with using Srestore in terms of de-interlacing the following Field Blended source to progressive? scharfis_brain would have me believe it's better than Restore24!
Download Sample A... (http://www.rarekungfumovies.com/a.mpg)
Download Sample B... (http://www.rarekungfumovies.com/b.mpg)

[Didée]

:rolleyes: - Simple example:

mpeg2source("tehsource.d2v")
bob(0,0.5)
SRestore()


This is given in the documentation that comes with Srestore. And approximately one thousand times in this forum.

You did not search very hard. Rather, not at all? :rolleyes:

[mantis2k]

Thanks and apologies for not searching properly!

Is bob(0,0.5) really necessary? If so, why wasn't it built in to rest of the function considering it looks deceptively simple? I was expecting several lines of code or at least one line with lot's of parameters.

Do you think that script will really deinterlace my video? The standard restore24 needed tweaking.

[Didée]

Yes the bob is necessary. The bob isn't built-in because of the countless number of different available bob-filters that people potentially might want to use. Therefore it's easier to leave the bobbing completely up to the user.
(Also, there are cases of progressive-blended sources where you don't need to bob, but that doesn't apply here.)

Srestore usually works quite good with default settings. Your source is a though one though ... all those artifacts and distortions could easily mislead an automated filter. I quickly tried Srestore on your various samples ... it's not error free, but pretty okay. It's questionable if tweaking would make it any better.

_____

Compare Restore24 to Henry Ford's first motor-driven car. It was slow, loud, uncomfortable, and whatnotelse. But even if it's a ridiculous car by today's standards, let's be happy that Mr. Ford had invented it. - Because without it, we wouldn't have Porsche's and Ferrari's today. (Or at least, they wouldn't be as advanced as they are today.)

[mantis2k]

Nope; doesn't work! The subs jump all over the place! There is big time ghosting... That doesn't happen with the tweaked r24. Thanks for showing me how to use Srestore anyhow, so at least I know I've tried it.

[tormento]

Could you please write the tweaked parameters you applied to r24? I am getting some problems here (http://forum.doom9.org/showthread.php?t=152982).

[mantis2k]

scharfis_brain wrote the modification for another movie that was transferred in the same way as the above clips, about 3 years ago. I doubt it would work on your source, but it doesn't hurt to try. You should definitely contact him, as he is a real expert at deinterlacing! Without his help, I don't know what I would have done...
Restore24... (http://www.rarekungfumovies.com/restore24_RC1_WIP.avs)

import("c:\program files (x86)\AviSynth 2.5\plugins\restore24_RC1_WIP.avs")

#I modified this line for a 25fps source as originally it was designed for 23.976fps output (great for AVI but not DVD)
Restore24(r24fps=25.000,numr=3125,deno=6250,useLL=true,stringuent=false,fulltriples=false,r24deint=1,fra=1,frr=1,edgetype=0,edgemode=2,edgeeval=2,r24size=.75,r24ysize=0.75,nr=-5,ldmp=32.0,debug=0)

[Didée]

@mantis2k -- to rule out a possible usage error, please post the complete script that you've been using. I tried all 5 samples ("a","b","clip1","clip2","clip3"), and found the results quite OK.
(At least better than I would have guessed. After Srestore, the subtitles are still jumping a little, yes. But then, all of the content is jumping, that's how it is ...)

[Didée]

Also,
#I modified this line for a 25fps source as originally it was designed for 23.976fps output (great for AVI but not DVD)
Restore24(r24fps=25.000,numr=3125,deno=6250,
is really not a good idea. As far as I can see, the source IS 23.976 fps. If you tell the deblender to output 25fps just because you like that number more, then the result is not good. Per second there are [only] 24 unique frames available, but you force the tool to deliver 25 frames. This means that the deblender necessarily will output at least one blended frame per second, resulting in stuttery motion.
When the underlying source is 23.976, you have to restore exactly that framerate. Not any other framerate.

[mantis2k]

LoadPlugin("c:\program files (x86)\AviSynth 2.5\plugins\dgdecode.dll")
import("c:\program files (x86)\AviSynth 2.5\plugins\srestore.avs")
LoadPlugin("c:\program files (x86)\AviSynth 2.5\plugins\mt_masktools-26.dll")

#Input source
mpeg2source("c:\clip.d2v") #,cpu=4)

bob(0,0.5)
SRestore()

#Crop away side borders and junk
crop(60,0,-50,-0)

#Resize and add borders for 2.40:1 (16:9)
BilinearResize(720,426)
addborders(0,75,0,75)
It comes out really bad in terms of:
*jumpy frames--pretty much constant
*ghosting--pretty much constant as well

[mantis2k]

is really not a good idea. As far as I can see, the source IS 23.976 fps. If you tell the deblender to output 25fps just because you like that number more, then the result is not good. Per second there are [only] 24 unique frames available, but you force the tool to deliver 25 frames. This means that the deblender necessarily will output at least one blended frame per second, resulting in stuttery motion.
When the underlying source is 23.976, you have to restore exactly that framerate. Not any other framerate.
The source was originally 23.976 when on 35mm film, but once captured to DVD it became 25fps. I therefore need to output it as 25fps. I cannot "restore" it to 23.976, as I would then need to use DGPulldown to go to 25 or 29.97, but then it looks very jerky on TV with dropped frames. Sure, on PC it's fine with 23.976. However, after modifying that line (maybe I haven't modified it correctly), it seems perfect in terms of, well, everything! Smoothness, you name it... I didn't even need to look into Srestore, but like to be open-minded and see how these new filters stack up.

[Didée]

Believe me, I really would like to compare both, to see what Restore24 achieves. After all, it was me :) who wrote Restore24, so there is interest for an obvious reason.

Problem is I can't run it anymore, because I don't succeed in loading SmartDecimate. No matter whether I use the original SmartDec DLL (alongside with the belonging avisynth_c DLL), or the new compile by tritical (with appropriate new avisynth_c), no matter whether I use Avisynth 2.5.6, or Avisynth 2.5.8.

It is MY tool, and I can't get it to run anymore. Ain't that funny?

[mantis2k]

LoadCPlugin("c:\program files (x86)\AviSynth 2.5\plugins\SmartDecimate.dll")
Mine runs,

[mantis2k]

Download SmartDecimate plugin... (http://www.rarekungfumovies.com/SmartDecimate.dll)
I am using AviSynth 2.5, but can't be anymore specific about the version.

[Didée]

Nevermind, I found a safety repository in the depths of my HDD, with a working setup.

Still: it is not good to force 25fps output. The result is not, I repeat: NOT smooth. I clearly see blended frames, approximately every 25th frame.

I don't care personally, if you like, you can tell the tool it shall output 34.567 frames per second. It's all your choice. However, there is only ONE setting that is technically CORRECT in this case here, namely 23.976 fps output. Anything else is b*llsh*t.
You still can change the 23.976 to 25fps later on, doing the normal PAL-speedup. That's no big deal. But it is awkward to force the deblending tool to do something *wrong* in the first place!

***

Technically related, I see my initial suspect was correct. For whatever reason the blended fields are jumping so funnily, they make the usual blenddetection via lokal temporal comparison quite unreliable. (because many supposed-to-be-stationary pixels in fact are not stationary). Luckily, Restore24 has several blenddetection modes, and the one suggested by Scharfi is the correct one here. It's basically the oldest of the three modes, which does the detection via the global-edge-energy mode. This mode doesn't care much about stationary or not-stationary pixels, hence it is not affected by the jumping fields.

Darn. I really had hoped that Restore24 would R.I.P. Seems there are still cases where it deals good.

(MOmonster, if you read, please update Srestore. PLEASE. I don't want to maintain R24 anymore! Not at all!)


edit: though, after having a 2nd look, R24 doesn't catch everything correct, either. It mistakes some blends with good frames, too. ...-But hey, the source is so dirty, I can't even reliably decide with my own eyes which are good frames and which are bad. There's so much broken stuff in there, which could be either this or that. If man's brain has difficulties to decide, then the automated tools will fail more regularly. That's a known.

[mantis2k]

You still can change the 23.976 to 25fps later on, doing the normal PAL-speedup. That's no big deal. But it is awkward to force the deblending tool to do something *wrong* in the first place!
Are you talking about changingfps followed by resizing the audio? What fps function would you use after r24? And which software would you use for the audio? The worst thing is having to sync up the audio. Even after r24 and the all the filters, the video still goes through TMPGEnc and comes out perfectly in sync; I don't want to jeapardize that...

[mantis2k]

edit: though, after having a 2nd look, R24 doesn't catch everything correct, either. It mistakes some blends with good frames, too. ...-But hey, the source is so dirty, I can't even reliably decide with my own eyes which are good frames and which are bad. There's so much broken stuff in there, which could be either this or that. If man's brain has difficulties to decide, then the automated tools will fail more regularly. That's a known.
Trust me, that r24 works extremely well even during high-speed choreographed fight scenes. The smoothness is very noticeable. That (r24)--and the auto color correction function in ColourYUV--is about the best thing to happen to this "dirty" source. ;) Without the magic of r24, I would not be here discussing color correction and brightness. The project would have died long ago or the guy would need to pay out serious money to get the 35mm transferred professionally.

[Didée]

Trust me, that r24 works extremely well even during high-speed choreographed fight scenes.
It's not that I wouldn't trust you. It's just that you have 24 clean elements, and try to allocate 25 positions with those. When you have 24 cake pieces and 25 hungry people, there is a problem. However, one of those 25 hungry people shouldn't be there at all, since only 24 people received an invention. So the problem would be easy to solve.


Are you talking about changingfps followed by resizing the audio?
Yes ...

What fps function would you use after r24? And which software would you use for the audio?
Back when I did such bigger stuff (it's been some time since), I used CoolEdit to resample the audio. But Avisynth can do that too. The slightly more simple method is to just use "AssumeFPS(25.0, sync_audio=true)". The slower version is to use SSRC for resampling ... please excuse I don't know its syntax out of the sleeve. And Im very tired now, its getting late, and the day was long. I'm sure the forum holds all necessary information, and the search page is always eager to get some work. G'nite.

[tormento]

Why not change the audio/video fps in matroska container to get them in sync?

[mantis2k]

It's fine. I did it this morning before leaving for work using the above script + the following software (http://forum.doom9.org/showthread.php?t=125966) for resizing audio. Came out perfect. No sync problems.

[mantis2k]

:rolleyes: - Simple example:

mpeg2source("tehsource.d2v")
bob(0,0.5)
SRestore()


This is given in the documentation that comes with Srestore. And approximately one thousand times in this forum.

You did not search very hard. Rather, not at all? :rolleyes:

Damn, all I needed was to change the above to this in order to get SRestore to work:
bob(-0.2,0.6) .reduceflicker(strength=1)

Why is the quality so different just because of that line?

[Didée]

Why is the quality so different just because of that line?
In short: because your source is particularly crappy.

It was already said that all that illness in your source can easily mislead an automated blend remover. One major point is that the blended frames are spatially distorted (stretched in vertical direction - seems there was field jump on the original source, and that field jump then got incorporated into the field blending), and the lot of other artifacts won't exactly help on the matter.

Now, ReduceFlicker does even-out most of that field wobble, so Srestore has a more clear input to make decisions on.

However, you shouldn't use that directly as input. While Reduceflicker produces something "easier" for Srestore, it definetly degrades the "good" original frames! (After all, it does a sort of median-clipping...)
You should only feed that as "dclip" into Srestore, to be used solely for analysing purposes. Like so:

source
bobby = bob() # any bobber of choice
calmy = bobby.ReduceFlicker(strength=1)

bobby.Srestore(dclip=calmy)


Looking closer, ReduceFlicker does cause quite "sharp" boundaries in places where the median clipping took place. An alternate way is to use the following instead of ReduceFlicker:

source
bobby = bob() # any bobber of choice
calmy = bobby.Clense(reduceflicker=false).merge(bobby,0.5)

bobby.Srestore(dclip=calmy)

That's a more simple way of doing what ReduceFlicker does with the given setings. (Sometimes it's better if a filter does not try to be 'intelligent'.) - The result of Clense/Merge is overall softer, less artifical than ReduceFlicker. If it actually makes a difference for Srestore's result, I can't tell. That's a matter of try'n'error.

[Emulgator]

From what I've seen, there may be no automated way of deinterlacing helping with this footage.
But manually it is possible. YATTA people have to go though this as well...

My guess: this film has been transferred using a misaligned flying spot scanner.

The sync (better the correct offset) between scanning phase and film transport phase must have been jittering.

So what you have is half of all fields where some top or bottom lines were unfortunately scanned
when the frame was (already or still) in motion, where the previous (or following) field is scanned from the same frame, now properly fixed at its position.

The latter fields are good and may serve for restoration.

All the deinterlacing, restore and whatsoever algorithms are based on combing, but you got no real combs here, just partially vertically blurred fields.
This is no usual artifact that can be overcome by deinterlacing.

Most deinterlacing and restoring solutions would assume that they could draw some information from the moving field as well,
which is wrong here and must be avoided in any case.

These fields have to be discarded by any means and because I guess the pattern is non-deterministic
(the samples I got from you are too short to make a safe decision) it may still mean that this work is to be done manually.

BTW, all colour, frame, grain restoration can only be undertaken
after field discarding is done properly.

If not done, you will inherit ghosting to previously clean fields, depending on restoration algorithms.

After all restoration is done, you have clean frames.
Final steps are rather easy.

NTSC-DVD: Assumefps 24000/1001, fix audio to duration,
encode with 3:2 pulldown and you get a clean NTSC film version.
Frame by frame clean encodes, played back with pulldown. No hickups.

PAL-DVD: Assumefps 25, encode with 2:2 pulldown and you have the PAL speedup version.
Frame by frame clean. No hickups.

Blu-ray: Assume fps 24, encode progressive and you have it as it was shot.
Frame by frame clean.
No hickups.

[Didée]

Hmh, I can't agree. From what I see in the samples,

- there's definetly field blending caused by a normconversion box. This can easily be see on objects that are moving in horizontal direction.

- it is always the blended fields that have this strange "vertical stretch". In particular, these stretched fields change phase two times in every second, which perfectly aligns with the NTSC->PAL normconversion characteristic.

Hence, if the source is prepared sufficently to make a de-blender reckognize the blends as such, it will knock out the blended fields, which is equal to knocking out the malformed fields.


All the deinterlacing, restore and whatsoever algorithms are based on combing
This does not apply for deblending scripts like Srestore and Restore24. They don't look at all for combing, they only examine fields (or bob-frames) for characteristics typical for blending. A problem is that those stretched fields can throw off temporal relations. Restore24 is not affected by this when used in its spatial modes edgetype=1|2, and for Srestore, the trick with ReduceFlicker (or clense/merge combo) apparently is sufficient to make it behave.

The problem with manually YATTA'ing this source is not only the time needed, but rather that you'll get into problems with deciding "what is good, what is bad" by eyeballing. Your eyes get tired when looking at such a mess. A turing machine won't get tired. ;)

[Emulgator]

Hence, if the source is prepared sufficently to make a de-blender recognize the blends as such,
it will knock out the blended fields, which is equal to knocking out the malformed fields.

Yes, if this can be done, I would gladly agree.
A problem is that those stretched fields can throw off temporal relations.
That's what I fear. That this particular artifact may still kick in and mislead some algorithms...

I guess I will start some manual pattern searching and discarding.
And when I'm tired i will return...