10 Bit debanding

may24

Hi hab da mal folgendes Problem:
Ich reencode meine Animes nach 10 bit AVC. Doch jetzt ist mir aufgefallen das doch einiges an Banding zu sehen ist.
Zuerst hatte ich x264 in Verdacht, aber nachdem ich mir das Ganze im VDM nochmal angesehen habe mußte ich feststellen das der obere Stack nahezu komplett frei von Banding ist und der unteren Stack den Teil der für die Schlieren verantwortlich ist. (Siehe Bild 1)
Encoded man das nun mit x264 werden die Beiden Stacks ja übereinander gelegt und man sieht den Effekt sehr stark.
Das passiert auch wenn man DitherPost() aktiviert - oder GradFun3() wegläßt.

Kann sich da jemand einen Reim drauf machen ? Was kann man dagegen tun ?

hier ist mein avs:

Code

LWLibavVideoSource("Hell_Girl.mkv")
dfttest(Sigma=1,lsb=true)


clip=last


sup = clip.MSuper(Pel=2)
backward_vec = sup.MAnalyse(isb = true, truemotion=true, search=5, dct=8, trymany=true )
forward_vec = sup.MAnalyse(isb = false, truemotion=true, search=5, dct=8, trymany=true ) 




MDeGrain1(clip,sup,backward_vec,forward_vec)
dfttest(Sigma=4,dither=1,tbsize=1)


Dither_resize16(1280,722)
MSharpen(strength=190)
GradFun3()
Dither_crop16(0,0,0,-2)


Dither_quantize(bitdepth=10, mode=7,reducerange=true)
Dither_out()
#DitherPost()


return(last)

Alles anzeigen

(Das Bild 1 ist hier nicht so qualitativ wie oben beschrieben. Das liegt daran das ich es nach jpg gewandelt habe. An sonsten wäre es 7.3 MB groß)

hell1.jpg hell2.jpg

LigH

Sieht hier irgendjemand ein Bild?

Selur

LigH: Nö
may24: Wie fütterst Du den x264 mit dem erweiterten Farbraum? (soweit ich mich entsinne muss man dazu avs2yuv verwenden und in der x264 command line irgendwie explizit angeben was für einen Farbraum man hat,...)

may24

Boa, endlich ... zusätzlich zu den "üblichen" Forumsproblemen (500) kommt jetzt auch noch eigene Internet Verbindungsprobleme hinzu. Hab drei Anläufe gebraucht um wenigstens den Thread zu starten. Ganz zu schweigen von Bilder hochladen...

Na ja. Hier ist meine x264 cli:

Code

"C:\Program Files (x86)\Video Tools\avs2yuv\avs2yuv.exe" -raw "hell.avs" -o - | "C:\Program Files\x264\x264-10bit-r2358.exe" --crf 17 --level 4.1 --b-adapt 2 --bframes 3 --ref 5 --partitions all --direct auto --weightb --me umh --subme 10 --mixed-refs --no-fast-pskip --no-dct-decimate --vbv-bufsize 30000 --vbv-maxrate 38000 --trellis 2 --threads auto --output hell-17-10.h264 --demuxer raw --fps 25 --input-depth 10 --input-res 1280x720 -

sneaker2

Die Ein- und Ausgabe von GradFun3() ohne zusätzliche Parameter ist 8 Bit, wirf dazu einen Blick in die Dokumentation. Beachte bei jedem Filter, ob die Eingabe 8 Bit oder 16 Bit ist, und ob die Ausgabe 8 Bit oder 16 Bit ist. Jeder Filter muß die jeweilige Ein- und Ausgabe ausdrücklich unterstützen, sonst produzierst Du nur Müll.

may24

Ok, das scheint's gewesen zu sein
Mir ist allerdings nicht klar warum lsb=true und lsb_in=true gesetzt sein muß damit's richtig dargestellt wird.

Da wäre aber nochwas. Der GradFun produziert scheinbar eine 2px Linie am unteren Rand. Deshalb das Resizing auch auf 1280x722 und der Crop(0,0,0,-2)
Weiß jemand warum ?

sneaker2

Ein- und Ausgabesample und Dein aktuelles Skript.

may24

Skript siehe oben - bis auf die Zeile: GradFun3(lsb=true, lsb_in=true)
Sample lade ich morgen hoch ...

sneaker2

Und alle Deine Funktionen arbeiten mit 16 Bit stacked? Kann ich mir nicht vorstellen. Siehe Beitrag #5.

sneaker2

Achso, den Sample-Upload kannst Du Dir erst mal sparen. Wenn Du Dein Skript auf 8 Bit/16 Bit-Ein- und Ausgabe hin korrigiert hast, wird der Fehler verschwinden.

may24

Hier ist 'n Schnipsel

Script:

Code

LWLibavVideoSource("Hell_Girl.mkv")
dfttest(Sigma=1,lsb=true)


clip=last


sup = clip.MSuper(Pel=2)
backward_vec = sup.MAnalyse(isb = true, truemotion=true, search=5, dct=8, trymany=true )
forward_vec = sup.MAnalyse(isb = false, truemotion=true, search=5, dct=8, trymany=true ) 




MDeGrain1(clip,sup,backward_vec,forward_vec)
dfttest(Sigma=4,dither=1,tbsize=1)


Dither_resize16(1280,722)
MSharpen(strength=190)
GradFun3(lsb=true, lsb_in=true)
Dither_crop16(0,0,0,-2)


Dither_quantize(bitdepth=10, mode=7,reducerange=true)
Dither_out()


return(last)

Alles anzeigen

sneaker2

Siehe Beiträge #5, #9 und #10.

may24

... nicht so wirklich.
Diter1pre("MSharpen(strength=190)") produziert immer noch die besagte grüne Linie. Und das ist der einzige 8 Bit Filter sonst hier.

Selur

zu MSharpen: dachte immer, dass wenn man den benutzt man erst nach dem Filter Resizen sollte, nicht vorher,..

may24

Selur: ?? Der kommt doch nach dem Resize ....

LigH

Selur meint das auch anders herum, aber seine Interpunktion ist oft etwas sparsam, daher die grammatische Verschachtelungstiefe nicht immer offensichtlich...

Wenn man MSharpen verwendet, sollte erst nach dessen Verwendung eine Skalierung erfolgen, meint er. Ich kann das weder bestätigen noch dementieren, weil ich den selten verwende, aber vielleicht steht ja was in seiner Dokumentation.

Selur

Sorry, hatte gerade jemand an der Tür geklingelt, als ich den Post getippt hatte. -> LigH hat aber recht mit seiner Interpretation meiner Aussage.
Erst MSharpen dann Resizen, wurde zumindest bei Doom9 vor Jahren immer gepostet,.. (sollte man per Suche auch finden können)

Selur

eventuell hab ich es auch falsch im Kopf aber ein einfaches vertauschen der Aufrufe sollte das ja schnell klären können,...

may24

Ok, bin jetzt grad nicht zu Hause. Werd's aber testen sobald ich's bin

sneaker2

Zitat von may24

... nicht so wirklich.
Diter1pre("MSharpen(strength=190)") produziert immer noch die besagte grüne Linie. Und das ist der einzige 8 Bit Filter sonst hier.

1. Immer das ganze Skript, wenn Du mehr als eine Zeile geändert hast (was hier offensichtlich der Fall ist)
2. Woher weißt Du, inwieweit MSharpen() mit Dither1Pre() kompatibel ist?

Jetzt mitmachen!