Avisynth verstümmelt Luma-Histogramm??

  • Ich habe ein ganz unangenehmes und grundlegendes Problem bei der Benutzung von Avisynth zusammen mit VirtualDub: Sobald ich irgendein AVI-File über ein AVS-Script in VD öffne, ist die Helligkeitsverteilung anders als beim direkten Öffnen des Files in VD: Das Luma-Histogramm (z.B. im VD-"Levels"-Filter) geht nicht mehr kontinuierlich von 0-255, sondern ist in etwa 20 schmale Bänder zerhackt: In regelmäßigen Abständen kommen Helligkeitswerte garnicht mehr vor, oder sind viel häufiger als im Original vertreten, so als wenn da irgendwo unterwegs eine Art Rundungsfehler passiert. Ein Graukeil wird tendenziell zur Treppe, und gerade bei Schwarzweißmaterial sieht es einfach nur scheußlich aus (unnatürlich scharf umrandete oder "streifige" Wolken, flache Schatten, usw.).
    Der Fehler hängt NICHT von der Verwendung bestimmter Avisynth-Filter ab, lässt sich auch nicht durch Angabe des "Matrix"-Parameters bei "ConvertTo..." oder durch ColorYUV beeinflussen, und tritt bei komprimiertem Quellmaterial ebenso wie bei unkompromierten AVIs auf.
    Ich kann mir nicht vorstellen, dass dies die normale Arbeitsweise von AVS und VD ist, und frage mich jetzt, wo in meinem System der Wurm steckt. Bin dankbar für jeden Vorschlag, was ich noch ausprobieren kann. VD allein funktioniert einwandfrei, hat aber halt nicht all die nützlichen Funktionen von AVS.....

  • :welcome:

    Ich vermute, AviSynth öffnet das Video in einem YUV-Farbraum, weil du nicht das Öffnen im RGB-Farbraum erzwingst. Somit wird es als YUV an VirtualDub weitergegeben, und dort erst nach RGB konvertiert - mit leichten Rundungsfehlern (die genau so auftreten, wenn du es in AviSynth nach RGB konvertierts, nachdem es als YUV geöffent wurde).

    Versuch's mal mit AviSource("*.avi", pixel_type="RGB24").

    Aber abgesehen davon: "Na und?" - Wem sollten ein paar Sprünge in der Helligkeit denn subjektiv auffallen? Über solche Kleinigkeiten würde ich mir keinen Kopf machen. Das sind Rundungsunterschiede im Bereich von 1 bit, wie sie zwangsläufig auftreten, wenn mit Ganzzahlwerten gerechnet wird, die auch noch nur 8 bit Genauigkeit haben - nach dem nächsten Resize oder Rauschfilter sind die schon längst wieder kaschiert.

    Oder versuch mal anschließend ein Levels(0,1.5,255,0,255) - aber nur, wenn du Beruhigungstabletten in greifbarer Nähe hast. ;) :D

    [Blockierte Grafik: http://cosgan.de/images/smilie/figuren/a070.gif] Ein Histogramm muß nicht glatt sein, damit das Bild gut aussehen kann.

  • Danke für den Tip, ich werde es mal versuchen. Dumme Newbie-Frage: Ist es in diesem Forum eigentlich gestattet, Links zu Beispiel-AVIs/BMPs zu posten?

    Mein Problem ist halt, dass das Bild NICHT gut aussieht - nur deswegen hab ich mir das Histogramm gestern mal genauer angeschaut und dabei die Lücken entdeckt. Ich bin dabei, uralte Schwarzweiß-Filmaufnahmen zu restaurieren, und da fällt es schon sehr derb auf; besonders weil halt manchmal das Originalbild recht kontrastarm ist und jede Kontrastanhebung die Helligkeitssprünge an den Lücken (quasi ein Posterize-Effekt) extrem verstärkt. Der Fehler stört auch deshalb so sehr, weil derartige "Effekte" halt einer analogen Schwarzweiß-(Zelluloid-)Aufnahme völlig fremd sind und das Ganze sofort sehr "computerig" und unnatürlich aussehen lassen.

    Als Ergebnis soll natürlich ohnehin ein DVD-taugliches File für TV-Wiedergavbe (also mit begrenztem Lumabereich 16-235) herauskommen, und es sollte doch möglich sein, diese 220 *gleichgroßen* Helligkeitsstufen unverzerrt durch alle Signalwandlungen durchzubringen, ganz gleich ob als Y-Wert oder als R=G=B-Wert. Wie hindere ich VD daran, beim Einlesen das von AVS kommende Signal jedes Mal so plump auf 0-255 zu stretchen? Durchgehend 16-235, mit geringfügig kontrastarmem Bild im RGB-Raum, würde mir ja schon reichen; dann könnte man das unkomprimiert abgespeicherte Resultat des ersten Bearbeitungsschrittes auch verlustfrei wieder in ein zweites AVI-Script einlesen, um es weiter zu bearbeiten...

  • Die beste Möglichkeit, unnötige Zweit-Konvertierungen zu vermeiden, ist der Verzicht auf VirtualDub-Filter, indem man den Video-Modus auf "Fast Recompress" stellt - so erhält der Codec direkt und ohne Umwege das, was in VirtualDub hineinkommt: In deinem Fall die AviSynth-Ausgabe.

    Zur Analyse aber wird VirtualDub wohl immer das Material noch mal nach RGB umrechnen. Es arbeitet nun mal nur in diesem Farbraum. Wenn du also Informationen brauchst, solltest du dir mal die AviSynth-Funktion "Histogram()" anschauen. Die ist zusätzlich noch um einiges hübscher in der Darstellung (v.a. im "Levels"- und "Color"-Modus).

  • Erstmal danke für die prompten und nützlichen Erläuterungen. Nachdem mir die System-Zusammenhänge klar geworden sind (ich also sicher war, dass hier kein Defekt vorliegt), habe ich auch einen Trick gefunden, das Problem zu meiner Zufriedenheit zu umgehen. Der einzige Nachteil ist, dass man bei meiner Lösung nicht den vollen RGB-Farbraum ausnutzen kann, sondern nur den Bereich 16-235. Das Problem tritt aber ohnehin vorwiegend bei kontrastarmen, "weichen" Vorlagen auf, also sollte die Beschränkung nicht so sehr stören.

    Vielleicht ist mein Script (sorry wenn es die großen Experten hier langweilt!) doch dem Einen oder Anderen nützlich, der auch mit schlechtem Quellmaterial zu kämpfen hat und auf geringstmöglichen weiteren Verlust an Nuancen und Originaltreue Wert legt. Ganz auf VD-Filter zu verzichten finde ich sehr schwer, denn sowas wie den "Deshaker" habe ich für AVS noch nicht in der gleichen Qualität gefunden, und bei manchen Einstellungen (Weißabgleich, Kontrast, Farbton) hilft VDs Preview-Funktion enorm.

    Mein Beispiel-Quellfile findet ihr unter:
    http://www.truesoundtransfers.de/greyscale0255.avi

    und hier ist das Script. Wenn man das erste und letzte "Levels"-Kommando weglässt, sieht man den Unterschied doch sehr deutlich - Grautreppe statt Graukeil!

    #RGB<->YUV Umwandlung ohne Grautreppen-Artefakte, selbst wenn man mehrere Instanzen von AVS und VD hintereinanderschaltet
    #Verlangt RGB-Signal mit reduziertem Kontrast: Lumawerte unter 16 und über 235 übersteuern, da der YUV Lumabereich nur 220 und nicht 256 ist

    input=AVISource("h:\~Film\greyscale0255.avi", pixel_type="RGB24")

    #-------------------------
    #Erster Levels-Filter vermeidet nichtlineare Luma-Zuordnung von RGB auf YUV

    input=Levels(input,16,1,235,0,255)
    input=ConvertToYUY2(input)

    #-------------------------
    #Hier kommt die YUY2 und/oder YV12 Filterkette hin
    #Filter die RGB-Farbraum verlangen sollten entweder vor den ersten "ConvertToYUY2"-Befehl oder ans Ende hinter den "ConvertToRGB"-Befehl gestellt werden

    input=Histogram(input, mode="classic")

    #-------------------------
    #Zweiter Levels-Filter für artefaktlose RGB-Darstellung und Speicherung in VirtualDub
    #Notwendig, falls das entstehende VD-Ausgangsfile (unkomprimiert oder Huffyuv-RGB) als Quellfile für eine weitere AVS/VD Bearbeitungsstufe dienen soll
    #Kann am Schluß der Bearbeitung weggelassen werden wenn voller RGB-Kontrast (aber dann mit Artefakten!) im Ausgangsfile gewünscht wird

    input=ConvertToRGB(input)
    input=Levels(input,0,1,255,16,235)

    return input

  • Anstatt andauernd "input=Filter(input, parameter)" zu schreiben, reicht auch "Filter(parameter)". AviSynth schleift intern den letzten Bearbeitungsschritt als impliziten Clip mit dem Namen "last" durch. Und "return last" ist automatisch komplett implizit.

    Beispiel:

    AVISource("h:\~Film\greyscale0255.avi", pixel_type="RGB24")
    Levels(16,1,235,0,255)
    ConvertToYUY2()
    ...
    __

    Außerdem könnte für dich interessant sein:

    http://www.avisynth.org/ColorYUV -- ColorYUV(levels="PC->TV") | ColorYUV(levels="TV->PC")

  • Außerdem könnte für dich interessant sein:

    http://www.avisynth.org/ColorYUV -- ColorYUV(levels="PC->TV") | ColorYUV(levels="TV->PC")

    Den Befehl kenne ich, mit dem habe ich mich ja rumgeärgert und kam zu nichts (bzw. kam dazu, meine Frage hier zu stellen). Das Problem ist, dass "ColorYUV" - wie der Name ja schon vermuten läßt - nur im YUV-Format arbeitet, aber das RGB-Signal bei der Wandlung mit "ConvertToYUY2", die ja VOR "ColorYUV" stehen muß, bereits einmal verändert wird: Ohne vorher "Levels (0,1,255,16,235)" zu setzen, wird halt RGB=0 zu YUV=16 usw. bis RGB=255 zu YUV=235 umgerechnet. Und da es keine "halben Bits" gibt, werden insgesamt 36 Original-Graustufen durch den Rundungsfehler verschluckt, und zwar nicht durch Übersteuern an den (vielleicht im Bild garnicht oder kaum vertretenen) Extremwerten, sondern an 36 Stellen quer durch den Tonumfang. Normalerweise vielleicht nicht besonders störend, aber wenn das Material viele großflächige Grau- bzw. Farbschattierungen aufweist, noch dazu nicht besonders scharf ist, und obendrein noch eine stärkere Kontrast- oder Gammakorrektur verträgt, dann sieht man die entstehenden Stufen halt doch als "Konturen" an Stellen, wo keine sein sollten, im bewölkten Himmel etwa, oder an den diffusen Rändern eines Scheinwerferkegels, die zu "Ringen" verfremdet werden. Anschließendes Schärfen des Bildes verschlimmert das Problem, indem die Pseudokonturen auch noch schön hervorgehoben und verstärkt werden.

    Jedenfalls danke ich allen Beteiligten nochmal für ihre Hilfe; meine Bearbeitungen sehen jetzt weitaus besser und natürlicher aus, und der kleinere Kontrastumfang ist bei TV-Wiedergabe der fertigen DVD kein großer Nachteil - im Gegenteil: die überstrahlten Lichter und ins Schwarze abgesoffenen Schatten, die mich auch bei etlichen Kauf-DVDs speziell von S/W-Material stören (und von denen ich auf diese Weise auch gelernt habe, wie sie zustandekommen), kommen so selbst bei Wiedergabe über einen einfachen Röhren-TV nicht mehr vor. Vielen Dank!

Jetzt mitmachen!

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