Bewegungskompensiertes Deinterlacing - mvbob()

Scharfi, nur mal ein Vorschlag: Könntest du den DLL-Dateien in deinem Package eine Versionsnummer dranhängen?

Das wäre noch 'ne Idee. Grundsätzlich sollte man wohl von allen Plugins auch jeweils "das Neueste" nehmen können ... mit Ausnahme vielleicht von EEDI2. Scharfi sagt, die beigefügte (ältere) Version sei besser beim Verbinden von Diagonalen als die neueste EEDI-Revision von tritical.

Und, noch so'n kleines Detail:

Zitat

PointBob(clip Input) ... - does NOT accept YV12!

lässt sich umgehen, indem man ganz einfach die Resizer zum Croppen benutzt:

Function PointBob(clip Input)
{	
	w = Input.Width()
	h = Input.Height()
	Order = Getparity(Input)# ? False : True
	Input = Input.SeparateFields()
	Even  = Input.SelectEven() 
	Odd   = Input.SelectOdd() 
	Even = Order ? Even.PointResize(w, h, 0,1,w,h/2+.001) : Even.PointResize(w,h)
	Odd  = Order ? Odd.PointResize(w,h)  : Odd .PointResize(w, h, 0,1,w,h/2+.001)
	Interleave(Even, Odd).AssumeFrameBased()
	Order ? AssumeTFF() : AssumeBFF()
}

Oder spricht da etwas dagegen? (Chroma?)

Oh mann, das wird noch mal mein Sargnagel. Habe mir "Halbbild-Legastheniker":) ja in letzter Zeit selber einige Nachhilfe gegeben, aber interlactes YV12 und Chroma, da verknoten sich die Neuronen immer noch zum Gordischen.

Ja, aber ... wie ist denn das eigentlich, so gesehen, mit dem "üblichen"

Bob.SeparateFields.SelectEvery.Weave

Das *soll* ja verlustlos sein, d.h. keine Veränderung der Originalfelder verursachen. Aber, geht das denn überhaupt mit den Chroma-Ebenen bei YV12 interlaced? (Und bei Luma versteh' ich's eigentlich auch nicht so ganz...)
Weil: der Bob-Filter führt ja auch eine Subpixel-Verschiebung der Felder durch !! (Normalerweise 0.25 Pixel up/down, IanB hat ja mal die genaue Formel gegeben).
Allein durch diesen Subpixel-Shift beim Bobben müsste doch die "Verlustlosigkeit" bereits ad absurdum geführt werden, weil bei dem anschließenden SeparateFields eben nicht mehr die Originalfelder selektiert werden können, sondern nur noch die bereits um 1/4 Pixel verschobenen 'Originalfelder' !
Oder nicht?

Ich höre schon "YV12 ist halt für interlacing nicht geeignet", aber das hilft ja auch nicht weiter. Es gibt diese Sourcen nun mal ... und es kann nicht sein, dass man sie nicht "korrekt" bearbeiten kann.

Nix AVS Bug: Scripter's Bug.;) Hab's wirklich ohne Ausprobieren hingeschrieben (weil, "hat ja am anderen Rechner auch funktioniert"), und ne Kleinigkeit vergessen:
0,1,w,h/2+.001
(Oder alternativ h=even.height() setzen.)

Dann klappt das schon.

Wieso habt ihr eigentlich mcbob hier noch nicht vorgestellt? Bei mir liefert es zumindest ganz gute ergebnisse, abgesehen von ein paar Artefakten. Hat MVBob ja auch...

Also gut, dann stelle ich mal vor:

Zitat

(Mitten im Party-Getümmel)

"Community: MCBob ... MCBob: Community.

- Getränke holt ihr euch an der Bar."

Is' halt noch nicht fertig. Was hilft das beste Konzept, solange die Praxis dir immer noch 'ne lange Nase dreht ... warum also viel Staub aufwirbeln.

Problem ist, die Fehlererkennung von dem vieeelen MVFlow-Murks eng genug einzugrenzen. Die Fehlstellen sollen ja ALLE erkannt werden (irgendwer kommt immer mit 'nem FreezeFrame daher, zeigt mit dem Finger auf ein Pixel, und ruft "Da! Artefakt! Ein Artefakt! Unbrauchbarer Schrott!!"), ohne die "guten" Stellen mit anzutasten, weil's dann ja wieder flimmert. Und aus den per Script verfügbaren Perspektiven sieht "gut" und "schlecht" oftmals so verdammt gleich aus ...

Probier(t) doch mal den ToyTrain- und den ScrollingText-Clip, evtl. auch den Musicians (Links gibts hier). ToyTrain hat Artefakte (rotierendes Dingsbums links unten), und zeigt leichtes Restflimmern (Schafe). ScrollingText trickst die derzeitige Fehlererkennung vollständig aus: die großen Buchstaben bobben zu 100%.

Was das Potential angeht: Spaßeshalber mal jegliche Fehlerbehandlung abschalten, indem am Scriptende einfach nur der Clip "naked" ausgegeben wird ... Aha, ohne Fehlerbehandlung sieht man: es bobbt gar nichts, es flimmert gar nichts.
Da woll'n wir hin, oder? Nur halt ohne durchschlüpfende Artefakte ...

Bin verschiedene Sachen am testen, aber ... wo immer man ein Loch stopft, tut sich woanders ein neues auf. Wie immer halt.

Für's erste bleibt MCBob also die langsamste aller verfügbaren Möglichkeiten, vorhandenes Potential nicht vollständig auszuschöpfen.

Hallo Didee ,
MCbob liefert teilweise echt erstaunliche Ergebnisse !

Ich habe da ein 25>30fps telecinetes Video , das ich mit Repal wieder auf 25 bringen will.
nicht alle Bobber funktionieren hier , bis jetzt nur leakkernelbob und mcbob.
leakkernelbob ist ja nicht so der Hammer , mcbob viel besser , nur :

da gibt es bei Bewegungen oft Streifen (Art vertikal versetzte Doppelkanten):
zb frame 20 , 28 Gesicht des Mannes

ausserdem sind die Farben oft nicht syncron:
zb frame 10 , 15 Kopf des Mannes

Sample(10mb huffyuv): http://www.megaupload.com/?d=23E0PDV3
Script:

[size=10][NOPARSE]
avisource("mc test.avi")


DeDot()
assumebff()
ConvertToyv12


mcbob()
repal()
[/NOPARSE][/SIZE]

liegt es am Ausgangsmaterial ? oder muss ich Mcbob-Parameter ändern ?
oder hat jemand ne andere Idee für das Video, restore24 hat irgendwie nicht geklappt !

vielen Dank schonmal ! Flo

Da is' nix telecined ... Normkonvertierung per fieldblending.

==> MCBob hat hier schon mal *gar nichts* verloren (Komma, und MVBob auch nicht)

... und was, bitteschön, verbirgt sich hinter

>> "restore24 hat irgendwie nicht geklappt "

Irgendwie ist irgendwie etwas unklar.

Hab' jetzt echt keine Zeit zum encoden & hochladen, aber ich hab' das Sampelchen mal schnell-schnell in Restore24 'reingestopft, und das Ergebnis sah eigentlich ziemlich "richtig" aus ...

Wahrscheinlich wirklich an der falschen Stelle gepostet.
wenn ich mit dem Thema umziehen soll sagt bescheid , und wohin !

is fieldblending nicht dem telecinen ähnlich ?
Das Farbproblem hab ich gelöst , ich hatte einfach bei Converttoyv12 kein interlaced=true aktiviert

wieso hat mcbob hier nichts verloren , Repal benötigt doch einen guten Bobber ?
"restore24 hat irgendwie nicht geklappt" heist , dass die obige Lösung viel bessere
Ergebnisse liefert , als sowohl das alte als auch das neue Restore24 .
r24 doppelt einige Bilder , haut dafür andere ganz raus ! Repal nicht ...
vielleicht hab ich r24 falsch mit Params gefüttert , neues r24 :

Restore24(r24fps=23.976,numr=1250,deno=2997,useLL=true,stringuent=false,fulltriples=false r24deint=1,fra=1,frr=1,edgetype=0,edgemode=2,edgeeval=2,r24size=.75,r24ysize=0.75,ldmp=32.0,debug=0)

hab wenig Ahnung von den Params des neuen r24 , beim alten hab ich diverse Bobber getestet

wie gasagt leakkernel,mcbob + repal alles super > ausser den "Doppelkanten"

He, es gibt ja schon ne neue Version!

http://home.arcor.de/dhanselmann/_stuff/MCBob_v03c.avs

Didée: was dagegen wenn das in die Didée Filter Cloection kommt? oder noch zu Beta?

Könnte man eigentlich dazunehmen, jo. Hat zwar noch so einiges Entwicklungspotential vor sich, aber ausdrücklich schlecht sind die Ergebnisse ja nun auch wieder nicht;) ... und vor Herbst'07 wird sich da sowieso nichts bewegen.
Zumindest aber sollte Vinverse() als Script-Funktion herausgenommen, und stattdessen triticals Plugin verwendet werden ... ein paar Erklärungen bzgl. der Parameter wären auch nicht schlecht.
... Und da geht's schon wieder los, von wegen was noch alles zu tun wäre. Ja,ja ...

P.S. Geht's nur mir so, oder klingt

Zitat von Redfox

Filter Cloection

irgendwie nach "Kloake" ... ?