Blöcke und Kompressionsartefakte entfernen – ein Vergleich

[Archimedes1]

Ich bin mal wieder am Testen eines Plugins (für AviSynth), das, so scheint es, auch vorzüglich für das Entfernen von Blöcken und Kompressionsartefakten geeignet ist. Jetzt würde mich halt wieder interessieren, wie das von anderer Software gehandhabt wird.

Anbei ein Testbild, dass mit einer JPG-Qualität von nur 20 % abgespeichert wurde. Wer Zeit und Lust hat, kann sich daran ja mal probieren. Sofern möglich, bitte nicht nachschärfen!

 

[10dency]

Stell doch als Referenz dein Ergebnis mit AviSynth dazu.

 

[Archimedes1]

Das 2. Bild ist die Variante mit AviSynth.

 

[Archimedes1]

Der Filter nennt sich übrigens TNLMeans. Der implementierte Algorithmus ist eine Weiterentwicklung der sog. Nachbarschaftsfilter. Für die Videobearbeitung ist der Filter v. a. wegen der quälend langsamen Verarbeitungsgeschwindigkeit nicht sinnvoll einsetzbar (das Filtern mit geeigneten Parametern würde Tage, Wochen dauern). Für die Bildbearbeitung dagegen, ist er - richtig eingestellt! - das ideale Werkzeug zum Entrauschen. Aber auch zum Entfernen von Blöcken und Kompressionsartefakten scheint TNLMeans vorzüglich geeignet zu sein.

Nachteil des Verfahrens ist, wie gesagt, die langsame Verarbeitungsgeschwindigkeit. Für das hier dargestellte Bild der Größe 800x600 benötigte mein Klapprechner (1,5 GHz, Intel Centrino) ganze 4 Minuten und 26 Sekunden! Das Suchfenster war dabei auf 21x21 Pixel und das Nachbarschaftsfenster auf 7x7 Pixel eingestellt, so wie es in den wissenschaftlichen Papieren empfohlen wird. Man kann den Filter natürlich auch weniger rechenintensiv einstellen, ohne dass die Qualität all zu sehr darunter leidet.

 

[mariane]

Ich würde das ja mal gerne testen, aber wie als PS-User - gibt es da ein Plugin - für PS natürlich?

 

[Archimedes1]

Ob’s da ein entsprechendes Plugin für Adobe Photoshop gibt, kann ich dir leider nicht sagen. Das das Verfahren mit vernünftigen Parametern sehr viel Rechenzeit erfordert, wird so ein Plugin allerdings nicht immer auf Gegenliebe stoßen.

One can estimate the complexity of an unsophisticated version as follows. If we take a similarity window of size (2f + 1)^2, and since we can restrict the search of similar windows in a larger "search window" of size (2s + 1)^2, the overall complexity of the algorithm is N^2 x (2f + 1)^2 x (2s + 1)^2, where N^2 is the number of pixels of the image. As for practical numbers, we took in all experiments f = 3, s = 10, so that the final complexity is about 49 x 441 x N^2. For a 512×512 image, this takes about 30 seconds on a normal PC.

 

[Archimedes1]

Anbei ein weiteres Beispiel. Wiederum hat das Ausgangsbild nur 20 % JPG-Qualität. Die Einstellungen waren die gleichen, wie beim ersten Beispiel (Ax=Ay=10, Sx=Sy=3, Bx=By=0, a=1.0, h_y=4.8, h_u=4.8, h_v=4.8).

 

[Chrisbeck]

das bearbeitete bild hat aber auch wieder die 10fache größe. da kann man natürlich auch direkt in guter qualität speichern. das tool bringt also nur etwas wenn man das bild nur in komprimierter form vorliegen hat. die eigenen bilder hat man natürlich meistens als original.

 

[mariane]

Die andere Frage, die sich mir stellt: lohnt das? Das zweite Bild ist schon besser, dennoch sind nach wie vor Artefakte erkennbar, also die Bildqualität ist jetzt nicht überragend.
Bei einer besseren Ausgangssituation (sagen wir Jpeg 50%) wiederum wird der Unterschied noch geringer ausfallen bzw. man kann dann mit den Artefakten leben, was ja eigentlich auch der tiefere Sinn beim Jpeg-Format ist (stärkere Kompression durch vertretbare Abstriche bei der Qualität), sonst würde man von vornherein ein anderes Format wählen.

 

[sk1958]

Wer Zeit und Lust hat, kann sich daran ja mal probieren.

Hier ein Versuch mit dem Photoshop Plug-In DeJpeg von Topaz Labs (Freeware). Kommt in die Nähe.

Die Artefakte des Ausgangsbildes sind schon heftig. Ich kann mir kaum vorstellen, dass jemand so stark komprimiert (außer für das Internet, nein, in den Zeiten von DSL selbst da nicht).

Last but not least ein eigener Versuch:

• Originalbild, 100% jpeg
• 20% jpeg (PS CS2)
• 20% mit DeJpeg bearbeitet

Vielleicht habe ich Tomaten auf den Augen, aber die Artefakte scheinen mir nicht so ausgeprägt zu sein.

 

[Archimedes1]

Hier ein Versuch mit dem Photoshop Plug-In DeJpeg von Topaz Labs (Freeware).

Ich habe mir jetzt auch mal Topaz DeJPEG zu Gemüte geführt. Das Plugin lässt sich ja auch unter IrfanView installieren.

Erst wenn man alle Schärferegler zurückdreht, kommt man zu einigermaßen vernünftigen Ergebnissen. An die Ergebnisse von TNLMeans komme ich aber beim besten Willen nicht heran. TNLMeans arbeitet hier wesentlich sauberer (homogenere Flächen, weniger Artefakte, mehr Details etc.).

Ich hänge mal Beispiel mit IrfanView an. Ich habe ganz bewusst mehr Artefakte stehen lassen als beim Beispiel mit TNLMeans, dennoch sind weniger Details zu erkennen.

 

[sk1958]

Ja klar ist DeJpeg nicht so gut. Ich sagte ja auch "kommt in die Nähe".

Allerdings kann ich mir noch nicht vorstellen, wo so extrem verjepgte Bilder im täglichen Leben vorkommen. Der Algorithmus ist sicher toll, aber ich vermute fast, so etwas braucht man eher für wissenschaftliche Anwendungen.

Bei den jpeg-Bildern (von Freunden und Verwandten), die ich weiter verarbeiten will, sind viel weniger Artefakte zu sehen, als ich bei meinem Selbstversuch erzeugt habe. Bei dieser kleineren Menge an Bildstörungen liefert DeJpeg gute bis sehr gute Ergebnisse.

Last but not least, was nützt der beste Algorithmus, wenn er nicht als Plug-In für PS und Kompatible erhältlich ist?

 

[Archimedes1]

Mit den stark komprimierten Bildern wollte ich nur zeigen, was möglich ist. Bei noch stärker komprimierten Bildern wird’s aber auch für TNLMeans schwierig, noch was Vernünftiges herauszuholen.