-
Neuer Gutscheincode unseres Partners Schutzfolien24:
DSLR-Forum2025
Dauerhaft 10% Rabatt auf alle Displayschutzfolien und Schutzgläser der Eigenmarken
"Upscreen", "Screenleaf", BROTECT" und "Savvies".
Der Code ist für alle Geräteklassen gültig. -
Stimmt ab über die Sieger des DSLR-Forum Fotowettbewerbs Mai 2025.
Thema: "Grün"
Nur noch bis zum 31.05.2025 23:59!
Jeder darf abstimmen!
Zur Abstimmung und Bewertung hier lang -
In eigener Sache!
Liebe Mitglieder, liebe Besucher und Gäste
ich weiß, es ist ein leidiges Thema, aber ich muss es ansprechen: Werbung, Werbeblocker und Finanzierung des Forums.
Bitte hier weiterlesen ... -
Nicht erreichbare Adressen im Benutzerkonto
Wir bekommen zurzeit eine große Anzahl an E-Mails, die das System zum Beispiel als Benachrichtigungen an Nutzer verschickt,
als unzustellbar zurück, weil z.B. die Adressen nicht erreichbar sind oder das Postfach gar nicht existiert.
Stellt doch bitte sicher, dass die Benachrichtigungen, die ihr vom System erwartet, auch zugestellt werden können.
Nicht erreichbare E-Mail-Adressen sind dazu wenig hilfreich.
Danke!
WERBUNG
Neues HDR-Programm für Windows: SNS-HDR
- Themenersteller Gast_322058
- Erstellt am
-
- Schlagworte
- hdr
Anbei eines meiner ersten HDR's. Bin mit dem Ergebnis sehr zufrieden. Genaue Einstellungen in SNS weiß ich nicht mehr (habe solange "gespielt" bis das Ergebnis passte). Ich habe das gute Gefühl, für 30€ eine tolle Software bekommen zu haben!
Schonmal ein großes lob an den Entwickler!
Schonmal ein großes lob an den Entwickler!
würdest du für private Vergleichstest, die originale Belichtungsreihe zur Verfügung stellen? Können auch verkleinert sein.
Sebastian,
I have one more feature request. It would be great to have something like a clipping warning integrated to SNS-HDR. This would be very helpful to indicate where darks or highlights tending to clip and gives the user therefore a chance to use the other integrated tools to compensate if necessary. There are of course more ways to integrate a warning like this, tools like Lightroom are indicating these parts with blue (for darks) and red (for highlights).
Regards,
Joerg
I have one more feature request. It would be great to have something like a clipping warning integrated to SNS-HDR. This would be very helpful to indicate where darks or highlights tending to clip and gives the user therefore a chance to use the other integrated tools to compensate if necessary. There are of course more ways to integrate a warning like this, tools like Lightroom are indicating these parts with blue (for darks) and red (for highlights).
Regards,
Joerg
@Tom,
ist aus einer 5er-Reihe JPGs entstanden (-5, -3, -1, +1, +3).
@Carsten,
kann ich machen, muss heute abend noch weg, mal sehen, stelle ich morgen ein.
lg Joghi
Aufgrund der äußerst positiven Resonanz habe ich SNS-HDR in der Demoversion mit EasyHDR verglichen.
SNS-HDR liefert dabei wirklich sehr schöne, realistische Ergebnisse mit den Standardeinstellungen, wobei die Performance verbesserungswürdig ist.
Mit EasyHDR habe ich versucht das gute Ergebnis von SNS-HDR nachzustellen und dies ist mir ebenfalls gelungen, so dass ich die große Euphorie nicht so ganz nachvollziehen kann. EasyHDR arbeitet gefühlt wesentlich schneller und scheint in der Entwicklung ebenfalls weiter voran geschritten zu sein.
Wem also bei SNS-HDR etwas fehlt (z. B. Presets) sollte sich vielleicht nochmal mit EasyHDR beschäftigen. Ansonsten freut es mich, dass es mit SNS-HDR eine weitere Alternative gibt!
SNS-HDR liefert dabei wirklich sehr schöne, realistische Ergebnisse mit den Standardeinstellungen, wobei die Performance verbesserungswürdig ist.
Mit EasyHDR habe ich versucht das gute Ergebnis von SNS-HDR nachzustellen und dies ist mir ebenfalls gelungen, so dass ich die große Euphorie nicht so ganz nachvollziehen kann. EasyHDR arbeitet gefühlt wesentlich schneller und scheint in der Entwicklung ebenfalls weiter voran geschritten zu sein.
Wem also bei SNS-HDR etwas fehlt (z. B. Presets) sollte sich vielleicht nochmal mit EasyHDR beschäftigen. Ansonsten freut es mich, dass es mit SNS-HDR eine weitere Alternative gibt!
Zuletzt bearbeitet:
Hello Pebal,
nice processing.
With my skills i´ve got the following result out of Easy-HDR. Just opened the raw directly in Easy-HDR and started processing.
nice processing.
With my skills i´ve got the following result out of Easy-HDR. Just opened the raw directly in Easy-HDR and started processing.
Gast_322058
Guest
Da sieht man mal wieder, dass SNS-HDR einfach besser mit Halos umgehen kann.
Ich denke auch, dass bei SNS der Himmel besser aussieht und die Kirche auch.
Das Ergebnis mit SNS-HDR finde ich deutlich besser, mehr Zeichnung in den Wolken und stimmigere Farben.
LG Martin
Und das gute an SNS ist, das es praktisch schon so in dieser Qualität aus der Software kommt. Mit der Maskierungsfunktion könnte man jetzt noch bestimmte Bereiche gezielt verändern, bzw. Effekte verstärken.
Zur Performance: Ich habe ein Bild (RAW) in Photomatix und in SNS geöffnet und mal auf die Zeit geschaut ab dem Öffnen bis zum fertigen Bild. Also keine Veränderungen gemacht von den Einstellungen bzw. an den Reglern. SNS 1:25min und Photomatix 35 sek.
Ich denke, dass der Programmierer hier auch ein offenes Ohr hat und die nächsten Versionen eventuell auch an Performance gewinnen bzw. vielleicht die ein oder anderen Wünsche von uns noch eingebaut werden
Zur Performance: Ich habe ein Bild (RAW) in Photomatix und in SNS geöffnet und mal auf die Zeit geschaut ab dem Öffnen bis zum fertigen Bild. Also keine Veränderungen gemacht von den Einstellungen bzw. an den Reglern. SNS 1:25min und Photomatix 35 sek.
Ich denke, dass der Programmierer hier auch ein offenes Ohr hat und die nächsten Versionen eventuell auch an Performance gewinnen bzw. vielleicht die ein oder anderen Wünsche von uns noch eingebaut werden
Gast_155657
Guest
Ich denke der Performanceverlust kommt durch den Einsatz der externen Tools (dcraw.exe, exiftool.exe). Besonders exiftool.exe ist langsam, da es eine eigene Perl-Umgebung mitbringt sich sich beim ersten Start im temporären Ordner des Benutzers installiert. dcraw ist der Raw-Konverter den SNS-HDR offenbar verwendet. dcraw ist zwar ganz in C programmiert, aber auch hier dürfte der externe Programmaufruf ins Gewicht fallen, bei dem dcraw erst einmal ein TIFF16 im Dateisystem erzeugt das dann von SNS-HDR wieder eingelesen wird. Eine SSD dürfte diese Übung deutlich beschleunigen, aber die hat ein Bildbearbeiter ja sowieso für solche Fälle. 
Ansonsten wird deutlich mehr Performance schwierig; es sei denn in den Algorithmen ist noch Luft. Es ist davon auszugehen, dass der Code selbst bereits in Hinblick auf Laufzeit durchdacht ist. Erfahrungsgemäß ist es schwierig aus solchem Code auf technischer Ebene mehr wie 5-10% heraus zu kitzeln.
Die Lösung ist ein echter Multicore ohne Hyperthreading (im Hyperthreading teilen sich jeweils zwei Kerne einen mathematischen Coprozessor). Denn SNS-HDR scheint die Berechnung ja gut auf alle verfügbaren Kerne skalieren zu können. Übrigens eine saubere Leistung, weshalb ich auch vermute, dass der Code bereits durchdacht ist.
Ansonsten wird deutlich mehr Performance schwierig; es sei denn in den Algorithmen ist noch Luft. Es ist davon auszugehen, dass der Code selbst bereits in Hinblick auf Laufzeit durchdacht ist. Erfahrungsgemäß ist es schwierig aus solchem Code auf technischer Ebene mehr wie 5-10% heraus zu kitzeln.
Die Lösung ist ein echter Multicore ohne Hyperthreading (im Hyperthreading teilen sich jeweils zwei Kerne einen mathematischen Coprozessor). Denn SNS-HDR scheint die Berechnung ja gut auf alle verfügbaren Kerne skalieren zu können. Übrigens eine saubere Leistung, weshalb ich auch vermute, dass der Code bereits durchdacht ist.
Zuletzt bearbeitet:
Ich habe den Test auf Vista 64Bit und einen Quadcore durchgeführt. Mich selber stört jetzt die Geschwindigkeit nicht. Weil ist erstmal das Bild da, geht alles recht schnell.
Nein!
Hyperthreading bedeutet, dass ein Prozessorkern Befehle zweier Threads zeitgleich abarbeiten kann. Es werden zwei logische CPUs auf einer physikaischen simmuliert.
Die erste Abbildung in diesem Link visualisiert das recht schön: Hyperthreading.
Hyperthreading macht eine CPU nie langsamer - schlechtestenfalls hat es keine Beschleunigungswirkung. Der statistische Geschwindigkeitszuwachs (soll) bei ca. 33% liegen (selber nicht gemessen).
In aufsteigender Geschwindigkeit: Singlecore ohne HT -> Singlecore mit HT -> Multicore ohne HT -> Multicore mit HT.
Gast_155657
Guest
Es ist müssig hier die technischen Details zu diskutieren. Zweifellos wird die einzelne CPU nicht langsamer, denn Hyperthreading ist einfach eine Technik die CPU besser auszulasten. In einer HT-Umgebung teilen sich zwei Threads einen echten, physischen Core. Echte Gleichzeitigkeit ist das nicht, aber das Zusammenspiel wird sehr gut optimiert. Wenn SNS-HDR zwei oder mehr Rechenthreads startet legt Windows je zwei auf einen Core und damit auch auf mathematischen Koprozessor und SSE Units.
Während ein Thread pausiert kann der andere den Core übernehmen. Dabei muss der andere Thread den Cache zurücksetzen. Dieser Overhead entsteht bei echten Cores mit jeweils eigenen Pipelines nicht. Nur scheinen die SNS-HDR-Threads eben nicht zu pausieren. Die Threads scheinen völlig parallel zu laufen und den Cache perfekt zu treffen, was die 100%tige CPU-Auslastung andeutet. Da rattern Schleifen in immer gleicher Folge über die Pixel. Der CPU-Cache ist immer voll. In solchen Fällen hilft HT auch nicht. Tatsächlich ringen zuviele Threads um CPU und FPU-Resourcen. Es sei denn (und das ist möglich) SNS-HDR startet per se nur soviele Rechenthreads wie es physische Cores gibt. So würde ich es machen um die Hardware wirklich optimal auszulasten. Ich hab's auch oft genug gemacht: es bringt deutlich unter 5%, und lohnt sich nur bei Berechnungen die einige Stunden laufen, und bei denen der Rechner völlig in Ruhe gelassen wird. Wie gesagt: das gilt nur für gut parallelisierbare Algorithmen (z.B. Simulationen) die die CPU bereits gut auslasten. Bei Code mit vielen Sprüngen und irregulären Zugriffsmustern auf den Speicher kann es durchaus zu mittleren Steigerungen von 33% kommen, weil die Pipelines ständig zusammen brechen (wobei diese Zahl wie aus der Werbung klingt).
Aber die Details sind hier eigentlich irrelevant. Ich wollte nur zum Ausdruck bringen, dass mMn die Performance von SNS-HDR nur durch eine SSD und schnellere Cores signifikant zu steigern ist. Eine weitere Möglichkeit ist natürlich den Code von dcraw direkt in das Programm zu integrieren (dcraw liegt ja im Quellcode vor). Oder auch, CUDA zu verwenden. Aber wozu? Da dürften wichtigere Sachen auf der Liste des Programmierers stehen, wie das Lightroom-Plugin.
Übrigens müsste es sehr einfach sein SNS-HDR für Linux/MacOS zu portieren. Schließlich sind dcraw/exiftool betriebssystemunabhängig, und der Rest ist das Kommandozeilenprogramm SNS-HDR.exe. Wird wohl in C oder C++ implementiert sein; kann also überall laufen.
Mir reicht die Performance von SNS-HDR jedenfalls. Die Ergebnisse sind wichtiger.
Während ein Thread pausiert kann der andere den Core übernehmen. Dabei muss der andere Thread den Cache zurücksetzen. Dieser Overhead entsteht bei echten Cores mit jeweils eigenen Pipelines nicht. Nur scheinen die SNS-HDR-Threads eben nicht zu pausieren. Die Threads scheinen völlig parallel zu laufen und den Cache perfekt zu treffen, was die 100%tige CPU-Auslastung andeutet. Da rattern Schleifen in immer gleicher Folge über die Pixel. Der CPU-Cache ist immer voll. In solchen Fällen hilft HT auch nicht. Tatsächlich ringen zuviele Threads um CPU und FPU-Resourcen. Es sei denn (und das ist möglich) SNS-HDR startet per se nur soviele Rechenthreads wie es physische Cores gibt. So würde ich es machen um die Hardware wirklich optimal auszulasten. Ich hab's auch oft genug gemacht: es bringt deutlich unter 5%, und lohnt sich nur bei Berechnungen die einige Stunden laufen, und bei denen der Rechner völlig in Ruhe gelassen wird. Wie gesagt: das gilt nur für gut parallelisierbare Algorithmen (z.B. Simulationen) die die CPU bereits gut auslasten. Bei Code mit vielen Sprüngen und irregulären Zugriffsmustern auf den Speicher kann es durchaus zu mittleren Steigerungen von 33% kommen, weil die Pipelines ständig zusammen brechen (wobei diese Zahl wie aus der Werbung klingt).
Aber die Details sind hier eigentlich irrelevant. Ich wollte nur zum Ausdruck bringen, dass mMn die Performance von SNS-HDR nur durch eine SSD und schnellere Cores signifikant zu steigern ist. Eine weitere Möglichkeit ist natürlich den Code von dcraw direkt in das Programm zu integrieren (dcraw liegt ja im Quellcode vor). Oder auch, CUDA zu verwenden. Aber wozu? Da dürften wichtigere Sachen auf der Liste des Programmierers stehen, wie das Lightroom-Plugin.
Übrigens müsste es sehr einfach sein SNS-HDR für Linux/MacOS zu portieren. Schließlich sind dcraw/exiftool betriebssystemunabhängig, und der Rest ist das Kommandozeilenprogramm SNS-HDR.exe. Wird wohl in C oder C++ implementiert sein; kann also überall laufen.
Mir reicht die Performance von SNS-HDR jedenfalls. Die Ergebnisse sind wichtiger.
Zuletzt bearbeitet:
Sternenfall, bin ganz deiner Meinung. Wir reden hier ja nicht von 30 Minuten Berechnung. Sobald das Bild da ist, kann man alles in Realtime machen. Lieber ein paar der genannten Wünsche von mir die ich weiter vorne geschrieben habe als Weihnachtsgeschenk umsetzen, das wäre echt toll
ich tu mich schwer mit microsoft framework.
fahre windows xp sp2 32 bit und nutze im moment wohl noch framework 1.1
nun wollte ich (wegen SNS-HDR) auf version 3.5 "aufrüsten", doch das setup bricht mit einer fehlermeldung ab. version 4..x ist ja wohl schon für die 64 bit rechner gedacht.
jedenfalls habe ich probleme das hdr-proggi auszuprobieren, denn es verlangt ja mindestens FW 3.0
fahre windows xp sp2 32 bit und nutze im moment wohl noch framework 1.1
nun wollte ich (wegen SNS-HDR) auf version 3.5 "aufrüsten", doch das setup bricht mit einer fehlermeldung ab. version 4..x ist ja wohl schon für die 64 bit rechner gedacht.
jedenfalls habe ich probleme das hdr-proggi auszuprobieren, denn es verlangt ja mindestens FW 3.0
Ich habe mal schnell gegoogelt. Müßtes das hier nicht das richtige für dich sein: Framework 4.0 für XP 32 Bit, jedoch steht da mit Service Pack 3:
http://www.microsoft.com/downloads/...bd-25c1-4fc0-919f-b21f31ab88b7&displaylang=de
http://www.microsoft.com/downloads/...bd-25c1-4fc0-919f-b21f31ab88b7&displaylang=de
Hallo Sebastian,
i have a question about the Requester you´ve use in SNS-HDR (i´ve use the Pro version and has Updated it on my Laptop (Win 7 64 Bit) and my PC (Win 7 32 Bit). On my Laptop it works fine, but on my PC i see only the Requesters with the Text and 3 Pixels high the upper part of the Button´s but nothing more - this was at the first version and the update don´t correct this bug.
It´s not real a problem, because i know most times what SNS from me want, because i know the complete Requesters from the Laptop, but if the bug is correct, i´m not realy afraid...
Your sincerly Digibike
i have a question about the Requester you´ve use in SNS-HDR (i´ve use the Pro version and has Updated it on my Laptop (Win 7 64 Bit) and my PC (Win 7 32 Bit). On my Laptop it works fine, but on my PC i see only the Requesters with the Text and 3 Pixels high the upper part of the Button´s but nothing more - this was at the first version and the update don´t correct this bug.
It´s not real a problem, because i know most times what SNS from me want, because i know the complete Requesters from the Laptop, but if the bug is correct, i´m not realy afraid...
Your sincerly Digibike
WERBUNG