Beiträge von Didée

Ja, wegen dem StackHorizontal() am Ende. Mach ein # - Kreuzchen davor, dann passts schon.

@Goldi - wenn alles funktioniert, lass es wie es ist. Ich hab auch nur schnell passende Links zusammengegoogelt. Die verlinkten funktionieren auf jeden Fall. Ob oder wie andere / ältere / neuere Versionen funktionieren oder nicht, das ist mir im Moment sowas von Latte, ehrlich gesagt ...

masktools v2.0-a48 (die masktools-25.dll benutzen wenn Avisynth=v2.5.8, die masktools-26.dll benutzen wenn Avisynth=v2.6)
RemoveGrain 1.0-pre (Nur RemoveGrainSSE2.dll und RepairSSE2.dll benutzen)
NNEDI3 v0.9.4
TIVTC v1.0.5

Vermutlich schon. Aber ob Du auch weißt was ich meine?

Es besteht - in der Theorie - ja wohl gar kein Zweifel, dass ein 25fps Film, abgespielt auf einem 50Hz Display mit 2:2 Pulldown, eindeutig "flüssiger" ist als ein 24fps Filme, der mit 3:2 Pulldown auf einem 60Hz Display abgespielt wird. Bei 2:2(50) ist jedes Bild 40ms lang. Bei 3:2(60) sind die Bilder abwechselnd 33.3ms / 50ms lang. 2:2 ist gleichmäßig, 3:2 ist ungleichmäßig. Also ist 2:2 "flüssiger".

Wenn ich's aber in Real auf dem PC-Monitor teste, dann tu' ich mich ehrlich gesagt ziemlich schwer, einen deutlichen Unterschied zwischen den beiden Varianten zu erkennen. Das Stichwort ist hier "Sample+Hold --> Netzhaut-Bewegungsunschärfe". Die überlagert bei diesen geringen Bildwiederholraten nämlich sehr stark die Wahrnehmung der Bewegungsdarstellung, und deswegen wirkt der eigentlich flüssigere 2:2 Pulldown fast genauso ruckelig wie der 3:2 Pulldown.

Und bei 12Hz Bewegungsphasen von Animationen ist so gesehen sowieso alles ruckelig. Ist ja mehr eine bessere Einzelbildschaltung, denn eine Bewegtbilddarstellung.

Nö, beim Ton muss man nichts anpassen. Hat Selur doch schon gesagt - ändern tut sich bei Srestore nur die Bilder-pro-Sekunde, aber die Spielzeit bleibt die gleiche. Kleine Unterschiede ergeben sich immer, wegen der unterschiedlichen Framelänge. PAL(25): 40ms, NTSC(24): 41.7ms. Leg' mal eine Referenzstrecke mit Bauklötzchen von 4cm Länge. Dann nimm Bauklötzchen von 4.17cm Länge, und versuche die Referenzstrecke mit genau der gleichen Länge zu legen. Ah, geht nicht.

Und wegen der Beurteilung ob die 24fps oder die 25fps flüssiger laufen: Wenn man an einem PC-Monitor sitzt der mit 60Hz läuft, dann ist sowas eher schwierig zu beurteilen.:) - (Wird ja alles mit zusätzlichem Pulldown abgespielt. Entweder muss der Monitor jeweils auf 50Hz und 24/48/72 Hz umgestellt werden, oder man verlangsamt beide auf einheitlich 20fps (oder beschleunigung auf 30fps). Dann kann man Unterschiede viel besser beurteilen.)

Außerdem - bei solchen Animationen von "flüssiger Bewegung" zu reden ist ja sowieso ein Witz. Mit 12Hz Bewegungsphasen gibt es keine "flüssigen" Bewegungen. Man kann vielleicht von "gleichmäßig" reden, aber doch nicht von "flüssig".

Propaganda: Speedup ist das Zauberwort.

Die Präsenz der ungebrochenen 2:2 und 4:4 Patterns ist zwingend. Da gibt's eigentlich gar nix zu diskutieren.

Bei Deinem Srestore-Ding fehlen Frames, in regelmäßiger Folge! Schau doch mal z.B. die letzte Szene (Straße/vogelperspektive). Im einfachen Bob: immer 2-2-2-2-... Frames. Nach Srestore: 2-2-2-...-1-2-... Frames. Das ist doch nicht richtig!

Das Quellmatarial hat völlig eindeutige, reine 2:2:2:2 und 4:4:4:4 Patterns. Genau diese Pattern sind im ursprünglichen 24p drin gewesen. Weil Speedup verwendet wurde, stecken jetzt die gleichen Pattern immer noch im 25i50 drin. Es wurde zur Konvertierung nichts dazugerechnet. Wo nichts hinzugefügt wurde, da muss nichts entfernt werden.

Es stimmt schon dass bei einfachem Fieldmatching (mein Script) Fehler an den Szenenwechseln auftreten. Das ist aber ein Problem des vermurksten Quellmaterials, das mit Sicherheit eine Reise von 24p über Pulldown/30i mit anschließender Rückkonvertierung hinter sich hat. Da waren irgendwelche Automaten im Spiel, und die machen halt öfters mal Fehler. Trotzdem ist das Prinzip richtig, nämlich NICHT 1 Frame aus 25 zu entfernen. Von der Bildfolge her müssen alle Fields/Frames drin bleiben. Dass einige dieser Fields/Frames fehlerhaft sind ist natürlich Sch..ade. Aber deswegen dürfen sie nicht einfach weggeschmissen werden.

Hab doch gesagt, dass die verstreuten Einzelblends hier völllig ignoriere.

Kammeffekte gibt's bei dem geposteten Script keine, deswegen ist ja NNEDI drin. Bitte beachten dass im Script ohne/mit NNEDI nebeneinander gezeigt werden. Das rechte Bild ist das gute. Nicht das linke.

Und das Ergebnis läuft mit Sicherheit flüssiger als Dein Srestore-Vorschlag. Der entfernt mit der zu-24fps-Wandlung einzelne Frames aus den 4:4 und 2:2 Sektionen, d.h. da fehlt dann ein Frame pro Sekunde, der eigentlich da sein soll. Das kann unmöglich flüssiger sein ....

In diesem Fall ist es aber nicht richtig, das Material mit Srestore auf 24fps zu reduzieren. Es scheint nämlich ein Speedup zu sein - mit Bob() angeschaut, seh' ich eigentlich nur reine 4:4:4:4 und 2:2:2:2 Sequenzen , ohne zusätzliche Verdopppelungen oder sowas. (Es sind ein paar vereinzelte Blend-Fields drin, aber die überseh' ich einfach mal. Keine Ahnung wie die 'reingekommen sind, aber mit einer 24<>25 Fps-Konvertierung haben die hier nichts zu tun.)

Ich würd da einfach nur Fieldmatching machen, und dann noch mit NNEDI das Aliasing entfernen:

mpeg2source("beispiel_(Nel-son).d2v")
tfm(pp=0,slow=2)
a=last
a.nnedi3(field=-2)
merge(selecteven(),selectodd())
d1=mt_makediff(a,last)
d2=mt_makediff(last,last.removegrain(20))
dd=d2.repair(d1,13)
last.mt_adddiff(dd,U=2,V=2)
#frfun7(1.01,10,12) # mussnich sein, nur 'ne Möglichkeit für ein einfaches Cleanup
stackhorizontal(a,last)
return(last)

Der "omode" schaltet doch um zwischen 'normalem' Blendremoval und dem BlendIVTC-Removal.

Es müsste so sein:

omode = 1 - 5
Keine Änderung der Framerate. Es werden nur erkannte (vermutete) Blends durch Nachbarframes ersetzt.
Input = bobbed

omode = 6 (default)
Blendersetzung + Dezimierung:
50 --> 24
60 --> 25
Input = bobbed

omode = {string}
BlendIVTC-Removal, also [a b bc cd d] --> [a b c c d] + Dezimierung, also
30 --> 24
Input = normal, kein bob

Das sind die Standardfälle, die üblicherweise auftreten und Sinn machen. Was der Automatismus beschließt wenn nicht-Standard-Framerate 'reinkommt, bzw. wenn die Methode nicht zur Framerate passt, das weiß ich jetzt auch nicht.

Man muss sich das mal SO anschauen - dann sieht man sehr schnell das eigentliche Problem:

mpeg2source("G:\Benutzer\Dieter\Downloads\308_cut\308_cut.d2v")
bob()
stackhorizontal(last,stackvertical(last.utoy(),last.vtoy()))

In dem Material sind die Chroma-Ebenen gar nicht interlaced. Die Bottom-Fields enthalten genau das "gleiche" Bild wie die Top-Fields.
Wenn also in einem Bottom-Field ein anderes Bild drinsteckt als im Top-Field, dann ist zu diesem Bild leider die richtige Chroma-Information gar nicht vorhanden. Und wenn im Bottom-Field ein Bild drinsteckt, dass man eigentlich "unbedingt braucht", dann hat man ein Problem.

Der spontane Gedanke ist, dass man zumindest in 12fps-Sektionen Chroma von einem Nachbarbild verwenden könnte ... aber das ist ziemlich problematisch, weil ja alles voller Field-Blending ist, kann man (per Algorithmus/Filter) kaum unterscheiden, was eigentlich gut und was schlecht ist. Und der Umstand, dass auch in den Blend-freien Lumafeldern oftmal ein "negatives Highpass-Blending" drin ist, hilft der Sache nicht wirklich. Und in 24fps-Sektionen geht's sowieso nicht.

"Some shit simply is beyond repair."

Falsch ist aber die Annahme, dass ein x2 skaliertes Bild eine Art "Optimum" darstellen würde und eine weitere Skalierung dann eine Verschlechterung bringen würde. Kann zwar sein, muss aber nicht. Eher sogar im Gegenteil: eine x2-Skalierung dieser speziellen Art sollte oft sogar noch weiter gefiltert werden.

Punkt ist, dass diese Edge-directed Algorithmen die diese x2/x4/etc Beschränkung haben, sie aus einem bestimmten Grund haben: sie nehmen die "Originalpixel", und ziehen sie auseinander so dass jeweils 1 Pixel Zwischenraum entsteht. Die Zwischenräume werden dann gefüllt, und die "Original"pixel werden beibehalten.
Berechnungstechnisch ist es sehr naheliegend, es so zu machen. Bildtechnisch, bzw. Frequenztechnisch betreffs des Bildsignales, ist das Ergebnis aber so gar nicht "richtig". Ein Originalpixel ist ein Representant eines lokalen Frequenzbandes im (kleinen) Originalbild. "Verpflanzt" man dieses Originalpixel unverändert ins große Bild, dann sollte das Pixel nun eigentlich ein anderes (engeres) Frequenzband representieren. Was es aber nicht tut, weil es ja unverändert übernommen wurde ...

Um's nicht ausufern zu lassen, kürze ich jetzt mal ab:

Am Anschluss an eine x2- oder x4 -Skalierung kannst Du ziemlich beruhigt mit einem "normalen" Resizer auf die genaue gewünschte Endgröße u/o Seitenverhältnis skalieren. Dabei entsteht kaum ein nennenswerter Verlust.

Und das was eigentlich noch zu tun nötig wäre, - eine Art von Frequenzverdichtung -, das ist dann nochmal ein schwieriges Thema, an dem man sehr viel herumknobeln kann.

Der Witz am "Objektiven Qualitätsverlust" ist aber, dass man ihn in der Praxis meist gar nicht feststellen kann. Ich meine, sicher ... wenn man erst von groß zu klein skaliert und dann wieder zu groß, dann sinkt natürlich die Qualität. Aber darum geht es in der Praxis ja gar nicht. In der Praxis HABE ich ein SD-Video, und ich HABE ein FullHD-Display, auf dem ich das SD-Video darstellen muss. Also muss man irgendwie hochskalieren. Macht man "nichts", dann macht's eben der Player oder der TV. Der Wunsch und Versuch, es mit Zeit- und Rechenaufwand besser zu machen als die einfachen Realtime-Filter, ist durchaus zulässig.

Von Qualitätsverlust zu sprechen passt da irgendwie nicht so gut, finde ich. Eine DVD wird ja nicht dadurch schlechter, dass ich sie auf einem heute üblichen Fernseher abspiele. Eine größere Referenz existiert hier ja nicht, das kleine Bild von z.B. einer DVD oder TV-Aufnahme ist ja mein "Original".

Mit 'nem SW-Player natürlich möglich. Skaliert wird es aber trotzdem nochmal. In dem Fall macht's dann halt der Bildschirm-Renderer, wenn er's für die Anzeige auf 1920x1080 skaliert.

-edit-

Mit doppeltem Zeitbedarf könnte man auch ein beinahe-Placebo durchführen:

720x576 --2X--> 1440x1152 --> Downscale: 960x540 --2X--> 1920x1080.

Das ist dann bestimmt doppelt so gut, weil man den Wunderfilter ja 2 Mal verwendet hat.

[*duckundweg*...]

Wenn's nur um die Analyse des 2*Scaling -Ergebnisses geht, dann okay. Aber, für ein "praxistaugliches" Endergebnis musst Du auf jeden Fall noch einen zusätzlichen Resize-Step machen. Ansonsten gibt's "Eierköpfe".

Andererseits - wenn jemand beim Herumspielen mit "normalen" Videoquellen wirklich so unglaublich gute Ergebnisse 'rausbekommt wie es die jeweiligen Werbeabteilungen versprechen, dann - nur keine falsche Zurückhaltung, bitte die Ergebnisse unbedingt hier posten! :):)

Hoppla, stimmt, die Szenenwechsel sind nicht ganz koscher. Na, vermutlich wurde das NTSC-Material im Pulldown-Status editiert, dadurch wurden an den Schnittstellen verwaiste Felder produziert, und bei der Wandlung zu PAL wurden die dann irgendwie hinein-verblendet. Oder sowas in der Richtung.

Soll das überhaupt repariert werden? Die 1, 2 Frames an den Szenenwechseln sind doch harmlos. Es ging doch eigentlich darum, dass auf dem TV ständig alles voller Kammartefakte ist ...

... und wenn ich das Sample per USB-Stick an meinen TV (Samsung D6500) verfüttere, dann spielt der das auch ohne Artefakte ab.

Progressive/PhaseShift ist zwar irgendwie doof, aber absolut zulässig und "im Standard". Entweder kriegt der Plasma das Fieldmatching / Pulldown-Removal nicht gebacken (evtl. muss man an irgendwelchen Deinterlacing-Optionen etwas umstellen, damit 2:2 Pull mit PhaseShift korrekt verarbeitet wird ... bei meinem Samsung ist in diesem Fall "Filmmodus=Auto1" auch besser als die "Universalwaffe" Auto2), oder der HTPC/XBMC macht irgendwas mit dem Ausgangssignal, so dass der TV keine Chance mehr hat. (Falsches Upscaling, oder Signal als progressiv flaggen, oder werweißwas.)

Jedenfalls, das Video als solches scheint kein Problem zu haben. Mit dem ist alles in Ordnung.

Ist ja nicht so, als ob das "Superresolution" -Thema nicht schon mehrfach durchgekaut worden wäre ...

Superresolution kann vor allem dann arbeiten, wenn das Quellmaterial hinreichen viel Aliasing hat. Das kann sein zum Beispiel sein, wenn von einem "großen" Kamerasensor ein kleines Bild generiert wird, indem nur jedes x-te Pixel abgenommen wird.

Im Fall der Infognition Seite (bzw. MSU) ist es so, dass ein großes Bild auf Briefmarken-Größe reduziert wird. Bei der enstehenden "sehr kleinen" Auflösung hat man zwangsweise ein relativ hohes Aliasing, deswegen lassen sich hier relativ schöne "Showcases" aufbauen, in denen man die angebliche Mächtigkeit der Methoden demonstrieren kann.

In den meisten "normalen" Quellen, sagen wir mal normaler SD-Input von DVD oder von DVB-Sat, sind diese Voraussetzungen aber gar nicht gegeben. Das nötige Aliasing ist in dieser Form gar nicht gegeben, und noch dazu muss man hier mit den Kompressionsartefakten kämpfen: Einerseits erfordert dediziertes Upscaling ein gutes Maß an sehr spezieller Schärfung und "Emphasizement", was aber bei Artefakten im Quellmaterial gar nicht gut kommt. - Andererseits, im "Showcase" -Fall wird dieses Problem trickreich umgangen: durch die Verkleinerung auf 25% verschwinden auch die meisten Artefakte, wodurch dieser Problempunkt hier gar nicht erst zum Tragen kommt.

Es bleibt also dabei, was schon in der Diskussion letztes Jahr festgestellt hatten, und vorletztes, und vor-vor-letztes, ... überhaupt jedesmal, wenn das Thema wieder einmal aufs Tapet gebracht wird:

Es gibt Spezialfälle in denen Superresolution scheinbare Wunder vollbringen kann. Aber in den "Regelfällen", mit denen man typischerweise arbeitet, bleibt von der Wunderwirkung so gut wie nichts mehr übrig.

Deswegen ist, im Regelfall, ein Upsizing mit NNEDI3, plus ein wenig spezielle Schärfung, plus ein wenig temporal-Filterung, so nahe am Optimum wie man es mit einfachen, vertretbaren Mitteln überhaupt nur hinbekommen kann.

Was heißt "macht das Sinn" ... es geht bei e.d.i. eigentlich gar nicht anders. Es bleiben ja die Original-Pixel 1:1 erhalten, und es werden nur neue Pixel *dazwischen* eingefügt.
(Die einzige Möglichkeit das Post-Resizing zu vermeiden, wäre, es einfach "heimlich" intern zu machen, und dem User nix davon zu sagen...)

* * * * *

Ich möchte fast wetten, dass die die PSNR-Kalkulation vergeigt haben. Stichwort Subpixel-Shift.

Zitat

Many tools shift image by 1-3 pixels when upsizing it 4x. Although images shown in this comparison are taken "as is" demonstrating the shifts, PSNR values were calculated with the shifts compensated: videos were shifted by an integer amount of pixels which provided maximum PSNR for each of the methods. For example, InstantHD videos were shifted by 1 pixel and vReveal by 3 pixels. When measured without shifts their PSNR is much lower than shown in the charts here.

Aha. "By an integer amaount of pixels".

Ich weiß nicht wie's bei InstantHD oder bei vReveal ist, aber bei NNEDI3 hat man keinen ganzzahligen Pixel-Shift. (_rpow2: bei 2x sind's 0.5 Pixel, bei 4x sind's 1.5 Pixel.)

Wenn die also nur "Grob-Kompensation" auf ganzzahlige Pixel gemacht haben, dann sind die PSNR-Werte natürlich deutlich schlechter als sie eigentlich zu sein hätten.

Also, als ich vor ... drei, vier Jahren oder sowas ... den MSU-Enhancer probiert habe, war ich ausgesprochen wenig beeindruckt (Englisch: "underwhelmed") - Extrem langsam, und ich hab mich ziemlich schwer getan, in dem Output irgendeine Rechtfertigung dafür zu finden.

Und wie gesagt, PSNR Scores. Die Chart-Grafik zeigt doch ganz eindeutig:
Doofes Bicubic, doofes Lanczos, doofes Spline36: Jeder einzelne dieser Basis-Resizer hat bessere PSNR-Scores als NNEDI3!

Da fragt man sich doch, wieso "alle Welt" so sehr von NNEDI3 schwärmt. Es scheint doch einer der schlechtesten Resizer überhaupt zu sein.

Vielleicht liegt das Geheimnis darin, dass man den Chart umgekehrt lesen muss? Je schlechter das Scoring, um so besser das Praxis-Ergebnis? :seher: