Moiré-Effekt???

Ja,hast recht LigH.

Dich kriege ich aber auch noch mal dran

Um nochmal auf Post#16 zurückzukommen:

Zitat von hdst

Bei Kameraschwenks treten gelegentlich störende Schlieren auf, die auch QTGMC nicht reduziert. Das fällt vornehmlich bei Fenstern und Treppen auf.
http://www.file-upload.net/download-66951…reppen.m2v.html
Für einen Filtervorschlag wäre ich sehr dankbar.

Was genau meinst Du hier mit "Schlieren"? Ist hier auch das Chroma-Rainbowing gemeint? Oder vielleicht so ein langsamer "Wobbel" an horizontalen Kanten/Strukturen?

Jajaa... denke mal dass es schon um dieses langsam wandernde Aliasing geht. Leider wird sich das bei Szenen wie dieser kaum vermeiden lassen. Das ist die "Resonanz mit dem Schwarzen Loch", wenn Bewegung mit einer Vertikal-Geschwindigkeit nahe bei 1Pixel/Sekunde stattfindet.
Muss heute abend mal noch etwas probieren (was der alte Bürorechner hier nicht schaffen würde ohne zu durchschmelzen), aber allzu großer Optimismus ist da nicht angebracht.

Was das Chroma-Rainbowing angeht: Schmeiß' mal den GuavaComb weg, und alle anderen Ratschläge auch, und probier' dieses hier:

mpeg2source(...)


MergeChroma( SeparateFields().blur(0,1).Weave() )  #   " Hokus, Pokus, Regenbogen verschwindibus! "


QTGMC(1,1,3,rep0=0,rep1=0,rep2=0,edimode="NNEDI3",blksize=16,overlap=8,border=true,NNsize=3,NNeurons=3)

Üpsala.

Ja mal so auf die Schnelle das kann nur Dideè. Und? Sieht es jetzt okay aus?

Muß aber eins noch sagen. Ich glaube auch,wie Goldwingfahrer,das es eine VHS(oder was weiß ich) Aufnahme ist. Nur halt vom Sender erstellt und dann über DVB ausgestrahlt worden ist.Aber so wie es aussieht,hatte man kein starkes Interesse dieses Video vorher zu verbessern.

Zitat

Ich glaube auch,wie Goldwingfahrer,das es eine VHS

nein...so habe ichs nie gesagt...ich kenne zwar ein paar User die Filme von VHS digitalisieren und dann solche Moiré und auch Dot Crawl und so im Endresultat haben.
Und weiter habe ich geschrieben dass auch an einem meiner Panas DMR wenn ich auf HDD in mpeg2 aufnehme [SP] dass ich dann auch solche Moiré sehe.

Zitat

Die haben ihr Archiv bestimmt nicht auf VHS

Allerdings nicht.....eher auf Betacam SP....DVCPRO 25 oder auf Digital-Betacam.

Auch habe ich irgendwie überlesen dass die besagte Aufnahme schon älter ist,hab angenommen es sei eine Neue.

Vielleicht solltest du das Kapitel über benannte (optionale) Funktionsparameter noch einmal ganz genau lesen: Auf den Namen kann man verzichten, solange man die Parameter in der Reihenfolge ihrer Deklaration mit Werten belegt. Erst wenn man einen Parameter außer der Reihe verwendet, muss ab dieser Stelle der Name verwendet werden.

Pflicht-Parameter werden immer unbenannt angegeben und müssen zuerst in der Parameterliste auftauchen (oder anders herum: Alle Parameter nach dem ersten benannten müssen dann auch benannt sein). Und wenn der erste Parameter der Referenzclip-Parameter ist, hat er ohnehin eine Sonderstellung, um die Verarbeitung sowohl mit funktionaler Notation als auch mit objektorientierter Methoden-Notation und mit implizitem Parameter "last" zu gewährleisten.

Nun ja ... wenn man Parameter explizit benennt, dann muss der Name auch der Deklaration entsprechen. Vielleicht gab es da Änderungen zwischen bestimmten Versionen des QTGMC-Skriptes. Oder Erinnerungslücken...

LigH, da haste den Nagel gut auf den Kopf getroffen.:) - Mit blklsize/blocksize hab ich mich ganz einfach verschrieben (MVTools-intern/vs/Script-Parameter), und überhaupt hab ich das alles mit TGMC durchexerziert, nicht mit QTGMC. (TGMC ist übersichtlich, da kann ich systemische Änderungen 'reinschreiben wie ichs gerade will oder brauche. QTGMC ist mir dafür viel zu komplex und verstrickt.) Na, jedenfalls hab ich den Parameteraufruf dann von TGMC zu QTGMC hinüber"geraten" - und bis zur v3.11 von QTGMC hätte das auch funktioniert, da war der "preset"-Parameter noch nachgestellt. Nur bei der aktuellen Version ist der "Preset"-Parameter inzwischen führend angegeben, da funktioniert's nicht mehr.

Wie auch immer - dieses schleichend umschlagende Aliasing kriegt man bei diesem Video nicht weg. Zum einen ist es ein Worstcase-Beispiel für den Fall, wo die Methode versagen MUSS: normalerweise lassen sich die fehlenden Scanlines für ein Feld->Frame ja aus den Nachbarfeldern herholen. Aber wenn der Vertikalanteil der Bewegungsgeschwindigkeit ein ganz bestimmtes Maß hat, dann ist dort, wo man die Info herholen möchte, ganz einfach "nichts vorhanden". Und wenn die Geschwindigkeit nicht genau das kritische Maß hat, sondern nur nahe dran liegt, dann bekommt man zwangsweise dieses langsame Umschlagen an horizontalen Kanten.
Zum anderen kommt noch erschwerend hinzu, dass das Interlacing des Videos ohne Lowpass-Filter des progressiven Eingangsmaterials erstellt wurde. Das ist zwar schön hinsichtlich der Bildschärfe, aber das Problem zeigt nun, warum ein Lowpass-Filter normalerweise verwendet werden sollte. Wäre er verwendet worden, dann wäre das Aliasing-Problem sehr, sehr viel kleiner.

Was ich probiert hatte, war, den MVTools-Anteil des Deinterlacers auf einen *sehr* großen temporalen Radius umzustellen (wenn die Info in den direkten Nachbarfeldern nicht drinsteckt, kann man sie vielleicht aus den +-10 ... +-20 entfernten Nachbarn gewinnen). Aber das hat nicht funktioniert. Man bräuchte für jedes Pixel einen individuellen temporalen Radius, abhängig von der jeweils individuellen Bewegungsgeschwindigkeit. Das ist theoretisch nachvollziehbar, ist aber in der Praxis fast unmöglich zu realisieren.
_____

Wie ist das jetzt eigentlich mit der Regenbogen-Entfernung? Mir gefällt der vorgeschlagene Einzeilen-Trick bei diesem Video nämlich richtig gut ...

Solange ein Filter potentiell irgend etwas am Bild ändert, gibt es keine "universelle Unbedenklichkeitserklärung".