Luminanz-Probleme

[Kika]

Lustige Diskussion. Es scheint auch keiner auf die Idee gekommen zu sein, PicVideo mal RGB24 ausgeben zu lassen - dann stimmt's nämlich in jedem Fall. Er verschiebt nichts, er komprimiert die Range nicht, alles bestens.
RGB32 macht genauso Unfug wie YUY2, in beiden Fällen verschiebt sich die Range in Richtung 0.
Das erklärt auch die Unterschiede bei den Skripten, die ich hier schon gepostet habe.
Zu ColorYUV hat Tsunami ja schon alles wichtige gesagt. Als Notbehelf in Sonderfällen verwendbar, sonst nicht.

Und TMPGEnc benimmt sich tatsächlich so, wie ich's gepostet habe:

CCIR: Es wird die Range von 0-255 erwartet und auf 16-235 komprimiert

YCbCr: Es wird die Range von 16-235 erwartet und nichts geändert

[Tsunami]

[Kika]

Ich verwette sogar meinen Hintern darauf, dass einige Ergebnisse von Encoder-Tests dadurch verfälscht wurden.

[Kika]

So, inzwischen haben mehrere andere User auf Doom9 das so bestätigt. Wilberts Ansichten wurden dabei dann auch gleich noch mit als Irrtum erkannt.
Und eines der Probleme, die ich hatte, ist ein Bug, entweder in PICVideo oder aber im jeweiligen System-Codec für die YUY2-Konvertierung. Das betrifft aber nur MJPEG, bei HuffYUV oder DV-Codecs tritt das nicht auf.

Also nochmal:

TMPGEnc hat zwei Modi: CCIR und YCbCr. Diese wirken sich darauf aus, wie das Eingangsmaterial behandelt wird.

CCIR: Es wird die Range von 0-255 erwartet und auf 16-235 komprimiert.

YCbCr: Es wird die Range von 16-235 erwartet und nichts geändert.

Wer also mit Video arbeitet, das mit einer Luma-Range von 16-235 vorliegt, muss in TMPGEnc die Option "Output YUV data as basic YCbCr not CCIR" aktivieren.

Ist die Luma-Range aber 0-255, dann muss diese Option ausgeschaltet werden.

Die Hilfe in TMPGEnc ist da etwas missverständlich. Aber wenn man sich an die Aussage von mb1 erinnert, dass man mit TMPGEnc durchaus Videos mit Super-White und Super-Black erzeugen kann, dann erhält das alles einen Sinn.

Die Auswirkungen sind auch klar:
Ist die Range 0-255, dann komprimiert TMPGEnc diese im Modus CCIR auf 16-235. So soll es auch sein.
Ist sie aber bereits 16-235, dann würde im CCIR-Modus nochmal komprimiert werden, nämlich auf 32-219, und das ist Mist. Lässt sich zwar besser komprimieren, aber dafür wirkt das ganze Bild flau und kontrastarm.

Im YCbCr-Modus ist es dann so:
Liegt der Source mit 16-235 vor, dann ist alles OK. Es wird nichts verändert, die Farben und der Kontrast bleiben erhalten.
Hat der Source aber die Range von 0-255, dann entstehen Super-White und -Black. Denn MPEG sollte nunmal die Range von 16-235 haben. Da aber im YCbCr-Modus die Luma-Range nicht gewandelt wird, werden helle Flächen überstrahlt und dunkle werden noch dunkler.

[bergH]

tach auch !

Und wie erkenne ich , ob ich
16-235
oder
0-255 habe ?

O.K. am Histogramm erkennt man das wohl , gibt es einfachere Methoden, oder Programme, die das richtig anzeigen?
_________________
Gruß BergH

[Kika]

Nein, ohne Histogramm-Funktion hat man kaum eine Chance, das wirklich exakt herauszufinden.

AviSynth selbst bietet dazu ja z.B. die Möglichkeit, das folgenden Kommando zu benutzen:

ColorYUV(Analyze=true)

Am besten ist aber der optische Vergleich: Nach dem Encoden muss das Video exakt die gleichen Farben haben wie vorher. Höchstens die Level der einzelnen Luma-Werte dürfen sich unterscheiden, nicht aber ihre Platzierung.

Ich empfehle dazu folgende Methode:
Vom AVI mittels VirtualDub einen Screenshot machen.
Vom MPEG mittels MME den gleichen Frame exportieren.
In einer Bildbarbeitung wie PhotoShop oder Photo Impact von beiden Bildern ein Histogram berechnen lassen, vergleichen. Ist die räumliche Aufteilung identisch und unterschieden sich höchstens die Level (also die Höhe der Spitzen), dann ist alles richtig, sonst nicht.

Tatsache ist, dass die verschiedenen Codecs mit der Luminanz-Range unterschiedlich umgehen, Tatsache ist auch, dass die Encoder damit unterschiedlich umgehen.
So kann es passieren, dass dasselbe DV-Video auf zwei verschiedenen PCs bei sonst gleichen Einstellungen mit demselben Encoder unterschiedlich aussieht. Ganz einfach deshalb, weil manche DV-Codecs 16-235 liefern, manche aber 0-255.
Auch der Farbraum selbst spielt eine Rolle, und auch der Systemcodec, der zur Anzeige/Decodierung dieses Farbraums benutzt wird. Bei YUY2 ist das standardmäßig z.B. msyuv.dll - und der hat eine Macke. Wird der benutzt, um den YUV-Farbraum zu RGB24 zu konvertieren (bei TMPGEnc ist das so, wenn man in einem AVISynth-Skript nicht am Ende Converttorgb24() stehen hat), wird 255 zu 253 und 0 zu 2.

In AVISynth selbst kommt noch das Problem dazu, dass alle Wandlungen zu YUV die Luma-Range zu 16-235 komprimieren, alle Wandlungen zu RGB24 oder RGB32 sie aber auf 0-255 strecken. Und jede dieser Wandlungen verursacht Rundungsfehler.
Der Overkill ist dann, wenn man mit YV12 arbeitet und zwischendurch wegen irgendeinem Filter zu YUY2 konvertiert - das Ergebnis ist die Range von 32-219, eine anschließende Konvertierung zu RGB24 würde ihn auf 16-235 strecken, aber die vorher vorlorenen Werte natürlich nur interpolieren. Das Ergebnis währen total kontrastarme Videos mit flauen Farben.
Im umgekehrten Verhältnis angewendet, ergeben die Farbraumkonvertierungen dann im Schwarz-Bereich zu dunkle und im Weiß-Bereich zu helle Videos mit viel zu satten Farben.

Zurück zu TMPGEnc: Nochmal zur Sicherheit.
Der Standard-Modus (CCIR) erwartet RGB24-Videos mit der Range von 0-255. Encodet man damit Videos mit der Range von 16-235, dann werden die einfach nur schlecht.
Der YCbCr-Modus erwartet RGB24 mit der Range von 16-235. Encodet man damit Videos mit der Range von 0-255, dann werden die ebenfalls ziemlich schlecht.
Nur die richtige Luma-Range zusammen mit der richtigen Encodiermethode liefert gute Ergebnisse. Das gilt auch für CCE und jeden anderen Encoder, bei dem man das überhaupt einstellen kann.

Ein kleine Spitze kann ich mir jetzt nicht verkneifen: Wetten, dass die von der c't das damals bei ihrem Encodertest nicht gewußt haben?  

[Tsunami]

Frage :
verändert der Befehl 'ConvertToRGB24()' den Luminanz-Bereich von 15-235 (YUV) auf 0-255 (RGB) oder bleibt 16-235 im RGB-Farbraum bestehen?

Ich frage deshalb, weil bei meinen Tests mit TMPGEnc ein Video mit Luminanz 0-255 entstanden ist, abwohl ich ein DVD-MPEG als Input benutzt habe (16-235), im Avisynth-Script den Befehl 'ConvertToRGB24()' benutzt habe und im TMPGEnc die Option '[x] Output YUV data as Basic YCbCr not CCIR601' angehakt war, also die Luminanz nicht verändert werden sollte.
Wie kann man es denn anstellen, das man eine Luminanz von 16-235 erhält, wenn im Avisynth-Script der Befehl 'ConvertToRGB24()' steht und man den Luminanz-Bereich im TMPGEnc nicht komprimieren möchte?
Geht das doch nur über 'ColorYUV(levels="PC->TV")'?
Was wäre der einfachste Weg, um ein YUV in ein RGB umzuwandeln, den Luminanz-Bereich aber eben NICHT anzupassen, also ein 16-235 YUV in ein 0-255 RGB zu wandeln, wo die Werte 0-15 einheitlich auf 16 gesetzt sind, die Werte 236-255 einheitlich auf 235, und die Werte dazwischen 1:1 vom YUV übernommen werden? Oder geht das theoretisch schon nicht?

Leider kann man das mit dem Befehl 'ColorYUV(Analyze=true) ' nicht anzeigen lassen, denn der gilt nur für den YUV-Farbraum.
Gibt es so einen Befehl eventuell auch für den RGB-Farbraum?

sh0dan sagt, das man ein YUV-Video mit dem Luminanz-Bereich 0-255 in ein RGB32-Video mit dem Luminanzbereich 0-255 umwandeln kann, wenn man den Befehl 'ConvertToRGB32(matrix = "rec709")' benutzt.
http://forum.doom9.org/showthread.php?s=&threadid=68840&highlight=YCbCr

Edit 1 :
hier : http://www.avisynth.org/index.php?page=Convert
ist beschrieben, das man 'ConvertToRGB32(matrix = "rec709")' für HDTV benutzen sollte...

Edit 2 :

[scharfis_brain]

@Kika: kannst Du Dich noch an mein pers. Voyager problem erinnern?
ich hab doch (immernoch) dieses Problem mit den Farbsaeumen, d.h. die Farbe ist nicht gleichmaeszig, sondern sieht aus wie 16bit Farbtiefe, was auf und abblenden zur Qual macht. (Wie sich herrausstellte traegt der DVD-Player seinen Teil dazu bei, es ist aber auch auf dem PC sichtbar)

wie bekomme ich nun ein MPEG-2-Video ueber AVISynth in den TMPGenc, ohne dass das luma-range angetastet (mom / ex - pandiert) wird ?!?
Farbraumconvertierungen sind mir vollkommen egal, ich MUSS aber in YUY2 arbeiten koennen...

weiterhin waere ja dann auch ein MPEG-2- Decoder-Filter vonnoeten, der den Luma-range (garnatierterweise) nicht anfasst....

ohje, das ist ja fast komplizierter als interlacing.....

[Kika]

Also, MPEG2Dec3 tastet die Lumarange nicht an. Wenn ich meine DVB-Streams neu encoden muss, muss ich keinerlei Levelanpassung vornehmen.
TMPGEnc arbeitet dann im CCIR-Modus. YCbCr benötige ich nur für meine eigenen MJPEG-Videos sowie für einige verratzte DivXe. Als Genauigkeit benutze ich 9 oder 10 Bit.
Ich setze ans Ende des Skriptes auch immer ein ConvertToRGB24(). Das benötige ich zwar nicht wirklich, es stellt aber sicher, dass alles so klappt, wie es soll. Vor allem aber stellt es sicher, dass sich nicht ein anderer Codec als Decoder dazwischen klemmt und eventuell die Qualität versaut.
Ansonsten arbeite ich mit der alten Version von DVD2AVI, der 1.76, den neueren Versionen und auch den neueren MPEG2Dec-Varianten traue ich absolut nicht über den Weg. Die sind imho alle zu sehr auf Tempo getrimmt.

Bei den Playern habe ich auch schon festgestellt, dass es einige üble Mistmodelle gibt. Der Mustek (genauer Typ ist mir jetzt nicht bekannt) eines Bekannten stellt Farbflächen gerne mal als eine Art "Regenbogen", also mit deutlich wahrnehmbaren Abstufungen dar. Und der Pioneer meines Bruders erzeugt bei Half- und 2/3-D1 an Kanten erkennbare Treppenstufen.

Ich habe die Befürchtung, dass bei Dir am Decoder-System insgesamt was nicht stimmt. Setze doch zum Vergleich mal den mme (m2v.vfp) als MPEG2-Decoder ein und encode ein Stück des Videos (D2V) darüber direkt in TMPGEnc, also ohne AVIsynth. Ist es dann auf dem Monitor nicht mehr sichtbar und am Player auch besser, liegt's an AVISynth bzw. den bei Dir installierten Filtern und Codecs.
Bei Diesem Weg aber darauf achten, DVD2AVI korrekt einzustellen (YUV2 und TV).

[scharfis_brain]

also muesste ich wie folgt vorgehen:

mpeg2source()
converttoyuy2(interlaced=true) # wegen der filterei
(....processing....)
converttorgb24()


und dann CCIR im TMPGenc?


aaaaaaaber:
YUV -> RGB expandiert doch den Luma range, ergo loecher im histogramm (YUV 16-235 wird zu RGB 0-255 )

CCIR -> komprimiert den Luma range, ergo auslassungen im Histogramm, welche sich nicht unbedingt mit den loechern der YUV -> RGB wandlung decken muessen.... (0-255 wird wieder zu 16-235)

oder verstehe ich da was komplett falsch?

desweiteren sollte doch eine wandlung von YV12 nach YUY2 den Luma range unangetastet lassen, oder irre ich mich?


och menno, ich will doch einfach nur das video ohne irgendwelche veraenderungen am Range encoden

[Kika]

Bei YV12 zu YUY2 und umgekehrt passiert nichts.

TMPGEnc macht es so:
Modus YCbCr macht gar nichts, sondern nimmt das Bild so, wie es ist.
Liegt es als 16-235 vor, bleibt's so, und liegt's als 0-255 vor, dann bleibt's auch so.

CCIR komprimiert 0-255 zu 16-235.

Und genau deshalb klappt das so ja auch:

MPEG2Dec = YV12 mit 16-235
ConvertToYUY2 ändert nichts, da bereits YUV vorhanden war, also 16-235 (meine disbezügliche Aussage weiter oben war leider falsch)
ConvertToRGB24 expandiert zu 0-255
TMPGEnc, Modus CCIR komprimiert zu 16-235 - et voilà.

Beim Expandieren/Komprimieren treten "nur" die normalen Rundungsfehler auf, keine Löcher. Kann man ja anhand des Histogramms eines Quell- und eines Zielbildes sehen.

[scharfis_brain]

so, hab nochmal den thread durhcgestoebert

also wuerde

mpeg2source()
converttoyuy2(interlaced=true) # wegen der filterei
(....processing....)
converttorgb24(matrix = "rec709") # laesst luma range auch bei rgb bei 16..235


und dann YCrCb im TMPGenc (was den luma range auch so laesst, wie er ist)


ohne jegliche aenderung am luma range von MPEG2 nach MPEG2 encoden...

[Tsunami]

[Kika]

Wie ich die Histogramme vergleiche, habe ich ja schon geschrieben - direkt mit exportierten Bildern.

Ansonsten sagte ich ja schon, dass einige meiner älteren Ausführungen noch nicht so ganz korrekt waren.

YCbCr: Es findet keinerlei Änderung der Range statt. Auch kein Cutting usw.
CCIR: Es wird komprimiert.

Dadurch, das komprimiert wird, geht ja nur die Reichweite verloren, Bilddetails als solche verschwinden dabei ja nicht. Encodest Du also ein Bild mit 0-255, bei dem eine Bildinformation im Bereich 0-15 oder 236-255 leigt zu 16-235, dann geht die Information als solche nicht verloren, sondern bekommt praktisch neue Farben!

Man kann das auch nicht mithilfe von irgendwelche DirectShow-Dingen überprüfen, das geht nur mithilfe von Source, der exakt definiert ist, sonst ist jedes Ergebnis ein reines Ratespiel.
Als bei Tests die Finger weg von irgendwelchen Frameservern oder Codecs, zu deren Dekodierung der Encoder einen anderen Codec benötigt. TMPGEnc liest ausschließlich RGB24 - und nur wenn er den Source direkt ohne Umweg bekommt, kann man das Ergebnis voraussagen.
Die Wandlungen, die AVISynth durchführt (TV->PC und umgekehrt), sind NICHT sauber, da können neuron und sh0dan sagen, was sie wollen - die Knicks in den Histogrammen erscheinen immer.
Ich meine aber damit nicht die Histogramme, die TMPGEnc selbst anzeigt - was der da anzeigt, ist mir ein echtes Rätsel. Mich interessiert nur, was hinten rauskommt.
Und wenn meine Videos von DVD genauso (farblich) aussehen wie die vom Tape, dann war's wohl richtig, anderenfalls nicht.

mme ist immer analog zu DVD2AVI eingestellt, also auf TV-Farbraum.
Historgramm-Anzeigen in AVISynth oder TMPGEnc benutze ich nicht.

[Tsunami]

[Tsunami]

Ich habe soeben mal einen Test mit ffmpeg gemacht, um mal zu sehen, ob
der mir den Luminanzbereich einer DVD anzeigen kann.

Vorgehensweise : :
1.
ffmpeg -i e:\dvd\fight_club\vts_01_1.vob t.yuv

2.
nach ein paar Sekunden mit STRG+C abgebrochen.

3.
Mit WinHEx die Datei t.yuv geöffnet

4. es werden am Anfang die Zahlen '10' angezeigt (hexadezimale Schreibweise für 16 dezimal), also ist die minimale Luminanz 16, denn am Anfang ist der Film schwarz.

Wenn man jetzt ein kelines Programm schreibt, das den ffmpeg ein paar Sekunden lang auf ein vob loslässt, und anschliessend die t.yuv Datei analysiert nach dem kleisten und größten Wert, dann hat man den Luminanzbereich.
Ich könnte so ein kleines Programm demnächst mal schreiben.

Benutzte Dateien :
http://www.dvdrhelp.com/download/ffmpeggui.zip
http://www.kvcd.org/libz.zip

[Kika]

[Tsunami]

[Kika]

[Tsunami]

Ich habe mal ein kleines Tool geschrieben, das den Luminanz-Bereich eines Videos
herauszufinden versucht.

-----

öffentlicher Server (bitte Arcor-Download-Limit nicht überschreiten) :
das reine Programm ohne Installer :
http://home.arcor.de/nebelkerze/Luminanz_Analyzer_0_0_1.rar
826.173 Bytes
CRC32 : 7AD341EB
md5 : 761b628002ef928df0ae5cdeb4f7462d

das Gleiche Tool mit einem simplen Null-Soft-Installer :
http://home.arcor.de/nebelkerze/Luminanz_Analyzer_0_0_1__Setup.exe
959.848 Bytes
CRC32 : CC775687
md5 : f8fcd254030a30014a09d8b903ea0d5b

-----

Anmerkungen :

1.
Auch bei hochprofessionellen Produktionen scheinen ein paar Ausreißer aus der
Standard-DVD-Luma-Range von 16-235 'normal' zu sein und fallen nicht weiter auf.

2.
Jetzt weiß ich auch endlich, wieso manche textilfreie DVDs und Sauger-VCDs
so seltsam aussehen.
Der Hobby-Producer hat die TV-Luma-Range ganz offensichtlich nicht beachtet
und schon sieht man nur noch 'strahlende' Gesichter.
Ich dachte schon, an meinem Fernseher,
meinem Monitor oder meinem Player wäre eine Schraube locker.
LOOOL, go home you freak

3.
Weiß jemand, wodurch die Ausreißer entstehen könnten?
Ich kann mir die paar hundert 'Fehler' außerhalb der Standard-Luma-Range nicht erklären.
Arbeiten die Encoder so unsauber (ja?),
oder ist es der ffmpeg-Decoder (glaub ich eher nicht)?

4.
Kann es sein, das gerade Pixar-Videos und THX-Trailer die TV-Luma-Range nicht einhalten?
Das wäre ja peinlich.

5.
Sorry, für das häßliche Interface.
Ursprünglich war das viel simpler und einfacher, aber nach und nach hat sich herausgestellt,
das zuviel Infos besser sind, als zuwenig.

6.
Die automatische Erkennung der Luminance-Range ist noch nicht 100 prozentig,
aber zumindest 95 prozentig.
Einige kurze und farbarme Intro-Schnipsel machen noch Probleme.

7.
Was soll geändert werden?
Was läuft falsch?


P.S. Danke an BergH und Kika für die Anregungen