Infoseite // mpeg ausgabe wird grau

Frage von joerg eichhorn:


Hallo,

ich habe ein unkomprimiertes avi (;weiser hintergrund, darauf ein
hellgraues rechteck, darauf schwarze schrift) vorliegen. wenn ich daraus
mit einem mpeg-encoder (;probiert mit ligos premiere plugin und tmpgenc)
ein mpeg-2 fuer eine dvd erstelle, werden alle weissen flaechen grau.

wie kann ich das fixen? muss ich vorher das farbformat im avi (;24bit
rgb) wandeln?

vielen dank, gruss joerg eichhorn




Antwort von Heiko Nocon:

joerg eichhorn schrieb:

> ich habe ein unkomprimiertes avi (;weiser hintergrund, darauf ein
> hellgraues rechteck, darauf schwarze schrift) vorliegen.

Was ist "weiß" und was ist "grau"? Das ist der springende Punkt.

> wie kann ich das fixen? muss ich vorher das farbformat im avi (;24bit
> rgb) wandeln?

Das würde rein garnix bringen, denn genau bei diesem Schritt (;den der
MPEG-Encoder implizit sowieso macht) dürfte die die Ursache des Problems
liegen. Dein RGB-Weiß ist einfach zu weiß für den YUV-Farbraum. Oder
anders ausgedrückt: Schon dein RGB-"grau" ist, wenn man es in den
YUV-Farbraum konvertiert, weiß oder zumindest nahezu weiß.

Ergo: du mußt schon im RGB-Farbraum dafür sorgen, daß "Grau" ein wenig
dunkler wird, damit nach der Konvertierung in den YUV-Farbraum noch ein
sichtbarer Unterschied zwischen "grauem Grau" und "weißem Grau" besteht.
Sowas geht z.B. mit dem VirtualDub-Filter "levels".





Antwort von joerg eichhorn:

Heiko Nocon schrieb:

> joerg eichhorn schrieb:
>> wie kann ich das fixen? muss ich vorher das farbformat im avi (;24bit
>> rgb) wandeln?
>
> Das würde rein garnix bringen, denn genau bei diesem Schritt (;den der
> MPEG-Encoder implizit sowieso macht) dürfte die die Ursache des Problems
> liegen. Dein RGB-Weiß ist einfach zu weiß für den YUV-Farbraum. Oder
> anders ausgedrückt: Schon dein RGB-"grau" ist, wenn man es in den
> YUV-Farbraum konvertiert, weiß oder zumindest nahezu weiß.

wenn er mir mein helles grau weiss machte, koennte ich damit leben, das
ich es runter regele - bzw. in virtual dub den gamma anpasse.

mein problem ist aber, dass wenn ich das m2v im player - hier vlc
anschaue, die weisse flaeche eher mit 30% schwarz ausgibt.

danke, gruss joerg eichhorn




Antwort von Heiko Nocon:

joerg eichhorn schrieb:

> mein problem ist aber, dass wenn ich das m2v im player - hier vlc
> anschaue, die weisse flaeche eher mit 30% schwarz ausgibt.

Genau das passiert bei (;nichtsaturierender) Konvertierung, wenn die
RGB-Farbe im YUV-Farbraum nicht mehr abzubilden ist. Ein ganz
klassischer wrap-around-Effekt.

Verringere den Kontrast und Helligkeit des Originals etwas und der
Effekt wird verschwinden, das kannst du mir schon glauben. Alternativ
könntest du auch einen saturierenden RGB->YUV-Konverter verwenden. Das
ist aber die schlechtere Lösung, denn dann kommt es eben dazu, daß
Hellgrau und Weiß nach der Konvertierung beide zu Weiß werden. Das
Ergebnis sieht dann wie ein deutlich überbelichtetes Foto aus.

Welchen Filter du zur Verringerung von Helligkeit und Kontrast
verwendest, ist ziemlich unwichtig. Wichtig ist nur, daß die Filterung
bereits im RGB-Farbraum erfolgt und nicht erst nach der
YUV-Konvertierung. Dann ist die Scheiße nämlich bereits passiert und
kein Filter der Welt kann daran mehr etwas ändern.




Antwort von Andre Beck:

Heiko Nocon writes:
> joerg eichhorn schrieb:
>
>> mein problem ist aber, dass wenn ich das m2v im player - hier vlc
>> anschaue, die weisse flaeche eher mit 30% schwarz ausgibt.

Hast Du andere Player probiert?

> Genau das passiert bei (;nichtsaturierender) Konvertierung, wenn die
> RGB-Farbe im YUV-Farbraum nicht mehr abzubilden ist. Ein ganz
> klassischer wrap-around-Effekt.

Wobei wir hier von reinen Graustufen reden, die abbildbar sein müssen.
Es ist ja nicht so, dass es in RGB ein Ultraweiß gäbe. Die Graustufen
mögen also bei Konvertierung etwas an Auflösung verlieren, weil sie
digital etwas zusammenrücken, aber ein grober Wrap ist eigentlich
unmöglich, es sei denn die RGB-YUV-Konvertierung ist von Laien gecodet.

> Verringere den Kontrast und Helligkeit des Originals etwas und der
> Effekt wird verschwinden, das kannst du mir schon glauben. Alternativ
> könntest du auch einen saturierenden RGB->YUV-Konverter verwenden. Das
> ist aber die schlechtere Lösung, denn dann kommt es eben dazu, daß
> Hellgrau und Weiß nach der Konvertierung beide zu Weiß werden. Das
> Ergebnis sieht dann wie ein deutlich überbelichtetes Foto aus.

Ein korrekter Konverter für MPEG nach CCIR.601 sollte aber weder
saturieren noch gar wrappen, sondern *skalieren*: RGB(;0,0,0) wird
zu YUV(;16,...), RGB(;255,255,255) wird zu YUV(;235,...) und alles andere
spielt sich dazwischen oder in den anderen Dimensionen ab.

> Welchen Filter du zur Verringerung von Helligkeit und Kontrast
> verwendest, ist ziemlich unwichtig. Wichtig ist nur, daß die Filterung
> bereits im RGB-Farbraum erfolgt und nicht erst nach der
> YUV-Konvertierung. Dann ist die Scheiße nämlich bereits passiert und
> kein Filter der Welt kann daran mehr etwas ändern.

Kann ich nicht nachvollziehen. Entweder man fixt den Konverter nach
YUV oder man lässt es ganz. Sich in RGB künstlich auf Limits umzu-
rechnen, die dort gar nicht existieren, scheint mir absurd. Erschwerend
kommt hier höchstens hinzu, wenn man den MPEG-Encoder nicht mit RGB,
sondern mit YUV füttert: Hier kann er nicht automatisch erschließen,
ob der Input noch auf den Farbraum nach CCIR.601 skaliert werden muss
oder ob das schon passiert ist - man muss es ihm also je nach den
Gegebenheiten mitteilen. Ist diese Mitteilung flasch, also der YUV-
Input ist unskaliert, der Encoder denkt aber, er wäre skaliert, dann
kommen wir in den Bereich wo Ultraschwarz und Ultraweiß entstehen.
Die sind aber auch nicht per se am Wrappen, höchstens in einem schlecht
implementierten Player. Ein gut implementierter Player wird sie entweder
echt ausgeben (;als Spannungspegel, die nach niedriger respektive höher
sind, als die Standardpegel für Schwarz und Weiß) oder, sofern er das
nicht kann, saturieren (;PC-Softwareplayer, die in ein Overlay rendert).

Meine Vermutung ist daher, dass der Urposter eine Kombination aus
fehlerhaft encodetem MPEG (;wo sein Weiß zu Ultraweiß wird) und
falsch implementiertem Player (;der weder clipped noch saturiert
sondern wrapped) in Aktion beobachtet.

--
The S anta C laus O peration
or "how to turn a complete illusion into a neverending money source"

-> Andre "ABPSoft" Beck ABP-RIPE Dresden, Germany, Spacetime <-




Antwort von Heiko Nocon:

Andre Beck schrieb:

> Wobei wir hier von reinen Graustufen reden, die abbildbar sein müssen.

Nicht notwendigerweise. Es hängt schlicht vom Skalierungsfaktor der
Konvertierung ab.

> Es ist ja nicht so, dass es in RGB ein Ultraweiß gäbe. Die Graustufen
> mögen also bei Konvertierung etwas an Auflösung verlieren, weil sie
> digital etwas zusammenrücken, aber ein grober Wrap ist eigentlich
> unmöglich, es sei denn die RGB-YUV-Konvertierung ist von Laien gecodet.

Nein. Nur der der strunzdumme Konverter wird immer runterskalieren und
damit in 95 oder gar 99% Prozent der Fälle Qualität sinnlos vernichten.
Fast kein "natürliches" Video nutzt den RGB-Farbraum so weit aus, daß
eine Skalierung für die YUV-Konvertierung nötig wäre. Liegt natürlich
auch daran, daß natürliches Video fast immer aus YUV-Quellen stammt,
zumindest was den SOHO-Bereich angeht.

> Ein korrekter Konverter für MPEG nach CCIR.601 sollte aber weder
> saturieren noch gar wrappen, sondern *skalieren*

Eben das ist mit der genannten Wahrscheinlichkeit sinnlose Vernichtung
von Information. Der korrekte Konverter sollte, wann immer möglich,
weder skalieren noch saturieren oder wrappen. Nur genau dieses Verhalten
ermöglicht nämlich nahezu verlustfreie Farbraumkonvertierungen. Nur
wenn's verlustfrei wegen Überschreitung des Wertebereichs nicht geht,
dann muß der Konverter zwangsläufig irgendwas machen. Wrapping kommt
dabei natürlich nur für einen einzigen Zweck in Frage: dem Benutzer
unübersehbar deutlich zu zeigen, daß er was anderes probieren muß.

> Kann ich nicht nachvollziehen.

Warum nicht? Wenn die YUV-Konvertierung wrapped (;und das tat sie
offensichtlich), dann hilft hinterher nix mehr. Was ist daran nicht
nachzuvollziehen?

> Entweder man fixt den Konverter nach
> YUV oder man lässt es ganz.

Ähem... Dir ist doch sicher klar, daß die Verringerung des Kontrastes
auf RGB-Seite exakt das ist, was ein skalierender YUV-Konverter
letztlich auch macht, oder? Bloß eben mit dem Unterschied, daß man durch
manuelle Optimierung von Helligkeit und Kontrast die Möglichkeit hat,
die Schnittmenge der Konvertierung zu maximieren und damit die
Konvertierungsverluste zu minimieren. Eine fest vorgegebene Skalierung
hingegen kann höchstens zufällig das optimale Ergebnis bringen. Das ist
doch wirklich primitivste Mathematik, die braucht man dir doch sicher
nicht zu erklären.

Der einzige Vorteil einer fixen Skalierung ist, daß damit unter keinen
Umständen illegale Farbwerte auftreten können. Damit ist eine solche
Lösung DAU-tauglich. Gut wird sie davon aber nicht.





Antwort von Andre Beck:

Heiko Nocon writes:
> Andre Beck schrieb:
>
>> Wobei wir hier von reinen Graustufen reden, die abbildbar sein müssen.
>
> Nicht notwendigerweise. Es hängt schlicht vom Skalierungsfaktor der
> Konvertierung ab.

Der festgelegt ist. Es ist klar, was am Ende Weiß und Schwarz für
Koordinaten im Farbraum aufweisen müssen, also kann man den Faktor
nicht einfach willkürlich ändern. Das entspräche einer willkürlichen
Änderung von Schwarz- und Weißwert des Videos, eine Manipulation, die
man höchstens selbst vornimmt, wenn man sie *inhaltlich* wünscht, die
man aber IMO keinem schlichten Formatkonverter überlässt.

>> Es ist ja nicht so, dass es in RGB ein Ultraweiß gäbe. Die Graustufen
>> mögen also bei Konvertierung etwas an Auflösung verlieren, weil sie
>> digital etwas zusammenrücken, aber ein grober Wrap ist eigentlich
>> unmöglich, es sei denn die RGB-YUV-Konvertierung ist von Laien gecodet.
>
> Nein. Nur der der strunzdumme Konverter wird immer runterskalieren und
> damit in 95 oder gar 99% Prozent der Fälle Qualität sinnlos
> vernichten. Fast kein "natürliches" Video nutzt den RGB-Farbraum so
> weit aus, daß eine Skalierung für die YUV-Konvertierung nötig
> wäre. Liegt natürlich auch daran, daß natürliches Video fast immer aus
> YUV-Quellen stammt, zumindest was den SOHO-Bereich angeht.

Du willst damit sagen, bei der YUV2RGB-Konvertierung von Material mit
bekannter Herkunft aus einem CCIR.601-Raum würde bereits RGB erzeugt,
das den Farbraum nicht ausnutzt? Sorry, das glaube ich nicht, das wäre
dämlich (;was natürlich keineswegs ausschließt, dass Software existiert,
die das falsch macht, im Gegenteil). Ich erwarte, dass RGB-Weiß bei
(;255,255,255) liegt. Es ist hier nichts anderes definiert. Bei YUV
besteht leider die Situation, dass man einem YUV nicht ansieht, ab es
den gesamten Wertebereich ausnutzt, also Weiß bei Y%5 liegt, oder ob
es bereits Y#5 als Weiß ansieht. Das ist aber auch die einzige
Unsicherheit, die man mit einem Schalter am MPEG-Encoder ausmerzen kann.

Man kann sich darüber unterhalten, einen solchen Schalter auch wirken
zu lassen, wenn der Input RGB ist und man genau weiß, dass man RGB-
Material verfüttert, welches von CCIR-limitiertem YUV ohne Skalierung
auf den vollen Farbwürfel gewandelt wurde. Um den Fehlern anderer
Software nachzurennen, aber das ist ja scheinbar nötig.

>> Ein korrekter Konverter für MPEG nach CCIR.601 sollte aber weder
>> saturieren noch gar wrappen, sondern *skalieren*
>
> Eben das ist mit der genannten Wahrscheinlichkeit sinnlose Vernichtung
> von Information. Der korrekte Konverter sollte, wann immer möglich,
> weder skalieren noch saturieren oder wrappen.

Mit anderen Worten, er soll eine willkürliche Änderung der Bildhelligkeit
vornehmen? Nein, danke.

> Nur genau dieses Verhalten ermöglicht nämlich nahezu verlustfreie
> Farbraumkonvertierungen.

Eine Konvertierung von RGB nach CCIR.601-YUV kann nicht verlustfrei
sein. Dieses Ziel mit Manipulation des Materials in Richtung einer
unnatürlich hohen Helligkeits- und Farbdynamik doch noch erreichen
zu wollen erscheint mir voreilig. Wenn überhaupt, dann hat der
Konverter mit einem Schwarz- und Weißpunktabgleich daherzukommen,
damit ich das Ausmaß der Skalierung selbst bestimmen kann. Nahezu
verlustfreie Farbraumkonvertierungen bekommt man nur mit full range
YUV, und damit das klappt implementiert man die Arithmetik tunlichst
in wenigstens 16Bit und mit Saturierung vor der Rückkonvertierung
in die üblichen 8Bit der Samples.

> Nur wenn's verlustfrei wegen Überschreitung
> des Wertebereichs nicht geht, dann muß der Konverter zwangsläufig
> irgendwas machen. Wrapping kommt dabei natürlich nur für einen
> einzigen Zweck in Frage: dem Benutzer unübersehbar deutlich zu zeigen,
> daß er was anderes probieren muß.

Hmpf. Man kann sich Programmfehler auch schönreden. Eine ganze Plattform
lebt davon. Gut, es wäre nett, an einem solchen Konverter einen Schalter
für den Testbetrieb zu haben, der einem Wertebereichsüberschreitungen
mit einer Falschfarbe unübersehbar kenntlich macht. Aber sowas ist ein
explizit anzuschaltendes Feature. Wir reden hier doch eher von einer
PC-Software-typischen Kette von Fehlern, die hinterher als Feature
umzudeuten irgendwie abenteuerlich klingt.

>> Kann ich nicht nachvollziehen.
>
> Warum nicht? Wenn die YUV-Konvertierung wrapped (;und das tat sie
> offensichtlich), dann hilft hinterher nix mehr. Was ist daran nicht
> nachzuvollziehen?

Warum sie bei korrekter Implementation und Parametrisierung wrappen
sollte. Vor allem beim Encoder. Ich bin ja immer noch der Meinung,
dass tatsächlich der *Player* ein Ultraweiß gewrapped hat, aber das
muss uns der Urposter verraten.

>> Entweder man fixt den Konverter nach
>> YUV oder man lässt es ganz.
>
> Ähem... Dir ist doch sicher klar, daß die Verringerung des Kontrastes
> auf RGB-Seite exakt das ist, was ein skalierender YUV-Konverter
> letztlich auch macht, oder?

Nein. Der verringert nämlich den Kontrast erst nach der Konvertierung
(;die er selbstverständlich mit ausreichend großen Registern vornimmt,
damit da auch garantiert nix wrapped), und zwar genau auf die von
CCIR.601 vorgesehenen Werte (;oder besser gesagt um den entsprechenden
Faktor, der erwarten lässt, dass die Resultate im CCIR-Fenster landen).

> Bloß eben mit dem Unterschied, daß man
> durch manuelle Optimierung von Helligkeit und Kontrast die Möglichkeit
> hat, die Schnittmenge der Konvertierung zu maximieren und damit die
> Konvertierungsverluste zu minimieren.

Theoretisch ja, aber das ist doch ein Rumgemuckel um Fehler in der
Implementation der Verarbeitungskette. RGB-Weiß hat MPEG-Weiß zu
werden und RGB-Schwarz zu MPEG-Schwarz, fertig. Wenn man in der
Kette überhaupt RGB nutzt, versteht sich. Besteht die Kette aus-
schließlich aus YUV, dann muss sie end2end gewahr sein, ob das
full range YUV oder CCIR.601-YUV ist und das konsequent durchhalten.
Ich *vermute* mal, dass es ursprünglich so gedacht war, dass die
Kette end2end CCIR.601 bleibt und so Headroom für leichte Rechen-
fehler hat, die drinbleiben können oder aber am Ende saturiert werden,
und ich *vermute* außerdem, dass sich in der Praxis, insbesondere auf
dem PC-Video-Softwaremarkt unterhalb der Profilösungen, kaum eine
Software konsequent daran hält. Erst so entstehen die Unsicherheiten
an den Übergängen, die uns hier zur Diskussion verleiten.

> Eine fest vorgegebene Skalierung
> hingegen kann höchstens zufällig das optimale Ergebnis bringen. Das
> ist doch wirklich primitivste Mathematik, die braucht man dir doch
> sicher nicht zu erklären.

Die fest vorgegebene Skalierung bringt genau dann das optimale Ergebnis,
wenn der Input optimal war, also - sofern er aus RGB kommt - einen
sauberen Abgleich von Schwarz- und Weißpunkt bereits hinter sich hat.
Dass flaues Material dabei nicht besser wird, ist IMO kein Beinbruch,
dann man muss es ja nicht flau da reinstecken, wenn man es nicht auch
flau haben will. Sicher geht dabei etwas an Information verloren, was
man merkt, wenn man das flaue Zeug hinterher am Display mit Kontrast
und Helligkeit fixen will. Aber das ist kein Grund, das flaue Zeug
ungefragt künstlich aufzublasen, denn dann sieht das Resultat anders
aus, als es der Input tut. Und es geht bei ->CCIR.601 *immer* Infor-
mation verloren, ungefähr ein drittel Bit pro Kanal und Sample, wobei
ich das nur schätze und nicht den Shannon ausgrabe. Einer der vielen
Gründe, weswegen man MPEG nur als Endformat haben will. Die Impli-
kationen für DV et al sind allerdings interessant, danke für den Eye
Opener. Wobei DV-Verarbeitung ein schönes Beispiel für end2end CCIR sein
sollte: Rein als CCIR, komplette Verarbeitung im CCIR-beschnittenen
YUV-Raum und am Ende in den MPEG-Encoder mit Marker "already CCIR".

> Der einzige Vorteil einer fixen Skalierung ist, daß damit unter keinen
> Umständen illegale Farbwerte auftreten können. Damit ist eine solche
> Lösung DAU-tauglich. Gut wird sie davon aber nicht.

Ich hätte gern die Gewissheit, dass RGB-Weiß hinten auch als CCIR-Weiß
rauskommt. Immer. Auch wenn ich gezielt darauf verzichte, in meinem
Video, selbst in den Lichtern, etwas weißes zu haben - dann will ich
nicht plötzlich etwas weißes im MPEG sehen, es hat dann genau so grau
zu sein, wie ich das da reinstecke. Ich propagiere doch auch nicht die
Vorteile von Automatikaussteuerung und Dynamikkompressor...

--
The S anta C laus O peration
or "how to turn a complete illusion into a neverending money source"

-> Andre "ABPSoft" Beck ABP-RIPE Dresden, Germany, Spacetime <-