Luminanz-Probleme

[Kika]

Zu 1: Hatte ich auch schon. Und zwar so ziemlich jeden Fehler, der auftreten kann. Von Superwhite/black über verschobenen Luma bis hin zu super komprimiertem Luma.

Zu 2: Ist mir bei einem meiner Projekte auch schon passiert. Jetzt muss ich bei diesem Film, will ich ihn mir in vernüftiger Bildqualität ansehen, jedes Mal am TV Helligkeit und Kontrast anders einstellen.

Zu 3: Dass die Encoder so unsauber arbeiten, kann ich mir eigentlich nicht vorstellen. Soooo kompliziert ist eine korrekte Farbraumwandlung nun auch wieder nicht. Ich glaube eher, dass manche dieser Fehler schon beim Mastering gemacht werden. Außerdem habe ich arge Zweifel, dass alle, die mit der DVD-Produktion beschäftigt sind auch wirklich in jedem Detail genau wissen, was sie tun.

Zum Rest: Da sag' ich im Laufe der nächsten Tage was zu.

[Busterd]

Das beschriebene Problem beschäftigt mich schon seitdem ich TMPG verwende und eine DVB Karte habe.

Ich verwende Avisynth und DVD2Avi und bei mir sind die "Endvideos" entweder zu dunkel und mit leichten Rotstich bzw. etwas zu satten Farben (Option Output Yuv ... an) oder zu hell (sieht man gut an den 16:9 Rändern, Option Output Yuv ... aus).

Eine Lösung des Problems interessiert mich daher brennend.

Übrigens, der neue TMPG scheint das Problem nicht zu haben oder es war reiner Zufall, dass mein gerade encodiertes Video kein Problem diesbezüglich hatte.


Der Weg:

DVB Aufnahme (pva)
Demuxen mit PVA-Strumento
DVD2Avi (TV Scale und YUV 4:2:2)
Avisynth mit folgendem Script:

------------------------------------------------------------------------------------

LoadPlugin("C:\Programme\MovieStacker\Filters\MPEG2Dec3dg.dll")
LoadPlugin("C:\Programme\MovieStacker\Filters\Undot.dll")
LoadPlugin("C:\Programme\MovieStacker\Filters\aSharp.dll")
LoadPlugin("C:\Programme\MovieStacker\Filters\STMedianFilter.dll")
LoadPlugin("C:\Programme\MovieStacker\Filters\UnFilter.dll")

Mpeg2Source("E:\pvcrwork\Humboldts Erben - Atlantis der Wüste.d2v")
Undot()
aSharp(1, 4)
SeparateFields()
BicubicResize(448, 200, 0, 0.6, 12, 40, 696, 208).Weave()
STMedianFilter(3, 3, 1, 1)
MergeChroma(blur(1.5))
MergeLuma(blur(0.1))

## Linear Motion Adaptive Filtering ##
ScriptClip("nf = YDifferenceToNext()" + chr(13) + " \
UnFilter( -(fmin(round(nf)*2, 100)), -(fmin(round(nf)*2, 100)) ). \
TemporalSoften( fmin(round(2/nf),6), round(1/nf), round(3/nf), 1, 1) ")

AddBorders(16, 88, 16, 88)

## Functions ##
function fmin(int a, int b) {return (a < b) ? a : b}

------------------------------------------------------------------------------------

Das dann in den TMPG 3 (wo ja eine entsprechene Einstellung wie beim TMPG 2.5x fehlt) und diesmal sah das Bild farblich und von der Helligkeit fast wie das Orginal aus (kleinere Abweichungen gibt es wohl immer durch die Filterei).


@Tsunami

Die Downloads funktionieren leider nicht.

[Kika]

Nun, mit DVB arbeite ich ebenfalls, und da stellt sich das Problem gar nicht.

Zu Deinem Skript:

Ich benutze nach wie vor MPEG2Dec3, nicht dg.
Du filterst extrem stark. Das macht das Video unnötig unscharf uns "schmierig".
Eigentlich braucht's zum Bitratensparen nicht mehr als ein CPU=6 in der Source-Zeile und dann nach einen Temporalfilter. Mehr ist nicht nötig.
So, wie Du filterst, erhält man mit Half-D1 und weniger Filtern ein schärferes Video als mit Deiner Methode.
Die Motion-Filterung benutze ich höchstens bei sehr schlechtem analogem Source, aber nicht bei DVB-Streams.

Ans Ende des Skriptes gehört zwingend ein ConvertToRGB24(interlaced=true)
TMPGEnc muss dann im CCIR-Modus arbeiten.

[Busterd]

@Kika

Und was muss ich bei DVB dann machen, dass das Bild des Orginals halbwegs "erhalten" bleibt?

Wo ist bei mir der Fehler, denn wenn ich das wie beschrieben mache, ist bei mir das Endprodukt je nach TMPG Einstellung entweder zu dunkel oder zu hell.

[Kika]

MPEG2Dec3 funktioniert bei mir absolut perfekt, die dg macht manchmal Mucken. Never touch a running system.

Für 90 Minuten auf einem 80er Rohlinge brauch' ich alles, aber mit Sicherheit keine MVCD und ein so starkes Herumgefiltere schon gar nicht.
Such mal nach der KVCD Notch Matrix, die hilft extrem. Und die Einstellung CPU=6 bei MPEG2Dec erledigt schon fast das komplette Filtern.

Mit kwag lag ich lange Zeit im Clinch, "optimal" ist für mich was anderes. Allerdings ist seine Notch Matrix sehr gut, und die Idee des bewegungsabhängigen Filterns ist so dumm auch nicht. Entscheidend ist aber, wie man den Encoder einstellt. Ich selbst benutze da bei TMPGEnc eine Eigenentwicklung, die ich für mich als "Überhöhten CQ-Modus" bezeichne. Ist besser, hat aber einen Nachteil: eine exakte Größenvoraussage ist damit nicht möglich. Der Trick liegt darin, sehr viel höhere Max.-Werte, aber niedrigere Q-Werte zu benutzen. Das befähigt TMPGEnc dazu, die Bitrate besser zu variieren.
Indiana Jones III hab' ich damit zum Spaß mal auf 'nem 80er Rohling unter gebracht - in 352x576.

[Busterd]

@kika

Bin ja für alles offen und werde das mal probieren. Die KVCD Notch Matrix kenne ich nur von QuEnc, werde sie mal testen?

Wäre das ein Script in "Deinem Sinne"?

LoadPlugin("C:\Programme\MovieStacker\Filters\MPEG2Dec3dg.dll")
LoadPlugin("C:\Programme\MovieStacker\Filters\STMedianFilter.dll")


Mpeg2Source("E:\pvcrwork\Tierische Waffen.d2v",cpu=6)
SeparateFields()
BicubicResize(448, 272, 0, 0.6, 10, 2, 700, 283).Weave()
STMedianFilter(3, 3, 1, 1)
MergeChroma(blur(1.5))
MergeLuma(blur(0.1))
AddBorders(16, 16, 16, 16)

ConvertToRGB24(interlaced=true)

[Tsunami]

Einige meiner Tests von oben muss ich revidieren und kann nun Kika doch bestätigen.
Mein Fehler lag darin, das ich die erzeugten MPEGs mit einem falschen Dekoder angeschaut hatte.
Nachdem da so einiges einfach nicht sein konnte habe ich mir nochmal den 601er Thread durchgelesen und bin auf ein Posting von mb1 gestossen, das ich zwar schonmal gelesen hatte, aber hier bei diesem Test nicht beachtet hatte.

Die DirectShow Decoder von Ligos, Elecard und Co, ebenso wie WinDVD und PowerDVD, genauso wie DVD2AVI etc etc können den Bereich von 0-15 bzw 236-255 nicht anzeigen.

Man muss dafür Tools wie MPEG2Schnitt, toMPEG, MPEGcraft oder ParseMPEG
benutzen, dann sieht man auch Head- und Foot-Room.

-----

so siehts aus, genau wie Kika gesagt hat :

TMPGEnc Plus 2.511.51.160 :

1.
[ ] Output YUV data as Basic YCbCr not CCIR601 (nicht angehakt)
aus 0-255 wird 16-235, Kompression wird durchgeführt

2.
[x] Output YUV data as Basic YCbCr not CCIR601 (angehakt)
0-255 bleibt 0-255
16-235 bleibt 16-235
keine Kompression, keine Expansion

-----

Edit 1 :
Der Download funktioniert tatsächlich nicht, allerdings weiß ich nicht wieso.
Die Dateien sind jedenfalls auf dem Arcor-Server und die Dateinamen stimmen auch.
Vielleicht ist bereits das Download-Limit von Arcor überschritten?

Edit 2 :

[scharfis_brain]

um mich mal selbst zu zitieren:

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...

das sollte doch besser sein, als den luma range mit convertyuy2torgb24 von 16..235 auf 0.255 aufzublasen und dann mit TMPGenc wieder auf 16.235 einzudampfen, da halt keine aenderung vorgenommen wird...

kanns derzeit leider nicht testen, pure spekulation....

[orchidee]

Ich habe mich jetzt auch zu einigen Tests bezüglich der Thematik "Luma-Range" durchgerungen.
Meine erste Zielstellung: Wie verhalten sich der Pic-MJPEG und der Canopus-DV-Codec beim Komprimieren und Decomprimieren?
Da die Aussagen hierzu im Thread für mich noch nicht so ganz klar sind, hab ich versucht nochmal von Grund auf anzufangen.

Herangehensweise: Es wird mit avisynth ein Bild aus grauen Steifen mit den Helligkeitswerten 0-255 erzeugt, und zwar jeweils in YUY2 und RGB24.
Das Script wird mit Vdubmod geöffnet und mit dem jeweiligen Codec die Codierung durchgeführt (fast recompress). Die erzeugten avi´s werden nun über avisynth mit vdubmod geöffnet, wobei in avisource der entsprechende pixel_type (YUY2 bzw. RGB24) angegeben wird. Dann wird ein Snapshot gemacht (bmp) und das Histogram mit Corel-Photopaint ausgewertet.
Umgebung: W2k-SP4, CanopusDV-Codec 2.8, Pic-Mjpeg 2.3, Vdubmod 1.5.10.1, avisynth 2.54

Hier mal meine Ergebnisse:
Insgesamt können 4 Fälle unterschieden werden:
1.Quellclip=RGB24; Decodierung nach RGB24
2.Quellclip=RGB24; Decodierung nach YUY2
3.Quellclip=YUY2; Decodierung nach RGB24
4.Quellclip=YUY2; Decodierung nach YUY2

Selbstverständlich ist zu berücksichtigen, dass bei 2. und 4. Vdubmod anschließend wieder nach RGB wandelt.
Um diese Auswirkungen zu prüfen, wurde das Ausgangs-avs-Script(YUY2 und RGB-Version) in Vdub geladen und direkt ein Snapshot gemacht.
Der Histogram-Vergleich der beiden Versionen zeigt z.T. einige Abweichungen (Rundungsfehler bei der Wandlung). Bei der RGB-Version stimmen die Werte im Histogram exakt mit den im Script angegebenen Color-Werten überein.

Und nun zum interessanten Teil:
zunächst -der Pic-MJPEG und der Canopus DV verhalten sich absolut gleichartig auf meinem System!-

Fall1: perfekte Übereinstimmung der Histogramme mit dem Original
Fall2: im Ergebnis ist die Luma-Range expandiert worden, d.h. alle Grauwerte von 0-15 werden 0 und alle von 236-255 werden 255.
Der originale 127er-Wert bleibt praktisch erhalten, die anderen Werte werden mehr oder weniger stark auseinander gezogen. Obwohl dieses Verhalten für mich keinen Sinn ergibt, kann ich das ganz klar sehen.
Fall3: im Ergebnis ist die Luma-Range komprimiert worden (alle 24 originalen Lumawerte sind in den Bereich 16-235 gestaucht worden).
Fall4: gute Übereinstimmung der Histogramme mit dem Original (einige Werte weichen ab, z.B. 255 wird 253)

Erklärungsversuch: Da Encodierung und Decodierung hier nicht getrennt voneinander betrachtet werden konnten, gibt es mehrere
Varianten der Deutung. Die wahrscheinlichste ist folgende:
Beim Codieren hängt es davon ab, welches Material angeliefert wird. Bei YUY2 wird die Luma-Range immer komprimiert, bei RGB unverändert belassen.
Beim Decodieren hängt es davon ab, welches Material durch die Anwendung (z.B. avisynth) angefordert wird.
Bei YUY2-Anforderung wird die Luma-Range expandiert, bei RGB passiert nix.

Edit
<Diese Erklärung stimmt nicht, wie sich im Nachhinein herausgestellt hat>

Kann jemand meine Ergebnisse bestätigen?

[Tsunami]

Ich hätte eher erwartet, das sich die Fälle 2 und 3 genau andersherum verhalten, also YUV -> RGB = Expansion und RGB -> YUV = Kompression.

[Kika]

@Tsunami
Ich hab' doch die ganze Zeit gesagt, dass das so ist. ;)

Warum auf manchen PCs die MPEG-Videos so dunkel abgespielt werden, weiß ich auch nicht. Bei mir ist das nicht so. Ich habe das aber bei anderen Leute schon mit eigenen Augen gesehen.


@scharfis_brain

Wenn converttorgb24(matrix = "rec709") wirklich exakt das tut, was es soll, dann sollte das besser sein. Das aber immer unter der Voraussetzung, dass AVIsynth die Farbraumwandung besser hinbekommt als TMPGEnc das tut. Das müsste man tatsächlich mal in einem direkten Vergleich ausprobieren.

[scharfis_brain]

ich wuerde Dir diesen Vergleichstest ueberlassen, da ich
1) zu faul dazu bin
2) Du der Experte bist

[Busterd]

@kika, scharfis_brain

Habe bei ein paar DVB Aufnahmen mal den Weg von scharfis_brain ausprobiert mit folgendem Script (Bei DVD2AVI wieder TV und YUV und im TMPG den entsprechenden Haken gesetzt):


LoadPlugin("C:\Programme\MovieStacker\Filters\MPEG2Dec3dg.dll")
LoadPlugin("C:\Programme\MovieStacker\Filters\aSharp.dll")
LoadPlugin("C:\Programme\MovieStacker\Filters\STMedianFilter.dll")

Mpeg2Source("E:\pvcrwork\Sagenhafte Völker - Die Hunnen.d2v", cpu=6)
aSharp(1, 4)
SeparateFields()
BicubicResize(448, 200, 0, 0.6, 12, 40, 696, 208).Weave()
STMedianFilter(3, 3, 1, 1)
MergeChroma(blur(1.5))
MergeLuma(blur(0.1))
AddBorders(16, 88, 16, 88)
converttorgb24(matrix = "rec709", interlaced=true)

Ergebnis:

Das Video ist deutlich dunkler als das Orginal und das Endprodukt nach Kikas Weg, wobei mein Ligos Decoder die Videos allgemein zu hell darstellt oder kann es sein, dass PVA-Strumento und MPEG2Schnitt da auch wieder was bi der Quelle verändern?

Es scheint also nicht zu klappen. Daher bleib ich erstmal bei Kikas Methode, denn farblich und von der Helligkeit stimmen die Videos mit den Quellen weitesgehend überein (jedenfalls bei meinen bisherigen Tests).

[Tsunami]

Stimmt es, das der Canopus DV Codec Luminanz-Probleme bei der Konvertierung von YUY2 nach RGB24 hat?

http://forum.gleitz.info/showthread.php?t=12711&highlight=Helligkeit+Videocam
http://forum.doom9.org/showthread.php?s=8f8af36f0616ab5b9189e56a2295534b&threadid=58110&perpage=20&highlight=canopus%20TVsafe&pagenumber=2
http://forum.doom9.org/showthread.php?s=6dd0d722b4a8f2cd1c0205814730b0cb&threadid=87252

[Kika]

Mit DV-Codecs kenn' ich mich einfach nicht gut genug aus, da ich selbst ja immer noch analog (Hi8) filme.
mb1 sollte das aber wissen, der hat ja mal diverse Codecs gegenüber gestellt.

[mb1]

Hmm, kann ich eigentlich nicht bestätigen. Habe keine Probleme mit meiner Codec-Version.

Vielleicht ist es ein Problem des alten, auf der Canopus-Seite frei verfügbaren reinen Dekoders
_________________
Grüße
mb1

Prophet Mohammed:
"Ein für den Wissenserwerb verbrachter Tag ist Gott lieber als 100 Kriege für Gott."