restore24 + BlindDeHalo + LimitedSharpen

Offiziell aktuell, ja. Irgendwo im LimitedSharpen-Thread ist ein kleiner Link versteckt, zu einer schnelleren Version. Und mir sind in den letzten Tagen und Wochen so ein paar Ideen zur weiteren Beschleunigung gekommen. Modifizierung der DeRing-Routine, und eine (optionale) Ersetzung von PixieDust durch LRemoveDust. Zusammen mit der bereits getätigten Ersetzung von SSXSharpen durch LimitedSharpen sollte das dann *deutlich* schneller laufen
Kann ich nächster Tage bestimmt mal machen - schieb's ja schon längere Zeit vor mir her ...

Treib' Du mich nur ... bin's ja selber schuld: warum poste ich :idiot: den ganzen Kram auch in öffentlichen Foren?

Tja, das Wunder-Skript, das 1000 verschiedene Sachen macht und dabei auch noch in 4* Echtzeit läuft, das lässt noch auf sich warten ... und bis dahin laufen solche Sachen halt eher langsam.

Danke für's Angebot, aber rein algorithmisch hab ich die Sache bis jetzt noch im Griff. Hab zwar keinen Plan mehr, was diese 5 Dutzend von 200 Zeichen langen Strings für die verkehrte-Polen-LUTs eigentlich alle bedeuten -- aber geht schon, geht schon, kein Problem ...
Trotzdem Danke!

Oh, und bei den verschiedenen Probehäppchen auf der ersten Seite ist mir eingefallen, da hätte ich doch auch noch was...

Ist aus 'nem kleinen Feature-Test eines gewissen neuen Scriptes. Ist hier auch ohne Upsizing, noch etwas roh, bisserl stark ... aber man sieht wohl, wohin die Reise geht, oder gehen soll. Es wurde keinerlei Deringing verwendet.

Achtung: hatte vergessen, zum Enkodieren den "LumaFilter(24)" herauszunehmen, den ich beim rumprobieren gerne mal drinhabe. :redface:
Deswegen am besten in ffdshow "luma offset = -24" in den "picture properties" aktivieren - dann stimmt's wieder. Na ja.

Ein Beispiel (2.8 MB)

Noch ein Beispiel (2.2 MB)

sieht nett aus, ob man das Script irgendwie auf Realtime kriegt, so dass man es bei ffdshow mit einbinden kann *träum*

Cu Selur

Aus der Sicht von LS ist das in diesem Fall wurscht, weil Du ja die Größe durch R24 schon reduziert hast. Ich hebe nur dann die Stimme, wenn einer meint, *direkt vor* LS auf Endgröße resizen zu müssen: ist ja Quatsch, weil intern sowieso resized wird.
Noch besser ist (natürlich), LS die volle Framegröße zu liefern. Denke aber mal, dass das bei TNG wirklich keinen nennenswerten Unterschied macht.

Was mir nicht so sympathisch ist, ist der HorizontalReduce()'te Analyse-Clip für R24. Klar, es funktioniert, klar, es ist schneller ... aber zusammen mit der seit einiger Zeit verwendeten FineEdge()-Funktion verträgt sich das eigentlich nicht ganz so gut.
Wäre besser, wenn ich da noch eine "fast"-Option in R24 einbauen würde: Edge-Maske auf voller Framegröße erstellen, und erst dann für die interne Analyse reduzieren. Wäre nicht ganz so schnell wie die Reduce().Bob()-Methode - schätzungsweise nur 50% so viel Geschwindigkeitsvorteil, aber dafür auch genauer.

Hintergrund: Bedingt durch die Methode (eigentlich so 'ne Art "1. Ableitung"), hat FineEdge() eine kleine Eigenheit mit Details von 1 Pixel "Stärke" oder "Dicke". Die sind ja allgemein eher selten ... erst recht in Feld-geblendeten Normkonvertierungen. Aber durch Reduce() können solche "feinen" Details durch die Verkleinerung schon entstehen.
Z.B. hat mich Scharfi mal mit einem "Problem-Clip" versorgt, der von vornherein in 352*yyy gecapp'ed war. So wie's war in R24 gefüttert, kamen mehrere unschöne Ruckler dabei raus. Hat man den 352er Clip aber erst mal auf 704 hochgezogen und dann in R24 reingestopft, war das Ergebnis gleich besser.

edit:

Geschwindigkeitsmäßig ist R24 hier wohl eh' der größere Hemmschuh. Aber soweit's LS angeht, kannst Du das schon noch beschleunigen: Supersampling reduzieren (1.333 sollte auch noch reichen), und Smode=2 ist schneller als "3".

LimitedSharpen(ss_x=1.333,ss_y=1.333,Smode=2,strength=60~100)

Mit "strength" musste halt mal sehen. Eventuell gefällt auch Smode=1 besser, mit radius=1|2|3. Kommt immer drauf an, und ist auch Geschmackssache.
Beim Supersampling nicht unter 1.25 'druntergehen, sonst gibt's ganz bestimmt Aliasing-Probleme.

Jau, das war mein Vorschlag im Klartext

Angehängt, nur so zum Spass: eine noch weiter beschleunigte (und mächtig kastrierte) LS-Version namens "LS_schnell_schnell()" Die meisten Optionen sind weggefallen (im Funktionskopf nachsehen was noch da ist), und braucht *zwingend* die repair.dll aus kassandro's RemoveGrain-Paket.
Viel schneller geht's nicht, da hängt's jetzt nur noch am Supersampling. Empfohlen ist Smode=2 für maximalen Speed.

(Script "trocken" bearbeitet - hoffe es funktioniert auch ...)

edit: (typisch!)

Äh, ja. Sollte das aktuellste R24 sein. Von mir gab's seitdem nix neues zu dem Thema, und von Scharfi meines Wissens auch nicht.

Das steht im Original-Thread zu LimitedSharpen. (Stichwort: Aliasing.)

Kleine Anmerkung:
Bei Speedtests mit meiner neuen Kiste ist mir was witziges aufgefallen:

Man sollte BlindDeHalo nicht bei Filmen verwenden, bei denen kleien Sterne im Hintergrund sind.
Denn zumindest mit:

Sharpen(0.25)
BlindDeHalo2(3,3,150)
BicubicResize(704,304,0,0.9)
fastLS()

verschwinden kleine Sterne

Fällt beim normalen Gucken nicht auf, aber bei nem FrameToFrame Vergleich kommt einem recht schnell der Gedanke: "Sternenfresser!"

Cu Selur

@ Selur

Also, zum Bilderrätsel:

original=rechts-oben, x264+BDH=links-unten. Soweit ist's ja einfach. Welches der beiden anderen Nero bzw. x264 ist, da halte ich mich raus: Meine Erfahrung mit AVC tendiert gegen Null ... noch. Vielleicht in der 2. Jahreshälfte, oder so ... ich lass' die Technik erstmal noch reifen. Und bloß weil AVC jetzt "da ist", sehen meine schönen XviDs von gestern heute auch nicht schlechter aus

"Sternenfresser" ... hehe. Vielleicht ist Dein neuer Rechner ganz einfach zu schnell, so dass er vor lauter Eile diese kleinen Punkte gar nicht mitkriegt?

Nee. Zum einen ist das ein inherentes Problem der Methode: Für einen entsprechenden Filter sehen Sterne sehr leicht so aus, als *wären* sie das Ergebnis von EE.
Und dann ist Dein Standard-BDH-Trick mit (3,3,150) eben auch ein bisserl streng: für das tatsächlich vorhandene Enhancement bei LIS wäre wohl weniger angezeigt, so wie (2.5,2.5,125). (Grob über den Daumen.)

Ausserdem sieht man z.B. bei Nr. 4 Deiner Bilder recht schön ein anderes Problem von BDH: Die Halos werden gut entfernt, aber der (nach-geschärfte) Rand der Halos, der bleibt schon mal gerne stehen.
Deswegen bastel ich gerade auch an kombinierter Halo/Ringing - Entfernung für LS-EX.. Geht dann wieder eher in Richtung von mf's "Corona-Methode", mehr oder weniger. Im Auge hab' ich dann so'n Kombi, der erst à la BDH die Halos behandelt, und dann in einem 2. Schritt eine Bereinigung im "kleinen Wertebereich" durchführt, sowohl für restliche Halo-Ränder, als auch Moskito-Noise.

@ Trekkie

... 'tschuldigung, das ist mir jetzt gerade zu viel. Aber jedenfalls hast Du schon völlig recht - ich sollte dringend mal das aktuelle Paket mit den aktuellen Tools synchronisieren. Zumindest das ... nur wann, wuhää ...

Didée: He, he hab mit die Szenen extra rausgesucht um auf Vor- und Nachteile von BDH hinzuweisen.

"Deswegen bastel ich gerade auch an kombinierter Halo/Ringing - Entfernung für LS-EX.."
*boing, boing, freu*

Cu Selur

Zitat von Selur

Didée: He, he hab mit die Szenen extra rausgesucht um auf Vor- und Nachteile von BDH hinzuweisen.

Na ja ... noch ein Schwachpunkt von BDH ist ... der Benutzer. :zunge:

Weil - das mit dem vor-Schärfen per sharpen(0.25) kann ich mich nicht erinnern, empfohlen zu haben
Problem: Je stärker eine Region "nach Halo aussieht", umso stärker greift der Filter. Und umgekehrt. Deswegen sind die äußeren Ränder der Halos grundsätzlich ein Problem für BDH. Und durch dieses vor-Schärfen wird das bestimmt nicht besser ...

Den Sinn der Aktion seh' ich schon, ist völlig klar - Und das aktuelle Projekt enthält auch ein paar ~ähnliche~ Tricks. Der Teufel steckt halt, wie üblich, im Detail. 90% Hurra und 10% Buuuh, das will auch keiner haben ...

Das Resumée vorneweg, kurz und pauschal: Das sieht ziemlich gut aus, so wie's ist. Braucht man gar nicht mehr viel 'rumspielen, kann man so durchlaufen lassen.

(Mann oh mann, wenn ich da meine alten, per FieldDeinterlace zusammengemanschten Analog-Capture-Ruckel-und-Ghosting-in-Briefmarkengröße TNG Encodings dagegenhalte ... WUHÄÄÄH! Total für'n Müll, schade um die aufgewendete Zeit )

Mehr ins Detail:

Was Halo-Entfernung angeht ... tja, da hab ich schon viele, ganz viele Abende 'reingesteckt, und nach jedem hatte ich weniger Haare als zuvor. Die "perfekte" Universal-Lösung gibt's einfach nicht. Letztlich ist das ja alles nur geraten. Auch wenn ich mich wiederhole: eine *Erkennung* von Halos ist extrem schwierig, und BDH versucht das erst gar nicht. (Über ein Skript ist das erst recht kaum hinzukriegen.) Man kann halt nur - unter der Voraussetzung *dass* eine Quelle *prinzipiell* mit Halos behaftet ist - die Methode "je größer die min-max-Spanne in einem Bereich ist, umso größer die Wahrscheinlichkeit, dass so-und-soviel von dieser Spanne ein 'Halo' darstellen" anwenden, und mit den vorhandenen Parametern möglichst gut anpassen.
Und dann ist's ja noch zumindest denkbar (wenn nicht sogar wahrscheinlich), dass bei dem Mastering-Prozess der die Halos verursacht hat, unterschiedliche Einstellungen für verschiedene Szenen verwendet wurden (!). Wenn dass der Fall ist, dann ist das Ergebnis von BDH mit festen Einstellungen natürlich auch unterschiedlich ...

Tja, sorry, aber Besseres hab' ich leider nicht anzubieten. Wenn jemand etwas flexibleres oder intelligenteres als BDH erfinden würde, wär's mir auch recht. Bis dahin muss man sich halt mit dem tapferen kleinen Versuch von BDH irgendwie arrangieren

Betreffs der Schärfe, und "noch mehr Schärfe":

Würde mal sagen, dass die *eigentliche* Schärfe in den Demo-Clips schon weitgehend ausgereizt ist. Viele Features sind jetzt schon mehr oder minder "rasiermesserscharf" - wenn Du da noch mehr an der Schraube drehst, gibt's schnell Aliasing. Ich würde vielleicht sogar, ganz im Gegenteil, das derzeitige Ergebnis noch ein wenig "abschmelzen". So in der Gegend von

MergeLuma(last.blur(1), 0.12~0.24) # oder auch >>last.yv12convolution("1 4 6 4 1","1 4 6 4 1")<<

ganz am Scriptende.

Was da noch fehlt, ist nicht etwa Schärfe. Was fehlt, ist *Detail*. (Aber woher nehmen, und nicht stehlen?)
Wenn insgesamt zu wenig Detail da ist, dann entsteht eben der Eindruck von "Leere", und da hilft dann alles Schärfen nichts.
Eventuell könntest Du noch ein wenig mehr Detail (falls überhaupt vorhanden) herauskitzeln ... mit Selur's Methode: erst ein wenig vorschärfen, und dann die Parameter von BDH leicht erhöhen, bis es wieder passt. Geht auch besonders gut mit der "abschmelz-Methode" von oben zusammen.

(Es gäbe da auch noch eine andere Methode um schwächelndes Detail zu verstärken ... aber wenigstens die Überraschung möchte ich mir doch gerne für LS-EX aufheben :zunge: )

P.S. Von welchem Sender nimmst Du eigentlich TNG auf? Da ist ja gar kein Logo drin ...