Vorschläge Anime AVS Skript

In Ordnung, wird wirklich zu offtopic.

Didée
Also ich komprimiere mal ohne DeHalo (dauert auch ohne schon mind. 16 h :P), mal sehen, wie es dann aussieht. Ansonsten werd ich einen Freund bitten, mit DeHalo zu komprimieren, falls du noch etwas Gutes anbieten kannst. In dem Fall könnte man den neuen Befehl, der noch kommen kann, dann auch ins Skript aufnehmen für "arge Halos".

Zitat von Didée

Also was die Halos angeht ... Mr.Browns Script macht das doch schon ziemlich gut <g> , würde ich mal sagen. Deinorius, darfst Dich nicht von all' dem Moskit-Noise in dem Sample verwirren lassen: natürlich darf man ein XviD-encoding von so einem Anime nicht mit dem Preview in VirtualDub vergleichen ...

Hab ich doch gar nicht. oO Lies den Beitrag danach. Ich hab nur die Halos gemeint.

Hab einen Deinterlacer-Test auf Doom9 gefunden. Das was ich interessant fand ist, dass dort u.a. TDeint mit EEDI2 (maxd=20, nt=150) benutz wurde und noch bessere Ergebnisse lieferte als ohne. Weiß leider nicht was das genau macht (scharfis_brain fragen, der hat mitdiskutiert), aber möglicher weise wäre es eine überlegung wert es ins Script mit auf zu nehmen.

Was da gemacht wird, kann man grob so erklären:

EEDI2 ist kein Deinterlacer, denn er hat keine Erkennungsroutinen für sowas. Dafür ist das Teil super, wenn es ums Interpolieren geht.
TDeint hat diese Routinen, kann aber nicht so gut Interpolieren wie EEDI2, da liegt es nahe, beide zu kombinieren.
Die Parameter schließlich sind eine besondere Einstellung. Die muss man aber an den jeweiligen Videotyp anpassen.

Mr. Brown

Hattest du eigentlich schon mal Dup von neuron2 getestet?

Bei alten und einfachen Cartoons ist der echt praktisch um ein bischen Bitrate einzusparen.
Ich benutze ihn immer in meinem Simpsons-Skript, weil da meist jeder Frame doppelt ist und Dup eleminmiert dann alle Unterschiede (Noise) zwischen diesen Frames.
Ich benutze diese Einstellungen:

Dup(threshold=2,blend=true)

Die Standartwerte hatten manchmal den Effekt das mimimale Bewegungen im Hintergrund nicht erkannt wurden.
Bei neuen Animes wird dieser Filter nutzlos sein, aber bei Simpsons und wahrscheinlich noch mehr bei Southpark könnte er durchaus helfen. Natürlich muss man vorher dotcrawl und ähnliche Temporale Noise soweit wie moglich reduzieren, weil sie die Duplikaterkennung verfälscht.

Dieser Filter ist bei Trickfilmen mit limited motion sinnvoll, also bei solchen, die mit nur wenigen Frames pro Sekunde erstellt wurden. Bei Trickfilmen mit full motion ist er eher kontraproduktiv.
Bei Animes ist es meist so, dass die, die fürs Kino produziert wurden, entweder full motion oder einen Mix aus full und limited motion haben.

Dem stimme ich voll zu.

Zitat von Kika

Bei Animes ist es meist so, dass die, die fürs Kino produziert wurden, entweder full motion oder einen Mix aus full und limited motion haben.

Jepp, und Animeserien sind immer limited.

Zitat

Jepp, und Animeserien sind immer limited.

Exakt. Drum sollte man immer erst schauen, was man überhaupt als Source hat, bevor man ein spezielles Script entwickelt. Es gibt einige eigentlich gute Scripte, die bei limited versagen, während sie bei full genial gut funktionieren. Leider ist das Encodieren von Animes genau genommen viel komplizierter als das von Realfilmen oder Computer-Animationen.

So, ich habe mal ein wenig an meinem TemporalMedianMix gearbeitet. Im Anhang findet Ihr ein Vorher/Nacher-Beispiel. Natürlich gibt ein einzelnes Bild die Wirkung nicht wirklich gut genug wieder, aber wie man sieht, wird das Rauschen ganz gut entfernt, während Details weitestgehend erhalten bleiben - auch Farbverläufe werden nicht "platt gemacht". An der Linienbearbeitung arbeite ich aber noch, die macht noch Fehler und wirkt auch noch nicht ganz so, wie ich sie gerne hätte.
Inzwischen habe ich bereits mehrere Trickfilmepisoden von Drittgenerationen-VHS-Captures damit bearbeitet und bin schon mal zufriedener damit als mit vielen anderen Lösungen. Denn das Eckenproblem von Median-Filtern sowie das Nachziehproblem von Temporal-Filtern werden weitestgehend eliminiert.

Wo wir gerade bei der Unterscheidung von 'limited motion' und 'full motion' sind:
Auf dieser Animeseite gibt es einige interesante Hintergrundinfos darüber, wie Animeserien im letzten Jahrtausend produziert wurden. Nicht sehr ausführlich, aber recht anschaulich gemacht, insbesondere die Technik mit den Cels. Ob das mit der Framerate aber so komplet richtig ist, da bin ich mir nicht ganz sicher. http://www.jasms.de/d_bank/cell01.html
Auf der gleichen Seite gibt es auch ein technisches Glossar: LINK

Kika: Wird heut Abend getestet. :daumen:

Ich hab da auch was temporäres im bezug auf Cartoons/Animes auf der Werkbank, das in den nächsten Tagen diskusionswürdig wird. Es geht mir zwar primär darum die Simpsons Pro7~DVB-T Captures die noch auf meiner Platte versauern (ca. 35 GB) irgendwie decodierfähig zu bekommen(und die sind GROTIG:eek: sag ich euch), aber ein kurzer Test mit der 'Riding Bean' DVD ergab auch gute Ergebnise. Noch besser wahren sie bei Agent Aika. Aber weil gewisse Firmen zu viele Rechte haben , bin ich im meinen Rechten eingeschränkt (zu Bleistift upen von Beispiel-Encodes), ihr wisst was ich meine...
Allgemeines Ziel ist es 'limited motion' Zeichentrick (zu min. 99%) ohne tempo-artefakte (Nachziehen) zu denoisen. Das Prob. mit den "Eckenproblem von Median-Filtern" (meinst du die angegriffen Ränder [besonders] der Cels?) kann man wohl nur mit den Masktools lösen, oder? Vieleicht auch mit Repair? Nicht das ich mit beiden Filtern umgehen könnte....:lol:

Was ist eigentlich mit dem DCTFilter? Der konnte doch Anime-Quellen recht gut komprimierbar machen.

Redfox
Eckenproblem... Median-Filter neigen dazu, alles eckige rund zu machen.
Um das auszugleichen habe ich aber weder Repair noch die Maskools benutzt, sondern Overlay. Die Theorie dahinter: Werden damit zwei Bilder überblendet, bleiben die Pixel, die in beiden vorhanden sind, unangetastet, während die, die nur in einem Bild vorhanden sind, abgeschwächt werden - sie tauchen aber noch auf. Und das ist wichtig, um die Ecken wieder eckig zu bekommen. Wenn man auf diese Weise einen Temporal- mit einem Median-Filter UND dem ungefilterten Source mixt, kann man innerhalb gewisser Grenzen das beste aus beiden Welten haben.
Die Masktools benutze ich dann, um die Kanten etwas zu stabilisieren.

Und nicht vergessen: Der Filter ist ein reiner Denoiser, wobei die Parameter mi und ti (Median Influence und Temporal Influence) sich "einseitig gegenseitig" beeinflussen. Ein niedriger ti-Wert sorgt dafür, dass der Median-Filter stärker wird, während der mi-Wert keinen Einfluß auf den Temporal-Filter hat. Das ließ sich ohne aufwändige (und langsame) Logik nicht anders machen.

Deinorius
Der DCTFilter richtet ziemliche Schäden in großen Farbflächen an, sowas mag ich nicht.

Kika: THX! Danke für die Info! Ich hätte zwar zuhause woll selbst gesehen wie du das gemacht hast, aber ich bin halt ungeduldig.
Das Ekige wird zu Rundem? Hm, war mir bis jetzt noch nicht aufgefallen. Gut zu Wissen, werde mal in Zukunft verstärkt darauf achten. Aufgefallen war mir bisjetzt nur das Medianfillter die Übergänge an den Rändern stark angreifen. OK, das machen ja alle Filter, aber die schienen mir, je nach Einstellung, noch am destruktiefsten zu sein.

Deinorius
Wie Kika sagte, in den normalen Einstellungen erzeugt es schnell die üblichen DCT-Blockartefakte
Auserdem erzeugen die Einstellungen:
DCTFilterD(X) #X=10-14
starkes Gibbssches Phänomen. Die einzige praktische Verwenndung für diesen Filter die ich bis jetzt gefunden habe, währe die Erstellung guter Beispiele für die Auswirkungen einer zu niedrigen Bitrate.

Der VagueDenoiser der statt der DCT-Transformation eine Wavelet-Transformation durchführt ist da meiner Meinung nach besser.

Andererseits ist der DCTFilter ein Teil von Didee's Deblockskript. Keine Anung wie er aus einem Blöcke erzeugenden Filter ein Deblock-Skript bastelt. Dieser Kerl... :nein:

Zitat

Andererseits ist der DCTFilter ein Teil von Didee's Deblockskript. Keine Anung wie er aus einem Blöcke erzeugenden Filter ein Deblock-Skript bastelt.

Oh, da Didée und auch scharfi ziemlich viel Zeit aufgebracht haben, mir einiges über AVISynth beizubringen, kann ich das sogar nachvollziehen. Es geht frei nach dem Motto: Man muss den Gegner kennen, um ihn wirkungsvoll bekämpfen zu können.
Das Problem ist, dass die beiden auch die Wirkungsweise der Filter intern nachvollziehen können, während es bei mir nur für das Beurteilen der Auswirkungen reicht. Aber selbst damit lässt sich schon einiges machen.

Aber nochmal zu meinem Denoiser: Um dabei die Auswirkungen des Median-Filters in voller Brutalität zu sehen, setze einfach mi auf 1 und ti auf 0.1 - das Ergebnis ist grausam.

Zitat von Kika

So, ich habe mal ein wenig an meinem TemporalMedianMix gearbeitet...

Jesses, da öffne ich zuhause das Zip-Archiv und dann sind da nur die beiden Pics drin... Ich dachte da hätest du die neue Version da auch reingepackt. Die letze von dir gepostete Version ist schon 2 Wochen alt.

Com'on Kika, gib dem Affen Zucker!:ja:

Andererseits, so hatte ich Zeit noch 'n bischen an meinem Skriptchen zu feilen. Bin jetzt so weit das ich mich entscheiden kann zwischen herausgefilterter (primär mit Bifrost + DeDot) Cromanoisie (Überquantisierung) + manchmal auffälligen Cromablends oder die Noise zur Hälfte drin bleibt. Allerdings will ich das Croma nicht spatial filtern weil das dann nur noch mehr geblurt wird, es ist jetzt schon ziemlich fubar, auch für DVB-T-Verhältnisse ist das stark über SNAFU. :cool:

Ich dachte es währe besser sich die übereinstimmungen aus anderen Frames zu rekonstruktion zu nutzen, dann 'etwas' zu bluren und leicht zu schärfen, alles auf das Croma bezogen verseht sich. Das Luma braucht noch ne anderer Kur.... *seuftz*

Zitat von Kika

Oh, da Didée und auch scharfi ziemlich viel Zeit aufgebracht haben, mir einiges über AVISynth beizubringen...

Jeah, Seit Monaten schon verfolge ich sämtliche Gäspräche zwischen dir und denn beiden Experten. SEHR lehreiche Lektüre, nicht nur für dich. :ja: Konnte man fast schon zusammenfassen und ein AviSynth-Lehrbuch draus schneidern.:)

Ach das, ich bin doch immer noch nicht fertig.
Hauptsächlich habe ich an den parametern gespielt und versucht, die Maske (und auch die Methode) für die Ränder zu verbessern.

Bei den Beispielbildern hatte ich eine Version, die sich nur in zwei Dingen unterscheidet:
blur(clean,1,0.8) -> blur(clean,0.8,0.8)

vor ... .binarize(bicl,upper=false) kommt noch ein .expand()

Das war schon alles.

Der Sinn meines Filters besteht ja darin, Zieheffekte weitestgehend zu vermeiden, dabei Rauschen auf ein erträgliches Maß zu reduzieren und die Schärfe möglichst nicht anzugreifen. Da ich mit YV12LutXY nicht klar komme und Repair in diesem Fall weit weniger nutzt als gehofft, habe ich Overlay benutzt. Um die Parameter voll steuern zu können, wären eigentlich drei Overlay-Befehle nötig. Aber dadurch würde das Script elendig langsam, außerdem würde sich die Balance zwischen ungefiltertem Source, Median-gefiltertem und Temporal-gefiltertem Clip recht ungünstig verschieben.

Sinn des Filters ist definitv nicht, Rauschen völlig zu entfernen, das macht Trickfilme immer gleich "platt". Wenn es darum geht, da gibt's andere Filter (und bessere) für. Für guten Source ist er auch kaum brauchbar (sowas filtere ich aber auch meist erst garnicht).

Zitat von Naito

Hab einen Deinterlacer-Test auf Doom9 gefunden. ....... möglicher weise wäre es eine überlegung wert es ins Script mit auf zu nehmen.

Ich fürchte, Koman.. äh ich meine Naito (macht der Gewohnheit;) ) das 'echte' Deinterlacer hier nicht viel helfen. Die Sache bei Animes ist die, das die Kammartefakte durch die Wandlung von 24 Bildern pro Sekunde (Master) auf 25 Bildern pro Sekunde (PAL) herkommen.

Wenn ich die Sache richtig sehe, dann haben Interlaced Material (Sport und Studio-Aufnamen beispielsweise) und Geblendendetes Material (Kinofilme und Animes auf DVD und im Fernsehn(aber nicht im Kino!)) MEHR Unterschiede als Gemeinsamkeiten und dürfen auch keinesfalls mit den gleichen Mitteln 'entkämmt'werden.
Die einzige Gemeinsakeit von Interlaced Material und Geblendendetem Material ist die, das beide augenscheinlich Kämme enthalten - PUNKT!

Dann fangen die Unterschide an:
Das echt Interlaced Material war immer schon 'kammig'(Aufnametechnik der Kamera), das geblendendete Material hingegen wurde es erst durch eine Normwandlung (nach PAL in unserem Fall) .

Aus geblendendetem Material kann man wieder echt progresives Material machen und zwar mit den 24 Bilder pro Sekunde die es vor der Normwandlung hatte. Das geht mit Hilfe von Inverse Telecine kurz IVTC. Aus echtem interlaced Material dagegen kann man nur 'unechtes' SEMI-Progresives Material berechnen und zwar durch interpolation. Das hat dann allerdings 50 (!) Bilder pro Sekunde (Stichwort Boben, einige Deinterlacer schmeisen aber intern schon jedes 2te Bild weg wodurch man 25 Bilder pro Sekunde bekommt).

Das liegt daran das in einem echten interlaced Bild die Information aus 2 Halb-Bildern steckt, in einer sekunde geblendendetem film (25 Bilder) allerdings die Bewegungen aus 24 Bildern des Masters!

Im Prinzip handelt es sich um völlig entgegengesetzt wirkende Techniken:
Interlaced Material: 50 Halb-Bilder in 25 Interlaced-Bildern = 'Gestauchte/Komprimierte' Bewegung
Geblendendeter Film: 24 Progresive Bilder in 25 geblendenden Bildern = 'Gestrekte' Bewegung

Siehe auch hier:
http://home.arcor.de/scharfis_brain…erlacing/#2.2.2

Ich hoffe das ist sowohl richtig als auch plausibel erklärt. Ich bin ja auch nur ein Anfänger auf diesem Gebiet.

Und wenn du mir jetzt bitte deine Klinkpackung Aspirin reichen könntest, Kika...

Zitat

Die Sache bei Animes ist die, das die Kammartefakte durch die Wandlung von 24 Bildern pro Sekunde (Master) auf 25 Bildern pro Sekunde (PAL) herkommen.

Den Satz würde ich streichen, da es sich so anhört als ob eine Normwandlugn zu Kammartefakten führen würde,...

Kika
Wegen deiner Funktion solltest du dich vielleicht mal etwas mehr mit den mt_masktools beschäftigen. Hier sind denn zum Beispiel auch Edgedetection-Modelle von mg262 drin, die sich sehr gut für Anime eignen. Zudem würde die Funktion noch schneller werden. FitY2UV wäre dann zum Beispiel unnötig. Anstatt Overlay wäre mt_lutxy wahrscheinlich schon besser, allerdings scheint Average eine sehr gute Alternative hier zu sein. Es ist schneller und du kannst gleich drei Clips miteinander mischen. Vielleicht bringt dir das ja was. Soweit ich weiß ist sowohl merge als auch die Kombi mergeluma + mergechroma ein wenig schneller als Overlay, inwieweit das auch für die neuste Avisynth Version stimmt kann ich aber nicht sagen.

Mr. Brown
Da du schon vier komplexe Funktionen in deinem Skript nutzt und simpel deinterlacte Normwandlungen schlechte Motion und höheren Bitratenbedarf zu Folge haben, solltest du vielleicht doch darüber nachdenken restore24 oder Crestore mit ins Skript einzubauen. Beide Version (restore24 rc + Crestore 1.0) arbeiten sehr schnell und sind auch nicht schwierig anzuwenden.