Luminanz-Bereich

    Beim Experimentieren mit AVISynth und verschiedenen Programmen ist mir aufgefallen, dass ich nur dann in TMPGEnc ein korrektes Ergebnis erhalte, wenn das AVISynth-Skript den Befehl ColorYUV(levels="PC->TV") enthält.
    Ohne den Befehl wird das Video zu dunkel. Die Histogramm-Funktion von TMPGEnc zeigt auch an, dass beim Original (ausprobiert habe ich MJPEG PICVideo und D2V) die Luma-Range 16-235 genutzt wird, beim Skript aber 0-255.

    Mit VirtualDub als Frameserver passiert das aber nicht. CCE hingegen interpretiert die Luma-Range wieder ganz anders - der macht's generell zu dunkel.

    Das Verhalten ist zu 100% reproduzierbar.
    Ohne ColorYUV(levels="PC->TV") habe ich grundsätzlich zu kontrastreiche Videos.
    Also scheinen die einzelnen Programme das wirklich unterschiedlich zu interpretieren.
    Mich interessiert nun, ob das generell so ist oder ob das in Abhängigkeit der installierten Komponenten geschehen kann.

    Der Limiter kann hier auch nicht helfen, er würde ja noch mehr stauchen bzw. abschneiden, als es ohnehin schon der Fall ist.
    Wie gesagt, mit ColorYUV(levels="PC->TV") funktionierts ja einwandfrei.
    Übrigens, gehe ich per PlugInPack aus Premiere heraus über AVIsynth in TMPGEnc, dann darf ColorYUV(levels="PC->TV") NICHT enthalten sein.
    Immer diese blöden Fallstricke... ;)

    Also diese Luminanz-Geschichte beschäftigt mich jetzt schon geraume Zeit aber ich habe immer noch nicht ganz den Durchblick!

    Ich würde wirklich gerne wissen, wie man die Einstellungen korrekt tätigt, so daß nichts abgeschnitten, verdunkelt oder sonstwie verändert wird.

    [FRAGE] Wenn AVISynth willkürlich die Levels ändert müßte die Problematik doch nicht nur beim TMPGEnc bestehen, oder? Alle anderen Encoder hätten dann ja auch einen falschen Input.


    Also: Ich benutze die BIG3 für meine DVD-Backups.

    Im Laufe dieser Prozedur komme ich insgesamt an 3 Stellen an einer Luminanz-Level-Einstellmöglichkeit vorbei:

    Zunächst in DVD2AVI, dann in AVISynth, zuletzt im CCE.

    Ich habe bei DVD2AVI den Level auf "TV Scale", im AVISynth-Script mache ich nichts daran, im CCE stelle ich wieder 16 to 236 ein.


    Beim CCE scheint das Level-Setting wohl ziemlich egal zu sein, wie ich im engl. Doom9-Forum las (Dank nochmals an arlsair für den Link). Der Schreiber dort hat wohl über AVISynth sein Bildmaterial sowohl im YUY2 als auch im RGB32-Format an den CCE übergeben und der hat bei gleichen Einstellungen bitgenau dasselbe Outputvideo produziert.
    Nach dem UpperFieldFirst-Button noch so ein dämlicher Button, der nichts bringt ...
    Naja, zur Sicherheit habe ich das trotzdem mal bei "16 to 236" belassen.


    Wenn jetzt nun AVISynth die Levels auf 0-255 aufpumpt wäre das natürlich nicht so schön.

    [FRAGE] Aber was genau wäre dann eigentlich?

    Variante 1:
    Gesetz den Fall dem CCE ist es wirklich egal, was er als Input bekommt, dann würde ich also ein Video mit den Levels 0-255 erhalten, hätte also andere Levels bezogen auf die OriginalDVD.

    [FRAGE] Wie wirkt sich das nun auf das Bild aus? Schneidet der Fernseher oder der DVD-Player zu große Levels einfach ab (wie der Leveler das wohl tun soll) und macht das Bild also dunkler oder wird nichts abgeschnitten und das Bild also insgesamt heller?

    Ich habe mal gelesen, daß ein Video mit PC-Levels 0-255 am Fernseher Probleme machen kann. Welcher Art genau die sein sollen, stand leider nirgends.

    Hier im Forum hatte jmd. mal über Helligkeitsschwankungen bei seinem CCE-gecodeten Video berichtet. Jmd. anderes mutmaßte, daß es eben an den falschen Levels liegen würde.

    [FRAGE] Passiert das also - Helligkeitsschwankungen? Hat da jmd. Erfahrung? Wie sehen die aus? Schwankt es schnell oder langsam?


    Variante 2: Die Einstellung im CCE ist doch nicht egal, der Input auf Level 0-255 wird vom CCE beschnitten. Würde in dem Falle wohl eine Bildveränderung mit sich bringen -> sehr unschön.


    Problemlösungen?

    oder: [FRAGE] wie nun bekomme ich im CCE ein originalgetreues Bild?


    Es wäre wirklich nice, wenn sich jmd. meiner vielen Fragen annähme.

    Inzwischen bin ich da etwas weiter gekommen, nicht zuletzt auch dank Tsunami, der mir ein wenig auf die Sprünge geholfen hat.

    Zunächst: AVISynth 2.5x ist auf YV12 ausgelegt, bei jeder anderen Art der Farbcodierung muss man die in der Source-Zeile explizit angeben. Tut man das nicht, kann das Bild zu hell oder zu dunkel werden. Macht man es richtig, dann kann man sich den ColorYUV-Befehl sparen, denn der führt eine Konvertierung durch, die das Bild leicht verändert.

    Außerdem hängt es je nach Source-Material auch noch teilweise davon ab, was an Codecs und/oder DirectShow-Filtern auf dem jeweiligen System installiert ist. Irgendeiner der Codecs/Filter muss ja schließlich die Anzeige von YUV und RGB übernehmen. Die Codecs interpretieren den Farbraum aber zum Teil unterschiedlich. Ein Problem, das sich auch bei DV-Videos stellt.

    CCE macht standardgemäß 16-236 und das sollte man so lassen.
    Mit dem Farbbereich noch was grundsätzliches: Es ist ein gewaltiger Unterschied, ob man den Farbraum begrenzt (Limiter) oder komprimiert. Beim Begrenzen kommt es zu Verlusten, manche Helligkeitswerte entfallen ganz einfach (Clipping), was TVs auch tun und was in unglücklichen Fällen zu so einer Art Solarisatioseffekt in sehr Hellen und sehr dunklen Flächen führt.
    Beim Komprimieren und auch beim Expandieren sieht das etwas anders aus.
    Hat der Source den Range von 0-255 und wird auf 16-235 komprimiert, dann wird das Bild aufgehellt. Hat er 15-235 und wird auf 0-255 expandiert, wird das Bild dunkler.
    Hat der Source aber 16-235 und wird nochmal komprimiert - wodurch ja die Range von 32-220 entsteht - dann wird das Ergebnis einfach nur 'ne Katastrophe.
    Hat der Source 0-255 und wird auch so komprimiert und dann auf DVD gebrannt, entsteht beim Abspielen ein Clipping. Die dunkelsten und hellsten Stellen verschwinden ganz einfach.

    Ganz korrekt war das mit der Erklärung vom Komprimieren und Expandieren nicht: Das "heller" oder "dunkler" bezieht sich sicher nur auf die im Original dunklen Bereiche - die hellen werden anders herum beeinflusst. Vielleicht ist die Bezeichnung "stärkerer / schwächerer Kontrast" besser geeignet.

    MPEG-Video, das auf Fernsehern gezeigt werden soll, hat absichtlich einen geringeren Kontrastumfang, weil die Fernsehelektronik unterscheidet zwischen "schwarz außerhalb des Bildes" (0%) und "schwarz innerhalb des Bildes" (~5%). Was also einen Helligkeitswert von 16 hat, wird am Fernseher noch tiefschwarz dargestellt, auch wenn man es auf dem PC-Monitor schon grau sehen würde. Und ähnlich ist es bei hellen Bereichen: Für den Einsruck "weiß" reichen schon 80% Helligkeit im Originalsignal. Das wird von vielen DVD.Authoring-Studios auch nicht beachtet - deshalb überstrahlen DVD-Untertitel oft das Video erheblich, wenn sie 100% weiß und deckend sind.

    Ausprobieren kann man den Effekt der Komprimierung / Expandierung mit einem mehrfachen Levels-Filter (in AviSynth oder VirtualDub). Und für eine "korrekte" Simulation des Ergebnisses am Fernseher sollte man nicht vergessen, dass der auch noch einen höheren Gamma-Wert hat als ein PC-Monitor (um etwa 1.3 bis 1.5 könnte sinnvoll sein).

    Kika

    Danke für Deine weiteren Erläuterungen und dank auch

    LigH für Deine Ergänzungen.


    Allerdings ist die Sache jetzt nur noch komplizierter/verwirrender geworden. :huh:

    Ist das Ergebnis von kikas Experiment jetzt also, daß AVISynth je nach installierter Codecs auf dem System den Farbraum mal so, mal so interpretiert?

    Ich dachte, AVISynth benötigt keinerlei externe Codecs, um zu funktionieren.
    Es nimmt die Farbraumberechnungen ja wohl selbst vor, oder überläßt es das dem verwendeten Codec?

    Ich habe mir mal den ColorYUV-Befehl genauer angesehen und bin mit den ganzen Möglichkeiten der Helligkeits-Veränderungen überfordert.

    Hat vielleicht jmd. von euch den Durchblick?

    Bei ColorYUV kann ich ja GAIN, OFFSET oder GAMMA angeben.

    GAIN scheint je nach parameter einfach alles aufzuhellen.

    OFFSET macht doch aber genau das gleiche? Wenn ich z.B. einen Offset von 2 angebe, wird doch alles einfach um 2 angehoben. Wo soll also der Unterschied zu GAIN sein?

    Wenn ich einen GAMMA-Wert angebe wird das Bild auch heller, wobei meines Wissens Gamma das Bild nicht gleichmäßig aufhellt, sondern über das gesamte Helligkeistspektrum gesehen in einer "Kurve", will heißen, daß die Mitteltöne stärker hervorgehoben werden als die Hellen oder dunklen Töne.

    Stimmt das? Hat das vielleicht jemand genauer?

    Um die Verwirrung komplett zu machen gibt es zusätzlich über "Levels" oder "Tweak" auch noch 2 Möglichkeiten auf die Helligkeit Einfluß zu nehmen.

    Bei Levels kann ich Brightness/Contrast/Gamma einstellen, bei Tweak Brightness/Contrast und zusätzlich Hue/Sat (was sich aber auf Chroma bezieht, oder?).

    Und wie um alles in der Welt unterscheidet sich jetzt BRIGHTNESS von GAIN, OFFSET und GAMMA? :huh:

    Oder anders gefragt - wie mache ich mein Bild denn jetzt auf die "richtige" Weise heller?

    Wieder alles im Hinblick auf eine leichte Erhöhung der Helligkeit, um der Verdunkelung durch das Encodieren mit dem CCE und der Verscheibungen im Farbraum entgegenzuwirken.

    AVISynth geht, wenn man ihm es nicht explizit angibt, von YV12 aus. Hat man anderen Source, dann MUSS das in der Source-Zeile auch angegeben werden.
    Um Videos zu öffnen, bedient sich AVISynth der installierten Codecs - und die interpretieren die Farbräume zum Teil unterschiedlich. So kann es vorkommen, dass dasselbe AVI auf PC A mit korrekter, auf PC B aber mit falscher Luma-Range decodiert wird.

    Das Kommando ColorYUV besitzt Presets (z.B. PC->TV), die man in einem solchen Fall benutzen sollte. Aber die Verwendung irgendeines Luminanz-Reglers, egal ob ColorYUV oder Limiter oder was auch immer, sollte man tunlichst vermeiden, ebenfalls mehrmalige Farbraumkonvertierungen. Sie führen IMMER zu gewissen Veränderungen am Bild, je nach Kommando mal mehr, mal weniger und sind deshalb eigentlich nur ein Notbehelf.

    Die Zusammenhänge sind schwierig zu erklären. Meine Empfehlung währe es, mit den Einstellungen etwas zu experimentieren und sich dann von Original und Ergebnis jeweils mal ein Histogramm anzeigen zu lassen. Damit begreift man's imho schneller und besser als von irgendwelchen Guides.

    So, hier nochmal was zu diesem Thema.

    Ausgangsmaterial waren Captures mit BT-TV-Karte und PicVideo. Diese Kombination liefert die Range von 16-235, der Codec kann wahlweise YUY2 und RGB24 ausgeben. Und hier steckt schon die erste Falle: NUR RGB ist bei TMPGEnc richtig. Lädt man das MJPEG-Video direkt in TMPGEnc ist erstmal alles richtig, man muss dann aber bei Setting->Advanced->Quantize Matrix unbedingt Output YUV Data as Basic YCbCr not CCIR601 aktivieren.
    Will man den Source durch AVISynth jagen, muss man aufpassen. Schaut Euch mal die folgenden beiden Skripte an:

    LoadPlugin("E:\AviSynth2.5\AVS25Plugins\convolution3d.dll")
    avisource("CAPTURE.00.avi",true,"RGB24")
    assumeTFF()
    ConvertToYUY2(interlaced=true)
    separatefields()
    Convolution3D (0, 8, 8, 8, 8, 3, 0)
    weave()

    LoadPlugin("E:\AviSynth2.5\AVS25Plugins\convolution3d.dll")
    avisource("CAPTURE.00.avi",true,"YUY2")
    assumeTFF()
    separatefields()
    Convolution3D (0, 8, 8, 8, 8, 3, 0)
    weave()

    Beide machen dasselbe, beide liefern YUY2 an TMPGEnc, aber nur das erste liefert die korrekte Range, daran würde auch ein abschließendes ConvertToRGB24() nichts ändern.

    Nun könnte man auf die Idee kommen, das YUY2-Skript (das zweite) zu benutzen und TMPGEnc dann CCIR601 ausgeben lassen - eine Variante, die beim Encoden erheblich schneller ist. Aber..., schaut man sich das Histogramm dieser Variante an, sieht man, dass die Farben verfälscht wurden!

    In dieser Luminanz-Range-Geschichte stecken also einige üble Fallstricke drin.

    Gruß,
    Kika

    Zitat von Kika

    So, hier nochmal was zu diesem Thema.

    Ausgangsmaterial waren Captures mit BT-TV-Karte und PicVideo. Diese Kombination liefert die Range von 16-235, der Codec kann wahlweise YUY2 und RGB24 ausgeben. Und hier steckt schon die erste Falle: NUR RGB ist bei TMPGEnc richtig. Lädt man das MJPEG-Video direkt in TMPGEnc ist erstmal alles richtig, man muss dann aber bei Setting->Advanced->Quantize Matrix unbedingt Output YUV Data as Basic YCbCr not CCIR601 aktivieren.


    Ich denke das dieses activierung immer falsch ist. Wann sie das aktivieren, die skalierung (scaling) (16,235)->(0,255) wird durchgefuhrt:

    http://www.kvcd.net/forum/viewtopi…er=asc&start=48

    Was passiert wann du das nicht aktiviere?

    Ich verstehe das nicht. Die erste script und sonst script sollte die gleiche resultat produzieren (sons activierung in TMPGEnc).

    Don't know the translation: Do you know how the video is stored with the pic-codec? Is it RGB or YUY2? The problem can be, that the color conversions are borked with this codec.

    Zitat

    Ich denke das dieses activierung immer falsch ist. Wann sie das aktivieren, die skalierung (scaling) (16,235)->(0,255) wird durchgefuhrt:

    Eben nicht! Das ist ja der springende Punkt. Ist diese Option aktiviert, wird das Video direkt ohne(!) Skalierung übernommen. Die Übersetzung in der Hilfe von TMPGEnc ist an dieser Stelle ungenau. Dass dem so ist, kann man mit Hilfe eines Histogramms leicht selbst herausfinden.
    Diese Option ist ja speziell für Source-Videos gedacht, die bereits im Format 16-235 vorliegen.

    Zitat

    Do you know how the video is stored with the pic-codec? Is it RGB or YUY2?

    PicVideo is able to store both formats: YUY2 and RGB24. (PicVideo kann beide Formate aufnehmen und wiedergeben)

    In AVISynth und auch TMPGEnc sind die Ergebnisse zwischen YUY2 und RGB aber unterschiedlich, daher auch die Differenz in beiden Skripts. An irgendeiner Stelle wird bei der Farbraumkonvertierung nicht richtig gearbeitet.
    Öffnet man das MJPEG mit TMPGEnc, wird RGB angefordert. Öffnet man es in AVISynth als RGB24, ist das Ergebnis mit dem direkt geöffneten Video identisch, öffnet man es in AVISynth als YUY2, dann ist das Ergebnis falsch.
    Ich kann mir das nur so erklären, dass AVIsynth bei YUV-Material von einer anderen Luminanz-Range ausgeht als bei RGB.

    Zitat

    Eben nicht! Das ist ja der springende Punkt. Ist diese Option aktiviert, wird das Video direkt ohne(!) Skalierung übernommen. Die Übersetzung in der Hilfe von TMPGEnc ist an dieser Stelle ungenau. Dass dem so ist, kann man mit Hilfe eines Histogramms leicht selbst herausfinden.

    Das ist falsch. Ich habe das getest. Sie konnen die teste finden in die link (letzte zwei/drei posts von meinen).

    If die option is _nicht_ activiert dan wird das video ohne skalierung unbernommen (doch die video ist clipped zur [16,235], und nicht [8,235] wie in die in der hilfe steht).

    Zitat

    PicVideo is able to store both formats: YUY2 and RGB24. (PicVideo kann beide Formate aufnehmen und wiedergeben)

    Welche format hast du gebraucht?

    Zitat

    öffnet man es in AVISynth als YUY2, dann ist das Ergebnis falsch.

    Wenn die formate of die avi ist YUY2, dann konnte ich das nicht erklaren.

    Zitat

    dass AVIsynth bei YUV-Material von einer anderen Luminanz-Range ausgeht als bei RGB.

    ? Wenn du eine RGB -> YUV durch fuhre (in AviSynth), du beschaffe [16,235]. Wenn dus eine YUV -> RGB durch fuhre (in AviSynth), und die YUV-clip war ursprunglich [0,255]. Dann sind die Farben verfälscht.

    Wilbert

    Die Anleitung bzw. Hilfe zu TMPGenc hat da, wie ich schon schrieb, ein paar Fehler. Gemeint ist tatsächlich 16-235 und nicht 8-235 - letzteres wäre ohnehin verkehrt.

    OK, also nochmal:
    Liegt das Video mit dem Luma-Bereich 16-235 vor, dann muss man YCbCr aktivieren, nicht CCIR. Dafür ist diese Option gedacht.
    Liegt das Video mit der Luma-Range von 0-255 vor, dann CCIR benutzen, damit der Luma-Bereich normgerecht geclippt wird.

    Zu PicVideo: Ich nehme von der TV-Karte im YUV(YUY2)-Modus auf, decodiert werden die Daten aber als RGB24.
    Ich habe von allen Varianten Einzelbilder erzeugt und jeweils die Histogramme verglichen. Z.B. folgende Skripte in VirtualDub geöffnet:

    avisource("CAPTURE.00.avi",true,"YUY2")
    Ergibt zu geringen Kontrast.

    avisource("CAPTURE.00.avi",true,"RGB24")
    Hier ist das Ergebnis exakt dasselbe als beim direkt geöffneten MJPEG.

    Dann dieselben Skripte in TMPGEnc geöffnet und mal mit CCIR und YCbCr encodet:

    avisource("CAPTURE.00.avi",true,"YUY2") -> CCIR
    Stark aufgehelltes, kontrastarmes Bild

    avisource("CAPTURE.00.avi",true,"YUY2") -> YCbCr
    Auf den ersten Blick OK, in Wirklichkeit aber geclippt.

    avisource("CAPTURE.00.avi",true,"RGB24") -> CCIR
    Aufgehelltes, kontrastarmes Bild.

    avisource("CAPTURE.00.avi",true,"RGB24") -> YCbCr
    Korrektes Ergebnis. Das Histogramm des resultierenden Videos hat exakt die gleichen Werte wie das des ursprünglichen MJPEG-Videos.

    Sorry for answering in english.

    Zitat

    OK, also nochmal:
    Liegt das Video mit dem Luma-Bereich 16-235 vor, dann muss man YCbCr aktivieren, nicht CCIR. Dafür ist diese Option gedacht.
    Liegt das Video mit der Luma-Range von 0-255 vor, dann CCIR benutzen, damit der Luma-Bereich normgerecht geclippt wird.

    I give up :nein: I already explained that both statements are false. I also pointed to the corresponding test results, did you even bother to read them? Please read them, and repeat them yourself.

    Zitat

    Zu PicVideo: Ich nehme von der TV-Karte im YUV(YUY2)-Modus auf, decodiert werden die Daten aber als RGB24.

    Iow, whether it is stored as YUY2 or RGB24, in both cases the output is RGB24
    [*]. How do you know?

    Zitat


    avisource("CAPTURE.00.avi",true,"YUY2")
    Ergibt zu geringen Kontrast.

    avisource("CAPTURE.00.avi",true,"RGB24")
    Hier ist das Ergebnis exakt dasselbe als beim direkt geöffneten MJPEG.

    Assuming that the output
    [*] is indeed always RGB24, this would imply that in the first script, two conversions are done: YUY2 -> RGB24 -> YUY2. Apperently the latter conversion is not good (i.e. produces [0,255] instead of [16,235]).

    You can correct that by adding

    ColorYUV(levels="PC->TV")

    to your first script.

    Zitat

    I give up I already explained that both statements are false.

    They aren't false, they are true. Otherwise, this Function and it's explanation does not make any sense. And: I have my Histograms, they don't lie.
    Like Hori himself wrote: "Since DV format movie has already recorded as CCIR601, better Result can be expected if this function is enabled."

    CCIR601 encoded means the Luma-Range of 16-235, the same as my MJPEG-Videos have.

    Zitat

    You can correct that by adding
    ColorYUV(levels="PC->TV")

    Yes, this works, but if you watch the Histogram after that, you will notice some Distortions in it.

    Zitat

    CCIR601 encoded means the Luma-Range of 16-235, the same as my MJPEG-Videos have.


    I know.

    Zitat

    I also pointed to the corresponding test results, did you even bother to read them? Please read them, and repeat them yourself.

    Nothing further to add. (Of course, if you think my tests are not correct, we can discuss that ...)

    Wilbert, i've read your Tests. But there is a little Problem: I'm not longer trusting AVISynth. That's why i use a "real" Video for my Tests and compared the Histograms before and after Encoding.

    You wrote:

    Zitat

    My conclusion is that all YUV values with Y<16 is clamped to (Y,U,V)=(16,128,128) when leaving "output YUV as Basic YCbCr and not CCIR601" unchecked.

    That's exactly the same i wrote above: Unchecking this option will change the Luma-Range. It will take a Source-Video with the range of 0-255 and compress the range to 16-235. This behaviour is normal.
    Checking this option will leave the Data as is. Nice, if the Video is already in 16-235, but very bad if the Source has the range of 0-255.

    Zitat

    That's exactly the same i wrote above: Unchecking this option will change the Luma-Range. It will take a Source-Video with the range of 0-255 and compress the range to 16-235.

    It will clamp (not scale) the range to 16-235. This means that the ranges [0,15] and [236,255] are just thrown away. But, you maybe meant that (when using the word compress) ...

    Zitat

    Checking this option will leave the Data as is. Nice, if the Video is already in 16-235, but very bad if the Source has the range of 0-255.

    Checking this option, it will scale to [0,255].

    If you feed it with [0,255]. I think it will also scale:

    [0,255] -> [0,255*255/235] -> clamped to [0,255]

    Of course, you don't want that

    Zitat

    But there is a little Problem: I'm not longer trusting AVISynth.

    Why is that?

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden