XviD Lumimasking

Ja (gestern abend), und hab auch eine Antwort gekriegt. Er schaut sichs mal an, aber nicht sofort, wegen Prüfungen.

Ein Zitat aus der PM, das mich erschüttert hat:

Zitat

Unfortunately there are no active developers left, so indeed, there's no one to respond..

Was ist mit suxen_drol und isibaar? weiß da einer genaueres?

Ich denke gerade darüber nach, das Lumimasking so zu modifizieren, dass man eine Art "Profil" erstellen kann, das aus einer Textdatei besteht, in der im wesentlichen ein Lookuptable abgelegt ist, das das Plugin einliest, und anhand dessen es das Lumimasking durchführt. Der Vorteil ist, dass man so schon mit der vorhandenen AQ sehr einfach experimentieren könnte, die Erkenntnisse dann aber einfach auf ein Lambda basiertes Plugin übertragen werden könnten.

Das Problem ist, dass diese Tabelle im Profil recht unübersichtlich werden könnte, wenn die Stärke des LM von sehr vielen Faktoren abhängt, und wenn man diese mit hoher Genauigkeit berücksichtigt.

Also eine Funktion LM(lum_global,lum_lokal,quant) bräuchte theoretisch ein 256*256 = 65000 Mio Einträge großes LUT.

Es gibt zwei Alternativen:

Entweder man betrachtet die Faktoren separat, also

LM(lum_global,lum_lokal,quant) = F1(lum_global)*F2(lum_lokal)*F3(quant)

Dann hätte man nicht mehr alle Freiheiten, aber käme mit 3 LUTs mit 256, 256 und 31 Einträgen aus, was ja machbar wäre. F3(quant) und F2(lum_global) sind ja wahrscheinlich eh Fensterfunktionen, die das LM für bestimmte Werte an (1) oder aus (0) schalten, bzw. kontinuierlich ausblenden.

Oder man verringert die Genauigkeit, mit der die Faktoren berücksichtigt werden. Kann man nur 64 verschiedene Helligkeitslevel unterscheiden, so reduziert sich die Größe der Tabelle auf 64*64 = 4096, was auch noch handhabbar wäre.

So, ich hatte ein bisschen Zeit und habe ein (noch) sehr einfaches Plugin für XviD gebastelt, dass das bisherige Lumimasking verbessern und erweitern soll. Es macht dabei momentan nur Gebrauch von der "neuen", RD-basierten Möglichkeit verschiedene Bildteile zu gewichten, die im ersten Leben dieses Threads entstanden ist. Es ist aber geplant, auch zusätzlich die herkömmliche adaptive Quantisierung zu verwenden, da die Lambda-Gewichtung nach meinen ersten Tests nicht so stark modulieren kann wie AQ.

Das Plugin liest ein Profil ein, in dem festgelegt werden kann, was es wie gewichten soll. So können experimentierfreudige Zeitgenossen (insbesondere Didèe) nach Herzenslust tunen und tweaken (ohne das man aneinander vorbeiredet :D).

Die Gewichtung funktioniert über Modulation des sogenannten Lambda-Faktors. Dieser Faktor wird eingesetzt, um eines günstiges verhältnis zwischen Bitverbrauch und Bildfehlern zu erreichen.Für verschiedene Encodierungsmodi wird dazu eine Größe RDScore = Bitverbrauch + lambda*Bildfehlern verglichen, und der Modus mit der niedrigsten Score verwendet.

Größere Lambdas begünstigen somit Modi, die wenig Bildfehler produzieren, dabei aber mehr Bits verbrauchen, kleinere Lambdas solche die weniger Bits brauchen, aber dabei mehr Bildfehler produzieren.

Der Lambdafaktor wird bei der Trellis Quantisierung und bei VHQ eingesetzt, das Plugin funktioniert bei hohen VHQ-Leveln und eingeschaltetem Trellis am besten, ohne VHQ und Trellis ist es wirkungslos. Es arbeitet nicht auf I-Frames.

Das Plugin ist in einer speziellen Version des Commandozeilenencoders integriert. Dieser sollte avisynth Skripte lesen können, aber bietet nicht alle Optionen, die Squid_80s mod offenlegt, da er auf der CVS Version von xvid_encraw basiert. Es wurden aber zusätzliche Parameter hinzugefügt.

Zum einen ein -trellis Parameter, mit dem man Trellis explizit aktivieren kann. Meistens ist Trellis zwar standardmäßig aktiviert, aber so kann man seine verwendung erzwingen,da es für die Funktion des Plugins wichtig ist.

Zum adneren der -hvs Parameter, der in der Form

-hvs Pfad

angegeben wird.

Damit übergibt man den Pfad zu einem Profil. Ein Profil besteht aus einer einfachen Textdatei, in der viele Zeilen der folgenden Form stehen:

Ganzzahl Kommazahl Kommazahl

zwischen den Zahlen sind Tabulatoren, hinter der zweiten Kommazahl muss direkt ein Zeilenumbruch stehen, nichts dazwischen. Die Bedeutung der Spalten ist folgende:

Helligkeitswert lokale Gewichtung globale Gewichtung

Aus diesen Daten erstellt das Plugin zwei Tabellen (global und lokal) mit jeweils 256 Einträgen. Standardmäßig ist jeder EIntrag der Tabellen 1.0. Im Profil angegebene Werte überschreiben diese. Kommen zwei Helligkeitswerte doppelt im Profil vor, so überschreibt der spätere den früheren.

Das Lambda eines Blockes mit der durchschnittlichen Helligkeit a in einem Frame mit der durchschnittlichen Helligkeit b ist das Produkt aus dem a-ten Eintrag der lokalen Tabelle und dem b-ten Eintrag der globalen Tabelle + 1.

So lässt sich der Mechanismus durch Nullsetzen von Einträgen für bestimmte Situationen deaktivieren. Schreibt man z.B. für die Helligkeitswerte 0 bis 100 0 in die globale Gewichtung, so passiert in Frames mit einer Helligkeit kleiner 100 nichts.

Ich habe die nächsten 2 Wochen nicht so viel Zeit, als dass ich intensive Tests fahren könnte, deshalb wollte ich hier um eure Mithilfe bitten, sinnvolle Profile für verschiedene Materialien und Situationen zu finden.

Ich habe vor, das Plugin noch zu erweitern, indem ich zusätzlich zur Lambda-Modulation noch adaptive Quantisierung verwende, und zusätzliche Kriterien einführe, von denen die Gewichtung abhängt. Auf dem Plan stehen im Moment Farbe (z.B. zur Vermeidung von sichtbaren Blöcken in blauem Himmel), Kanten (zur gezielten Verminderung von Ringing), Flachheit (wie viel "passiert" in einem Block).

Ich bitte um weitere Ideen, Vorschläge, Anregungen und Kritik.

Diese Version ist ausschlisßlich zu Testzwecken gedacht und absolut experimentell. Keine Gewähr für korrekte Funktion.

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

Es scheint ein Problem zu geben mit der angehängten Version. Auf meiner Windose beendet sich das Programm manchmal (nicht immer) nach dem Einlesen des Profils. Kann das jemand bestätigen, oder ist das nur bei mir so (mein Windows macht in letzter Zeit öfters Zicken)?

Ich compile den CL Encoder unter Linux, und da tritt das Problem nicht auf. Und unter Windows hab ich nicht das Handwerkszeug um zu debuggen.

Es geht weiter:

0.02
______________________________
fixed: line counter
changed: table entries are initialised to 0.0f
added: adaptive quantization
changed: column delimiters changed from tab to space

Man kann jetzt auch die adaptive Quantisierung beeinflussen. Das bedeutet, das einzelne Macroblöcke innerhalb eines Frames unterschiedliche Quantizer verwenden. Diese Methode funktioniert nicht in B-Frames.

Das Prinzip ist das gleiche wie bei den Lambdas. Der Basisquantizer (der Quantizer den der Frame von der Ratecontrol zugewiesen bekommen hat) wird mit dem Faktor (1 + lok Gewichtung * globale Gewichtung) multipliziert. Danach wird das Quantizerfeld normalisiert, da zwischen zwei aufeinanderfolgenden Macroblöcken höchstens 2 Quantizer unterschied sein dürfen.

Das Format der Profil Datei hat sich geändert in
Helligkeit Lambda-Lokal Lambda-Global AQ-Lokal AQ-Global

Zwischen den Spalten sind jetzt Leerzeichen, um aus Tabellenkalkulationsarbeitsblättern exportierte Profile zu erleichtern. Vielleicht hat ja jemand interesse ein OpenOffice Sheet zur Einfachen Erstellung von Profilen zu erstellen?

Das Build ist nicht unter Windows getestet, weil ich hier gerade nur mein Linux Läppi da hab.

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

Viel Spass beim Testen.

Ein weiteres Update:

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

(Achtung, die Datei wurde am 3.3.06 um 19:52 ausgetauscht, da sie eine fehlerhafte Version enthielt)

0.03 06-03-03
______________________________
fixed: memory bug
fixed: profile parsing for luminance 0 and 255
added: contrast/complexity measure
added: profile format version system
changed: profile format to version 3
added: documentation
changed column delimiters back from space to tab for clarity
fixed: memory bug in xvidcore

Insbesondere habe ich es geschafft die Readme mit einigen Details zur Funktionsweise zu erweitern:

Wichtige Hinweise:
__________________




Bei dieser Version von xvid_encraw handelt es sich um eine 
experimentelle, nicht offizielle Version zum Testen und Debuggen eines 
Plugins zur psychovisuellen Optimierung. Es wird keinerlei Haftung für 
eventuelle Schäden an Software, Hardware oder Daten übernommen. Die 
Benutzung erfolgt auf eigene Gefahr.


Anregungen, Kritik, Verbesserungsvorschläge und Ideen bitte hier:


[url]http://forum.gleitz.info/showthread.php?t=25150[/url]


Kopernikus




Funktionsweise:
_______________


Die beiliegende Binary von xvid_encraw unterscheidet sich von der im 
XviD-CVS durch zwei zusätzlicher Parameter -trellis und -hvs path


Der Parameter -trellis erzwingt die Verwendung der Trellis 
Quantisierung.


Der Parameter -hvs path aktiviert das HVS-Plugin und liest ein 
HVS-Profil in path ein


Das HVS-Profil gibt dem Anwender die Möglichkeit, Regeln zu definieren,
anhand derer das HVS-Plugin verschiedene Bildteile unterschiedlich 
stark komprimiert.


Dazu stehen zwei verschiedene Methoden zur Verfügung:


Adaptive Quantisierung (AQ) ermöglicht es, einzelnen Macroblöcken in 
einem Frame individuelle Quantizer zuzuordnen, und diese dadurch 
stärker oder schwächer zu quantisieren. Größere Quantizer komprimieren 
stärker, sparen aber Bits.


Nachteile:
-verbraucht Bitrate (2 Bit pro Macroblock)
-schränkt verwendbare Modi bei der Bewegungssuche ein
-Quantizer von zwei aufeinanderfolgenden Macroblöcken dürfen sich um 
höchstens 2 unterscheiden
-funktioniert nicht bei B-Frames




Lambda Modulation weist einzelnen Macroblöcken unterschiedliche 
Lambdawerte zu, anhand derer bei der RD-Optimierung von Bewegungssuche 
und Quantisierung Bitratenersparnis und Qualität gegeneinander 
abgewogen werden. Größere Lambdawerte gewichten Qualität stärker als 
Bitrate.


Nachteile:
-funktioniert nur in Verbindung mit hohen VHQ-Leveln und Trellis 
Quantisierung gut
-funktioniert nicht bei I-Frames


Das HVS-Plugin erlaubt es, diese beiden Methoden einzusetzen, um bei 
Blöcken, bei denen Fehler dem menschlichen Auge nicht so sehr 
auffallen Bits zu sparen und diese in Bereichen, in denen Fehler 
stärker sichtbar sind, dazu zu verwenden, um die Qualität zu steigern.


Auf die Sichtbarkeit von Fehlern hat eine Vielzahl von Faktoren 
Einfluss. Von diesen wertet das HVS-Plugin momentan 3 aus:


Die mittlere Helligkeit des Frames (=Framehelligkeit, FH) wird 
approximiert durch den Wert der Y-Komponente des Originalbildes 
gemittelt über das gesamte Frame.


Die mittlere Helligkeit eines Blocks (=Blockhelligkeit, BH) wird 
approximiert durch den Wert der Y-Komponente des Originalbilds 
gemittelt über den entsprechenden Block.


Der Kontrast eines Blocks (=Blockkontrast, BH) wird approximiert 
durch die doppelte durchschnittliche absolute Abweichung von der 
mittleren Helligkeit.


Die Regeln, nach denen Lambda und Quantizer von diesen Größen abhängen
sind im HVS-Profil formuliert.


Der Aufbau eines HVS-Profils wird am schnellsten durch ein Beispiel klar:


HVS PLUGIN PROFILE VERSION 3
0	0.0	0.0	0.0	0.0	0.0	0.0
1	1.0	0.5	0.3	0.2	0.5	0.7
2	1.0	0.5	0.3	0.2	0.5	0.7
3	1.0	0.5	0.4	0.4	0.4	0.4
...
70	3.1	1.2	0.1	0.2 0.6	0.3
...
90	1.0	1.0	2.0	2.0	4.0	4.0
...
120	1.0	0.0	2.0	3.0	1.1	2.0
...
255	2.0	1.0	1.0	1.0	3.5	-0.3


Es besteht aus einer Kopfzeile, in der das Format der nun folgenden 
Daten festgelegt wird, in diesem Fall ist es die Formatversion 3. 
Die darauf folgenden Zeilen bestehen aus einer Ganzzahl zwischen 1 und 
255 und danach durch Tabulatoren getrennt 6 Kommazahlen. Am Ende der 
Zeile befindet sich ein Zeilenumbruch.


Die erste Spalte einer Zeile ist eine Maßzahl (momentan entweder eine 
Helligkeit oder ein Kontrast), die anderen sechs sind Modifikatoren, 
die Lambdawert bzw. Quantizer eines Blocks beeinflussen.




Die Bedeutung der einzelnen Spalten ist folgende


 1.Spalte	| 2.Spalte	| 3.Spalte	| 4.Spalte	| 5.Spalte	|
____________|___________|___________|___________|___________|
 Maßzahl	| lmod(BH)	| lmod(FH)	| qmod(BH)	| qmod(FH)	| 
____________|___________|___________|___________|___________|




 6.Spalte	| 7.Spalte	|
____________|___________|
 lmod(BK)	| qmod(BK)	|
____________|___________|


Es gibt jeweils drei Modifikatoren, die den Lambdawert beeinflussen 
(lmod) und drei, die den Quantizer (qmod) beeinflussen. Von diesen 
dreien hängt einer von der durchschnittlichen Framehelligkeit ab, einer 
von der durchschnittlichen Blockhelligkeit und einer vom Blockkontrast.


Wenn ein Frame dem HVS-Plugin übergeben wird, so stellt es zuerst die 
Werte von die durchschnittliche Framehelligkeit, Blockhelligkeit und 
Blockkontrast für alle Blöcke fest, diese liegen immer zwischen 0 und 
255. Um den Lambdawert für einen bestimmten Block auszurechnen werden 
die 3 Lambda Modifikatoren miteinander multipliziert und 1 dazuaddiert.


Also für einen Block:


Lambda = 1 + lmod(FH) * lmod(BH) * lmod(BK)


Bei der adaptiven Quantisierung errechnet sich der Quantizer für einen 
Block folgendermaßen:


Quantizer = Basisquantizer * (1 + qmod(FH) * qmod(BH) * qmod(BK))


Die Modifikatoren werden durch das Profil festgelegt. Für einen Block 
mit BH 70, BK 90 in einem Frame mit einer FH von 120 sucht das Plugin 
im Profil die Zeile, deren Maßzahl (erster Wert) 120 beträgt, und nimmt 
in dieser Zeile den 3. Wert als lmod(FH), den 2.Wert in der Zeile mit 
der 70 vorne als lmod(BH) und den 7. Wert der Spalte mit der 120 vorne 
als qmod(BK). Die anderen analog.


Der lambdawert beträgt also in diesem Beispiel:
Lambda = 1 + 0.0*3.1*4.0 = 1


Der Quantizer berechnet sich zu 
Quantizer = Basisquantizer * (1 + 3.0*0.2*4.0) = 3.4*Basisquantizer


Die hier im Beispiel verwendeten Werte sind frei erfunden und absolut 
blödsinnig.


Hinweise zur Gestaltung eines Profils:


- Die FH-Modifikatoren eignen sich gut dazu, die HVS-Optimierungen für 
bestimmte Situationen zu deaktivieren. Soll z.B. in dunklen Frames 
nichts geändert werden, so setzt man einfach den FH Modifikator für 
kleine Werte (z.B. kleiner 60) auf 0. Dadurch wird das Produkt 0 und 
Lambda = 1, bzw. Quantizer = Basisquantizer.


- Bei AQ sollte man darauf achten, in welchem Bereich Quantizer 
auftreten. Bei einem Basisquantizer von 2 macht ein Faktor von +-2.0  
Sinn, bei einem Basisquantizer von 15 sollte eher ein geringerer 
Faktor gewählt werden. Die Quantizer werden noch normalisiert, sodass 
der Unterschied zwischen zwei aufeinanderfolgenden Blöcken höchstens 
+-2 ist.


-Die Psychophysik behauptet, dass die Intensität des kleinsten noch 
wahrnehmbaren Unterschieds proportional zur (Hintergrund) Intensität 
ist.(Gesetz von Weber)
D.h. die FH-Modifikatoren sollten mit größerer FH eher wachsen (AQ) 
bzw. sinken (Lambda).


-Die Psychophysik behauptet auch, dass Fehler in komplexeren Bereichen
(Textur) weniger stark wahrgenommen werden, die BK-Modifikatoren 
sollten mit größerer BK ebenfalls wachsen (AQ) bzw. sinken (Lambda).


-Und zu guter Letzt der wichtigste aller Hinweise:


	Probieren geht über studieren!


Viel Spass und Erfolg beim HVS modellieren.

Hat schon mal jemand versucht, ob das Ding bei ihm läuft? Ich habe einige Bugs gekillt, und es würde mich interessieren, ob encraw immer noch manchmal einfach stehenbleibt.

Ich werde mal versuchen, ein Profil zu erstellen, das das herkömmliche Lumimasking nachstellt, damit wir Anhaltspunkte haben, wie soetwas im Prinzip aussehen könnte.

Vielleicht sollte ich das tun.

Aber ich bin mir nicht so ganz sicher, ob das schon so richtig ausgereift ist. Die vielen vielen Zahlen sind glaubich sehr abschreckend. Vielleicht sollte ich das vorher noch ein bisschen umstrukturieren, und eine kleine GUI zur Erstellung und Verwaltung von Profilen basteln.

Mal sehen vielleicht morgen.

Hat eigentlich irgendjemand ausser mir schon damit rumgespielt?

Ok, ich hab jetzt mal ein OpenOffice Sheet gebastelt, mit dem man recht bequem Profile erstellen kann.

http://web3.gleitz.org/Kopernikus/hvs.sxc

Beispielprofile und englische ReadMe sind in Mache.

Merke gerade, dass man das entstandene cvs File noch mit einem Editor nachbearbeiten muss, und "," mit "." ersetzen muss.

Falls es jemanden interessiert:

http://xvid.ist-dein-freund.de

hier befindet sich ein Patch mit einem neuen Plugin, das nicht mehr diese komplizierten Profile verwendet.

Viel Spass beim Testen!

Welcher Text?

Edith:

Ab jetzt sind auch windows binaries verfügbar. Ich hoffe sie funktionieren auch richtig, sind von Linux cross-compiled. Zumindest unter Wine laufen sie.