YUV-Banding bei Encodierung von CG vermeiden

Anscheinend lag ich falsch ... ich dachte, statt die PNGs der Blender-Movies mit dem ziemlich langsamen ImageSource immer wieder zu lesen, könne ich auch eine Zwischendatei mit x264 --crf 6 erzeugen, die wäre schon exakt genug. Ja, sie bildet die AviSynth-Ausgabe exakt genug ab. Aber die AviSynth-Ausgabe ist nicht so recht exakt genug, scheint mir. Im Intro von "Sintel" gibt es viel Schnee und Himmel, insgesamt also sehr wenig Kontrast. Und da fällt doch schon ein ganz leichtes Banding auf. Das dürfte wohl der Konvertierung nach YV12 geschuldet sein.

Also mal verglichen: Die Differenz zwischen PNG-Quellbild 501 und einem PNG-Screenshot von Frame 500 (in AviSynth 0-basiert gezählt) aus VirtualDub gebildet und den Bereich ±4 gespreizt. Sieht hübsch bunt aus.

Ist das wirklich nur die RGB-YUV-Konvertierung? Oder steckt da noch mehr dahinter?

Jetzt zu möglichen Gegenmaßnahmen ... GradFun2db? Schlechte Idee; zwar werden die Übergänge zwischen den Bändern gedithert, aber auch abgeflacht. Kontraste zu schwach erkennbaren Objekten werden noch schwächer. Bei GradFun2db(2) geht es gerade noch, bei GradFun2db(4) verschwinden schon fast ein paar Felsumrisse im Schnee oder Himmel.

Kleinere Werte bis max. 1.0 führen übrigens zu einem Fehlverhalten; dokumentiert ist aber nicht, dass man den Threshold größer als 1.0 setzen muss, lediglich "Default is 1.2"...

Ich glaube, ich bräuchte dafür schon eine andere RGB-YUV-Konvertierfunktion, die gleich während dieser Umrechnung das Dithering anwendet, ohne die Kontraste zu beeinflussen.

Oder die 16-bit-Kanalverarbeitung (Deep Color). Hat da schon jemand praktische Erfahrung, wie man das korrekt verwendet?

Um es noch mal ganz klar zu betonen: Das Banding stammt nicht aus der Komprimierung, das ist schon nach ImageSource().ConvertToYV12() zu sehen. Sehr schwach, aber in Form eines leichten Ruckens in langsamen Helligkeitsschwankungen (z.B. Aufblenden).

@ sneaker2:

Ziemlich abweichend.

@ Selur:

Ja, 1080p. Das hat mich schon mehrere Tage Download gekostet. Für die 4K hätte ich noch nicht mal kurzfristig internen Plattenplatz, glaub ich, das müsste auf eine externe geladen werden...

4K und 1080 stimmen eigentlich gut überein, nur 2K zeigt irgendwie ein anderes Frame, eine andere Wellenphase im Fell?
__

P.S.:

Ziemlich gut zum Vergleichen eignet sich wohl der Bereich der Frames 8780 - 8800, wo der Mond zur Sonne überblendet.

Dann kommt leider noch ein relativ erheblicher Faktor dazu, wie ich mit Bedauern feststellen musste: Der :motz: TFT-Bildschirm. Ich muss für halbwegs lineare Darstellung im Grafiktreiber einen Desktop-Gammawert von 0,6 einstellen.

Auf einem anderen Monitor mit stabilerer Darstellung sieht das sicherlich ganz anders aus... R.I.P., guter alter SyncMaster, meine letzte Röhre hat mich vor ein paar Monaten verlassen. :heul:

Nun gut, bleiben wir mal dabei ... theoretisch ... würde Dithering bei der Konvertierung von RGB zu YUV wohl nützlich sein; gibt es dafür ein entsprechendes Plugin?

Anscheinend kann man dafür das Dither-Paket verwenden, das bietet eine Funktion Dither_convert_rgb_to_yuv(), braucht allerdings eine ziemlich neue Version der MVTools2; mitgeliefert wird eine Version 2.6.0.5. Fizick hat da wohl die Weiterentwicklung abgegeben? Nun gut, muss man ja wissen, dass die neueste Version jetzt woanders herkommt.

Bisher sieht es also so aus:

LoadPlugin("plugins\dfttest.dll")
LoadPlugin("plugins\QTGMC\mt_masktools-26.dll")
LoadPlugin("plugins\MVTools2\mvtools2.dll")
LoadPlugin("plugins\Dither\avstp.dll")
LoadPlugin("plugins\Dither\Dither.dll")
Import("plugins\Dither\Dither.avsi")


ImageSource("sintel-1080-png\%08d.png", 1, 21312)
AssumeFPS(24,1)
Dither_convert_rgb_to_yuv()

Jetzt überleg ich noch mal, ob irgendwelche Parameter nützlich wären...
__

Nee, das haut nicht hin...

Zitat

Avisynth open failure:
mt_lutxy : unsupported colorspace. masktools only support planar YUV colorspaces (YV12, YV16, YV24)
(plugins\Dither\Dither.avsi, line 1156)
(plugins\Dither\Dither.avsi, line 1131)
(plugins\Dither\Dither.avsi, line 366)
(sintel-1080.avs, line 10)

Hoppla, da war noch eine DLL aus dem QTGMC-Paket nicht ersetzt worden; danach kamen ja noch ein Update von -Vit- und das letzte 2.60a4-MT-Update von 06_taro. Die Version läuft.

Gut, 16-bit-Ausgabe an 10-bit-x264; das Ergebnis soll sowieso immer als Vorlage für weitere Konvertierungen dienen, also üblicherweise via FFMS2 oder DGDecNV.