• Zitat von Didée


    Weil, falls da zum Bleistift schon Code für "inverses lumimasking" (niedrigere Quantisierung für low-energy-Bereiche, a.k.a. "dark scenes" ... m.E. *das* wichtigste noch fehlende RDO/HVS-Feature) existieren sollte, dann beiss' ich mich in den /*zensiert*/ ...

    Bisher sieht ja das Lumimasking so aus:

    Wenn die durchschnittliche Helligkeit des Frames 170 nicht über bzw. 60 nicht unterschreitet, werden Blocks, die heller als 200 oder dunker als 90 sind stärker quantisiert. Das sieht dann ungefähr so aus (Anhang), wenn man den finalen Quantizer gegen Helligkeit des Blocks und den von der Ratecontrol vorgegeben Quantizer aufträgt.

    Wenn du etwas genauer ausführst, was dieses Inverse Lumimaksing anders machen und bewirken soll, kann ich mal versuchen (<- Betonung auf versuchen, ich hab XviD noch nie selber compilt) eine Spezialversion für Didée zu bauen.


    P.S.: Ich glaube katjarella hat das mit den Spezialoptionen nicht so ganz ernst gemeint. :D

    Dateien

    Es gibt eine Theorie, die besagt, dass das Universum sofort verschwinden und etwas noch Unerklärlicheres und Bizarres an seine Stelle treten wird, sobald jemand herausfindet, wofür es gut ist und warum es existiert.

    Es gibt eine andere Theorie, die besagt, dass das bereits geschehen ist.

  • Hübscher Graph :) - Wie geht sowas mit vier Komponenten ? ;)

    Zitat von Kopernikus

    Wenn du etwas genauer ausführst, was dieses Inverse Lumimaksing anders machen und bewirken soll


    Also die Idee ist wirklich nicht schwierig:

    Das derzeitige Lumimasking versucht die Komprimierung dort zu erhöhen, wo man sie nicht sehen kann.
    Nun erweitert man das um eine Funktion mit dem Zweck, die Komprimierung dort zu veringern, wo kleine Fehler viel stärker wahrgenommen werden - eben in dunklen Szenen.
    Also:

    alt:

    Average > 60 && Average < 170 ? RaiseQuantFor( Y_block < 90 || Y_block > 200 )
    (Kann das eigentlich so stimmen? Wenn FrameAverage<60, dann quetsche alle Blocks<90? Komisch...)

    zusätzlich:

    Average < 60 ? LowerQuantFor( Y_block < 0.66*(Average-16)+16 )


    mal ganz einfach vom Prinzip her, mit einer groben Schätzung. Wo/wieviel genau man die reduzierte Quantisierung zuweist, müsste man dann halt einmal sehen.

    Übertreiben darf man's auch nicht, weil man damit die Bitrate vermutlich schnell in unangenehme Höhen treiben kann ... bestimmt muss man da einiges herumprobieren, bis es dann (hoffentlich) passt. Formeln für die Entscheidung welcher Block wie zu quantisieren wäre kann man produzieren - das ist kein Problem ;) - könnte mir auch ein Förmelchen vorstellen, wo man dann nicht einfach per Checkbox das "Inverse Lumimasking" ("Dark Boost" ?) ein- oder ausschaltet, sondern z.B. einen Wert 0-100 vorgibt, der die "Aggressivität" bestimmt, oder so ...

  • Zitat von Didée

    Hübscher Graph :) - Wie geht sowas mit vier Komponenten ? ;)

    Ist GNUplot, nachdem ich ewig versucht hab, nach png zu exportieren hab ich einfach einen Screenshot gemacht


    Zitat von Didée


    Also die Idee ist wirklich nicht schwierig:

    Das derzeitige Lumimasking versucht die Komprimierung dort zu erhöhen, wo man sie nicht sehen kann.
    Nun erweitert man das um eine Funktion mit dem Zweck, die Komprimierung dort zu veringern, wo kleine Fehler viel stärker wahrgenommen werden - eben in dunklen Szenen.

    Zwar behauptet das das Gesetz von Weber/Fechner, aber das ist nur näherungsweise gültig. In einigen Texten, die ich zu diesem Thema gelesen habe, ist eine Beziehung zwischen Fehlersichtbarkeit und Helligkeit abgeleitet worden, die der Formel, die verwendet wird, nicht so unähnlich ist. Der Schwellenwert für die Wahrnehmung von Reizen ist in sehr dunklen Bereichen sogar deutlich höher als in sehr hellen. (z.B. http://www.cns.nyu.edu/~zwang/files/papers/icmps.pdf, ist nur eine Skizze im Anhang und an das Originalpaper kommt man nicht ran ohne weiteres)
    In wie fern das mit der Realität bei XviD übereinstimmt, habe ich jetzt nicht überprüft. Treten sichtbare Artefakte in dunklen Bereichen stärker auf?


    In der Dokumentation steht, dass diese doppelte Threshold Geschichte dazu da ist, um bei grundsätzlich sehr hellen und sehr dunklen Frames (z.B. Autoscheinwerfer in der Nacht) nicht zu Verblockungen in den etwas helleren Bereichen zu führen.

    Die Formel im Sourcecode zu ändern und das zu kompilieren, das ist kein Problem, an das VFW Interface trau ich mich nicht ran, und eine parametrisierte LM Formel würde vermutlich die API ändern, wäre also was Größeres. Aber hardcoded kann man das schon ändern.

    Also wir können das gerne mal probieren. Meister sprich, wie soll das Lumimasking sich verhalten? Ich geb hier mal die aktuelle Formel an:

    Für dunkle Blocks:
    Qneu = Qalt * (1 + (14/4)*(90-Y_Block)/90)

    Für helle Blocks:
    Qneu = Qalt*(1+ (10/3)*(Y_Block-200)/(255-200))

    Es gibt eine Theorie, die besagt, dass das Universum sofort verschwinden und etwas noch Unerklärlicheres und Bizarres an seine Stelle treten wird, sobald jemand herausfindet, wofür es gut ist und warum es existiert.

    Es gibt eine andere Theorie, die besagt, dass das bereits geschehen ist.

  • Zitat von Kopernikus

    Treten sichtbare Artefakte in dunklen Bereichen stärker auf?

    Siehe hier.

    "Diejenigen, die grundlegende Freiheiten aufgeben würden, um geringe vorübergehende Sicherheit zu erkaufen, verdienen weder Freiheit noch Sicherheit."
    Benjamin Franklin (1706-1790)

    Meine Erfahrungen in der Open Source-Welt: blog.bugie.de

  • Was hier angesprochen ist, hat aber mit Lumimasking nicht direkt so viel zu tun. Dunkel ist nicht gleich kontrastarm.

    Der Effekt des Contrastmasking, also das "Verstecken von Fehlern in kontrastreichen Bereichen" wird in XviD gar nicht ausgenutzt. Dazu hab ich auch nicht so viele Informationen gefunden, das müsste man eben selber ausprobieren.

    Ich bin leider nicht so firm mit dem XviD Sourcecode, aber prinzipiell könnte man das Lumimasking ein bisschen aufbohren, und die Kontraste berücksichtigen. Die LM Funktion rödelt eh einmal durch alle Blöcke, um die Helligkeiten zu berücksichtigen, da könnte man Kontraste relativ billig mitnehmen. Denke ich mal.

    Es gibt eine Theorie, die besagt, dass das Universum sofort verschwinden und etwas noch Unerklärlicheres und Bizarres an seine Stelle treten wird, sobald jemand herausfindet, wofür es gut ist und warum es existiert.

    Es gibt eine andere Theorie, die besagt, dass das bereits geschehen ist.

  • Jetzt aber mal langsam, damit wir nicht stolpern und ein Bein brechen.

    Zitat von Kopernikus

    Für dunkle Blocks:
    Qneu = Qalt * (1 + (14/4)*(90-Y_Block)/90)

    Für helle Blocks:
    Qneu = Qalt*(1+ (10/3)*(Y_Block-200)/(255-200))


    Zwar trau' ich mich kaum zu widersprechen - Du kennst XviD's Sourcen viel besser als ich (hast immerhin schon mal reingeschaut ;) ) - aber: kann *das* wirklich sein? Und warum überhaupt *Faktoren*? Ich hätte "Offsets" für die Quantizer erwartet, aber keine Faktoren.

    Beispiel:
    Avg_Frame = 100, Quant_Frame (Qalt) = 8, und ein Block mit Y_Block = 20. Wir berechnen Qneu für diesen Block:

    Code
    Qneu = Qalt * (1 + (14/4)*(90-Y_Block)/90)
    
    
         = 8 * (1 + 2.7222) ~= 30


    Lumimasking soll einen Blockquantizer von 8 auf 30 pushen? DREISSIG?! Sorry, aber da kann irgendwas nicht stimmen ...


    Also, bevor wir hier mit (womöglich komplizierten) Formeln anfangen, sollten wir erst mal Gewissheit darüber haben, wie diese angepassten Block-Quantizer wirklich berechnet werden.

    Um noch weiter in dieselbe Kerbe zu hauen:

    Zitat

    Der Effekt des Contrastmasking, also das "Verstecken von Fehlern in kontrastreichen Bereichen" wird in XviD gar nicht ausgenutzt. Dazu hab ich auch nicht so viele Informationen gefunden, das müsste man eben selber ausprobieren.


    Wenn man sich die von Dir geposteten Formeln anschaut, scheint das zu stimmen: keine Kontrast-abhängige Maskierung, sondern vielmehr eine, sozusagen, "großflächige".

    Aber: das stimmt nicht. Die Praxis beweist nämlich, dass XviD sehr wohl kontrastabhängig maskiert. Wenn man AQ aktiviert, und sich dann per ffdshow die Block-Quantizer anzeigen lässt, dann sieht man dass die höheren Quantizer nur für Blöcke benutzt werden, die am "Randbereich" des Kontrastumfanges des jeweiligen Frames liegen.

    Kopernikus, Du hast die Formeln aber nicht etwa aus alten Dev3-API - Sourcen ausgegraben, nein? Da war Lumimasking nämlich so schlecht (u.U. bis zur Unbrauchbarkeit), dass diese Formel gepasst haben könnten ...


    Und zum guten Schluss dieser Post:

    Zitat

    Zwar behauptet das das Gesetz von Weber/Fechner, aber das ist nur näherungsweise gültig. In einigen Texten, die ich zu diesem Thema gelesen habe, ist eine Beziehung zwischen Fehlersichtbarkeit und Helligkeit abgeleitet worden, die der Formel, die verwendet wird, nicht so unähnlich ist. Der Schwellenwert für die Wahrnehmung von Reizen ist in sehr dunklen Bereichen sogar deutlich höher als in sehr hellen.


    Weber/Fechner kenne ich nicht, und Papier ist geduldig. Jedenfalls bin ich mir ziemlich sicher, wenn ich ein Encoding mit avgQ ~= 4 mache, sehen helle Passagen gut aus, und dunkle Passagen oftmals schmierig. Wenn ich die Quantisierung für letztere auf 3 reduziere, wird's besser. Und bei 2 wird's gut.

    Da wollen wir hin.

  • Ok, was ich unterschlagen habe, ist, dass XviD die Quantizer nachher noch ein bisschen "glättet", damit benachbarte Blocks keine zu unterschiedlichen (Differenz > 2) Quantizer bekommen. Dabei werden zu krasse aussenseiter natürlich rausgeglättet.

    Es ist aber wirklich so, dass Lumimasking nur die durchschnittliche Blockhelligkeit und die gesamte Framehelligkeit berücksichtigen. Vielleicht habe ich noch eine Kontrastabhängige Funktion übersehen, aber ich wüsste auf Anhieb nicht wo.

    Zitat

    Aber: das stimmt nicht. Die Praxis beweist nämlich, dass XviD sehr wohl kontrastabhängig maskiert. Wenn man AQ aktiviert, und sich dann per ffdshow die Block-Quantizer anzeigen lässt, dann sieht man dass die höheren Quantizer nur für Blöcke benutzt werden, die am "Randbereich" des Kontrastumfanges des jeweiligen Frames liegen.

    Kopernikus, Du hast die Formeln aber nicht etwa aus alten Dev3-API - Sourcen ausgegraben, nein? Da war Lumimasking nämlich so schlecht (u.U. bis zur Unbrauchbarkeit), dass diese Formel gepasst haben könnten ...

    Nein, sind aus den aktuellen 1.10 beta2 Sourcen. Ich hab in den Mailinglisten oder dem CVS Log gesehen, dass uManiac suxen_drols Lumimasking algorithmus (der aktuelle) verändert hatte und da z.B. die globalen Thresholds rausgenommen hatte. Daraufhin gab es wohl Beschwerden über Verblockungen .

    Könnte das vielleicht damit zusammenhängen, dass in durchschnittlich sehr dunklen und sehr hellen Bereichen nicht mehr viel Platz für große Dynamikumfänge ist?

    Zitat

    Weber/Fechner kenne ich nicht, und Papier ist geduldig. Jedenfalls bin ich mir ziemlich sicher, wenn ich ein Encoding mit avgQ ~= 4 mache, sehen helle Passagen gut aus, und dunkle Passagen oftmals schmierig. Wenn ich die Quantisierung für letztere auf 3 reduziere, wird's besser. Und bei 2 wird's gut.

    Da wollen wir hin.

    Webers Gesetz sagt, dass die Amplitude eines gerade noch bemerkbaren unterschieds proportional zur Amplitude des Reizes ist.Also auf helligkeiten und Fehler bezogen: In hellen Bereichen sieht man erst sehr große Fehler, in dunklen Bereichen eher. Fechner sagt daraufhin, dass jeder gerade sichtbare Unterschied gleich sichtbar ist, daraus ergibt sich die logarithmische Beziehung bei Reizen, die sich ja z.B. auch in PSNR widerspiegelt.

    Aber Weber und Fechner sind nur grobe Näherungen, und vor allem bei großen oder sehr schwachen Reizen nicht gültig.

    Ich schlage vor, du schlägst eine Formel vor, und ich bau sie mal ein, und dann probieren wirs aus. (Probieren geht über studieren :)) Ich werde nachher noch ein bisschen XviD studieren, damit ich auch nichts übersehen habe.

    Es gibt eine Theorie, die besagt, dass das Universum sofort verschwinden und etwas noch Unerklärlicheres und Bizarres an seine Stelle treten wird, sobald jemand herausfindet, wofür es gut ist und warum es existiert.

    Es gibt eine andere Theorie, die besagt, dass das bereits geschehen ist.

  • (Aber doch nicht während ich gerade fleissig poste ... jetzt bin ich völlig verwirrt!)

    Also gut. Den Schwellenwert von 90 behalten wir einfach mal, scheint ganz okay zu sein.

    WENN: Yavg_Frame <= 90, DANN:

    - Einfache Variante:

    Dunkle Blöcke: Qneu = Qalt - 1 ( :D )


    - Andere Variante:

    Qneu = Qalt * (2+(((Yavg_Frame+16)/2-Y_Block)/(Yavg_Frame-16)/2))^2)/3

    Ist noch nicht ~wirklich~ das, was mir vorschwebt ... diese Formel liefert:

    Qneu = Qalt für Y_Block=16 und Y_Block=Yavg_Frame

    und

    Qneu = 2/3*Qalt für Y_Block = (16+Yavg_Frame)/2

    d.h. das ist einfach nur eine Parabel. Mit irgendwas muss man anfangen, warum also nicht damit.

  • Soll ich das mit den globalen Thresholds beibehalten?

    Es gibt eine Theorie, die besagt, dass das Universum sofort verschwinden und etwas noch Unerklärlicheres und Bizarres an seine Stelle treten wird, sobald jemand herausfindet, wofür es gut ist und warum es existiert.

    Es gibt eine andere Theorie, die besagt, dass das bereits geschehen ist.

  • Jo, sollte schon drinbleiben. Das Forcieren von niedrigerer Quantisierung macht nur Sinn, wenn der Frame im Durchschnitt eher dunkel ist. (In einer Sonnenbeschienenen Felsenlandschaft müssendie schwarzen Schlagschatten nicht "verbessert" werden. Im Gegenteil, hier -> normales AQ Lumimasking.)

    Deswegen hatte ich doch geschrieben: Für Frames mit AverageLuma kleiner als 90: etc.

  • Irgendwie geht bei deiner Formel eine Klammer zuwenig wieder zu, ich hätte sie am Schluss zugemacht, aber schau es dir lieber nochmal an.

    Hast du ICQ?

    Ich bin jetzt aber erstmal eine Runde offline, gegen späteren Nachmittag hoffe ich die ersten Ergebnisse präsentieren zu können.

    Was ist geschickter? VFW oder CLI?

    Es gibt eine Theorie, die besagt, dass das Universum sofort verschwinden und etwas noch Unerklärlicheres und Bizarres an seine Stelle treten wird, sobald jemand herausfindet, wofür es gut ist und warum es existiert.

    Es gibt eine andere Theorie, die besagt, dass das bereits geschehen ist.

  • Da gehen jetzt 5 Klammern auf, und nur 4 wieder zu :)

    Ist es das was du meinst?

    Bilder

    Es gibt eine Theorie, die besagt, dass das Universum sofort verschwinden und etwas noch Unerklärlicheres und Bizarres an seine Stelle treten wird, sobald jemand herausfindet, wofür es gut ist und warum es existiert.

    Es gibt eine andere Theorie, die besagt, dass das bereits geschehen ist.

  • Damit ihr euch ein bisschen die Zeit vertreiben könnt:

    Ein erster Versuch, an der Adaptiven Quantisierung rumzuschrauben:

    Ich hab versucht eine Art Contrastmasking versucht zu implementieren. D.h. von jedem Macroblock wird die durchschnittliche Hellgikeit bestimmt und dann die Standardabweichung (Summe über die Quadrate der Differenzen der Pixel zur Grundhelligkeit) berechnet.

    Je größer diese, desto unruhiger ist der Block. Da man in solchen Blöcken Quantisierungsfehler nicht so stark sieht, kann man den Quantizer erhöhen.
    Bisher auf folgende Art:

    Qneu = Qalt + (Contrast /1000)

    Die herkömmliche AQ ist dabei ausser Funktion gesetzt.

    Um zu testen, die angehängte XviD Version installieren, und mit AQ oder ohne encoden. Die herkömmliche AQ ist durch die Contrastmasking AQ ersetzt. Ohne Häkchen bei AQ ist alles wie beim Standard Build 1.10 beta 2, mit AQ ist die CM AQ aktiviert.

    Hinweise:
    -Wenn man mit konstantem Quantizer encodet, kann man die Bitratenersparnis direkt an der verminderten Endgröße sehen.
    -Wenn man bei ffdshow die Visualisierung der Quantizer aktiviert, kann man die Quantizer der Blöcke anschauen
    -Der bisherige Modus ist einfach ein Schuss ins Blaue, ich bin offen für Anregungen aller Arten.


    http://web3.gleitz.org/Kopernikus/XviD110beta2mod1.zip

    @Didee: Mir kam grad die Idee, dass es durchaus interessant sein könnte, im Encoder Kanten zu suchen, und Blöcke mit Kanten drin niedriger zu quantisieren, um Ringing zu vermeiden. Du kennst dich doch in der Materie sicher aus, wie findet man Kanten in einem 16x16 Block?

    Es gibt eine Theorie, die besagt, dass das Universum sofort verschwinden und etwas noch Unerklärlicheres und Bizarres an seine Stelle treten wird, sobald jemand herausfindet, wofür es gut ist und warum es existiert.

    Es gibt eine andere Theorie, die besagt, dass das bereits geschehen ist.

  • Zitat von Kopernikus

    Da gehen jetzt 5 Klammern auf, und nur 4 wieder zu :)


    Heiliger Strohsack, jetzt leck mich doch einer am A.. ..ermel !! Klammern sind beim auf-Papier-Schreiben ja gerade noch okay, aber in nur-Text - Editoren :mad:
    (Ich LIEBE inzwischen die Inverse Polnische Notation! Keine Klammern! )

    Zitat

    Ist es das was du meinst?

    [wunderschöne Formel-Grafik]


    Jawoll, das wär's gewesen. Naja, zumindest beinahe ;) - Da fehlt jetzt die Division durch Drei, ganz am Ende. Soll ja ein Faktor zwischen (2+1)/3 und (2+0)/3 'rauskommen. :)

    ***

    "Contrast Masking"

    Aaah ... jetzt verstehe ich, was Du mit dem Begriff meinst. Das heißt also (stark vereinfacht), je mehr "Textur"-Information ein Block trägt, umso stärker wird er quantisiert. Ja?
    Das ist auch ein interessanter Ansatz. Ganz spontan denke ich da an Anime - könnte helfen, einheitliche Flächen wirklich "glatt" zu kriegen. Hmh. Vielleicht auch hier der umgekehrte Ansatz: nicht die "unruhigen" Blöcke stärker quantisieren, sondern die "ruhigen" schwächer (wg. Mosquito-Noise-Bildung an den Linien, und so) ?

    Grundsätzlich mag ich den umgekehrten Ansatz ja lieber: nicht die Texturen stärker packen (immerhin ist das ja das, was der Codec überhaupt zu transportieren versucht), sondern da, wo am ehesten "ungünstiger" Verlust auftritt, schwächer komprimieren.
    Ganz am Ende macht's vielleicht gar nicht so viel Unterschied - das eine veringert den Durchschnitts-Quantiser, das andere erhöht ihn. In einem 2-pass-Szenario führen vielleicht beide Methoden zu sehr ähnlichem Ergebnis. Ist ne Frage der Philosophie: die Reichen schröpfen, Gewinn in die Luft werfen und darauf hoffen, dass er sich gerecht verteilen wird? Oder ausdrücklich den Armen helfen, und alle anderen müssen zusammenlegen?

    Das erinnert mich doch an ... nein, ich hör' jetzt lieber auf. :D

  • Also zu Contrastmasking: Der Ansatz ist eigentlich ganz einfach: Je mehr in einem Block &quot;los ist&quot;, desto weniger sieht man Fehler. Noch besser funktioniert das, wenn der Fehler eine ähnliche Frequenz hat wie die Textur. Hier sieht man das recht gut. In dieses Bild wurden 2 Blöcke starkes zufälliges Rauschen eingebaut. Einer in einer sehr kontrastarmen Gegend, der andere in einer stark texturierten. Den ersten findet man leicht, den zweiten nicht so leicht (Auflösung unten :))
    [Blockierte Grafik: http://web3.gleitz.org/Kopernikus/ContrastMasking.png] Daher kommt auch der Name Masking: Die Maske (Textur) maskiert das Target (in unserem Fall den Quantisierungsfehler). Interessant ist, dass Maske und Target nicht gleichzeitig präsent sein müssen.Die Maske kann auch kurz nachher oder sogar kurz vorher sichtbar sein, und das Target wird trotzdem maskiert.

    Zitat

    Das ist auch ein interessanter Ansatz. Ganz spontan denke ich da an Anime - könnte helfen, einheitliche Flächen wirklich &quot;glatt&quot; zu kriegen. Hmh. Vielleicht auch hier der umgekehrte Ansatz: nicht die &quot;unruhigen&quot; Blöcke stärker quantisieren, sondern die &quot;ruhigen&quot; schwächer (wg. Mosquito-Noise-Bildung an den Linien, und so) ? Grundsätzlich mag ich den umgekehrten Ansatz ja lieber: nicht die Texturen stärker packen (immerhin ist das ja das, was der Codec überhaupt zu transportieren versucht), sondern da, wo am ehesten &quot;ungünstiger&quot; Verlust auftritt, schwächer komprimieren. Ganz am Ende macht's vielleicht gar nicht so viel Unterschied - das eine veringert den Durchschnitts-Quantiser, das andere erhöht ihn. In einem 2-pass-Szenario führen vielleicht beide Methoden zu sehr ähnlichem Ergebnis. Ist ne Frage der Philosophie: die Reichen schröpfen, Gewinn in die Luft werfen und darauf hoffen, dass er sich gerecht verteilen wird? Oder ausdrücklich den Armen helfen, und alle anderen müssen zusammenlegen?

    Umgekehrt kann man das natürlich auch machen, aber im ursprünglichen Lumi Masking wurden auch nur Quantiser erhöht, deswegen hab ich das jetzt auch so gemacht.

    Zitat

    nicht die &quot;unruhigen&quot; Blöcke stärker quantisieren, sondern die &quot;ruhigen&quot; schwächer (wg. Mosquito-Noise-Bildung an den Linien, und so) ?

    Deswegen hab ich mich grade nach Kantenerkennungsmethoden umgeschaut. Wenn man weiß, dass durch einen Block eine Kante läuft, kann man da den Quantizer nicht-erhöhen oder sogar erniedrigen. Auflösung: vom Betrachter aus gesehen rechtes Knie neben dem Ellenbogen.

    Es gibt eine Theorie, die besagt, dass das Universum sofort verschwinden und etwas noch Unerklärlicheres und Bizarres an seine Stelle treten wird, sobald jemand herausfindet, wofür es gut ist und warum es existiert.

    Es gibt eine andere Theorie, die besagt, dass das bereits geschehen ist.

  • Zitat von Kopernikus

    @Didee: Mir kam grad die Idee, dass es durchaus interessant sein könnte, im Encoder Kanten zu suchen, und Blöcke mit Kanten drin niedriger zu quantisieren, um Ringing zu vermeiden. Du kennst dich doch in der Materie sicher aus, wie findet man Kanten in einem 16x16 Block?


    Kommt drauf an, was für Mittel und in welcher Form die Bildinformationen zu Verfügung stehen. (Merke: wie all' die Sachen Marke "unterste Ebene" in XviD funktionieren, da kenne ich mich wirklich nicht aus. Bewege mich üblicherweise ein, zwei Abstraktionsebenen höher ;) )

    Methoden gibt's viele. Die einfachste Kantendetektion vergleicht einfach die Differenz diff(Pixel, avg(3*3 Pixel)), also der Unterschied eines Pixels zum Durchschnitt seiner 3x3-Umgebung. Einfach, schnell, und sehr anfällig gegen Rauschen.
    Stabiler, ruhiger und langsamer arbeiten sog. "Canny"-Verfahren ... z.B. erstmal alles weichzeichnen (z.B. 3x3 average), und dann die beschriebene einfache methode.
    oder: Einen Sobel-Kernel anwenden.
    Oder: Zwei Orthogonale Kernels anwenden.
    Oder: oder dieses, oder jenes, folgendes, nochwasanderes ...

    Nochwas ist wichtig: Ein guter Plan, *wo* eingespart und *wo* ausgeteilt werden soll. Wenn wir nämlich versuchen, die Quantizer überall dort zu verringern, wo es dem Bildinhalt gut tuen würde, dann bleibt *nix* mehr übrig, wo wir die nötigen Bits hernehmen können ... weil wir die Quantizer bereits überall im gesamten Frame erhöht haben ;)

  • Zitat

    Kommt drauf an, was für Mittel und in welcher Form die Bildinformationen zu Verfügung stehen. (Merke: wie all' die Sachen Marke "unterste Ebene" in XviD funktionieren, da kenne ich mich wirklich nicht aus. Bewege mich üblicherweise ein, zwei Abstraktionsebenen höher )

    Also ich hab das ganze Bild (alle 3 Planes mit Wet jedes Pixels), und ich kann alles machen, was man in C programmieren kann (also eine ganze Menge). Ich bin grad am Sobel Kernel mit rumspielen. Wann und was man einspart ist natürlich wichtig, aber selbst wenn man die Kantenerkennung nur nutzt, um Blocks mit Kanten vor überquantisierung zu schützen (also den Quantizer belässt), interessant, um damit zu spielen ist es in jedem Fall :) Kanten sind auf jeden Fall anfällig. Mosquito Noise ist ätzend und fällt auf. Gerade Leute die sich ein bissel auskennen schauen dort eher hin.

    Es gibt eine Theorie, die besagt, dass das Universum sofort verschwinden und etwas noch Unerklärlicheres und Bizarres an seine Stelle treten wird, sobald jemand herausfindet, wofür es gut ist und warum es existiert.

    Es gibt eine andere Theorie, die besagt, dass das bereits geschehen ist.

  • Ich bin mir nicht so ganz sicher, ob die vorgeschlagene Funktion das tut, was wir wollen. zum einen ist u.U. eine ganz hässliche Division durch 0 drin, zum anderen hauen uns die Quantizer für sehr niedrige Frame und Blockhelligkeiten ins unendliche ab. Geplottet sieht sie so aus (siehe Anhnag).

    Falls jemand Interesse hat zu testen, hab ich noch eine weitere Version mit einem anderen Lumimasking Algo erstellt:

    http://web3.gleitz.org/Kopernikus/XviD110beta2mod2.zip

    Ich hab noch nicht so viel damit getestet, für Meinungen Kritik und Anregungen bin ich dankbar.

    Dateien

    Es gibt eine Theorie, die besagt, dass das Universum sofort verschwinden und etwas noch Unerklärlicheres und Bizarres an seine Stelle treten wird, sobald jemand herausfindet, wofür es gut ist und warum es existiert.

    Es gibt eine andere Theorie, die besagt, dass das bereits geschehen ist.

Jetzt mitmachen!

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