-
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 ... -
DSLR-Forum Fotowettbewerb neu erfunden!
Nach wochenlanger intensiver Arbeit an der Erneuerung des Formates unseres internen Fotowettbewerbes ist es Frosty als Moderator
und au lait als Programmierer gelungen, unseren Wettbewerb auf ein völlig neues Level zu heben!
Lest hier alle Infos zum DSLR-Forum Fotowettbewerb 2.0
Einen voll funktionsfähigen Demowettbewerb kannst du dir hier ansehen. -
Neuer Partner: AkkuShop.de
Akkus, Ladegeräte und mehr (nicht nur) für Digitalkameras und Drohnen
-
Neuer Gutscheincode unseres Partners Schutzfolien24:
DSLR-Forum2024
Dauerhaft 10% Rabatt auf alle Displayschutzfolien der Eigenmarken "Upscreen", "Brotec", "Savvies".
Der Code ist für alle Geräteklassen gültig. -
Stimmt ab über die Sieger des DSLR-Forum Fotowettbewerbs April 2024.
Thema: "Sprichwörtlich"
Nur noch bis zum 30.04.2024 23:59!
Jeder darf abstimmen!
Zur Abstimmung und Bewertung hier lang
WERBUNG
Neue Freeware: Picturenaut / HDRI-Generator und Tonemapper
- Themenersteller Ectoplasma
- Erstellt am
Ectoplasma
Themenersteller
AW: Neue Freeware: HDRI-Generator und Tonemapper
Jupp, ich weiß *gg*. Liegt meist am RAW-Konverter. Werte dieser Art werden vom MKHDRI als nicht gültig ausgefiltert. Manchmal steht dort aber auch etwas sinnvolles drin.
Mit dem Bias ist in der Tat die EV-Einstellung gemeint. Erwähnte ich das nicht? Öhm, Schande über mich.
Ganz genau das meine ich. Sorry, wenn ich das schlecht erklärt habe. In MKHDRI kann man die Zeit und Blende nur dann expliziet angeben, wenn diese in den EXIFs fehlen. Einen EV-Wert, kann man aber mit dem besagten Schalter -ab angeben, um den Belichtungsunterschied einstellen zu können, wenn man mehrere Ausbelichtungen aus einem RAW gemacht hat. Es sei denn, der RAW-Konverter hat das schon für einen erledigt. Wüßte aber nicht, welcher das jetzt macht.
Viele Grüße
Marc
CamBoy schrieb:
Jupp, ich weiß *gg*. Liegt meist am RAW-Konverter. Werte dieser Art werden vom MKHDRI als nicht gültig ausgefiltert. Manchmal steht dort aber auch etwas sinnvolles drin.
CamBoy schrieb:
Mit dem Bias ist in der Tat die EV-Einstellung gemeint. Erwähnte ich das nicht? Öhm, Schande über mich.
CamBoy schrieb:
Ganz genau das meine ich. Sorry, wenn ich das schlecht erklärt habe. In MKHDRI kann man die Zeit und Blende nur dann expliziet angeben, wenn diese in den EXIFs fehlen. Einen EV-Wert, kann man aber mit dem besagten Schalter -ab angeben, um den Belichtungsunterschied einstellen zu können, wenn man mehrere Ausbelichtungen aus einem RAW gemacht hat. Es sei denn, der RAW-Konverter hat das schon für einen erledigt. Wüßte aber nicht, welcher das jetzt macht.
Viele Grüße
Marc
Ectoplasma
Themenersteller
AW: Neue Freeware: HDRI-Generator und Tonemapper
Das habe ich mich auch gefragt. Es könnte aber sein, dass bei bestimmten Bildmaterial, der Algorithmus versagt, wenn z.B. sehr viel Rauschen im Bildmaterial ist. Es könnte aber auch ein anderes Problem sein. MKHDRI sortiert die Bilder nach Belichtung und aligned immer paare, die belichtungsmäßig, dicht beieinander liegen. Wenn nun in den EXIFs immer das gleiche steht, dann ist Sortierung der Bilder undefiniert. MKHDRI könnte dadurch versucht haben, zwei Bilder, die belichtungstechnisch sehr weit auseinander liegen, zu alignen. Und das ist wahrscheinlich fehlgeschalgen. Ich glaube ich baue mal eine Erweiterung ein, die den Benutzter warnt, wenn die EXIF Infos identisch sind oder die Belichtung zu dicht ist. Am besten werden HDRIs, wenn die einzelnen Bilder mindestens 1 EV auseinander liegen.
Viele Grüße
Marc
cody29 schrieb:dann doch aber komisch, dass mkhdri versucht durch die Option -a Deine Bilder zu "alignen". Da die Bilder aus einem RAW kommen, müssten die doch deckungsgleich sein
Das habe ich mich auch gefragt. Es könnte aber sein, dass bei bestimmten Bildmaterial, der Algorithmus versagt, wenn z.B. sehr viel Rauschen im Bildmaterial ist. Es könnte aber auch ein anderes Problem sein. MKHDRI sortiert die Bilder nach Belichtung und aligned immer paare, die belichtungsmäßig, dicht beieinander liegen. Wenn nun in den EXIFs immer das gleiche steht, dann ist Sortierung der Bilder undefiniert. MKHDRI könnte dadurch versucht haben, zwei Bilder, die belichtungstechnisch sehr weit auseinander liegen, zu alignen. Und das ist wahrscheinlich fehlgeschalgen. Ich glaube ich baue mal eine Erweiterung ein, die den Benutzter warnt, wenn die EXIF Infos identisch sind oder die Belichtung zu dicht ist. Am besten werden HDRIs, wenn die einzelnen Bilder mindestens 1 EV auseinander liegen.
Viele Grüße
Marc
AW: Neue Freeware: HDRI-Generator und Tonemapper
Also würde es nichts nützen, wenn ich unterschiedliche Belichtungen mit unterschiedlicher Belichtungszeit habe, da dein Programm nicht danach erkennt? (alle anderen tun dies aber, soweit ich weiß, nach dieser Methode)
Vielleicht hatte ich deswegen damals nicht so gute Ergebnisse mit den alten Versionen die ich getestet habe.
Wie muss ich den (auf welchen Wert) Exposure Bias ändern, damit dein Programm erkennt, das ich unterschiedliche Belichtungszeiten habe. (also z.B. -2, 0 +2)
Alle anderen Programme die ich kenne, erkennen automatisch aus der unterschiedlichen Belichtungszeit (z.B 1/800s, 1/200s, 1/50s) die entsprechenden unterschiedlichen EV Belichtungen...
Oder meinen wir das selbe und reden die ganze Zeit nur aneinander vorbei?
Ectoplasma schrieb:
Also würde es nichts nützen, wenn ich unterschiedliche Belichtungen mit unterschiedlicher Belichtungszeit habe, da dein Programm nicht danach erkennt? (alle anderen tun dies aber, soweit ich weiß, nach dieser Methode)
Vielleicht hatte ich deswegen damals nicht so gute Ergebnisse mit den alten Versionen die ich getestet habe.
Wie muss ich den (auf welchen Wert) Exposure Bias ändern, damit dein Programm erkennt, das ich unterschiedliche Belichtungszeiten habe. (also z.B. -2, 0 +2)
Alle anderen Programme die ich kenne, erkennen automatisch aus der unterschiedlichen Belichtungszeit (z.B 1/800s, 1/200s, 1/50s) die entsprechenden unterschiedlichen EV Belichtungen...
Oder meinen wir das selbe und reden die ganze Zeit nur aneinander vorbei?
Ectoplasma
Themenersteller
AW: Neue Freeware: HDRI-Generator und Tonemapper
Doch CamBoy, natürlich erkennt mein Programm das.
Nochmal ganz von vorne *gg*. Wenn du mit einem RAW Konverter, mehrere Ausbelichtungen, mit sagen wir -2EV, 0EV und +2EV, aus EIN UND DEM SELBEN RAW machst, dann sind die Bilder ja unterschiedlich hell ausbelichtet vom RAW-Konverter. Einige RAW-Konverter, wie z.B. die von Canon, lassen die EXIF Informationen dabei unangetastet. Für mein Programm sieht es jetzt so aus, als seien alle Bilder gleich belichtet. Der RAW-Konverter müßte aber in das EXIF-Feld "Bias", die Werte -2, 0, und +2 hineinschreiben, damit mein Programm weiß, welche Belichtung die Bilder haben. Weil aber einige RAW-Konverter das wie gesagt nicht machen, kann man die EV-Werte mit MKHDRI auch von Hand eingeben und muss dies in so einem Fall sogar.
Anders sieht das bei Belichtungsreihen aus, die wirklich aus unterschiedlichen Bildern stammen. Hier werden Blende und Zeit einfach ausgewertet. Und diese sind bei einer "echten" Belichtungsreihe, in jedem Fall unterschiedlich. Da muss der Anwender nichts machen.
Das hängt mit dem oben genannten Problem nicht zusammen ;-)
Wir reden definitiv aneinander vorbei. Ich hoffe ich konnte mit der obigen Erklärung ein wenig Licht ins Dunkel bringen.
Noch ein paar mehr Infos zur Klärung.
Also, mein Programm erkennt nicht von sich aus, wie hell oder dunkel ein Bild ist. Es erkennt die Belichtung nur an den EXIF Informationen. Oder wenn diese nicht vorhanden sind, an dem, was der Benutzer vorgibt. Die Belichtung setzt sich aus mehreren Parametern zusammen. Blende, Zeit und einem Exposure Bias, bekannt auch als Exposure Value (EV liegt meist im Bereich +/-2).
Gerade das Exposure Bias Feld in den EXIFs, wird von einigen RAW-Konvertern lausig gepflegt. Das geht soweit, dass dort machmal unsinnige Werte stehen, die MKHDRI aber ausfiltert. Ich hatte auch schon eine Testbelichtungsreihe von einem FC Member, wo bei einem Bild, genau ein Bias von -2 eingestellt war. Würde MKHDRI dieses Feld nicht auswerten, könnte man solche Belichtungsreihen nicht zusammenrechnen. Das könnten andere Programme auch nicht. Bei der beliebten Mehrfachausbelichtung aus einem RAW, tritt das besagte Problem auf, dass die EXIF-Infos, nicht korriegiert wirden. Ein RAW Konverter könnte natürlich das Feld Blende oder Zeit Pflegen, dass tun sie aber auch nicht. Ergo, MKHDRI erkennt nur, dass alle drei Ausbelichtungen, die selbe Belichtung haben, was ja aber nicht mehr stimmt. Deshalb der besagte Schalter -ab, um die Belichtungsunterschiede von Hand eingeben zu können. Genau so gut könnte ich auch einen Schalter spendieren, mit dem du nachträglich die Blende oder die Zeit ändern könntest. Das Ergebnis wäre das Gleiche.
Viele Grüße
Marc
CamBoy schrieb:
Doch CamBoy, natürlich erkennt mein Programm das.
Nochmal ganz von vorne *gg*. Wenn du mit einem RAW Konverter, mehrere Ausbelichtungen, mit sagen wir -2EV, 0EV und +2EV, aus EIN UND DEM SELBEN RAW machst, dann sind die Bilder ja unterschiedlich hell ausbelichtet vom RAW-Konverter. Einige RAW-Konverter, wie z.B. die von Canon, lassen die EXIF Informationen dabei unangetastet. Für mein Programm sieht es jetzt so aus, als seien alle Bilder gleich belichtet. Der RAW-Konverter müßte aber in das EXIF-Feld "Bias", die Werte -2, 0, und +2 hineinschreiben, damit mein Programm weiß, welche Belichtung die Bilder haben. Weil aber einige RAW-Konverter das wie gesagt nicht machen, kann man die EV-Werte mit MKHDRI auch von Hand eingeben und muss dies in so einem Fall sogar.
Anders sieht das bei Belichtungsreihen aus, die wirklich aus unterschiedlichen Bildern stammen. Hier werden Blende und Zeit einfach ausgewertet. Und diese sind bei einer "echten" Belichtungsreihe, in jedem Fall unterschiedlich. Da muss der Anwender nichts machen.
CamBoy schrieb:
Das hängt mit dem oben genannten Problem nicht zusammen ;-)
CamBoy schrieb:
Wir reden definitiv aneinander vorbei. Ich hoffe ich konnte mit der obigen Erklärung ein wenig Licht ins Dunkel bringen.
Noch ein paar mehr Infos zur Klärung.
Also, mein Programm erkennt nicht von sich aus, wie hell oder dunkel ein Bild ist. Es erkennt die Belichtung nur an den EXIF Informationen. Oder wenn diese nicht vorhanden sind, an dem, was der Benutzer vorgibt. Die Belichtung setzt sich aus mehreren Parametern zusammen. Blende, Zeit und einem Exposure Bias, bekannt auch als Exposure Value (EV liegt meist im Bereich +/-2).
Gerade das Exposure Bias Feld in den EXIFs, wird von einigen RAW-Konvertern lausig gepflegt. Das geht soweit, dass dort machmal unsinnige Werte stehen, die MKHDRI aber ausfiltert. Ich hatte auch schon eine Testbelichtungsreihe von einem FC Member, wo bei einem Bild, genau ein Bias von -2 eingestellt war. Würde MKHDRI dieses Feld nicht auswerten, könnte man solche Belichtungsreihen nicht zusammenrechnen. Das könnten andere Programme auch nicht. Bei der beliebten Mehrfachausbelichtung aus einem RAW, tritt das besagte Problem auf, dass die EXIF-Infos, nicht korriegiert wirden. Ein RAW Konverter könnte natürlich das Feld Blende oder Zeit Pflegen, dass tun sie aber auch nicht. Ergo, MKHDRI erkennt nur, dass alle drei Ausbelichtungen, die selbe Belichtung haben, was ja aber nicht mehr stimmt. Deshalb der besagte Schalter -ab, um die Belichtungsunterschiede von Hand eingeben zu können. Genau so gut könnte ich auch einen Schalter spendieren, mit dem du nachträglich die Blende oder die Zeit ändern könntest. Das Ergebnis wäre das Gleiche.
Viele Grüße
Marc
Gast_2756
Guest
AW: Neue Freeware: HDRI-Generator und Tonemapper
geil geil
geil geilAW: Neue Freeware: HDRI-Generator und Tonemapper
so, jetzt habe ich es endlich geschafft...
zum Rauschproblem:
mit einer Änderung der Belichtung habe ich das Problem nicht richtig lösen können, erst ein Wert ab e:-4 hat das Rauschen vermindert, dann war das Bild aber auch schon sehr dunkel. Statt dessen habe ich den Parameter -nl: auf 0,04 angehoben, dann läuft es schon deutlich besser. Oder ist der Parameter zu hoch angesetzt?
Zum anderen Thema:
da habe ich heute nachmittag Blödsinn erzählt
Es lag tatsächlich am Schalter -a der die Fehlermeldung brachte. (Dabei war ich mir ziemlich sicher, dass es ohne -a auch die Fehlermeldung gab, aber wie das so mal ist, wenn man sich 100% sicher ist )
Aber damit Du den Fehler besser beheben kannst, habe ich mal drei Beispielbilder angehängt. Mit allen dreien und der Option -a kommt der Fehler, läßt man IMG_0249.jpg weg, läuft es auch sauber durch. Hoffe, Du kannst damit testen. Sind crops damit ich die Bilder hier ablegen kann. Verkleinere ich die Bilder tritt ebenfalls kein Fehler auf (dann sind die Bilder wahrscheinlich ausreichend deckungsgleich).
so, jetzt habe ich es endlich geschafft...
zum Rauschproblem:
mit einer Änderung der Belichtung habe ich das Problem nicht richtig lösen können, erst ein Wert ab e:-4 hat das Rauschen vermindert, dann war das Bild aber auch schon sehr dunkel. Statt dessen habe ich den Parameter -nl: auf 0,04 angehoben, dann läuft es schon deutlich besser. Oder ist der Parameter zu hoch angesetzt?
Zum anderen Thema:
da habe ich heute nachmittag Blödsinn erzählt
Es lag tatsächlich am Schalter -a der die Fehlermeldung brachte. (Dabei war ich mir ziemlich sicher, dass es ohne -a auch die Fehlermeldung gab, aber wie das so mal ist, wenn man sich 100% sicher ist
)Aber damit Du den Fehler besser beheben kannst, habe ich mal drei Beispielbilder angehängt. Mit allen dreien und der Option -a kommt der Fehler, läßt man IMG_0249.jpg weg, läuft es auch sauber durch. Hoffe, Du kannst damit testen. Sind crops damit ich die Bilder hier ablegen kann. Verkleinere ich die Bilder tritt ebenfalls kein Fehler auf (dann sind die Bilder wahrscheinlich ausreichend deckungsgleich).
Ectoplasma
Themenersteller
AW: Neue Freeware: HDRI-Generator und Tonemapper
Ist ok ein Wert von 0,04. Viel höher würde ich aber auch nicht gehen.
Danke für die JPEGs! Das ist gut, so kann ich den Fehler schneller finden.
Ich melde mich dann morgen wieder.
Viele Grüße
Marc
EDIT:
Neue gefixte Version bereits online ;-)
cody29 schrieb:
Ist ok ein Wert von 0,04. Viel höher würde ich aber auch nicht gehen.
Danke für die JPEGs! Das ist gut, so kann ich den Fehler schneller finden.
Ich melde mich dann morgen wieder.
Viele Grüße
Marc
EDIT:
Neue gefixte Version bereits online ;-)
Zuletzt bearbeitet:
AW: Neue Freeware: HDRI-Generator und Tonemapper
Oki, ist klar... Das ich beim RAW Konvertieren immer die selben Belichtungsdaten erhalte, ist mir bekannt gewesen, aber das ist ja zum Glück nicht mein Problem.
Macht es jetzt Sinn, hier außer dem Ändern von der Belichtungszeit auch den Bias zu ändern? Sprich das normale Bild mit der EV0 Belichtung auch den Exposure Bias 0 eintragen und bei dem + 2EV dementsprechend +2 oder bei -2EV auch -2?
Ich meine letztendlich ist es ja egal, da ich die Zeit verändere und es nicht unbedingt bräuchte, aber interessant wäre es auf jeden Fall mal...
Also nochmal kurz gefasst, könnte ich den Exposure Bias bei meinem EXIF auf 0 stellen, statt der immer angegebenen 4294966.92? (bei 0EV) Und entsprechend auf + oder - 2 bei den anderen Belichtungen?
Naja, ich werde mal den genauen Test machen, wenn du die Oberfläche fertig hast. Kann auch gerne als Beta Tester dienen, E-Mail müsstest du ja noch haben. Mal schauen ob du deinen größten Konkurrenten (wir hatten es ja mal davon) schlägst, ich hoffe ja!
(Wie ich mittlerweile herausgefunden habe kam das Rauschen damals hauptsächlich von der RAW + 2EV Nachbelichtung, da hier auch das Rauschen ansteigt. Also quasi von ISO 100 auf ISO 400) Leider hat man nicht immer ein Stativ dabei und dieser Ergebnisse aus einem RAW sind auch um Welten besser, als nur eine normale Belichtung...
Hoffentlich klappt's bald mit der Oberfläche, ich wünsche dir viel Erfolg!
Ectoplasma schrieb:
Oki, ist klar... Das ich beim RAW Konvertieren immer die selben Belichtungsdaten erhalte, ist mir bekannt gewesen, aber das ist ja zum Glück nicht mein Problem.
Macht es jetzt Sinn, hier außer dem Ändern von der Belichtungszeit auch den Bias zu ändern? Sprich das normale Bild mit der EV0 Belichtung auch den Exposure Bias 0 eintragen und bei dem + 2EV dementsprechend +2 oder bei -2EV auch -2?
Ich meine letztendlich ist es ja egal, da ich die Zeit verändere und es nicht unbedingt bräuchte, aber interessant wäre es auf jeden Fall mal...
Also nochmal kurz gefasst, könnte ich den Exposure Bias bei meinem EXIF auf 0 stellen, statt der immer angegebenen 4294966.92? (bei 0EV) Und entsprechend auf + oder - 2 bei den anderen Belichtungen?
Naja, ich werde mal den genauen Test machen, wenn du die Oberfläche fertig hast. Kann auch gerne als Beta Tester dienen, E-Mail müsstest du ja noch haben. Mal schauen ob du deinen größten Konkurrenten (wir hatten es ja mal davon) schlägst, ich hoffe ja!
(Wie ich mittlerweile herausgefunden habe kam das Rauschen damals hauptsächlich von der RAW + 2EV Nachbelichtung, da hier auch das Rauschen ansteigt. Also quasi von ISO 100 auf ISO 400) Leider hat man nicht immer ein Stativ dabei und dieser Ergebnisse aus einem RAW sind auch um Welten besser, als nur eine normale Belichtung...
Hoffentlich klappt's bald mit der Oberfläche, ich wünsche dir viel Erfolg!
Ectoplasma
Themenersteller
AW: Neue Freeware: HDRI-Generator und Tonemapper
Wobei macht jetzt was Sinn? *gg*.
Nicht das wir uns jetzt mißverstehen, aber du änderst entweder die Zeit oder den Bias, aber sicherlich nicht beides, falls du die Ausbelichtung aus einem RAW meinst ;-)
Absolut korrekt!
Wenn du, wie schon gesagt, die Belichtungszeit veränderst, dann ändere nicht mehr den Exposure - Bias.
Das kannst du so machen, bei Ausbelichtungen aus einem RAW, mußt es aber nicht unbedingt, da es ja wie gesagt den Schalter -ab in MKHDRI gibt. Aber deine Idee mit dem direkten Ändern der Bias-Daten in den EXIFs, funktioniert natürlich auch. Nur dann bitte nicht mehr die Zeit ändern. Dass wäre ja sonst eine mehrfach korrigierte Belichtung und somit falsch. Die Formel die MKHDRI für die Belichtung benutzt, steht ja schon in einem meiner vorherigen Posts.
Danke, danke, mit dem schlagen der Konkurrenz, werden wir mal sehen *gg*.
Jupp, dass ist ein grundsätzliches Problem. In den unteren 4-Bits eines RAWs, rauscht es ziemlich stark. Ich persönlich halte daher auch nicht sonderlich viel von der Methode der Mehrfachsubelichtung, wenn du nicht gerade eine gute Rauschfilter-Software dein eigen nennst. Wir hatten das Thema schon einmal. Im Grunde bräuchte man ein RAW auch nicht mehrfach ausbelichten. Wenn man einen RAW-Konverter hat, der ein RAW in ein 16-Bit linear TIFF umwandelen kann, dann bräuchte man so ein TIFF nur in ein HDRI umwandeln durch einen Tonemapper schicken und feritg. Dauert keine 1 Minute. Das ist auch eine Funktion, die MKHDRI noch fehlt.
Danke CamBoy, ich werde mir Mühe geben. Grafische Oberflächen bauen, ist oft leider zeitintensiver, als die eigentliche Funktionalität einer Software zu implementieren.
Viele Grüße
Marc
CamBoy schrieb:
Wobei macht jetzt was Sinn? *gg*.
Nicht das wir uns jetzt mißverstehen, aber du änderst entweder die Zeit oder den Bias, aber sicherlich nicht beides, falls du die Ausbelichtung aus einem RAW meinst ;-)
CamBoy schrieb:
Absolut korrekt!
CamBoy schrieb:
Wenn du, wie schon gesagt, die Belichtungszeit veränderst, dann ändere nicht mehr den Exposure - Bias.
CamBoy schrieb:
Das kannst du so machen, bei Ausbelichtungen aus einem RAW, mußt es aber nicht unbedingt, da es ja wie gesagt den Schalter -ab in MKHDRI gibt. Aber deine Idee mit dem direkten Ändern der Bias-Daten in den EXIFs, funktioniert natürlich auch. Nur dann bitte nicht mehr die Zeit ändern. Dass wäre ja sonst eine mehrfach korrigierte Belichtung und somit falsch. Die Formel die MKHDRI für die Belichtung benutzt, steht ja schon in einem meiner vorherigen Posts.
CamBoy schrieb:
Danke, danke, mit dem schlagen der Konkurrenz, werden wir mal sehen *gg*.
CamBoy schrieb:
Jupp, dass ist ein grundsätzliches Problem. In den unteren 4-Bits eines RAWs, rauscht es ziemlich stark. Ich persönlich halte daher auch nicht sonderlich viel von der Methode der Mehrfachsubelichtung, wenn du nicht gerade eine gute Rauschfilter-Software dein eigen nennst. Wir hatten das Thema schon einmal. Im Grunde bräuchte man ein RAW auch nicht mehrfach ausbelichten. Wenn man einen RAW-Konverter hat, der ein RAW in ein 16-Bit linear TIFF umwandelen kann, dann bräuchte man so ein TIFF nur in ein HDRI umwandeln durch einen Tonemapper schicken und feritg. Dauert keine 1 Minute. Das ist auch eine Funktion, die MKHDRI noch fehlt.
CamBoy schrieb:
Danke CamBoy, ich werde mir Mühe geben. Grafische Oberflächen bauen, ist oft leider zeitintensiver, als die eigentliche Funktionalität einer Software zu implementieren.
Viele Grüße
Marc
AW: Neue Freeware: HDRI-Generator und Tonemapper
Na dann ist ja alles klar, ich ändere nur noch (wie immer) die Belichtungszeit in den EXIF...
Das mit dem direkten RAW --> HDR wäre natürlich optimal, wobei halt auch zur Not der Umweg über 3 Tiffs geht...
Na dann schauen wir mal was uns der Weihnachtsmann vielleicht von dir bringt...
Ectoplasma schrieb:
Na dann ist ja alles klar, ich ändere nur noch (wie immer) die Belichtungszeit in den EXIF...
Das mit dem direkten RAW --> HDR wäre natürlich optimal, wobei halt auch zur Not der Umweg über 3 Tiffs geht...
Na dann schauen wir mal was uns der Weihnachtsmann vielleicht von dir bringt...
AW: Neue Freeware: HDRI-Generator und Tonemapper
eine Frage dazu noch: Wenn ich die EV-Werte händisch angebe, dann müssen die Bilder aber doch in der richtigen Reihenfolge geladen werden, oder?
Viele Grüße
Franklin
Hallo Marc,Ectoplasma schrieb:
eine Frage dazu noch: Wenn ich die EV-Werte händisch angebe, dann müssen die Bilder aber doch in der richtigen Reihenfolge geladen werden, oder?
Viele Grüße
Franklin
AW: Neue Freeware: HDRI-Generator und Tonemapper
Er fragt die Werte einzeln ab... wenn Du also 4 Bilder in beliebiger Reihenfolge reinsteckst, gibt er den Bildnamen aus und fragt dazu den ev Wert ab. Und das halt 4 mal. Reihenfolge ist also egal solang du weißt, welches Bild welchen EV Wert hat.
Franklin2K schrieb:
Er fragt die Werte einzeln ab... wenn Du also 4 Bilder in beliebiger Reihenfolge reinsteckst, gibt er den Bildnamen aus und fragt dazu den ev Wert ab. Und das halt 4 mal. Reihenfolge ist also egal solang du weißt, welches Bild welchen EV Wert hat.
AW: Neue Freeware: HDRI-Generator und Tonemapper
Hat jemand schonmal einen Vergleich mit einem "normalen" DRI gemacht?
Viele Grüße
Franklin
Prima. Danke Dir, ich werde nir das Tool mal anschauen.cody29 schrieb:
Hat jemand schonmal einen Vergleich mit einem "normalen" DRI gemacht?
Viele Grüße
Franklin
Dokumentation zu HDRI-Generator und Tonemapper
ich habe die textdateien tutorial, credits und lizenz in einem dokument zusammengefasst, umgestaltet, mit links versehen und ein pdf daraus erstellt. würde es gerne hier hochladen (sofern von "Ectoplasma" genehmigt und erwünscht). die datei ist aber leider zu gross. besteht da eine andere möglichkeit?
btw: @Ectoplasma: willst du dir das dokument zuerst selbst ansehen?
ich habe die textdateien tutorial, credits und lizenz in einem dokument zusammengefasst, umgestaltet, mit links versehen und ein pdf daraus erstellt. würde es gerne hier hochladen (sofern von "Ectoplasma" genehmigt und erwünscht). die datei ist aber leider zu gross. besteht da eine andere möglichkeit?
btw: @Ectoplasma: willst du dir das dokument zuerst selbst ansehen?
AW: Neue Freeware: HDRI-Generator und Tonemapper
Habe vorher DRI mit dem Image Stacker gemacht. Bei mkhdri hat man ein bischen mehr Einfluss auf den Vorgang über die verschiedenen Schalter und Parameter, die man übergeben kann (wobei ich noch nicht alle ausprobiert und schon gar nicht alle verstanden habe). Während beim Image Stacker alle Bildwerte addiert werden und nach linear auf 16Bit skaliert werden, benutzt mkhdri beim Umwandeln in 16bit nichtlineare "Kurvenwerte".
Die Ergebnisse mit mkhdri sehen für mich besser aus, direkt verglichen habe ich sie aber nicht.
Hoffe, ich erzähle da keinen Quatsch über mkhdri und Image Stacker.
Manuell habe ich mit Gimp mal versucht DRIs herzustellen, dies ging aber mangels richtiger Parameter mehr oder weniger in die Hose.
Franklin2K schrieb:
Habe vorher DRI mit dem Image Stacker gemacht. Bei mkhdri hat man ein bischen mehr Einfluss auf den Vorgang über die verschiedenen Schalter und Parameter, die man übergeben kann (wobei ich noch nicht alle ausprobiert und schon gar nicht alle verstanden habe). Während beim Image Stacker alle Bildwerte addiert werden und nach linear auf 16Bit skaliert werden, benutzt mkhdri beim Umwandeln in 16bit nichtlineare "Kurvenwerte".
Die Ergebnisse mit mkhdri sehen für mich besser aus, direkt verglichen habe ich sie aber nicht.
Hoffe, ich erzähle da keinen Quatsch über mkhdri und Image Stacker.
Manuell habe ich mit Gimp mal versucht DRIs herzustellen, dies ging aber mangels richtiger Parameter mehr oder weniger in die Hose.
Ectoplasma
Themenersteller
AW: Dokumentation zu HDRI-Generator und Tonemapper
Prima Arbeit. Ich selbst habe prinzipiell nichts dagegen einzuwenden. Interessanter wäre eher zu wissen, was die Moderatoren dazu sagen. Du kannst mir ja ein Exemplar an ectoplasma1@gmx.de schicken. Danke schonmal. Ich schaue mir das gerne mal an.
MKHDRI macht es etwas anders.
Kleiner Exkurs in Sachen HDRI.
1. Ein HDRI ist per Definition linear, hat also keine Gammakorrektur.
2. Ein HDRI kann einen hohen Kontrastumfang speichern. Dieser entspricht meist dem, was das menschliche Auge erfassen kann. Daher benutzt ein HDRI meist 32-Bit Fließkommawerte für die Farbkanäle, um sowohl eine hohe Farbauflösung, als auch eine hohen Dynamikumfang speichern zu können.
3. SEHR SEHR WICHTIG!!! Ein HDRI kann NICHT! auf einem PC-Monitor dargestellt werden, da ein PC-Monitor oder Drucker diesen Kontrastumfang nicht bieten. Das geht erst mit einem Laser-Projektor (und einer Sonnenbrille *gg*). Manche behaupten, ein HDRI sähe kontrastarm aus und hätte wenig Farbauflösung. Das ist blanker Unsinn. Zudem behaupte ich mal, dass die wenigsten Menschen auf der Welt, je ein HDRI mit einem Laserprojektor betrachten konnten. Das, was man auf einem PC-Monitor bei einem echten HDRI sieht, ist nur ein magerer Belichtungsausschnitt. Der sieht in der Tat nicht gut aus.
Wie erstellt MKHDRI nun ein HDRI?
Zunächst versucht das Programm aus den Bildern der Belichtungsreihe die inverse Kammerakurve zu ermitteln. Invers deshalb, damit man die Bilder der Belichtungsreihe linearisieren kann. Sind die Bilder linear, dann müssen sie erst noch Belichtungsmäßig aneinander angeglichen werden. Erst dann wird pro Pixel über alle Bilder ein Mittelwert gebildet, wobei die Pixel noch gewichtet werden und zwar so, dass ein Pixel mit einem höheren Rauchsch/Signal - Verhältnis mehr Gewicht bekommt. Dieser Vorgang funktioniert übrigens nur dann, wenn die Bilder linear sind, was MKHDRI im vorherigen Schritt ja erledigt. Die Vorgänge sind allerdings im Detail viel komplexer, als ich sie hier eben nur grob geschildert habe. Das Ergebnis ist jedenfalls das oben beschriebene HDRI (in 32-Bit Fließkomma).
Und nun? Was soll man jetzt damit, wenn man es gar nicht darstellen kann, bzw. nur einen mehr oder weniger schönen Belichtungsausschnitt? Zunächst sei nochmal erwähnt, dass es auch andere Bereiche gibt, die HDRIs nutzen, z.B. die Film- und Spieleindustrie. Aber das sei nur am Rande erwähnt.
Jetzt kommt der für Fotografen allerwichtigste Schritt.
DAS TONEMAPPING.
Dieses Wort vermisse ich leider jedes Mal in einer Diskussion über HDRIs. Tonemapper sind Programme, die die hohen Kontrastwerte eines HDRIs so komprimieren, dass sie wieder mit einem PC-Monitor dargstellt werden können. Tonemapper sind relativ neu. Tonemapper muß man zukünftig immer auf der Rechnung haben. Es ist unwahrscheinlich, dass sich der Wiedergabekontrast von Monitoren steigern wird. Hingegen werden die CCDs von Kameras immer besser und dem muss man mit geeigneter Software Rechnung tragen, damit man die gespeicherten Informationen, dementsprechend auf einem Drucker oder PC-Monitor darstellen kann.
In HDRI2LDRI ist ein Tonemapper eingebaut. Der Trick eines Tonemappers basiert auf folgender Beobachtung am menschlichen Auge. Es reagiert ziemlich unsensibel darauf, welcher Kontrastumfang wirklich vorhanden ist. Deshalb komprimert ein Tonemapper einfach starke Kontraste. Dem Auge ist es ziemlich egal, wie hoch dieser vorher war. Auf dem Bild, dass der Tonemapper ausgibt, erscheinen vormals überstrahlte Bereiche, auf einem PC-Monitor, plötzlich korrekt belichtet (allerdings auch nur dann, wenn es in der Belichtungsreihe ein Bild gab, dass die Lichter korrekt belichtet hatte). Es gibt zudem viel feinere Lichtabstufungen, als es bei den von Hand erstellten DRIs überhaupt möglich wäre. Allerdings gibt es auch Nachteile und diese sind unglücklicherweise davon abhängig, welcher Tonemapper verwendet wurde. So können z.B. kleinste Details im Bild verschwimmen, oder die Sättigung der Farben ändert sich. Letzteres ist aber leicht korriegierbar. Wie gesagt, Tonemapper stehen noch am Anfang ihrer Entwicklung.
HDRI2LDRI, kann als LDRIs, u.a. 16-Bit TIFFs erzeugen. Diese 16-Bit TIFFs haben übrigens keinen wesentlich höheren Dynamikumfang, als ein 8-Bit TIFF, sie haben aber eine wesentlich höhere Farbauflösung ;-)
Ich hoffe ich konnte einiges klären.
Mehr dazu und viel genauer, steht das alles in Blochis HDRI Handbuch, das ich im Tutorial von MKHDRI erwähne.
Im Anhang seht ihr noch ein LDRI, ... was sonst auch ;-) Die Quelle war aber natürlich ein HDRI. Das Bild im Anhang wurde nicht nachbearbeitet. Nur verkleinert, mit einem Lczos-Resample-Filter (IrfanView) und nicht nachgeschärft.
Viele Grüße
Marc
dionysos schrieb:
Prima Arbeit. Ich selbst habe prinzipiell nichts dagegen einzuwenden. Interessanter wäre eher zu wissen, was die Moderatoren dazu sagen. Du kannst mir ja ein Exemplar an ectoplasma1@gmx.de schicken. Danke schonmal. Ich schaue mir das gerne mal an.
cody29 schrieb:
MKHDRI macht es etwas anders.
Kleiner Exkurs in Sachen HDRI.
1. Ein HDRI ist per Definition linear, hat also keine Gammakorrektur.
2. Ein HDRI kann einen hohen Kontrastumfang speichern. Dieser entspricht meist dem, was das menschliche Auge erfassen kann. Daher benutzt ein HDRI meist 32-Bit Fließkommawerte für die Farbkanäle, um sowohl eine hohe Farbauflösung, als auch eine hohen Dynamikumfang speichern zu können.
3. SEHR SEHR WICHTIG!!! Ein HDRI kann NICHT! auf einem PC-Monitor dargestellt werden, da ein PC-Monitor oder Drucker diesen Kontrastumfang nicht bieten. Das geht erst mit einem Laser-Projektor (und einer Sonnenbrille *gg*). Manche behaupten, ein HDRI sähe kontrastarm aus und hätte wenig Farbauflösung. Das ist blanker Unsinn. Zudem behaupte ich mal, dass die wenigsten Menschen auf der Welt, je ein HDRI mit einem Laserprojektor betrachten konnten. Das, was man auf einem PC-Monitor bei einem echten HDRI sieht, ist nur ein magerer Belichtungsausschnitt. Der sieht in der Tat nicht gut aus.
Wie erstellt MKHDRI nun ein HDRI?
Zunächst versucht das Programm aus den Bildern der Belichtungsreihe die inverse Kammerakurve zu ermitteln. Invers deshalb, damit man die Bilder der Belichtungsreihe linearisieren kann. Sind die Bilder linear, dann müssen sie erst noch Belichtungsmäßig aneinander angeglichen werden. Erst dann wird pro Pixel über alle Bilder ein Mittelwert gebildet, wobei die Pixel noch gewichtet werden und zwar so, dass ein Pixel mit einem höheren Rauchsch/Signal - Verhältnis mehr Gewicht bekommt. Dieser Vorgang funktioniert übrigens nur dann, wenn die Bilder linear sind, was MKHDRI im vorherigen Schritt ja erledigt. Die Vorgänge sind allerdings im Detail viel komplexer, als ich sie hier eben nur grob geschildert habe. Das Ergebnis ist jedenfalls das oben beschriebene HDRI (in 32-Bit Fließkomma).
Und nun? Was soll man jetzt damit, wenn man es gar nicht darstellen kann, bzw. nur einen mehr oder weniger schönen Belichtungsausschnitt? Zunächst sei nochmal erwähnt, dass es auch andere Bereiche gibt, die HDRIs nutzen, z.B. die Film- und Spieleindustrie. Aber das sei nur am Rande erwähnt.
Jetzt kommt der für Fotografen allerwichtigste Schritt.
DAS TONEMAPPING.
Dieses Wort vermisse ich leider jedes Mal in einer Diskussion über HDRIs. Tonemapper sind Programme, die die hohen Kontrastwerte eines HDRIs so komprimieren, dass sie wieder mit einem PC-Monitor dargstellt werden können. Tonemapper sind relativ neu. Tonemapper muß man zukünftig immer auf der Rechnung haben. Es ist unwahrscheinlich, dass sich der Wiedergabekontrast von Monitoren steigern wird. Hingegen werden die CCDs von Kameras immer besser und dem muss man mit geeigneter Software Rechnung tragen, damit man die gespeicherten Informationen, dementsprechend auf einem Drucker oder PC-Monitor darstellen kann.
In HDRI2LDRI ist ein Tonemapper eingebaut. Der Trick eines Tonemappers basiert auf folgender Beobachtung am menschlichen Auge. Es reagiert ziemlich unsensibel darauf, welcher Kontrastumfang wirklich vorhanden ist. Deshalb komprimert ein Tonemapper einfach starke Kontraste. Dem Auge ist es ziemlich egal, wie hoch dieser vorher war. Auf dem Bild, dass der Tonemapper ausgibt, erscheinen vormals überstrahlte Bereiche, auf einem PC-Monitor, plötzlich korrekt belichtet (allerdings auch nur dann, wenn es in der Belichtungsreihe ein Bild gab, dass die Lichter korrekt belichtet hatte). Es gibt zudem viel feinere Lichtabstufungen, als es bei den von Hand erstellten DRIs überhaupt möglich wäre. Allerdings gibt es auch Nachteile und diese sind unglücklicherweise davon abhängig, welcher Tonemapper verwendet wurde. So können z.B. kleinste Details im Bild verschwimmen, oder die Sättigung der Farben ändert sich. Letzteres ist aber leicht korriegierbar. Wie gesagt, Tonemapper stehen noch am Anfang ihrer Entwicklung.
HDRI2LDRI, kann als LDRIs, u.a. 16-Bit TIFFs erzeugen. Diese 16-Bit TIFFs haben übrigens keinen wesentlich höheren Dynamikumfang, als ein 8-Bit TIFF, sie haben aber eine wesentlich höhere Farbauflösung ;-)
Ich hoffe ich konnte einiges klären.
Mehr dazu und viel genauer, steht das alles in Blochis HDRI Handbuch, das ich im Tutorial von MKHDRI erwähne.
Im Anhang seht ihr noch ein LDRI, ... was sonst auch ;-) Die Quelle war aber natürlich ein HDRI. Das Bild im Anhang wurde nicht nachbearbeitet. Nur verkleinert, mit einem Lczos-Resample-Filter (IrfanView) und nicht nachgeschärft.
Viele Grüße
Marc
AW: Neue Freeware: HDRI-Generator und Tonemapper
So, habe mal ne kleinen und schnellen Vergleich aus einem RAW gemacht... (So hätte das Bild unveränderlich als JPEG ausgesehen, also auch ein weiteres Beispiel, für die Verwendung von RAW anstatt JPEG)
Ich habe hier mit Absicht mal ein wenig dunkel wirkendes Bild genommen, da hier der eigentliche Effekt oft größer ist, als bei den Lichtern. (wenn man nur eine RAW Datei nimmt / hat!) Bei einer richtigen Belichtungsreihe sieht das natürlich wieder etwas anders aus, leider hab ich gerade nix passendes da... Ist eh meist nur für Nachtaufnahmen und statischen Motiven interessant, aber eben nicht für normale bewegende Motiver aller Art, incl Sport. Muss bei Gelegenheit solch einen Vergleich nochmal mit einem RAW machen, das auch die Vorteile in den Highlights zeigt.
Wie gesagt, alle Bilder aus einem RAW mit jeweils 3 Endbildern (-2, 0, +2) in 16-Bit Tiff. Bei allen Programmen nur die jeweiligen Standarteinstellungen, also Bilder rein und Endergebnisse gespeichert, ohne irgendwelche sonstigen Parameter. (Verbesserungen durch Wahl der Parameter sind natürlich bestimmt möglich, würden aber solch einen einfachen Vergleich verfälschen...)
Zu den Bildern:
Original = 0EV Belichtung oder das Bild aus der Kamera (wie es auch als JPEG ausgesehen hätte)
MKHDRI = Programm von Ectoplasma
DRI = Normal bekannte DRI Methode ala Digi Achim und Varianten (hier wurde als hellstes Bild ein +1.4EV belichtetes Bild verwendet, da sich diese Methode von dem hellsten Bild beginnend aufbaut und so mehr auf Überbelichtungen / richtige Anfangsbelichtung geachtet werden muss...
IS = Programm Image Stacker
K = Die erwähnte Konkurrenz (wird nicht näher benannt!)
END = Endergebnis nach meiner persönlichen Bearbeitung (Geschmack ist ja immer verschieden, ich mag es gerne etwas farbenprächtiger...)
Es kann sich jeder selber mal ein Bild der Ergebnisse machen, ich denke das Programm von Marc schlägt sich sehr gut und ist durch den richtigen Einsatz der Paramerter durchaus noch zu Verbesserungen fähig. Einzig der helle Bereich bei den Bäumen (Zeichnung der Äste) oben links gefällt mir noch nicht so richtig, hier fehlen mir wohl die richtigen Einstellungen / Parameter.
Nun aber zu den Bilder...
So, habe mal ne kleinen und schnellen Vergleich aus einem RAW gemacht... (So hätte das Bild unveränderlich als JPEG ausgesehen, also auch ein weiteres Beispiel, für die Verwendung von RAW anstatt JPEG)
Ich habe hier mit Absicht mal ein wenig dunkel wirkendes Bild genommen, da hier der eigentliche Effekt oft größer ist, als bei den Lichtern. (wenn man nur eine RAW Datei nimmt / hat!) Bei einer richtigen Belichtungsreihe sieht das natürlich wieder etwas anders aus, leider hab ich gerade nix passendes da... Ist eh meist nur für Nachtaufnahmen und statischen Motiven interessant, aber eben nicht für normale bewegende Motiver aller Art, incl Sport. Muss bei Gelegenheit solch einen Vergleich nochmal mit einem RAW machen, das auch die Vorteile in den Highlights zeigt.
Wie gesagt, alle Bilder aus einem RAW mit jeweils 3 Endbildern (-2, 0, +2) in 16-Bit Tiff. Bei allen Programmen nur die jeweiligen Standarteinstellungen, also Bilder rein und Endergebnisse gespeichert, ohne irgendwelche sonstigen Parameter. (Verbesserungen durch Wahl der Parameter sind natürlich bestimmt möglich, würden aber solch einen einfachen Vergleich verfälschen...)
Zu den Bildern:
Original = 0EV Belichtung oder das Bild aus der Kamera (wie es auch als JPEG ausgesehen hätte)
MKHDRI = Programm von Ectoplasma
DRI = Normal bekannte DRI Methode ala Digi Achim und Varianten (hier wurde als hellstes Bild ein +1.4EV belichtetes Bild verwendet, da sich diese Methode von dem hellsten Bild beginnend aufbaut und so mehr auf Überbelichtungen / richtige Anfangsbelichtung geachtet werden muss...
IS = Programm Image Stacker
K = Die erwähnte Konkurrenz (wird nicht näher benannt!)
END = Endergebnis nach meiner persönlichen Bearbeitung (Geschmack ist ja immer verschieden, ich mag es gerne etwas farbenprächtiger...)
Es kann sich jeder selber mal ein Bild der Ergebnisse machen, ich denke das Programm von Marc schlägt sich sehr gut und ist durch den richtigen Einsatz der Paramerter durchaus noch zu Verbesserungen fähig. Einzig der helle Bereich bei den Bäumen (Zeichnung der Äste) oben links gefällt mir noch nicht so richtig, hier fehlen mir wohl die richtigen Einstellungen / Parameter.
Nun aber zu den Bilder...
Zuletzt bearbeitet:
WERBUNG