Luminanz-Bereich

    Zitat

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

    Hm, but i GET the same Color-Range like the Source if i use that, like i wrote in former posts, i've checked this many times.
    The Histograms of the Source and the Target-Videos are exactly the same (OK, there's always a little loss while encoding, but that's not what i meant).

    Let's have another try:
    If you have DV-Source and a correct working DV-Codec, you get a Video with the Range of 16-235. That's the same Range, a MPEG2-Video should have, right?
    Now feed this Video directly into TMPGEnc. What Option will you Choose? CCIR601 or YCbCr?. Consider: This is an Output-Option, and the Video still is in CCIR601.
    If encoding in CCIR601 only clamps the Range, nothing should happen, because there's nothing to clamp in the Source. But watch the resulting Video, i bet, it is lightened.
    If encoding in YCbCr is scaling to 0-255, the resulting Video must be darkened, but (on my machine) it isn't - like my MJPEG-Source also.
    That's what i discovered, and i can repeat and repeat it, it's always the same Result.

    Why i'm not trusting AVIsynth any longer? Because of all of this mess with the Luma-Range. ;)

    Zitat

    If you have DV-Source and a correct working DV-Codec, you get a Video with the Range of 16-235. That's the same Range, a MPEG2-Video should have, right?


    Yup.

    Zitat

    If encoding in CCIR601 only clamps the Range, nothing should happen, because there's nothing to clamp in the Source.


    Yup.

    Zitat

    But watch the resulting Video, i bet, it is lightened.


    Very strange. Could you upload a small picvideo video clip somewere? Including the codec you used.

    I suggest you try the same test (both CCIR601 and YCbCr) with a divx/xvid clip, and compare them with the divx/xvid itself?

    MJPEGCorrect? Du meinst wohl ColorYUV()?
    Was der bewirkt sollte eigentlich aus dieser Diskussion hervorgehen und steht auch in der Anleitung zu AVISynth mit drin.

    Wilbert
    I have to get new Webspace first, my last Provider kicked me... :(

    Ach so, das kannte ich selbst nicht.
    Scheint aber genau dafür gedacht zu sein, das zu beheben, was ich hier zu beschreiben versucht habe.

    Zurzeit komme ich nicht dazu, aber ich werden die Tage (voraussichtlich am Wochenende) mal ein paar genaue Tests mit diversen Codecs und Encodern durchführen, um diese Luma-Geschichte ein für allemal zu klären.

    Das wäre sehr fein, Kika.

    Wenn Du dabei bist, kannst du auch mal den CCE mit seinen beiden Einstellungen "16 to 236" und "0 to 255" testen?

    Wie machst Du das genau mit dem Histogramm?

    Nimmst Du einen Screenshot und siehst es Dir in einem Grafikprogramm an?
    Das Histogramm, das TMPEGEnc anzeigt, läßt sich ja leider nicht exportieren.

    Ich würde das mit der Luminanz nämlich mal gerne testen.

    Ja, die Screenshots werden bei AVIs mithilfe von VirtualDub, bei MPEGs mithilfe von MME erzeugt. Wichtig ist nur, dass die Darstellung OHNE Overlay erfolgt.
    Danach kann man in PhotoShop oder PhotoImpact (welches ich benutze) die Histogramme erzeugen lassen.

    Hallo Kika,
    in welches Format speicherst du denn? .BMP scheint die ganze Range von 0-255 auszunutzen, obwohl ich einen Shot von einem "o to 236"-Pic gemacht habe.

    Außerdem ist mir die Abkürzung "MME" leider nicht geläufig. Ist das ein Player?

    Wenn ich mit Google nach "MME MPEG" suche, kommen ziemlich verschiedenartige Ergebnisse - sehr interessant finde ich eine Seite über "Martingale's advanced proprietary Motion Estimation algorithm"; aber wahrscheinlich handelt es sich doch um ein Programm, das beim M2V-VFAPI-Filter mitgeliefert wird:

    http://www.marumo.ne.jp/mpeg2/

    Will aber nicht ausschließen, dass die miteinander zu tun haben...

    Abgesehen davon, kann man doch auch mit DVD2AVI Screenshots aus MPEG2-Video machen, oder?

    LigH


    Das Tool aus dem Link ist das richtige. Der Vorteil ist, dass ich wirklich das reine, dekodierte Bild bekomme und auch genau sehe, ob's ein I-, B- oder P-Frame ist.

    Übrigens: Bislang sieht's bei den Tests so aus, dass der YCbCr-Mode die Luma-Range einfach nur übernimmt. Also weder was abschneidet, noch was komprimiert. 16-235 bleibt 16-235, 0-255 bleibt 0-255.
    Der CCIR-Modus hingegen komprimiert 0-255 zu 16-235 und unglücklicherweise versaut er damit Material, das bereits in 16-235 vorliegt.
    Nur so ist es zu erklären, dass man mit TMPGEnc durchaus MPEGs herstellen kann, die die Luma-Range 0-255 haben - und somit verkehrt sind.
    Ganz fertig bin ich mit den Tests aber noch nicht, und eine Sache ist merkwürdig: Selbst wenn ich beim Source auf die richtige Range achte und den jeweils korrekten Encodier-Modus wähle, sind die Ergebnisse nicht identisch.
    Außerdem stehen meine Resultate jetzt im absoluten Widerspruch zu dem, was Wilbert schrieb.
    Sieht so aus, als müsste jemand, der ebenfalls einigermaßen Fit in diesem Themenbereich ist, auch nochmal eine Testserie durchführen, um wirklich sicher sein zu können.
    Eines steht aber 100% fest: ColorYUV(levels="PC->TV") ist keine echte Lösung, da tatsächlich dabei das Histogramm und damit logischerweise auch das Bild verändert wird. Dasselbe gilt für MJPEGCorrect. Beides kann also höchstens ein Notbehelf sein.

    Habt ihr bei den Tests bedacht, das TMPG immer RGB-Input verwendet?
    D.h.
    - entweder fordert er vom Decoder (z.B. PicVideo, MainConcept-DV,...) RGB, dann wird gleich dort YUV auf RGB gewandelt
    - oder er sucht einen Filter, der YUV->RGB kann (z.B. der msyuv.dll).

    Beide Varianten sind also von einem externen Codec abhängig, wo man nicht so ohne weiteres sieht, ob dieser CCIR oder 0-255 erwartet.

    AviSource(..., pixel_type="RGB") macht also genau das gleiche wie TMPG.
    Man sieht also im Beispiel von KIKA, dass PicVideo bei der internen YUY-RGB-Wandlung auf 0...255 wandelt.

    TMPG "ohne Kreuzchen" macht für RGB 0-255 ein CCIR-YUV, mit Kreuzchen ein "illegales" mit superblack und superwhite-Anteilen.

    PS: mpeg2dec(3) verwendet das TV/PC-Flag von DVD2AVI nicht, vfapi SCHON! Mit mpegdec3 kann also nie ein 0-255-mpeg korrekt in AviSynth gebracht werden.

    (das ist mein Wissensstand dazu)

    Ja, an solche Dinge habe ich gedacht. Ich habe zur Sicherheit sogar testweise mal msyuv.dll aus dem System entfernt.
    Den Unterschied zwischen YUV und RGB sieht man ja auch ganz gut, wenn man das MJPEG-AVI mal direkt und mal via AVISynth laufen lässt, von den Ausgabe-Optionen des Codecs selbst ganz abgesehen.

    Zitat

    TMPG "ohne Kreuzchen" macht für RGB 0-255 ein CCIR-YUV, mit Kreuzchen ein "illegales" mit superblack und superwhite-Anteilen.

    Deckt sich exakt mit meinen Beobachtungen.
    Source mit 0-255 -> CCIR (ohne Kreuzchen)
    Source mit 16-235 -> YCbCr (mit Kreuzchen)

    dazu fällt mir noch ein: eine Anzeige welcher Codec zum Dekodieren verwendet wird, wäre dafür hilfreich, sowohl in AviSynth als auch in TMPG. Im Procoder gibts das z.B.
    Wäre (für AviSynth) mal einen Vorschlag an sh0dan wert...

    Stimmt, gute Idee. Ich habe ja schon früher in diesem Thread die Befürchtung geäußert, dass die Ergebnisse je nach installierten Codecs unterschiedlich sein könnten.
    Nur fürchte ich, dass wir dieses Feature für TMPGEnc nicht bekommen können. Bei AVISynth..., nun, Du hast mit Sicherheit einen besseren Draht zu sh0dan als ich. ;)
    Wenn ich weiß, welcher Codec benutzt wird und wenn ich dann noch weiß, wie der sich in Bezug auf die Luma-Range verhält (vor allem auch, wenn er YUV und RGB liefern kann), dann lässt sich damit eine Menge anfangen.

    Nachtrag: Auf die Level-Geschichte bin ich auch hereingefallen, also ich von VFAPI zu MPEG2dec wechselte. ;)

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden