Postprocessing mit DGDecode.dll

Auch das Auftreten von Ringartefakten ist abhängig von der Quantisierung, deshalb wäre auch hier ein Deringing-Filter im Decoder nützlich, weil er dann Zugriff auf die quantisierten Parameter vor der inversen Transformation hat; um es genau zu erfahren, wäre es aber besser, Donald Graft (neuron2) im englischen Board direkt zu befragen.

Und wer mit der Vorgabe der Deblocking-Stärke nicht zufrieden ist, der kann sie auch mit "moderate_h" / "moderate_v" anpassen. Aber dass die sich auch auf das Deringing auswirken würden, scheint nicht so direkt dokumentiert zu sein.

Also, ich sag mal so ...

Egal ob DGDecode etwas über den Inputstream weiß oder nicht weiß, und was es weiß wenn es etwas weiß ... der Deringer ist murks implementiert, da kann man genauso gut blur(1) nehmen. Womöglich ist das Ergebnis nach blur(1) sogar noch schärfer als nach DGDecodes Deringer.
Und der Deblocker ist auch, na, sagen wir mal, etwas in die Jahre gekommen. Um effektiv zu sein, frisst der für meinen Geschmack viel zu viel Detail. Da gefällt mir die von h.264 geliehene Variante Deblock() besser. Obwohl dieser Filter über Avisynth nur "blind" arbeiten kann (ohne Information über die Quantisierung der Blöcke in der Source), ist das Resultat betreffs Entfernung der Blöcke ähnlich gut wie bei dem besser "informierten" alten Deblocker, und es wird dabei deutlich mehr Detail erhalten.

Allerdings, solange die Blockbildung der Quelle nicht allzu stark ist, greife ich desöfteren gerne zu einer gewissen Scriptvariante von Deblock(), weil selbst dieser neuere Filter bei nur leichter/mäßiger Blockigkeit noch so einiges Detail auf dem Weg zur Bereinigung mitreisst.

Hm, findet jemand sowas wie ein LDeblock? Oder weiß, wovon der Meister spricht?

Vielleicht DeBlock_QED ?

Danke! Ich wusste, auf Dich ist Verlass

Argh, muss grade mal meine Numerik-Kenntnisse hervorkramen, von wegen 2D-Diskretisierung, freien Randwerten,...

Aber wieder mal ein geniales Ding. Mal schauen, wann ich dazu komme, das mal anzutesten.