Entrauschen: Gimp & Co. vs. der Rest der Welt

[EuleNr2]

So, hier mal eine Version mit (Gimps) dcamnoise. Das Nette ist, daß man Farb- und Helligkeitskanäle getrennt behandeln kann; Rechenzeit ein paar Sekunden.

 

[grundstoffkonzentrat]

Man muss aufpassen, dass man nicht Äpfel mit Birnen vergleicht. Der (objektive) Vergleich von Entrauschmethoden muss an Hand mehrerer Kriterien erfolgen. Auch sollte so ein Vergleich mit mehreren Bildern durchgeführt werden. Ein zeitintensives Unterfangen also.

Vor allem müsste man dazu mal ein Gütemaß festlegen. Wann ist ein Algorithmus zur Entrauschung "optimal"? Ich vermute mal, man kann da nur von Pareto-Optimalität sprechen: Ein Algorithmus ist dann nicht optimal, wenn es einen anderen gibt, der entweder bei identischem Detailverlust ein geringeres Rauschniveau (wie ist das definiert?) bietet, oder bei identischem Rauschniveau einen geringeren Detailverlust...
Kurz: Objektiv wird das schwer. Das ist aber auch nicht unbedingt erforderlich. Es genügt ja, wenn das Ergebnis dem jeweiligen Betrachter am besten zusagt, also "subjektiv optimal" ist.

Nach den wissenschaftlichen Papieren zu schließen, ist das implementierte Verfahren in TNLMeans "die Entrauschmethode schlechthin" - was ich mittlerweile auch bestätigen kann.

Oha, noch mehr Lesestoff. Naja, an einem einsamen Herbstabend...

Die TNLMeans-Variante (siehe Bild) zeigt, obwohl sie sichtbar stärker entrauscht als die ungeschärfte Noise-Ninja-Variante (oberhalb der Couch gut zu erkennen), mehr Details (siehe Couch). Wenn ich eine etwas weniger entrauschte Version hochladen würde, würde man das gut erkennen. Die Unterschiede mögen mitunter akademisch sein, aber sie sind da.

Auf den zweiten Blick muss ich dir da Recht geben. Allerdings sollte man für meinen Geschmack die Farbkanäle dann stärker entrauschen, ich empfinde die verbliebenen "Farbinseln" (zu sehen oben auf der Lautsprecherbox) noch als etwas störend.

Nachteil des Verfahrens ist allerdings die extrem langsame Verarbeitungsgeschwindigkeit. Für das vorliegende Bild benötigt mein Klapprechner schon mal ca. 13,5 Minuten! Aus diesem Grund teste ich die Parameter immer erst an einem kleinen Ausschnitt.

Das ist schon recht heftig. Allerdings wird man das ja eigentlich nun auch nicht auf jedes Bild loslassen. Mit der ganzen EBV-Prozedur fange ich für gewöhnlich nur bei einigen ausgewählten Bildern überhaupt an. Wenn man es dann ganz ernst meint, und mal ein Bild "perfekt" entrauschen will, kann es ja ruhig etwas dauern.

Innherhalb meines kleinen Programms, das eher für die Stapelverarbeitung konzipiert ist (wenn ich mal Zeit habe, dann implementiere ich auch eine Vorschau), [...]

Interessant. Also, du rufst in dem Programm ein Skript auf, das Skript dann wieder ein Binärprogramm? Welches? Kann man das irgendwo bekommen? Viellecht baut mal jemand ein Gimp-Plugin draus...

 

[Nightstalker]

übrigens habe ich gerade Neat Image unter Wine probiert, läuft ohne Probleme und tut einen guten Job.

 

[grundstoffkonzentrat]

So, hier mal eine Version mit (Gimps) dcamnoise. Das Nette ist, daß man Farb- und Helligkeitskanäle getrennt behandeln kann; Rechenzeit ein paar Sekunden.

Wo findet man denn das Plugin in halbwegs aktueller Version? Ich habe nur kaputte Links und eine Version für Gimp 2.0 auf einer privaten Seite gefunden...
Allerdings bin ich bei der Suche danach auf das gestoßen:
https://www.dslr-forum.de/showthread.php?t=219336
Er hat den "fft3d"-Filter von jemand anderem implementiert. Ich habe das mal kompiliert und auf mein Kunstwerk (Banause, wer etwas anderes behauptet! ;-)) angewandt (Parameter: -b 8 -s 8 -slow 6) und wieder etwas nachgeschärft.
Umständlich zu bedienen, aber im Ergebnis auch ganz brauchbar.

 

[EuleNr2]

Entwickelt wurde dcamnoise von Peter Heckert, allerdings scheint da nach 2005 nichts mehr passiert zu sein, vgl. http://home.arcor.de/peter.heckert/ sowie für die Win-Version http://photocomix-resources.deviantart.com/art/DCamnoise-2-for-Gimp-windows-81260805

P.S.: Zwecks Einordnung, Interpretation und Würdigung der künstlerischen Aspekte Deines Werkes empfehle ich, es einfach mal an die Buergelmaschine zu schicken:http://www.hanebuechlein.de/exot/buergelmaschine/index.html ; Hintergrund: http://www.spiegel.de/kultur/gesellschaft/0,1518,509157,00.html.

 

[Archimedes1]

Interessant. Also, du rufst in dem Programm ein Skript auf, das Skript dann wieder ein Binärprogramm? Welches? Kann man das irgendwo bekommen? Viellecht baut mal jemand ein Gimp-Plugin draus...

Das Programm dient in erster Linie dazu, (vorgefertigte) AviSynth-Scripte einlesen und verarbeiten zu können. Es geht um das Testen und Anwenden von AviSynth(-Plugins) für die Bildbearbeitung (Anwendbarkeit). Letztendlich aber wird in den meisten Fällen immer auf ein Plugin zugriffen, in diesem Falle eben auf TNLMeans.

TNLMeans is an implementation of the NL-means denoising algorithm. Aside from the original method, TNLMeans also supports extension into 3D, a faster, block based approach, and a multiscale version.

Noch eine kleine Anmerkung zur Geschwindigkeit: Ich hatte bei der Entrauschung Bx=By=0 eingestellt, was die Rechenzeit um ein Vielfaches verlängert. Bei Bx=By=1 (blockbasierter Ansatz) dauert das Entrauschen ungefähr 3,5 Minuten (die Unterschiede fallen, je nach Motiv, mitunter sehr gering aus). In beiden Fällen hatte ich niedrige Prozessprioriät eingestellt.

FFT3DFilter benutze ich in der Regel zum Entrauschen von Videos (guter Kompromiss zwischen Schnelligkeit und Qualität). Ich hatte es am Anfang auch zum Entrauschen von Bildern eingesetzt. Ist im Prinzip keine schlechte Lösung. FFT3DFilter neigt aber, je nach Motiv und Wahl der Parameter (Stärke der Entrauschung), zu Artefaktbildungen an feinen Umrissen. Um diesen zu begegnen, muss die Blockgröße verringert werden. Allerdings darf sie nicht zu klein gewählt werden, denn ansonsten werden größere Flächen nicht mehr sauber entrauscht (Artefaktbildung). Im obigen Bild kann man solche Artefakte im Übrigen auch sehr gut erkennen (rechts oben). Das ist ein generelles Problem des Verfahrens. Lässt sich aber durchaus minimieren.

 

[grundstoffkonzentrat]

Im obigen Bild kann man solche Artefakte im Übrigen auch sehr gut erkennen (rechts oben). Das ein generelles Problem des Verfahrens. Lässt sich aber durchaus minimieren.

Ja, definitiv. Auch diese Verfahren ist mal wieder ein Kompromiss...
AviSynth bzw. Plugins dafür muss ich mir wohl mal näher ansehen.

Um mal ein Fazit zu ziehen: Die verschiedenen Programme und Verfahren wählen - auch je nach Einstellung - ziemlich unterschiedliche Kompromisse zwischen Detailverlust und verbleibendem Rauschen (und evtl. Artefakten). Dabei ist die Beurteilung des Ergebnisses ziemlich subjektiv, den einen stört das Rauschen mehr, den anderen der Detailverlust.
Die von mir befürchtete deutliche Lücke zwischen "einfachen", offenen Verfahren und den spezialisierten kommerziellen Tools kann ich nicht recht feststellen. Letztere kochen offensichtlich auch nur mit Wasser.

Ich danke allen Beteiligten für die Beiträge!

 

[NaumannU]

Nicht nur aus "ideologischen", sondern auch aus praktischen Gründen würde ich gerne bei Open Source bleiben (für die Bildebearbeitung Windows booten oder mit Wine rumbasteln müssen wäre unschön). Wenn man jetzt aber mit den kommerziellen Programmen _deutlich_ bessere Ergebnisse erzielen könnte, wäre es eine Überlegung wert...

Wie wäre es Beides zu kombinieren: Bibble Pro läuft auch nativ unter Linux und bringt NoiseNinja mit. Inwiefern Letzteres auch in der Testversion läuft weiss ich grad nicht....

 

[grundstoffkonzentrat]

Wie wäre es Beides zu kombinieren: Bibble Pro läuft auch nativ unter Linux und bringt NoiseNinja mit.

OK, das wäre eine Option. Allerdings wollen die doch einiges an Geld dafür haben. Und ich habe keine Lust, Geld für Software auszugeben und mich mit Binary-only herumzuschlagen, wenn es auch kostenlos mit OpenSource geht.
Deswegen wollte ich mit diesem Thread mal herausfinden, was ich verpasse, wenn ich nur auf Gimp und Konsorten setze. Ergebnis (beim Entrauschen): Etwas, aber nicht so viel wie befürchtet.
Gerade habe ich dennoch mal versucht, mir die Testversion zu holen: Es scheitert daran, dass es keine 64-Bit-Version gibt. Und selbst kompilieren geht natürlich nicht mangels Quellcode. Tja...

 

[NaumannU]

OK, das wäre eine Option. Allerdings wollen die doch einiges an Geld dafür haben. Und ich habe keine Lust, Geld für Software auszugeben und mich mit Binary-only herumzuschlagen, wenn es auch kostenlos mit OpenSource geht.

Ich bin selbst eingefleischter Opensource-Fan, aber was Bibble hier als Komplettlösung für RAW-Developing, Workflow und Verschlagwortung bietet ist mit Opensource-Lösungen gerade mal ansatzweise zu bewerkstelligen. Qualitativ ist mir in den letzten Jahren kein OS-Tool untergekommen was da auch nur ansatzweise rankommt. Gerade dann wenn die Bildermengen etwas größer werden ein wahrer Segen. Am Nächsten dran dürfte noch digikam sein. Und sooo viel Geld (gerade beim aktuellen Dollar-Kurs) ist es nicht was die da haben wollen, noch dazu für das Gebotene.

Gerade habe ich dennoch mal versucht, mir die Testversion zu holen: Es scheitert daran, dass es keine 64-Bit-Version gibt. Und selbst kompilieren geht natürlich nicht mangels Quellcode. Tja...

Wo ist das Problem? Nimm die 32Bit-Version. Rennt hier unter Ubuntu64 vollkommen problemlos. Bibble 5 solls demnächst dann wohl auch nativ für 64Bit geben.

 

[grundstoffkonzentrat]

Wo ist das Problem? Nimm die 32Bit-Version.

OK, das stimmt: Entgegen meiner Erwartungen und Befürchtungen führt ein "dpkg --force-architecture" tatsächlich problemlos zum Ziel.