• Herzlich willkommen im "neuen" DSLR-Forum!

    Wir hoffen, dass Euch das neue Design und die neuen Features gefallen und Ihr Euch schnell zurechtfindet.
    Wir werden wohl alle etwas Zeit brauchen, um uns in die neue Umgebung einzuleben. Auch für uns ist das alles neu.

    Euer DSLR-Forum-Team

  • 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

AW: Neue Freeware: HDRI-Generator und Tonemapper

Danke CamBoy,

gute Arbeit. Für mich ist soetwas auch interessant zu sehen. Die Schwächen, die du bei dem Resultat mit meiner Software in den Standardeinstellungen ansprichst, sehe ich in jedem Fall genau so. Dieses Resultat ist das Ergebnis einer nicht ganz passenden Tonemapper - Konfiguration. Da kann ich aber nur sagen, abwarten *gg*.

Viele Grüße
Marc
 
AW: Dokumentation zu HDRI-Generator und Tonemapper

Ectoplasma schrieb:
...
MKHDRI macht es etwas anders.

Kleiner Exkurs in Sachen HDRI.
...

Schön, dass Du es noch mal richtig und ausführlich darstellst ;) Meine Ausführungen waren im Vergleich dazu doch etwas stümperhaft :D


Habe gestern noch mit einigen Parametern herumgespielt und dabei ist mir aufgefallen, dass bei hdri2ldri der Parameter -g anscheinend keinen Einfluss hat oder von mir nicht bemerkt worden ist.
Hatte ein HDRI mit g-Werten von 1, 2.2, 3.4 in 3 LDRIs umgewandelt. Beim Betrachten der Endprodukte habe ich keinen Unterschied feststellen können. Oder macht der Parameter nur in Verbindung mit Schalter -rg Sinn?
 
AW: Dokumentation zu HDRI-Generator und Tonemapper

cody29 schrieb:
Habe gestern noch mit einigen Parametern herumgespielt und dabei ist mir aufgefallen, dass bei hdri2ldri der Parameter -g anscheinend keinen Einfluss hat oder von mir nicht bemerkt worden ist.
Hatte ein HDRI mit g-Werten von 1, 2.2, 3.4 in 3 LDRIs umgewandelt. Beim Betrachten der Endprodukte habe ich keinen Unterschied feststellen können. Oder macht der Parameter nur in Verbindung mit Schalter -rg Sinn?

Das ist so. Man kann mit HDRI2LDRI verschiedene Kurvenformen angeben. Und zwar eine eigene, mit den Parametern -c oder -ic (das i für invers), eine Rec. 709 Gamma - Kurve mit dem Parameter -g und eine Standard - Gamma - Kurve, auch mit dem Parameter -g, wobei man mit dem Parameter -rg bestimmt, dass man eine Standard - Gamma - Kurve haben möchte.

Man schreibt also:

c:> hdri2ldri -g:2.4 .... <---- Rec. 709 Gamma - Kurve

oder

c:> hdri2ldri -g:2.4 -rg .... <---- Standard - Gamma - Kurve

Hinter dem Parameter -g:, kannst du einen beliebigen Wert schreiben.
Der Wert 1 würde eine lineare Kurve bedeuten ;-)

Gibt man den Parameter -g nicht an, wird standarmäßig ein Gamma von 2.2 angenommen.

Du hast wahrscheinlich den Parameter -ic, mit -g kombiniert. Die Parameter -c oder -ic, gewinnen vor dem Parameter -g. Eine Mischform beider Kurvenformen, gibt es nicht. Der Schalter -g hat dann keine Wirkung. Ich denke, ich sollte einen Hinweis bei dieser Schalterkombination ausgeben, dass -g keine Wirkung hat, wenn man bereits eine Custom - Curve mit -c oder -ic, angegeben hat.

Viele Grüße
Marc
 
AW: Neue Freeware: HDRI-Generator und Tonemapper

ok, dann habe ich den Schalter falsch angewendet :rolleyes:
vielleicht können dynoisos (hat das ja schon anscheinend aufbereitet), Du und ich das Tutorial noch erweitern bzw. vielleicht ein "Handbuch" verfassen ...
Meine Unterstützung hast du jedenfalls.
 
AW: Neue Freeware: HDRI-Generator und Tonemapper

ich werde die doku (PDF + Word) heute nachmittag oder abend an Ectoplasma senden.
 
AW: Neue Freeware: HDRI-Generator und Tonemapper

Leider bin ich absolut zu blöd dazu. Vielleicht kann mir jemand sagen was ich so alles verkehrt mache.

Vor längerer Zeit hatte ich mir Belichtungsreihen angefertigt, hauptsächlich zum lernen wie das mit DRI nun geht. Imagestacker bringt ja nun nix. Mit den Ebenen von PSP bin ich auch nicht zu Rande gekommen, die Übergänge sahen scheußlich aus, wenn es auch "im Prinzip" geklappt hat. Mit diesem Utility bekomme ich nun auch Ergebnisse die scheußlich aussehen.

Zum Ausgangsmaterial: Belichtungsreihe in RAW mit +2/-2 Blenden. Av-Modus, Zeiten 1/25, 1/100, 1/400. Entwickelt mit dem EOS Viewer Utility, Farbtemeratur manuell gesetzt auf 6400 Kelvin, Kontrast hoch, Sättigung hoch, Schärfung aus (macht man ja erst ganz zum Schluß, hab' ich gelernt). Keine Belichtungskorrektur in den RAWs gemacht.

Erster Versuch: entwickelt als 16-Bit Tif linear.
Tool aufgerufen mit mkhdri -out:test.tif -co:kurve.xxx -linear *.tif
file 'IMG_6521.TIF' (16-BIT 3504x2336) opened

image 'IMG_6521.TIF' does not contain EXIF informations
please enter the shutter speed = 1/100
please enter the F-number =

error: invalid F-number 0.000000e+000

Tja, leider wurde ich nicht nach der Blende gefragt - ich hätte dem Programm schon wahrheitsgemäß "10" eingegeben, wenn es mich nur gelassen hätte. Da fehlt wohl der Aufruf der Eingabe...

Dasselbe dann mit 16 bit ohne linear und unter weglassung des Parameters "-linear".

Mit 8-Bit Tifs klappt es dann, weil dort EXIFs drin sind und keine Eingabe erfolgen muß.
mkhdri -out:test.tif -co:kurve.txt *.tif
file 'IMG_6521.TIF' (8-BIT 3504x2336) opened
file 'IMG_6522.TIF' (8-BIT 3504x2336) opened
file 'IMG_6523.TIF' (8-BIT 3504x2336) opened
F-Stops : 8.000000
estimate brightness transfer functions ...
estimate camera curve for channel 1 ...
estimate camera curve for channel 2 ...
estimate camera curve for channel 3 ...
writing camera curve file 'kurve.txt' ...
combining images ...
dynamic range : 12918.510257
max radiance : 51.553983
writing image file 'test.tif' ...
success

Wie kommt das Programm auf 8 F-Stops? Sind das nicht 4?

Als Kurve.txt hat es geschrieben:


polynomial red =
0.000137289994,
0.0271763272,
0.123603745,
1.00815945,
-2.8674419,
2.70836509;


polynomial green =
-0.000249863905,
0.019816062,
0.148621361,
1.03222156,
-2.89046988,
2.69006076;


polynomial blue =
-0.00647542195,
0.228940539,
-0.688899293,
1.46643418;

Mir sagt das nix ;)

Das Tif sieht im Irfanview jedenfalls schrecklich aus, der Himmel ist weiß, ich hätte aber gerne die Struktur vom unterbelichteten Bild darin, deswegen mache ich den ganzen Quatsch doch....

Also das andere Tool aufgerufen:
hdri2ldri -c:kurve.txt test.tif lotest.tif
loading curve file 'kurve.txt' ...
loading HDRI image file 'test.tif' ... 3.825 seconds
convert from RGB to Yxy color space ...
apply exposure multiplier -1.5 ...
tone mapping ... 3.094 seconds
convert from Yxy to RGB color space ...
histogram equalization ...
writing LDRI image file 'lotest.tif' ... 3.355 seconds
minimum luminance : 0.000605
maximum luminance : 0.937475
intensities : 17888
success

Das Ergebnis ist ein total unterbelichtetes Bild mit rosa Himmel, das Gebäude ist nur eine schwarze Fläche. Also andersrum, warum auch immer:

hdri2ldri -ic:kurve.txt test.tif lotest.tif
loading curve file 'kurve.txt' ...
loading HDRI image file 'test.tif' ... 3.776 seconds
convert from RGB to Yxy color space ...
apply exposure multiplier -1.5 ...
tone mapping ... 3.065 seconds
convert from Yxy to RGB color space ...
histogram equalization ...
writing LDRI image file 'lotest.tif' ... 3.404 seconds
minimum luminance : 0.000605
maximum luminance : 0.937475
intensities : 62809
success

Ja, nun sieht es aus wie ein Bild. Aber sehr schlecht. Der Himmel is doch nix.

Ich hänge den Kram mal an - mit IrfanView auf 25% verkleinert, keine Schärfung, nix dran gemacht. :(
Besteht noch Hoffnung für einen Deppen wie mich, jemals ein anständig aussehendes DRI-Bild hinzubekommen oder kann ich das Kapitel schließen? Andere können es doch auch! Ist das Ausgangsmaterial sowas von komplett untauglich oder wie, was, warum geht das nicht?
 
AW: Neue Freeware: HDRI-Generator und Tonemapper

Beruhigt mich zu sehen, das ich nicht der einzige bin der es nicht Out-of-the-Box hinbekommt:p

Gibt es eine Empfehlung für die Anfertigung der Ausgangsbilder? Ich - als Laie in dem Gebiet - habe einfach je nach Geduld 3 (Belichtungsreihe +-2Ev) und vielen Bildern (je 1 FStop von hell bis dunkel) gemacht, und diese einfach als Input genommen. Die Ergebnisse waren... unbefriedigend:p

Von daher wäre ich an einer Lösung von moon's Problem interessiert - vieleicht kann ich mir ja was ableiten daraus:)
 
AW: Neue Freeware: HDRI-Generator und Tonemapper

Rand__ schrieb:
Beruhigt mich zu sehen, das ich nicht der einzige bin der es nicht Out-of-the-Box hinbekommt:p
Out-Of-The-Box erwarte ich ja gar nicht, ich bin schon bereit etwas daran zu arbeiten, nur weiß ich leider nicht, was ich in welche Richtung "schrauben" muß, und Möglichkeiten gibt es viele da es auch viele Parameter gibt. Deshalb wäre ich für Hinweise dankbar in welche Richtung ich Experimente anstellen sollte.

Habe jetzt mal im RAW-Konverter Kontrast auf "niedrig" gesetzt, Farbtemperatur auf 6800K (das andere war mir zu kühl) und mit -0.5 EV entwickelt. Durch die Kontrastsenkung und die Unterbelichtung hat auch das +-0 Ev belichtete Bild nun ein wenig Zeichnung im Himmel.

Das Ergebnis ist ein wenig besser als vorhin, zumindest gewinnt der Himmel an Zeichnung. Leider geht er ins rosafarbene was nun überhaupt nicht paßt.

mkhdri -out:test.tif -co:kurve.txt *.tif
file 'IMG_6521.TIF' (8-BIT 3504x2336) opened
file 'IMG_6522.TIF' (8-BIT 3504x2336) opened
file 'IMG_6523.TIF' (8-BIT 3504x2336) opened
F-Stops : 8.000000
estimate brightness transfer functions ...
estimate camera curve for channel 1 ...
estimate camera curve for channel 2 ...
estimate camera curve for channel 3 ...
writing camera curve file 'kurve.txt' ...
combining images ...
dynamic range : 437.746238
max radiance : 3.436490
writing image file 'test.tif' ...
success

polynomial red =
-0.00103459672,
0.119217846,
-0.592957819,
2.99980529,
-5.2740462,
3.74901548;


polynomial green =
-3.81870885e-005,
0.0592376409,
0.0446499686,
0.248054919,
0.25808302,
-1.48161742,
1.87163006;


polynomial blue =
0.000523752597,
0.0291660166,
0.568377895,
-1.51565466,
2.60473856,
-0.687151564;


hdri2ldri -ic:kurve.txt test.tif lotest.tif
loading curve file 'kurve.txt' ...
loading HDRI image file 'test.tif' ... 3.786 seconds
convert from RGB to Yxy color space ...
apply exposure multiplier -1.5 ...
tone mapping ... 3.025 seconds
convert from Yxy to RGB color space ...
histogram equalization ...
writing LDRI image file 'lotest.tif' ... 3.495 seconds
minimum luminance : 0.005357
maximum luminance : 0.826694
intensities : 62816
success


Bei der Verkleinerung auf 25% habe ich diesmal im IrfanView Schärfen auf "10" gesetzt & die Kompression etwas verringert.

Das kann ja so alles nicht richtig sein! Falls von Interesse: Aufnahmen mit dem 50/1.4, 20D.

Ich fände es hilfreich, wenn Du auch dein Ausgangsmaterial und die unbefriedigenden Ergebnisse zeigen würdest. Der Programmautor (ectoplasma?) kann sicher mehr dazu sagen. Und die DRI-Experten wie CamBoy sollen nicht nur über meine Bilder lachen :D

Vielleicht kann auch jemand Ausgangsmaterial nebst gelungenen Ergebnissen sowie das genaue Vorgehen mal präsentieren, damit wir sehen wo anzusetzen ist. Das beste Programm nützt nix, wenn man es mit Datenmüll füttert...
 
AW: Neue Freeware: HDRI-Generator und Tonemapper

moon1883 schrieb:
Leider bin ich absolut zu blöd dazu. Vielleicht kann mir jemand sagen was ich so alles verkehrt mache.

Denke ich nicht. Das Problem ist, dass deine Bilder bereits extrem hell sind und im Himmel fast immer weiss. Warum MKHDRI das nicht sauber löst, erkläre ich weiter unten.

moon1883 schrieb:
Erster Versuch: entwickelt als 16-Bit Tif linear.
Tool aufgerufen mit mkhdri -out:test.tif -co:kurve.xxx -linear *.tif
file 'IMG_6521.TIF' (16-BIT 3504x2336) opened

image 'IMG_6521.TIF' does not contain EXIF informations
please enter the shutter speed = 1/100
please enter the F-number =

error: invalid F-number 0.000000e+000

Tja, leider wurde ich nicht nach der Blende gefragt - ich hätte dem Programm schon wahrheitsgemäß "10" eingegeben, wenn es mich nur gelassen hätte. Da fehlt wohl der Aufruf der Eingabe...

Wurdest du doch.

please enter the F-number =

Die Werte kann man nicht als Bruch eingeben. Man muss für 1/100, 0.01 schreiben. Eingaben als Brüche, könnte ich noch in MKHDRI hinzufügen.

moon1883 schrieb:
...
Wie kommt das Programm auf 8 F-Stops? Sind das nicht 4?
...

Kommt drauf an, was in den EXIFs steht. Aber es stimmt, nach deinen oberen Angaben, sind es 4 F-Stops. Ich schau nochmal in die Software, kann ja auch ein Ausgabefehler sein.

moon1883 schrieb:
Das Tif sieht im Irfanview jedenfalls schrecklich aus, der Himmel ist weiß, ich hätte aber gerne die Struktur vom unterbelichteten Bild darin, deswegen mache ich den ganzen Quatsch doch....

In Irfanview betrachtest du ja auch nur das HDRI und das sieht nicht gut aus. Weiter oben, hatte ich einen kleinen Exkurs in Sachen HDRI gepostet. Da steht genau beschrieben, warum das so ist ;-)

moon1883 schrieb:
Also das andere Tool aufgerufen:
...

Das ruft man eh immer auf. Siehe Exkurs HDRI ;-)

moon1883 schrieb:
...
hdri2ldri -c:kurve.txt test.tif lotest.tif
...
hdri2ldri -ic:kurve.txt test.tif lotest.tif <--- immer so!
...

MKHDRI gibt die inverse Kamerakurve aus. Die Zahlenkolonne die du siehst, ist ein Polynom und für den Endanwender nicht sonderlich interessant. Aber genau diese Zahlenkolonne, ist die inverse Kamerakurve pro Farbkanal, die MKHDRI ermittelt hat. Der Parameter -ic in HDRI2LDRI, invertiert die Kamerakurve wieder. Das ist der Standardablauf und dieser ist im Tutorial auch nicht anders beschrieben, soweit ich weiss.

moon1883 schrieb:
Ja, nun sieht es aus wie ein Bild. Aber sehr schlecht. Der Himmel is doch nix.

Weil es wie gesagt, stark übersättigt ist, bis auf einem Bild. Da kann dann auch MKHDRI kaum Kontrast herausholen. Überbelichtungen sind eigentlich kein Problem. Es ist nur so, wenn als Dateninformation, mehr Überbelichtungen, als Normalbelichtungen vorhanden sind, dann sieht das Ergebnis am Ende auch mehr überbelichtet aus. Das ist beim Himmel der Fall. Vielleicht finde ich aber auch hier eine Lösung.

Ich hoffe ihr werdet nicht ungeduldig. Meine Software steht noch am Anfang, zumindest was das Austesten anderer Belichtungsreihen, als meiner eigenen, anbelangt. Ich werde das Problem, mit zuviel Überstrahlungen, mal anlysieren. Ich hoffe, ich finde eine Lösung.

Viele Grüße
Marc
 
AW: Neue Freeware: HDRI-Generator und Tonemapper

Ectoplasma schrieb:
Denke ich nicht. Das Problem ist, dass deine Bilder bereits extrem hell sind und im Himmel fast immer weiss. Warum MKHDRI das nicht sauber löst, erkläre ich weiter unten.
Das ganze ist auch schwer zu lösen - aber DRI macht nun mal nur dann Sinn, wenn es AUSSER im am kürzesten belichteten Bild überbelichtete Stellen gibt. In dem Zusammenhang ist es im zweiten Versuch von mir kontraproduktiv gewesen, auch die beiden helleren Bilder mit -0.5 Ev zu entwickeln. Die Software müßte u.a. alle Stellen im Bild ignorieren, bzw aus den anderen Bildern nehmen, die einen rgb 255,255,255 aufweisen. Evtl sogar schon knapp darunter.

Ectoplasma schrieb:
Wurdest du doch.

please enter the F-number =

Die Werte kann man nicht als Bruch eingeben. Man muss für 1/100, 0.01 schreiben. Eingaben als Brüche, könnte ich noch in MKHDRI hinzufügen.
Ne, mußt Du nicht, aber ich hab's nicht in der Doku tutorial.txt gefunden. Ich wurde eben nicht gefragt, da ich "1/100" eingeben konnte, weil der Cursor da parkte und mir die Eingabe erlaubte, bei "enter the F-number" der Cursor hingegen nicht parkte, sondern das Programm bereits mit der Fehlermeldung beendet war. Fragen bedeutet auch, eine Antwort zuzulassen ;) Das "1/100" zuvor keine gültige Antwort war, konnte ich nicht wissen. Klar habe ich kein Problem damit statt dessen 0.01 einzugeben, da mußt Du keinen String-Parser schreiben, sondern dies nur in der Anleitung vermerken.

Ich weiß, es nervt, ich habe selbst mal was programmiert und veröffentlicht... lange her, aber ich weiß noch daß man ein super-Programm schreiben und debuggen kann in x Stunden. Um eine brauchbare Anleitung zu schreiben braucht man x*2 Stunden. Um den ganzen Deppen zu erklären wie sie die Software bedienen müssen, benötigt man mehr als x^2 Stunden ;)

Ectoplasma schrieb:
Weil es wie gesagt, stark übersättigt ist, bis auf einem Bild. Da kann dann auch MKHDRI kaum Kontrast herausholen. Überbelichtungen sind eigentlich kein Problem. Es ist nur so, wenn als Dateninformation, mehr Überbelichtungen, als Normalbelichtungen vorhanden sind, dann sieht das Ergebnis am Ende auch mehr überbelichtet aus. Das ist beim Himmel der Fall. Vielleicht finde ich aber auch hier eine Lösung.
Es ist ja nicht übersättigt, sondern überbelichtet, ich nehme an Du meintest das. An der Sättigung kann ich ja im RAW-Konverter vorher was machen. Allerdings habe ich inzwischen eingesehen daß es keinen Sinn hat, die beiden überbelichteten Aufnahmen mit -0.5 zu entwickeln - das kann Deine Software nur verwirren, da dann die überbelichteten Stellen nicht mehr 255,255,255 sind sondern ein "gesenktes Grau" wie z.B. 224,224,224 - das hatten wir ja neulich bei dem "überbelichtungs-Test" gesehen (weiß nicht ob Du den Thread gelesen hast).
Ectoplasma schrieb:
Ich hoffe ihr werdet nicht ungeduldig. Meine Software steht noch am Anfang, zumindest was das Austesten anderer Belichtungsreihen, als meiner eigenen, anbelangt. Ich werde das Problem, mit zuviel Überstrahlungen, mal anlysieren. Ich hoffe, ich finde eine Lösung.
Ungeduld - nein von mir aus gar nicht! Im Gegenteil, ich hoffe Du wirst nicht ungeduldig mit den Doofies wie mir, die mit Deiner Software (noch?) nicht umgehen können. Mir macht es Spaß mit einem Software-Entwickler aus Anwendersicht zu schreiben.

Um zunächst mal Grundlagen zu schaffen:
Nach meinem Kenntnisstand hat das am kürzesten belichtete Bild der DRI-Reihe an den hellsten Stellen gerade so keine Überbelichtung. Alle folgenden helleren Bilder der Reihe weisen überstrahlte Stellen auf, wohingegen die dunklen Bildpartieen zunehmend "richtig" belichtet sind. Korrigier mich mal bitte, wenn ich da falsch liegen sollte.

Bei gleicher Gelegenheit habe ich noch andere Belichtungsreihen gemacht. Kann ich Dir bei Bedarf gerne als Original-RAW (Canon-.CR2) zugänglich machen (die fetten TIFs passen aber nicht auf meinen gratis-Webspace) - ggf. PN :)
 
AW: Neue Freeware: HDRI-Generator und Tonemapper

Neues Beispiel, diesmal mit eher "zu dunklem" Material.

Ebenfalls 20D mit 50/1.4, Av, {0, -2, +2}, f9, ISO 100, t=1/6s, 1/25, 0.6s.
Für alle 3 RAWs: Farbtemp 6600 K, Kontrast niedrig, Sättigung niedrig, Ev belassen.

Die Überstrahlungen sollten hier keine Sorgen bereiten, die führe ich auf Fehler des Objektivs zurück (so ist mein Gammel nun mal).

Rest (Irfanview batch etc) wie letztes Post.

>mkhdri -out:test.tif -co:kurve.txt *.tif
file 'IMG_6538.TIF' (8-BIT 3504x2336) opened
file 'IMG_6539.TIF' (8-BIT 3504x2336) opened
file 'IMG_6540.TIF' (8-BIT 3504x2336) opened
F-Stops : 7.906891
estimate brightness transfer functions ...
estimate camera curve for channel 1 ...
estimate camera curve for channel 2 ...
estimate camera curve for channel 3 ...
writing camera curve file 'kurve.txt' ...
combining images ...
dynamic range : 12380.109349
max radiance : 10.446475
writing image file 'test.tif' ...
success

Warum jetzt diese krummen F-Stops von 7.9...?

>hdri2ldri -ic:kurve.txt test.tif lotest.tif
loading curve file 'kurve.txt' ...
loading HDRI image file 'test.tif' ... 3.765 seconds
convert from RGB to Yxy color space ...
apply exposure multiplier -1.5 ...
tone mapping ... 2.984 seconds
convert from Yxy to RGB color space ...
histogram equalization ...
writing LDRI image file 'lotest.tif' ... 3.455 seconds
minimum luminance : 0.002476
maximum luminance : 1.004728
intensities : 64286
success


polynomial red =
0.00043622687,
0.069485483,
0.0598612208,
0.074532786,
0.634914723,
-1.24000515,
1.40077471;


polynomial green =
-0.000108423652,
0.065524212,
0.138852997,
-0.278704957,
1.42730919,
-2.08898857,
1.73611555;


polynomial blue =
0.000346849037,
0.0318806719,
0.109867866,
0.693677151,
-1.36490569,
1.52913315;

Hoffe, Du kannst was damit anfangen. Ich denke, "test.jpg" kann ich künftig weglassen. Ich hätte die Schatten auf dem linken Pfosten gerne im lotest so deutlich wie bei "test.jpg" - was muß ich jetzt machen?
 
AW: Neue Freeware: HDRI-Generator und Tonemapper

Hallo Marc,

ich bin gerade auch am Testen Deines Programms. Irgend etwas muss ich falsch
machen, da das Ergebnis von ImageStacker weniger überstrahlt ist und auch
keine so warmen Farben ausgibt.
Ich habe im Grunde nur die Standardoptionen verwendet. Als Input habe ich eine
Belichtungsreihe aus drei Fotos verwendet. Keine Fotos, wo sich der Aufwand lohnen
würde, sie sind aber gut zum Testen.

mkhdri -a -co:curve.txt -out:hdri.tif *.tif
hdri2ldri -ic:curve.txt hdri.tif ldri.tif

Unten sind die Ergebnisse und ein Vergleich mit ImageStacker.

1: ldri
2: Imagestacker
3: von oben ldri,stacker,ldri,stacker

Wenn Du noch nach Fotos suchst, um Dein Programm zu testen, kann ich Dir
die Raws zuschicken.

Danke, dass Du Dir so viel Mühe damit machst.
icon14.gif
Ich bin schon gespannt, wie die
künftigen Versionen funktionieren werden. :)

Gruß,
Michael
 
AW: Neue Freeware: HDRI-Generator und Tonemapper

Bei Deinem Beispiel sieht die LDRI-Version hier erheblich besser aus als die vom Imagestacker (kalt, tot). Überhaupt, mit dem Imagestacker habe ich noch gar nichts brauchbares zustandegebracht ausser Frust - was da rauskommt, kann ich auch jederzeit aus einem der RAWs der Reihe rausbekommen.

Da ist das Tool hier doch erheblich vielversprechender! Sieh nur mal in meinem "dunklen" Beispiel wie gut die Zweige/Blätter in dem überbelichteten Fenster im LDRI herauskommen. Datt kann noch was werden - Imagestacker nicht, der macht nur einen "Durchschnitt", nicht mehr und nicht weniger.

Denke, es hängt auch sehr daran wie man die RAWs entwickelt - kannst Du das Ausgangsmaterial auch noch dazu stellen?
 
AW: Neue Freeware: HDRI-Generator und Tonemapper

moon1883 schrieb:
Das ganze ist auch schwer zu lösen - aber DRI macht nun mal nur dann Sinn, wenn es AUSSER im am kürzesten belichteten Bild überbelichtete Stellen gibt. In dem Zusammenhang ist es im zweiten Versuch von mir kontraproduktiv gewesen, auch die beiden helleren Bilder mit -0.5 Ev zu entwickeln. Die Software müßte u.a. alle Stellen im Bild ignorieren, bzw aus den anderen Bildern nehmen, die einen rgb 255,255,255 aufweisen. Evtl sogar schon knapp darunter.

Die Software ignoriert Stellen mit 255, 255, 255 ja auch. Der Parameter -sl, ist dafür verantwortlich. Er steht auf 0.97 und ignoriert Werte bis zu 248. Nur manchmal kann die Helligkeit, die man sieht, täuschen. Es hätte ja sein können, dass die hellsten Stellen noch nicht diesen Wert erreicht haben. Jedenfalls habe ich die Bilder mal durchlaufen lassen und siehe da, die Bildinformation im Himmel der hellsten Bilder, werden ignoriert. Unten habe ich mal einen Belichtungsausschnitt des HDRIs angehängt. Man sieht, dass der Himmel die volle Zeichnung hat. Das Problem liegt am Tonemapper und hier muss ich nochmal ansetzten.


moon1883 schrieb:
Ne, mußt Du nicht, aber ich hab's nicht in der Doku tutorial.txt gefunden.

Ok, verstanden, muss ich mal im Tutorial vermerken.

moon1883 schrieb:
Ich weiß, es nervt, ich habe selbst mal was programmiert und veröffentlicht... lange her, aber ich weiß noch daß man ein super-Programm schreiben und debuggen kann in x Stunden. Um eine brauchbare Anleitung zu schreiben braucht man x*2 Stunden. Um den ganzen Deppen zu erklären wie sie die Software bedienen müssen, benötigt man mehr als x^2 Stunden ;)

Ne, du nervst gar nicht. Im Ernst, brauche jede Unterstützung bzw. Mithifle. Die Software soll ja am Ende gut werden und Narrensicher. Ist halt mein Anspruch.

moon1883 schrieb:
... sind sondern ein "gesenktes Grau" wie z.B. 224,224,224 - das hatten wir ja neulich bei dem "überbelichtungs-Test" gesehen (weiß nicht ob Du den Thread gelesen hast).

Ne, habs leider nicht gelesen. Ich suche mal danach.

moon1883 schrieb:
Ungeduld - nein von mir aus gar nicht! Im Gegenteil, ich hoffe Du wirst nicht ungeduldig mit den Doofies wie mir, die mit Deiner Software (noch?) nicht umgehen können. Mir macht es Spaß mit einem Software-Entwickler aus Anwendersicht zu schreiben.

*gg*
Die Software kann wie gesagt auch nicht zaubern, selbst dann nicht, wenn man alle Parameter kennt ;-) Am Tonemapper kann man allerdings noch viel einstellen. Da sind auch Optionen dabei, die man im Moment gar nicht konfigurieren kann. Diese machen erst bei Benutzerinteraktionen mit einer grafischen Oberfläche Sinn. Darum, abwarten ;-)

moon1883 schrieb:
Um zunächst mal Grundlagen zu schaffen:
Nach meinem Kenntnisstand hat das am kürzesten belichtete Bild der DRI-Reihe an den hellsten Stellen gerade so keine Überbelichtung. Alle folgenden helleren Bilder der Reihe weisen überstrahlte Stellen auf, wohingegen die dunklen Bildpartieen zunehmend "richtig" belichtet sind. Korrigier mich mal bitte, wenn ich da falsch liegen sollte.

Alles richtig. Und wie man ja im Anhang sieht, zeigt der Belichtungsausschnitt des von MKHDRI generierten HDRIs, ja auch die volle Zeichnung. Natürlich wirkt es dunkel, aber wie gesagt, es ist nur ein Ausschnitt. Das kann man übrigens mit HDRShop so einstellen.

moon1883 schrieb:
Bei gleicher Gelegenheit habe ich noch andere Belichtungsreihen gemacht. Kann ich Dir bei Bedarf gerne als Original-RAW (Canon-.CR2) zugänglich machen (die fetten TIFs passen aber nicht auf meinen gratis-Webspace) - ggf. PN :)

Gerne, schicke die Bilder einfach an ectoplasma1@gmx.de. Da ist genug Platz.

Viele Grüße
Marc
 
AW: Neue Freeware: HDRI-Generator und Tonemapper

Und da Du ja noch nicht genug zu tun hast mit der Weiterentwicklung und den anderen Fragen, hier nochmal mein Senf;)

Zum Workflow (nur falls noch jemand ähnliche Probs hat)

Seit dem letzten Versuch bekomme ich auch bessere Ergebnisse bzw überhaupt welche. Vorher hatte ich
Raws mit CS2 geöffnet, dann als TIFF gespeichert
Jpgs mit XnView direkt in TIFF gewandelt

-> immer eher merkwürdige Ergebnisse, bzw Imagestacker hat nur Müll ergeben -> was aber an XnView liegt wie ich inzwischen herausgefunden habe (wobei der widerrum die 16/32 Bit Bilder aus mkhdri korrekt anzeigt??)

Was bei mir ganz gut funktioniert:
Raw mit CS/ARC öffnen, alle ACR automatismen deaktivieren und direkt als TIFF speichern (keine Kompression). Damit behält das TIFF die Exifs, die scheint er zu verlieren wenn man wie og das Bild erst speichert wenn es bereits in CS2 importiert wurde.

Dann das bekannte Spiel mit mkhdri bzw hdri2ldri.

Auffällig ist, das bei mir der HDRViewer nicht geht... Fehlermeldungen und Dr. Watson - bei so ca jedem Bild.

Glücklicherweise kann CS2 auch HDR Bilder anzeigen (16+32 Bit), da sieht man dann schon mal ob es am hdr oder ldr liegt.

Auffällig ist aber, das mkhdri mit verschiedenen Input Bildern Probleme hat, die angehängten Bilder (+2 weitere) ergeben ein komplett weisses hdri und ein komplett schwarzes ldri


F:\temp\dist_1_04> mkhdri -a -co:myCurve.txt -out:myPicbs.tif in\bigisee\*.tif
file 'in\bigisee\_MG_4623.tif' (16-BIT 3504x2336) opened
file 'in\bigisee\_MG_4624.tif' (16-BIT 3504x2336) opened
file 'in\bigisee\_MG_4625.tif' (16-BIT 3504x2336) opened
file 'in\bigisee\_MG_4626.tif' (16-BIT 3504x2336) opened
file 'in\bigisee\_MG_4627.tif' (16-BIT 3504x2336) opened
file 'in\bigisee\_MG_4628.tif' (16-BIT 3504x2336) opened
file 'in\bigisee\_MG_4629.tif' (16-BIT 3504x2336) opened
file 'in\bigisee\_MG_4630.tif' (16-BIT 3504x2336) opened
F-Stops : 3.228819
align images ...
no shifts against image 'in\bigisee\_MG_4630.tif'
estimate brightness transfer functions ...
estimate camera curve for channel 1 ...
estimate camera curve for channel 2 ...
estimate camera curve for channel 3 ...
writing camera curve file 'myCurve.txt' ...
combining images ...
dynamic range : 1.001167
max radiance : 1.000183
writing image file 'myPicbs.tif' ...
success

F:\temp\dist_1_04>hdri2ldri -ic:myCurve.txt myPicbs.tif myPicbs_ldri.tif
loading curve file 'myCurve.txt' ...
loading HDRI image file 'myPicbs.tif' ... 1.313 seconds
convert from RGB to Yxy color space ...
apply exposure multiplier -1.5 ...
tone mapping ... 1.672 seconds
convert from Yxy to RGB color space ...
histogram equalization ...
writing LDRI image file 'myPicbs_ldri.tif' ... 1.344 seconds
minimum luminance : 0.525003
maximum luminance : 0.525003
intensities : 1
success



polynomial red =
0.999045033,
0.000954967153;


polynomial green =
0.999052028,
0.000947971731;


polynomial blue =
0.998773002,
0.00122699795;
 
AW: Neue Freeware: HDRI-Generator und Tonemapper

2. Teil

Einmal das ldri in schwarz;)

Und zum Vergleich das Imagestacker Bild...

Liegt das ggf daran das da einfach zu wenig Helligkeitsinformationen vorhanden sind?

Andere Bilder mit stärker bleuchteten Elementen (Kirchen zB) ergeben sinnvollere Ergebnisse ...
 
AW: Neue Freeware: HDRI-Generator und Tonemapper

>Die Software ignoriert Stellen mit 255, 255, 255 ja auch. Der Parameter
>-sl, ist dafür verantwortlich.

Mit den allen möglichen Parametern habe ich noch nicht herumgespielt. Gerne probiert man etwas kaputt weil man keine Ahnung hat was die Parameter bedeuten. Ich habe viel mit Fractint "gespielt" und kenne dieses abartig geniale Programm "ein bischen" und auch die Parameter "ein bischen", aber... nun ja, ich schweife ab.

>Er steht auf 0.97 und ignoriert Werte bis zu 248. Nur manchmal kann
>die Helligkeit, die man sieht, täuschen. Es hätte ja sein können, dass die
>hellsten Stellen noch nicht diesen Wert erreicht haben. Jedenfalls habe ich
>die Bilder mal durchlaufen lassen und siehe da, die Bildinformation im Himmel
>der hellsten Bilder, werden ignoriert. Unten habe ich mal einen
>Belichtungsausschnitt des HDRIs angehängt. Man sieht, dass der Himmel die
>volle Zeichnung hat. Das Problem liegt am Tonemapper und hier muss ich
>nochmal ansetzten.

Aber... was zeigt uns das Bild denn jetzt? In meinem unterbelichteten Bild hat der Himmel ja auch die gewünschte Zeichnung. In Deinem angehängten Beispiel ist das Gebäude ja nun auch "total" zu dunkel.

>Ne, du nervst gar nicht. Im Ernst, brauche jede Unterstützung bzw. Mithifle.
>Die Software soll ja am Ende gut werden und Narrensicher.

Da mache ich gerne mit. Für mich brauche ich keine Narrensichere Software; ich liebe DOS-Kommandozeilentools - aber ich muß natürlich wissen wie ich sie "füttere".

>Ne, habs leider nicht gelesen. Ich suche mal danach.

Der hier, ganzer Thread:
https://www.dslr-forum.de/showthread.php?t=57206&highlight=RAW+belichtung
Viel Lesestoff, in Posting #93 Beispielbilder von mir, in den folgenden Postings insbesondere von beiti die IMHO korrekten Schlußfolgerungen dazu.

Meine RAWs juckeln so langsam per Mail von meinem auf Deinen gmx-Account vor sich hin...
 
AW: Neue Freeware: HDRI-Generator und Tonemapper

Rand__ schrieb:
Liegt das ggf daran das da einfach zu wenig Helligkeitsinformationen vorhanden sind?
Kann es sein das Dein Quellmaterial einfach viel zu dunkel ist? Ich meine, ich seh' da wohl was, kann mir aber vorstellen das die meisten an ihren CRTs fast nur schwarze Flächen in allen Deinen Anhängen sehen. Wo sind denn die überbelichteten Aufnahmen?
 
AW: Neue Freeware: HDRI-Generator und Tonemapper

moon1883 schrieb:
Bei Deinem Beispiel sieht die LDRI-Version hier erheblich besser aus als die vom Imagestacker (kalt, tot). Überhaupt, mit dem Imagestacker habe ich noch gar nichts brauchbares zustandegebracht ausser Frust - was da rauskommt, kann ich auch jederzeit aus einem der RAWs der Reihe rausbekommen.
Finde ich nicht. Schau dir das mit den Ausschnitten vor einem dunklen Hintergrund an.
Die ImageStacker-Version sieht ziemlich sauber aus, während das LDRI "ausgebrannt"
zu sein scheint. (insbesondere der Schattenbereich link oben).
Die ausgebrannten Stellen und auch die Schatten mit den Sonnenstrahlen
sehen so aus, als ob da was mit dem Gammawert falsch gelaufen wäre.
moon1883 schrieb:
Da ist das Tool hier doch erheblich vielversprechender! Sieh nur mal in meinem "dunklen" Beispiel wie gut die Zweige/Blätter in dem überbelichteten Fenster im LDRI herauskommen. Datt kann noch was werden - Imagestacker nicht, der macht nur einen "Durchschnitt", nicht mehr und nicht weniger.
Denke, es hängt auch sehr daran wie man die RAWs entwickelt - kannst Du das Ausgangsmaterial auch noch dazu stellen?
Ich habe leider nirgendwo Platz dafür. Dass der Imagestacker nur den Mittelwert
der einzelnen "Pixel" berechnet, ist mir schon klar. ;)

Gruß,
Michael
 
WERBUNG
Zurück
Oben Unten