Interlace oder nicht?

Zitat

Das ist extrem schnell! Mit meinem Pentium I 166 Mhz MMX dauert es 20 Sekunden bis überhaubt mal ein Frame fertig ist!

Donnerwetter...so schnell habs ichs noch nie hingekriegt:ani_lol:
Das ist absoluter Weltrekord.

Zitat

Mit mode=17 sieht es vom Bild her fast identisch mit mode=11 aus, den es laut Dokumentation nicht gibt.....?

In "RemoveGrain 1.0"
Application Areas
RemoveGrain has started as a purely spatial denoiser (modes 1-9, 17, 18, 21, 22) and over time it has evolved into a general plugin which manipulates a pixel in terms of its eight direct neighbours (and of course the value of the pixel itself). It now includes modes for blurring (11, 12, 19, 20), modes for nondestructive sharpening (10, 25), smart bob modes (13-16) and last but not least the modes 23, 24 for removing small edge halos, which may be generated by sharpening filters or by lossy DCT compression.

Zitat

...wo der 11er in Scripten zum Einsatz kommt, kann mich auch vertun möchte nicht streiten.

In diesem Thread wird er auch erwähnt...deutsch.
http://www.technik.movie2digital.de/thread.php?threadid=41273&sid=

Eventuell "11" in Verbindung mit RGDering.

Hat mal wer mode 23&24 angeguckt,..
(Hab noch nie die neuere Doku gelesen :D)

Cu Selur

mode 23/24 gehören in die Kategorie "aha, SO einfach isses also doch nicht" ...

source:
[Blockierte Grafik: http://thumbnails.freeimagehost.eu/36/2b7296359499.gif]

RemoveGrain(23) :
[Blockierte Grafik: http://thumbnails.freeimagehost.eu/36/934177359500.gif]

Bitte mal unter ~400% Zoom anschauen, was da mit den armen Pixelchen eigentlich passiert ...
Und der Umstand, dass das Jpeg von RG(23) fast ein Viertel größer als das ungefilterte ist, gibt auch zu denken.

=> mode=23 ist völlig unbrauchbar, imho.

mode=24 ist etwas schwächer, d.h. er zerstört einfach nur etwas weniger.

In diesem Fall hier:

Am besten gar nicht.

Das Rauschen/Grain in dieser Source ist zu heftig, um SeeSaw noch *wirklich* nutzbringend einsetzen zu können.

Soll heissen: man kann SeeSaw's Parameter so einstellt, dass es mit dieser Source hier zurechtkommt ... indem man alles so "vorsichtig" einstellt, dass von dem, was SeeSaw eigentlich ausmacht, nimmer viel übrigbleibt.

(Das geplante "MV-SeeSaw" wird das wahrscheinlich besser hinkriegen - aber auch sehr viel langsamer, und nur dann, wenn ich's wirklich irgendwann man basteln werde.)

-> Würde hier ganz einfach beim üblichen Schema: erst Deinterlacen, dann entrauschen, dann schärfen bleiben. Spart Nerven, und viel Zeit.

Falls Du experimentier-Laune hast, kannste ja mal dieses Script ausprobieren. Hab's mal mit kleinen Änderungen auf Dein Material angewendet, sieht nicht ganz verkehrt aus.

Es ist halt so, dass ...

vinverse(3.0,amnt=12).fluxsmootht(7).removegrain(11)


o = last


[COLOR='Blue']fft1 = o.FFT3dFilter(sigma=2.0, plane=0, bt=2, bh=32 ,bw=32, measure=true)
fft2 = o.FFT3dFilter(sigma=3.0, plane=1, bt=2, bh=32 ,bw=32, measure=true)
fft3 = o.FFT3dFilter(sigma=3.0, plane=2, bt=2, bh=32 ,bw=32, measure=true)


o2 = o.ttempsmooth(2,8,8,2,2,strength=5)[/COLOR]
limitedsharpen(ss_x=2.0*704/720,ss_y=2.0*528/576,dest_x=704,dest_y=528,
\                  Smode=3, strength=340)


return(last)

... alles das was blau ist, wird überhaupt nicht verwendet. Dein einziger temporaler Rauschfilter ist FluxSmooth. FFT3DFilter und ttempsmooth landen im Nirvana.

Zitat

FFT3dFilter ... Also bringt er nichts wie du schon sagst.

Oh-hoho, der bringt schon was! Wenn man seinen Output auch wirklich benutzt, anstatt ihn nur in einer Variablen zu parken, die dann nicht mehr benutzt wird.

Script so modifiziert, dass auch alles benutzt wird, was Du 'reingepflanzt hast:

(Nur zur technischen Info, betreffs der "Grammatik" von Avisynth. Filterungs-technisch ist das wohl etwas zu viel ...)

vinverse(3.0,amnt=12).fluxsmootht(7).removegrain(11)o = lastfft1 = o .FFT3dFilter(sigma=2.0, plane=0, bt=2, bh=32 ,bw=32, measure=true)fft2 = fft1 .FFT3dFilter(sigma=3.0, plane=3, bt=2, bh=32 ,bw=32, measure=true)fft2 .ttempsmooth(2,8,8,2,2,strength=5)limitedsharpen(ss_x=2.0*704/720,ss_y=2.0*528/576,dest_x=704,dest_y=528,\                  Smode=3, strength=340)return(last)

Zitat

Aber es muss doch eine Möglichkeit geben, das man es gut hin bekommt so das dass Script noch mit einer annehmbaren Geschwindigkeit arbeitet?
Dein Script ist Top nur läuft es mit gerade mal 1~2 fps,

Sobald man Bewegungskompensation verwendet, wird alles langsam. Dagegen lässt sich leider nicht viel machen ...

Zitat

Eventuell hast du noch ein anderen Vorschlag im petto der etwas schneller ist?

Aber sicher.

Mpeg2Source(...)
BilinearResize(320,240)

pointresize ist schneller

Diesen Thread greife ich nochmal auf, denn auch ich habe Probleme, interlaced Material von progressivem zu unterscheiden:

Ich nehme mit einem digitalen Kabelfestplattenreceiver auf. Mir ist aufgefallen, daß meistens der Trailer, der wenige Minuten vor dem Film oder der Serienfolge ausgestrahlt wird, interlaced ist (d.h., ich erkenne am Computermonitor sofort die Halbbilder, siehe Bild).

[Blockierte Grafik: http://img17.imagevenue.com/loc621/th_66435_Unbenannt-Echtfarben-01_122_621lo.jpg]

Der eigentliche Film lässt keine Kammartefakte erkennen, auch nicht in Szenen mit viel Bewegung.

Habe immer geglaubt, daß ich alle meine MPEG´s deinterlacen muß bei der Umwandlung mit XviD nach AVI und hatte mich für Yadif (in Avisynth) entschieden.

Nun habe ich schon die Fernsehsender gefragt (Premiere, kabel eins classics u.a.) und man schrieb mir, daß die PAL-Norm ja keine progressive Ausstrahlung zuließe und sie alles interlaced ausstrahlen. Ist auch wieder wahr, oder?

Meine Frage ist, warum man manchmal den Zeilensprung erkennen kann und manchmal überhaupt nicht und ob empfohlen wird, zu deinterlacen, wenn keine Halbbilder erkennbar sind.

Das sind die zwei Bedeutungen des Wortes "interlaced"...

Die Haupt-Bedeutung ist, dass die Halbbilder zeitlich nacheinander übermittelt werden. Daran läßt sich nichts ändern, immerhin arbeiten die Röhren-Fernseher ja auch interlaced beim Anzeigen des Bildes.

Die Neben-Bedeutung ist, dass die Halbbilder auch zu unterschiedlichen Zeitpunkten aufgenommen wurden, und daher Bildinhalt von unterschiedlichen Zeitpunkten enthalten. Allerdings nennt man diesen Zustand in einigen Plugins auch lieber "combed" (comb [engl] = Kamm).

Was man durch Anschauen erkennt, und durch Deinterlacing eventuell herausrechnen will, ist also eher das Combing, wenn man das Interlacing eher als Eigenschaft der Bildübermittlung sieht, statt als Eigenschaft des Bildinhaltes.