Vorschläge Anime AVS Skript

  • MOmonster

    Zitat

    Anstatt Overlay wäre mt_lutxy wahrscheinlich schon besser


    Daher ja auch meine Frage neulich nach der UPN. Ich hatte in diesem Threat hier ja geschrieben, dass ich Overlay wählte, weil ich mit den LUT-Befehlen nicht klar komme.

    Merge habe ich neulich anstelle von Overlay ausprobiert, das brachte, wenn überhaupt, nur einen minimalen Vorteil. Tempofresser sind eindeutig die beiden Filter.

    Mir ging es, als ich diese Funktion schrieb, eigentlich hauptsächlich um die Theorie. Dass man das Ding tatsächlich praktisch einsetzen kann ist ein angenehmer Nebeneffekt. ;)

    Was die Masktools betrifft ... Hm, ob MT oder nicht, ist eine Art Gewissensfrage, oder? Wie auch immer, eigentlich fehlt mir nur noch ein Steinchen im Mosaik - nämlich das Bilden eigener Kernels für dedgemask, bzw. das Hintergrundwissen darum, wie die Werte der Kernels mit den Pixeln verrechnet werden. Habe ich das, kriege ich den Rest auch gebacken.

  • Entschuldigung wenn das schon mal angesprochen wurde, aber ich bin noch nicht dazu gekommen mir den ganzen Thread durchzulesen.

    Zitat

    ### Saubere Ränder ###
    LetterBox(2,2,2,2)


    Das wird starkes Ringes hervorufen(Gibbs Phänomen). Mit Letterbox(4,4,4,4) kann man das verhindern und verschwendet "nur" mvs, allerdings nur mit AVC Codecs.

  • Zitat von Redfox

    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.

    Zitat von Selur

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

    Aber genau das wollte ich sagen, Selur.

    Oder währe es besser zu sagen das die Kammarteffakte durch das blenden der 24 BpS auf 25 BpS entstehen?

    Ansonsten alles richtig?

  • Wie aus progressivem Material durch plending interlactes Material werden sollte ist mir total unklar. Meiner Ansicht nach ensteht das Problem nicht durch die Normwandlung, sondern durch den flaschen Umgang mit interlactem Material. (ist ne frage wo man den Schwerpunkt setzt)

  • Zitat von Naito

    @ Redfox
    Danke für die Erklärung.

    Dafür ist NERV... äh Redfox da. :cool:
    Allerdings: Das war alles 'As far as I know'! Ich wollte dich nur daruf hinweisen das die Standart-Deinterlancer bei Animes contraproduktiv sind, auch wenn man bei Mr. Browns Skript den Tdeint findet.
    Wenn ich mit meinen Recherchen bisher richtig liege, ereicht man die bessten Ergebnisse wenn man das Material erst per IVTC wieder auf 24 Bilder pro Sekunde bringt und danach einen PAL-Seep-Up durchführt(Punkt 2.1.1).
    Wenn ich das richtig sehe, verringert man damit auch die resultierende Datei den dadurch wird der Anime 4% kürzer(bzw. bessere Quali bei gleicher File-Größe).

    [EDIT:Mr. Brown hat recht, das mit den 4% ist falsch, das gilt für vor dem PAL-Speed-Up, nicht danach]

    MOmonster
    restore24 und Crestore sind eine ausgezeichnete Idee, ich experementiere auch gerade damit. Allerdings habe ich das Gefühl das die Firmen versuchen den IVTC-Vorgang so schwierig wie möglich zu machen. Die DVDs die ich habe sind fast alle 'Telecine ohne PAL-Speedup'(2.2.2), wenn ich das richtig beurteile.

    Ich nehme an das ist ein Versuch die Verbreitung von MPEG4-Kodierten Animes zu erschweren.

    [Blockierte Grafik: http://www.cheesebuerger.de/smiliegenerator/ablage/246/350.png]

    @ Selur
    Ich glaube wir reden an einander vorbei...
    Was ich Naito sagen wollte war, das diese Kammartefackte in seinen Animes durch den Telecine-vorgang entstanden sind. Also durch die Wandlung vom Kinostandart (24 Bilder pro Sekunde) auf PAL-Standart (25 Bilder pro Sekunde) entstanden sind.

    Zitat von Selur

    Wie aus progressivem Material durch plending interlactes Material werden sollte ist mir total unklar.


    Ich habe eigentlich fast nur zitiert (ich hoffe nicht sinnentstellend!), schauen wir uns doch noch mal scharfis_brain's Exotisches Interlacing an:

    Zitat von scharfis_brain acuf seier Exotisches Interlacing-Seite

    2.2.2 Telecine ohne PAL-Speedup - mit blending - interlaced
    Dies ist eine der grausamen Methoden, Film auf PAL zu transferieren. Hierbei werden Halbbilder, die zeitlich nicht genau unter einem Filmframe liegen, aus den zeitlich benachbarten Filmbildern gemischt (blending).
    ...
    Am TV fällt eine solche Telecine fast garnicht auf. Am PC hingegen hat man in fast jedem Frame interlacing. ...


    Was habe ich daran jetzt falsch wiedergegeben?

    Zitat von Selur

    Meiner Ansicht nach ensteht das Problem nicht durch die Normwandlung, sondern durch den flaschen Umgang mit interlactem Material.


    Aber Anime-Master (24 BpS) sind nie interlanct. Man kann nicht falsch mit etwas umgehen was man garnicht hat, oder? Er einzige Fall bei dem man echt interlact Material aus echt Progresivem machen könnte währe doch der wenn man ein Master mit 50 Progresiven Bildern per Sekunde hätte und dies dann in 25 BpS interlact Material umwandelt.
    http://forum.gleitz.info/showthread.php?t=23090&highlight=reinterlacing

    Zitat von Selur

    (ist ne frage wo man den Schwerpunkt setzt)

    Immer bestmögliche Qualität, egal welcher Aufwand! Oder wie meintest du das?

    Zitat von sade

    Das wird starkes Ringes hervorufen(Gibbs Phänomen). Mit Letterbox(4,4,4,4) kann man das verhindern und verschwendet "nur" mvs, allerdings nur mit AVC Codecs.

    Das bringt mich wieder auf ne Sache die mich schon seit einiger Zeit stört. Schauen wir uns diesen ganzen Crop, AdBorders, Letterbox, Resizekramm mal an:

    # Werte für die Zielaufloesung & das Zuschneiden
    Breite = 640 # mod 16 werte empfehlenswert aber nicht unbedingt notwendig
    Hoehe = 480 # mod 16 werte empfehlenswert aber nicht unbedingt notwendig
    Links = 4
    Oben = 4
    Rechts = -4
    Unten = -4

    ### Crop ###
    Crop(Links,Oben,Rechts,Unten)

    ### Saubere Ränder ###
    LetterBox(2,2,2,2)

    ### RESIZE ###
    LanczosResize(Breite,Hoehe) # Scharfer Resizer für hohe bitrate
    #BicubicResize(Breite,Hoehe,0,0.5) # Neutraler Resizer
    #BilinearResize(Breite,Hoehe) # Weicher Resizer für niedrige bitrate

    Erstmal Crop:
    Warum oben und unten 4 Pixelreihen weg? Das Bild ist zu diesem Zeitpunkt schon Progresiv. Ob 'Matsch'-Progressiv(Tdeint) oder echt IVTC-Progressiv ist dabei doch egal. Und warum die 4 Pixelreihen an der Seite? Der Overscan, den man enfernen sollte, ist doch nach Standart jeweils 8 Pixel breit.
    Und warum dann Letterbox? Dass entfernt doch noch mehr vom Bild (durch überscheiben mit Schwartzen Balken) damit werden jetzt schon 12 Horizontale Pixelreihen entfernt und der der Overscan ist immer noch da! Auserdem ist die Aussage ### Saubere Ränder ### doch falsch, weil durch die anschlisende interpolation des Resizeing doch am rand zwischen der Letterbox'(ihr versteht hoffendlich wie ich das meine) und dem verbleibenden Bild Rundungsfehler entstehen, oder?

    Und wegen dem Resizeing generel:
    Da hat man das Glück das man als im PAL-Gebiet lebender ne höhere Horizontale Auflösung hat und dann soll man diese für das menschliche Auge wichtigere Horizontale Auflösung quasi kaputtmachen? No Way!
    Währe es nicht besser wenn man nur in der Breite verkleinert (anamorbes enkoding ala SVCD)? Das Auge sollte diesen Detailverlust doch weniger stark warnehmen.

    Ich weiss, Stand-Alone-Player's spielen MPEG4 anscheinent nur mit quadratischen Pixeln(1:1) ab, aber selbstwenn ich so ein Ding hätte, würde ich den kram eher per Lanczos4Resize auf 768 × 576 bringen als wertvolle horizontale Auflösung zu killen.

    Oder liege ich da mal wieder total daneben?

    Was aber ist mvs, sade?

    Noch was anderes:
    Ich hab mal den FFT3DFilter getested und ich bin mit den Standart einstellungen nicht unbedingt zufrieden.
    Die Einstellung FFT3DFilter(Sigma=6,plane=4,wintype=1) erzeigt bei allen meinen Tests MASSIVE temporale Artfakte. Und ich meine wirklich massiv. Ich hab mich dann ein bisschen durch die Readme gearbeiet und das hier gefunden:
    "Filter can produce ghosting for large sigma (and kratio) for 3D modes."
    Nun, das ist definitiv der Fall. Also hab ich mir mal den 2D Modus angesehen und ich finde das der nicht wesendlich schlechter aussieht. Das ist durchaus ein Versuch wert.

    Noch ne andere Sache ist mir aufgefallen:
    "Weighting window wintype=0 can produce the worst grid artifactes, window type wintype=2 do not produce grid artifactes, but can produce some ringing, wintype=1 is intermediate case."

    Ringing entschteht ja als eine Art Gibbs Phänomen besonders an Kontrasstreichen Stellen und das is bei Animes und Cartoons ja der Standart. Ich hab deshalb mal wintype=0 ausprobiert mit Folgendem ergebnis:

    XIVD:
    Konstanter Quant 2, Cartoon Mode:
    (Sigma=3 plane=4 wintype=0 bt=1 degrid=1) = 2539520 Byts
    (Sigma=3 plane=4 wintype=1 bt=1 degrid=1) = 2613248 Byts

    Filter waren nur
    DeGrainMedian(limitY=2,limitUV=2,mode=1)
    und
    FFT3DFilter(s.o.)
    Es wurde nicht geschärft oder so was.

    Was Optisch auffählt ist das das Bild bei wintype=1 geringfügig schärfer wirkt als bei wintype=0. [EDIT: 1 war vorher 0, war ein blöder Tipfehler]
    Das passt, glaube ich, aber zu meiner Theorie, der eindruck er Schärfe entsteht möglicherweise durch den kontrast dieses Gibbs Phänomens. Optisch hätte es eine ähnliche Wirkung wie EE.

    Meine Einstellungsempfehlung als Standart währe:
    FFT3DFilter(Sigma=3, plane=4, wintype=0, bt=1, degrid=1)
    Sigma=3 ist schon recht hoch 6 aber selbst für die Simpsons zu viel!(meine Meinung)

    Zitat von Kika

    Na ja, "Blending" war hier der verkehrte Ausdruck. Es passiert, wenn durch echte Frameratenkonvertierung von 24 auf 25 gewandelt wird.


    Äh, und ich dachte Blending währe grade das richtige Wort für diesen Vorgang?:huh:

    [EDIT:] Oh, je da hab ich ja massig Fehler reingebaut:
    -der erste wintype Wert sollte 1 sein(geändert)
    -außerdem sprach ich im zusammenhang mit SAPs von 'statischen Pixeln', ich meinte natürlich 'quadratischen Pixeln' (geändert)
    -und Naito hab ich Falsche Infos (mal wieder...) über die resultiernde Dateigrösse gegeben (Dank an Mr.Brown für den Hinweis.)

  • Zitat

    Äh, und ich dachte Blending währe grade das richtige Wort für diesen Vorgang?



    Blending bedeutet, das da was ineinandergematscht wurde, entscheidend ist aber das WIE.
    Wenn z.B. interlaced 29.97 zu 25 fps gewandelt werden soll, so hat man keine andere Wahl, als ab und an (das WIE überlasse ich jetzt Deiner Fantasie) einzelne Fields mit anderen zu mischen (blenden). Die Alternativen dazu wären alle ruckelig. Was man im Allgemeinen aber unter Blending versteht ist das generelle Mischen von Fields zu Frames. Blur(0,1) macht das beispielsweise, wenn's auf interlaced Video angewendet wird.

  • Yup, blending wird hier falsch verwendet.
    Und Normwandlung teilweise auch, da eine Normwandlung halt von PAL/NTSC nach NTSC/PAL geht und diese keineswegs umbedingt zu interlacing usw. führen muß. Wenn man z.B. progressives Material von 23.976 frames per Speedup auf 25 fps bringt hat man eine NTSC->PAL Normwandlung durchgeführt, jedoch wird es nicht zu interlacing Streifen kommen, da das progressive Material nie in fields unterteilt wurde.

    Wenn man seine 23.976 fps jedoch erstmal per telecine auf 29.976 bringt und daraus dann einfach ein paar fileds verwirfst bis man auf 25fps interlactes Material kommt, gibt's Probleme.

    D.h. Normwandlung an sich ist nicht das Problem, sondern der nicht 'ordentliche' Umgang mit interlactem Material.

    Cu Selur

  • Redfox
    Das mit der horizontalen Auflösung stimmt nicht ganz. Und zwar aus mehreren Gründen. Zum einen haben wir aufgrund des Interlacings bzw. schlechten Telecinings (Blendkonvertierung) ja zumeist sowieso nur die halbe Auflösung (zumindest in bewegenden Szenen), zum anderen werde viele Normwandlung von NTSC->Pal (gerade im Bereich Anime) nicht von Hochauflösenden Quellen aus gemacht, sondern nur mit den vorliegenden (oftmals bereits telecined zu 29.97fps) niedrig auflösenden Material gemacht (720*480). Insofern ist es häufig gar nicht sinnvoll möglichts viel Auflösung erhalten zu wollen, weil die Details ja schon gar nicht mehr da sind. Wegen den Crop- und Letterboxwerten gebe ich dir aber recht.:)

  • Zitat von Naito

    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.

    EEDI2 für cartoon/anime ist der filter doch recht brauchbar (bei realvideo sieht die sache jedoch anders aber egal darum geht's hier nicht).

    Zitat von Redfox

    Mr. Brown

    Hattest du eigentlich schon mal Dup von neuron2 getestet?

    Ja hab ich aber selbst mit vorsichtigen settings tauchten hin und wieder ruckler auf die es in der source nicht gab!

    Zitat von Deinorius

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

    Also bei meinen test's hat der DCTFilter keine guten ergebnisse geliefert

    Zitat von MOmonster

    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.

    wenn jemand r24 oder crestore in seinen script braucht soll er es bitte selbst einbinden denn ich will dieses skript kompakt halten

    Zitat von sade

    Entschuldigung wenn das schon mal angesprochen wurde, aber ich bin noch nicht dazu gekommen mir den ganzen Thread durchzulesen.


    Das wird starkes Ringes hervorufen(Gibbs Phänomen). Mit Letterbox(4,4,4,4) kann man das verhindern und verschwendet "nur" mvs, allerdings nur mit AVC Codecs.

    meinst du damit das letterbox() halo's verursacht ? :nein:

    Zitat von Redfox

    Dafür ist NERV... äh Redfox da. :cool:
    Allerdings: Das war alles 'As far as I know'! Ich wollte dich nur daruf hinweisen das die Standart-Deinterlancer bei Animes contraproduktiv sind, auch wenn man bei Mr. Browns Skript den Tdeint findet.
    Wenn ich mit meinen Recherchen bisher richtig liege, ereicht man die bessten Ergebnisse wenn man das Material erst per IVTC wieder auf 24 Bilder pro Sekunde bringt und danach einen PAL-Seep-Up durchführt(Punkt 2.1.1).
    Wenn ich das richtig sehe, verringert man damit auch die resultierende Datei den dadurch wird der Anime 4% kürzer(bzw. bessere Quali bei gleicher File-Größe).

    also wer seine animes am pc ansieht (sowie ich) für den reicht ein IVTC auf 24p und fertig der speedup auf 25p ist nur sinnvoll wenn es auf'm fernseher laufen soll

    und die bessere quali weil's kürzer ist funzt nur auf'm PC den auf'm Fernseher erzeugen PAL und NTSC genau das selbe datenvolumen!

    das sind doch nur beispielwerte kann doch jeder kinderleicht so einstellen wie er will!

    overscan kann man mit
    crop(8,0,-8,0)
    entfernen richtig

    und mpeg4 in Sap's dass mach ich nicht !
    da encode ich lieber ne saubere dvd die überall läuft

  • Zitat von Naito

    Meinst du vielleicht "Was Optisch auffählt ist das das Bild bei wintype=0 geringfügig schärfer wirkt als bei wintype=1."?

    Hm, Nein eigendlich ungekert(hab's mittlerweile geändert). Aber wenn du anderer Meinung bist, dann kann es natürlich sein das meine Theorie falsch ist(Mal wieder...:( ).

    Zitat von Mr. Brown


    das sind doch nur beispielwerte kann doch jeder kinderleicht so einstellen wie er will!

    overscan kann man mit
    crop(8,0,-8,0)
    entfernen richtig


    Sicher, mich hat nur gestört das es bei einem Universal-Skript so iritirende Standartwerte gibt, die Noobs die nicht wissen das man den Overscan entfernen (oder mit rein schwarz überschreiben) sollte, nicht weiter helfen. Allerdings ging meine Kritik ja noch etwas weiter. Ich war degegen das man Letterbox vor dem Reziseing benutzt weil dann doch Interpolationsfehler entstehen. Wenn man sauberer Ränder haben wöllte dann müsste man (meiner Meinung nach) folgendes machen:
    LanczosResize(636,476)
    Addborders(2,2,2,2)
    Ergebnis währe dann ein 640x480 Bild mit pechschwarzen Rändern(was immer die auch für einen Zweck erfüllen).

    Zitat von sade


    Zitat:
    LetterBox(2,2,2,2)

    Das wird starkes Ringes hervorufen(Gibbs Phänomen).

    Zitat von Mr. Brown


    meinst du damit das letterbox() halo's verursacht ? :nein:


    Ich glaube (betonung liegt auf glauben, nicht wissen) was er meint sind nicht 'Halos' sondern 'Ringing'. Dies entsteht bei MPEG-Codecs an Stellen mit starken Kontrasten (siehe sade's Link) und dieser schwarze Rand, (welche Funktion der auch immer erfüllen soll) ist so ein starker Kontrast, an dessen Rändern dieses Gibbs Phänomen entsteht (je niedriger die Bitrate desto mehr).
    Halos auch bekant als "Heiligenschein" entstehen doch soweit ich weis (und ich weis nicht viel) durch schlecht gemachtes Schärfen, oder?
    Hier ist der erste Treffer den Zensoogle ausspukt bei der Suche nach 'Halos' 'schärfen'
    Link
    Steht alles unter 'Zuviel des Guten: der "Heiligenschein"'.

    Zitat von Mr. Brown

    EEDI2 für cartoon/anime ist der filter doch recht brauchbar (bei realvideo sieht die sache jedoch anders aber egal darum geht's hier nicht).


    Brauchbar ja, wenn man Geisterbilder die durch die interpolierten Interlacend-Kämme entstehen mag. Ich hab aber das Gefühl das die meisten dem eher wenig estetischen Reiz abgewinnen können (Ich zumindest nicht).

    Zitat von Mr. Brown


    Ja hab ich aber selbst mit vorsichtigen settings tauchten hin und wieder ruckler auf die es in der source nicht gab!


    Kika hat dazu schon alles gesagt. Ich benutze ihn Bei meine Simpsons encodes und bei diesem einfachen Material arbeitet er ausgezeichnet. Ich kämme nie auf die Idee diesen Filter bei eimen komplexen Anime wie 'Ghost in the Shell' zu benutzen oder zu empfehlen.

    Zitat von Mr. Brown


    wenn jemand r24 oder crestore in seinen script braucht soll er es bitte selbst einbinden denn ich will dieses skript kompakt halten


    Woltest du nicht anfangs garkeine externen Skripte aufnemen, weil das angeblich zu kompliziert für den Nutzer wähe? Aber OK, wir werden sehen.

    Zitat von MOmonster

    Wegen den Crop- und Letterboxwerten gebe ich dir aber recht.:)


    Puh, mal gute Nachrichten. Aber deine Erklärungen muss ich erstmal verdauen. Die iritiren mich irgentwie. Denoch besten Dank für die Info, ich wuste das noch nicht.

  • @ Redfox

    Code
    Letterbox(2,2,2,2)


    hatte ich sowieso vor zu entfernen weil ich gelesen hab das die meisten codecs für den übergang von schwarzen rand --> bild sehr viel bitrate benötigen und

    Code
    Letterbox(16,16,16,16)


    ist einfach zu breit

    mit den irreführenden standartwerten bei dem resize/crop zeug's hast du recht da werde ich mal etwas sicherere werte hernehmen

    und nun zu eedi2
    wenn ich ins skript einbaue und er dir nicht gefällt dann reicht ein "#"
    und schon bist du ihn los also wieso die aufregung ?

    so nun etwas an alle v9.50 ist gerade bei mir kurz vor der fertigstellung
    hauptsächliche verbesserungen werden sein:
    -besseres Dehalo
    -Dot-Crawl entfernung nun auch bei high motion

    EDIT:
    Dass mit Letterbox und Ringing hab ich jetzt verstanden wie ihr dass meint

  • Zitat

    meinst du damit das letterbox() halo's verursacht ?


    Ich mache gerade einen Test dazu. Zum Unterschied Ringing <-> Halos siehe RedFox' Post.

    Zu meinem Erstaunen verursacht es doch kein so starkes Ringing wie ich dachte. Anscheinend filtert der Inloop deblocking filter einiges raus.

    ohne Letterbox

    Code
    encoded 2001 frames, 13.49 fps, 329.56 kb/s


    mit Letterbox:

    Code
    encoded 2001 frames, 13.43 fps, 338.28 kb/s


    beide mit den selben Optionen:

    Code
    x264 -r 5 -b 3 -A all -8 -m 6 --b-pyramid --crf 30 --no-psnr --progress -o file.mp4 test.avs

    1. Bild Original 640x480
    2. Bild mit Letterbox
    3. Bild ohne Letterbox

  • Zitat von Redfox


    Hm, Nein eigendlich ungekert(hab's mittlerweile geändert). Aber wenn du anderer Meinung bist, dann kann es natürlich sein das meine Theorie falsch ist(Mal wieder...:( ).


    Meine Aussage kam daher, dass ich aus

    Zitat von Redfox


    Meine Einstellungsempfehlung als Standart währe:
    FFT3DFilter(Sigma=3, plane=4, wintype=0, bt=1, degrid=1)


    geschlussfolger habe das du meinstest, 0 sei schärfer als 1. Danke für die Richtigstellung.

    Hab das Script (leider) noch nie ausprobieren können, mein Rechner gibt sowas einfach nicht her. :( Versuche trotzdem etwas dazu beizutragen und dank an alle, die so hart mitarbeiten. :daumen:

  • Zitat von Naito

    Meine Aussage kam daher, dass ich aus


    geschlussfolger habe das du meinstest, 0 sei schärfer als 1. Danke für die Richtigstellung.

    Moment, um noch mal zu erklähren was ich meinte:
    Ich hatte in der Beschreibung folgendes gelesen:

    Zitat

    Weighting window wintype=0 can produce the worst grid artifactes, window type wintype=2 do not produce grid artifactes, but can produce some ringing, wintype=1 is intermediate case.


    Ich hatte das so interpretiert, das der FFT3DFilter unter Umständen Ringing hervorrufen kann. Anscheinend bei wintype=0 am wenigsten, bei wintype=2 am meisten und wintype=1 liegt es in der Mitte. Dieses Ringing entsteht primär im Gebiet starker Kontraste. Deshalb dachte ich, das Animes und Cartoons aufgrund der kontrastreichen Striche sehr anfälling für diesen negativen Nebeneffekt dieses Filters seien könnten. Deshalb habe ich diesen Vergleich gemacht. Optisch fiel mir auf das Bild von wintype=1 einen schärferen eindruck machte als wintype=0. Ich erinnerte mich daran das der Eindruck von Schärfe ja auch von künztlichen Sachen wie Edge Enhancement a.k.a Halos stammen kann. EE/Halos kommen ja normalerweise vom schlechen Schärfen, aber ich dachte wenn im Bereich der Kanten durch feines Ringing zusätzlicher Kontrast entsteht, dann kann es einen ähnliche optischen Effekt haben. Ich habe mir die Kanten dann genauer angesehen und hatte den Eindruck das wintype=1 nen Tacken mehr EE/Halos hat als wintype=0 und zwar auch an Stellen die vorher kein oder kaum EE hatten.
    Deshalb habe ich mir überlegt, das wintype=0 eine bessere Einstellung für Animes seinen sollte.
    Außerdem ist das Ergebnis von wintype=0 besser komprimierbar.


    Bin ich der einzige, bei dem die im AnimeSkript vorgeschlagenden Werte Temporale Artefakte hervorrufen? Könnte ja an meinem eher Westlichen Quellmaterial liegen.

    Zitat von Naito

    Hab das Script (leider) noch nie ausprobieren können, mein Rechner gibt sowas einfach nicht her.


    Ich habs auch nie ausprobiert, liegt aber nicht an meiner CPU;). Ich benutze das Script und die Anregungen aus der Diskusion immer nur als Vorlage für eigene Skripte.
    Wenn ich das richtig sehe sind Tdenit, FFT3DFilter, und die Dehaloer die grössten CPU-Quäler(in dieser Reihenfolge). Crestore ist etwas schneller als Tdeint und ergibt doch ein besseres Ergebniss (meiner Meinung nach). Als Dehalo-Alternative gibt es PoorDeHalo(allerdings ist dehaloen ne komplizierte Sache, ich würde wenns CPU-Mäsig vertretbar ist lieber die HighQuali-Metoden benutzen). Hier hat Didee Tips zur Einstellung gegeben. Infos über den von ihm angesprochenen 'repair'-Parameter gibts hier.

    Zitat von Naito

    Versuche trotzdem etwas dazu beizutragen und dank an alle, die so hart mitarbeiten.

    Ich bedanke mich auch ganz besonders bei Selur und Kika für ihre geduldigen Erklährungen, mittler weise ist mir weitgehent klar wo mein Missverständnis lag. Und Naito, entschuldige bitte die Fehlinformationen (hoffendlich sind hier nicht schon wieder welche drin... :hm:), ich hoffe das hat dich nicht zu sehr irirtiert.

  • Zitat von Redfox

    Woltest du nicht anfangs garkeine externen Skripte aufnemen, weil das angeblich zu kompliziert für den Nutzer wähe? Aber OK, wir werden sehen.

    Ja aber Crestore und vorallem Restore24 sind da schon etwas andere Kaliber

    Zitat von Naito

    Hab das Script (leider) noch nie ausprobieren können, mein Rechner gibt sowas einfach nicht her. :( Versuche trotzdem etwas dazu beizutragen und dank an alle, die so hart mitarbeiten. :daumen:

    Gute Quali dauert nunmal etwas länger

    aber ich versuche immer einen kompromiss zwischen quali und encodingspeed zu finden

    Zitat von Redfox

    Crestore ist etwas schneller als Tdeint und ergibt doch ein besseres Ergebniss (meiner Meinung nach).

    Nicht wenn du es mit Tdeint benutzt

    Tdeint ist nur im skript für DVB und falls mal irgendein spinner ne europäische zeichentrickserie als 25i auf dvd rausbringt

    Crestore und Restore24 bringen ja auch bessere ergebnisse bei Animes die nach PAL gewandelt wurden aber sowas kommt mir nicht ins Haus!
    Ich besorg mir NTSC DVD's die sind bei weitem besser

  • Zitat von Mr. Brown


    Gute Quali dauert nunmal etwas länger

    aber ich versuche immer einen kompromiss zwischen quali und encodingspeed zu finden


    Da stimme ich dir zu. Da ich jedoch absoluter Qualitätsfanatiker bin und mein Rechner nur so "stark" ist wie der von LigH, hab ich es mir bisher verkniffen von meinen DVDs ein Backup zu erstellen (hab z.B. RoLW, wär ne gute Source). Denn das würde dauern ....

    Noch ein paar Anmerkungen:
    1. Besteht die Möglichkeit die Pfade zu den Filtern durch Varibalen zu ersetzen? Z.B. so:

    Code
    %Filterpfad% = C:\PROGRA~1\GORDIA~1\AviSynthPlugins\
    LoadPlugin("%Filterpfad%\DeGrainMedian.dll")


    Das würde das ganze etwas einfacher machen, die Pfade an die eigenen anzupassen.

    2. Wäre es (v.a. nach der Diskussion) nicht besser IVTC als Standard zu definieren und TDeint auszukommentieren? (Als Newbie bekomm ich von DGIndex gesagt das ist PAL-Interlaced, was mach ich --> Deinterlacing mit TDeint. Das dass (meist) falsch ist weiß ich ja jetzt. :))

  • Zitat von Mr. Brown

    Nicht wenn du es mit Tdeint benutzt

    Yeah, das ist natürlich richtig. Wass ich meinte war das mir der optische Eindruck selbst bei nem Simplen und schnellen Bobber + Crestore besser gefällt als das 'nackte', langsame Tdeint.

    Zitat von Mr. Brown

    Ich besorg mir NTSC DVD's die sind bei weitem besser

    Mag sein, aber das ist warscheinlich nicht unbedingt der Universal-Fall für alle hier. Ich hab 2 dutzend PAL-Cartoon/Anime-DVDs und die alle als NTCS neu zukaufen nur weil das Backup dann unter Umständen einfacher wird ist nicht wirklich eine Option (ich werde mir am Wochenende aber mal ne NTSC-DVD besorgen).

    Zitat von Naito

    Noch ein paar Anmerkungen:
    1. Besteht die Möglichkeit die Pfade zu den Filtern durch Varibalen zu ersetzen? Z.B. so:

    Code
    %Filterpfad% = C:\PROGRA~1\GORDIA~1\AviSynthPlugins\
    LoadPlugin("%Filterpfad%\DeGrainMedian.dll")


    Das würde das ganze etwas einfacher machen, die Pfade an die eigenen anzupassen.

    Ausgezeichnete Idee! :ja: :daumen: Ich müßte das zum Beispiel schon ändern.

    Zitat von Naito

    2. Wäre es (v.a. nach der Diskussion) nicht besser IVTC als Standard zu definieren und TDeint auszukommentieren? (Als Newbie bekomm ich von DGIndex gesagt das ist PAL-Interlaced, was mach ich --> Deinterlacing mit TDeint. Das dass (meist) falsch ist weiß ich ja jetzt. :))

    Was wichtiges zu DGIndex und den Interlaced/Progresive-Angaben:

    Zitat von incredible

    :so-nicht:

    Mooooment a mol.

    a) Was DgIndex, DVD2AVI oder irgendwelche Flags sagen INTERESSIERT NICHT!!! ;) Denn DEIN Auge sagt dir ob etwas "Kammartefakte" hat oder nicht. Demnach Film previewen und sehen obs wirklich progressiv oder interlaced ist.

    Zitiert von hier
    Wenn ich das richtig verstehe hat das damit zu tun, das diese Angaben nicht durch eine Prüfung des Bildinhalts kommen, sondern aus 'flags' die sich im MPEG2-Videobild befinden und vom Programm ausgelesen werden. Dieses Flag soll, glaube ich, den Abspielprogrammen sagen ob sie ein MPEG2 Deinterlancen sollen oder nicht. Aber das Problem ist das die Angaben bei schlecht gemasterten DVDs fehlerhaft seien können. (diese Angaben sind wie immer ohne Gewähr;) )

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!