Archiv verlassen und diese Seite im Standarddesign anzeigen : 5 Minuten Belichtungszeit mit Dynax 7D
Hallo,
endlich habe es geschafft, Langzeitaufnahmen mit der 7D herzustellen.
Das Beispiel ist bei 200 ASA und 5 Minuten Belichtungszeit bei leichtem Regen entstanden.
Zunächst das jpeg-Bild:
http://www.d7userforum.de/phpBB2/4images/data/thumbnails/6/Alt-jpeg.jpg (http://www.d7userforum.de/phpBB2/4images/details.php?image_id=23104)
Dann das mit ps-cs2 (ich habe noch 13 Tage!!) aus der RAW Datei erzeugte Bild:
http://www.d7userforum.de/phpBB2/4images/data/thumbnails/6/Alt-mrw.jpg (http://www.d7userforum.de/phpBB2/4images/details.php?image_id=23105)
Deutlich ist auf beiden Bildern die helle linke obere Ecke zu sehen.
Am Vortag habe ich ein Dunkelbild bei 200 ASA und 5 Minuten Belichtungszeit erzeugt und diese Dunkel-RAW-Datei von der RAW-Datei subtrahiert:
http://www.d7userforum.de/phpBB2/4images/data/thumbnails/6/Neu-mrw.jpg (http://www.d7userforum.de/phpBB2/4images/details.php?image_id=23106)
Was sagt Ihr dazu?
Gruß
Stuessi
Hallo,
hier ist mein Programm, mit dem ich die RAW-Dateien voneinander subtrahiert habe.
Es ist in COMAL geschrieben, einer "alten" Sprache, die aus BASIC und Pascal zusammengesetzt ist. Sicher gibt es Programmierer, die das in eine "moderne" Sprache übertragen und dann das Programm allen im Forum zur Verfügung stellen, mit Dateinamenseingabe ....
Auf meinem 900MHz Computer braucht ein Durchlauf unter W98 2 1/2 Minuten.
Viel Spaß beim Lesen!
Stuessi
0010 // save "RAW-RAW1"
0020 // Programm von : "Stuessi"
0030 // Datum : 18.01.2006
0040 USE unidump
0050 OPEN FILE 1,"PICT2113.MRW",READ // Original RAW Datei file1
0060 OPEN FILE 2,"PICT2106.MRW",READ // Dunkelbild file2 wird abgezogen
0070 OPEN FILE 3,"PIC-2113.MRW",WRITE //neues RAW-Datei
0080
0090 DIM a$ OF 1, b$ OF 1, c$ OF 1
0100 DIM dwert1$ OF 3
0110 //die ersten 4 Byte werden von file1 nach file3 uebertragen
0120 FOR i:=1 TO 4 DO
0130 a$:=GET$(1,1)
0140 IF a$="" THEN a$:=CHR$(0)
0150 PRINT FILE 3: a$,
0160 ENDFOR i
0170 //die ersten 4 Byte werden von file2 gelesen
0180 FOR i:=1 TO 4 DO a$:=GET$(2,1)
0190 //offset von file2 lesen
0200 offset2:=0
0210 FOR i:=3 TO 0 STEP -1 DO
0220 a$:=GET$(2,1)
0230 IF a$="" THEN a$:=CHR$(0)
0240 offset2:=offset2+ORD(a$)*256^i
0250 ENDFOR i
0260 //offset von file1 lesen und Daten in file 3 schreiben
0270 offset1:=0
0280 FOR i:=3 TO 0 STEP -1 DO
0290 a$:=GET$(1,1)
0300 IF a$="" THEN a$:=CHR$(0)
0310 PRINT FILE 3: a$,
0320 offset1:=offset1+ORD(a$)*256^i
0330 ENDFOR i
0340 //an den Anfang der Daten von file2 gehen
0350 FOR i:=1 TO offset2 DO a$:=GET$(2,1)
0360 //Byte vor Bilddaten von file1 nach file3 kopieren
0370 FOR i:=1 TO offset1 DO
0380 a$:=GET$(1,1)
0390 IF a$="" THEN a$:=CHR$(0)
0400 PRINT FILE 3: a$,
0410 ENDFOR i
0420 zaehler1#:=8+offset1
0430 //
0440 pixel#:=2008*3016 DIV 2
0450 // 3 Byte lesen fuer 2 pixel
0460 FOR i:=1 TO pixel# DO
0470 zaehler1#:+2
0480 dwert1$:=""; dwert2$:=""
0490 FOR k:=1 TO 3 DO
0500 a$:=GET$(1,1); b$:=GET$(2,1)
0510 IF a$="" THEN a$:=CHR$(0)
0520 IF b$="" THEN b$:=CHR$(0)
0530 dwert1$:=dwert1$+a$; dwert2$:=dwert2$+b$
0540 ENDFOR k
0550
0560 // aus drei 8-Bit-Werten werden zwei 12-bit-werte
0570 // file1
0580 wertfile1pix1#:=(ORD(dwert1$(1:1)))*16+(ORD(dwert1 $(2:2))) DIV 16
0590 wertfile1pix2#:=(ORD(dwert1$(2:2)) MOD 16)*256+ORD(dwert1$(3:3))
0600 //file2
0610 wertfile2pix1#:=(ORD(dwert2$(1:1)))*16+(ORD(dwert2 $(2:2))) DIV 16
0620 wertfile2pix2#:=(ORD(dwert2$(2:2)) MOD 16)*256+ORD(dwert2$(3:3))
0630
0640 //Daten-file2 von daten-file1 subtrahieren
0650
0660 wertfile3pix1#:=wertfile1pix1#-wertfile2pix1#
0670 IF wertfile3pix1#<0 THEN wertfile3pix1#:=0
0680 wertfile3pix2#:=wertfile1pix2#-wertfile2pix2#
0690 IF wertfile3pix2#<0 THEN wertfile3pix2#:=0
0700
0710 // aus zwei 12-Bit-Werten werden drei 8-Bit-werte
0720 // diese werden in file3 geschrieben
0730
0740 b1#:=wertfile3pix1# DIV 16
0750 PRINT FILE 3: CHR$(b1#),
0760 b2#:=(wertfile3pix1# MOD 16)*16+wertfile3pix2# DIV 256
0770 PRINT FILE 3: CHR$(b2#),
0780 b3#:=wertfile3pix2# MOD 256
0790 PRINT FILE 3: CHR$(b3#),
0800 ENDFOR i
0810 CLOSE FILE 2
0820
0830 // rest von file3 wird geschrieben
0840
0850 WHILE NOT EOF(1) DO
0860 a$:=GET$(1,1)
0870 zaehler#:+1
0880 IF a$="" THEN a$:=CHR$(0)
0890 PRINT FILE 3: a$,
0900 ENDWHILE
0910 CLOSE FILE 1
0920 CLOSE FILE 3
Hallo Stuessi,
das trifft ja mal wieder das Auge mit der Faust :)
Ich lese gerade im Seibelbuch über diese Technik bei extremen langzeitbelichtungen um das Sensorglühen weg zu bekommen und schwups die wups ... ein praktisches beispielbild.
Klasse ... das sieht ja recht gut aus.
Kann man davon ausgehen, dass das Sensorglühen immer gleich ist (bei gleichen Einstellungen der Kamera natürlich). ODer gibt es noch Temperatureinflüsse.
Wenn keine äusseren Einflüsse da sind, dann könnte man ja einfach mal bei unterschieldlichen Einstellugnen das Sensorglühen quasi in sein Archiv legen.
Grüße jms
ach ja - im Scheiben-Buch wird geschreiben,da ss das auch mit jps funktionieren sollte. Im PS die Ebenen mit "differenz" überlagen.
Könntest Du das mal mit Deiner RAW-Methode vergleichen?
Grüße
TorstenG
18.01.2006, 21:24
Hallo!
Starke Sache! Das mit dem Programm wäre nicht schlecht, denn nicht jeder hat Photoshop oder ein anderes, das das auch kann!
ach ja - im Scheiben-Buch wird geschreiben,da ss das auch mit jps funktionieren sollte. Im PS die Ebenen mit "differenz" überlagen.
Könntest Du das mal mit Deiner RAW-Methode vergleichen?
Grüße
Hallo,
im Prinzip geht das. Ich habe aber keine überzeugende Ergebnisse erhalten. Mir war das zu ungenau, da dieDifferenz nicht im RAW-Bearbeitungsmodus von PS gemacht werden kann. Nur in der RAW Datei sind die Pixelwerte noch proportional zur Helligkeit, wie ich feststellte. Jeder RAW-Konverter "verfälscht" die Pixelwerte. Deshalb hat mich die Idee der RAW-Bearbeitung seit einigen Tagen nicht mehr losgelassen.
Gruß
Stuessi
Kann man davon ausgehen, dass das Sensorglühen immer gleich ist (bei gleichen Einstellungen der Kamera natürlich). ODer gibt es noch Temperatureinflüsse.
Hallo,
wenn man den Astronomen glaubt -und sie haben sicher Recht bei ihren tollen Aufnahmen- kommt es auf 1/10 Grad Temperaturstabilität an.
Ich habe ein NullBild von gestern genommen und es klappte gut. Also werde ich mir einige Nullbilder unter verschiedenen Bedingungen herstellen. Bei der Aufnahme ist die maximal 30 Sekunden währende Rauschunterdrückung der Kamera natürlich ausgeschaltet gewesen.
Gruß
Stuessi
Kann man davon ausgehen, dass das Sensorglühen immer gleich ist (bei gleichen Einstellungen der Kamera natürlich). ODer gibt es noch Temperatureinflüsse.
wenn man den Astronomen glaubt -und sie haben sicher Recht bei ihren tollen Aufnahmen- kommt es auf 1/10 Grad Temperaturstabilität an.
Hallo,
Inzwischen habe ich weitere Tests durchgeführt. Die Temperaturabhängigkeit ist wirklich sehr groß. Leider heizt sich die Kamera auch von 5min-Aufnahme zu 5min-Aufnahme immer mehr auf.
Bei den Bildern habe ich jeweils 10% Intensität als Maximalintensität eingestellt, damit man den Unterschied sieht.
Zunächst bei Zimmertemperatur (21°Celsius) 1. und 4. Bild einer Reihe:
http://www.d7userforum.de/phpBB2/4images/data/thumbnails/6/PICT2120hg10.jpg (http://www.d7userforum.de/phpBB2/4images/details.php?image_id=23149) http://www.d7userforum.de/phpBB2/4images/data/thumbnails/6/PICT2123hg10.jpg (http://www.d7userforum.de/phpBB2/4images/details.php?image_id=23151)
Dann habe ich die Kamera 11h in den Kühlschrank gelegt und dort Testaufnahmen gemacht.
Temperatur 3°Celsius:
http://www.d7userforum.de/phpBB2/4images/data/thumbnails/6/PICT2127hg10.jpg (http://www.d7userforum.de/phpBB2/4images/details.php?image_id=23150)
Gruß
Stuessi
wow - das ist ja extrem - also klappt das mit der "x Minuten Objektivdecke bei y Einstellung Archiv" nicht und man muss immer gleich nach der Langzeitbelichtung noch ein "Deckelbild" machen.
Danke für Deinen Versuch (obwohl ich ein komisches Gefühl hätte meine Cam in den Kühlschrank zu legen.
Grüße jms
Hallo,
in der letzten Nacht habe ich meine 7D wieder aus dem Kühlschrank herausgeholt und bei Einstellung 100 ASA mit dem KoMi 17-35/2,8-4 bei 17mm und Blende 4 das Orionsternbild
http://www.d7userforum.de/phpBB2/4images/data/thumbnails/871/Orion.jpg (http://www.d7userforum.de/phpBB2/4images/details.php?image_id=23289)
und mit einem uralten Zeiss 180mm/2,8 Objektiv den Orionnebel abgelichtet.
Belichtungszeiten jeweils 5 Minuten.
http://www.d7userforum.de/phpBB2/4images/data/thumbnails/871/Orionnebel.jpg (http://www.d7userforum.de/phpBB2/4images/details.php?image_id=23290)
Dunkelbilder habe ich jeweils nach den Aufnahmen gemacht und mit obigem Programm abgezogen, dann die MRW-Dateien in cs2 bearbeitet.
Gruß
Stuessi
MiLLHouSe
24.01.2006, 14:50
Was ist ein Dunkelbild(-abzug)?
Hast du die Bilder nur mit Stativ gemacht oder die Kamera auf ein Teleskop gepackt und autom. nachgeführt?
Jerichos
24.01.2006, 15:00
Hi Stuessi,
erstmal dickes Lob für Deine Bemühungen. Sieht ja wirklich klasse aus.
Ich kann grad mit dem Programm nicht viel anfangen. Gibt es eine Möglichkeit daraus eine ausführbare EXE zu machen, bei der man beispielsweise gleich zu Beginn aufgefordert wird die Quelldatei, die Darkframedatei und die Zieldatei anzugeben? Das wär natürlich die Ideallösung, gerade weil Du ja wieder eine RAW-Datei ausgibst.
Alternative, was braucht man um das oben gezeigte Programm auszuführen? Das Programm COMAL? Wo gibt´s das? Kenn mich da leider wenig aus. ;)
TorstenG
24.01.2006, 16:28
Hab mal was dazu rausgesucht! (http://www.josvisser.nl/opencomal/)
EDIT: Ähm, komm damit gerade auch nicht weiter, ist ein GZ-File! Hab gerade keinen passenden Entpacker parat ...
Was ist ein Dunkelbild(-abzug)?
Hast du die Bilder nur mit Stativ gemacht oder die Kamera auf ein Teleskop gepackt und autom. nachgeführt?
Hallo,
nach einem Bild A mit z.B. 5 Minuten Belichtungsdauer wird bei verschlossenem Objektiv noch eine 5 Minuten Aufnahme D gemacht. Die zweite Aufnahme nennt man Dunkelbild oder "dark frame".
Dieses 2. Bild wird von der 1. Aufnahme abgezogen, d.h.
es wird ein neues RAW-Bild A-neu berechnet nach dem Prinzip
Intensitätswert (A-neu(x,y)) = Wert(A(x,y))-Wert(D(x,y)) mit 12 Bit Genauigkeit.
Diese Prozedur führt die Kamera bei eingeschalteter Rauschunterdrückung bei Zeiten von 1 sec bis 30 sec selbst aus, bei längeren Zeiten aber immer nur mit einem 30-sec-Dunkelbild.
Zur zweiten Frage: Ich habe die Kamera auf ein Teleskop (LX50) gepackt, dessen Nachführung leider 30% falsch läuft, so dass ich alle 2 sec per Hand durch Tastendruck korrigieren musste.
Gruß
Stuessi
Hab mal was dazu rausgesucht! (http://www.josvisser.nl/opencomal/)
EDIT: Ähm, komm damit gerade auch nicht weiter, ist ein GZ-File! Hab gerade keinen passenden Entpacker parat ...
Hallo Torsten,
mit dieser Version klappt es nicht.
Die Sprache COMAL wurde 1973 entwickelt. Ich habe sie seit 1984 auf CBM8032, c64, CBM8096 und dann als UNICOMAL auf einem IBM-PC als Ersatz für BASIC neben Pascal benutzt. Da es heute für (fast) jedes Problem spezielle Programme gibt, programmiere ich nur noch sehr selten, wenn , dann auf DOS Ebene in COMAL.
Mein Programm habe ich nun auch mit Eingabe versehen und in eine EXE-Datei kompiliert, die in DOS-Umgebung bei mir unter W98 und XP läuft.
Man muss nur die umzuwandelnden Dateien in das Verzeichnis kopieren, in dem die EXE-Datei ist und letztere aus dem Explorer heraus aufrufen.
Wie kann ich sie ans Forum schicken?
Gruß
Stuessi
Jerichos
24.01.2006, 20:30
Wie kann ich sie ans Forum schicken?
Gruß
Stuessi
info@d7userforum.de dann stell ich sie auf den Server zum Download!
Klasse. :top:
info@d7userforum.de dann stell ich sie auf den Server zum Download!
Hallo,
schon erfolgt.
Gruß
Stuessi
Jerichos
24.01.2006, 21:45
Hallo,
schon erfolgt.
Gruß
Stuessi
Sicher?
Bei mir liegt nix im Postfach. Hast Du direkt die .exe. verschickt? Mag sein, dass da bei unserem Virenscanner die roten Lampen angehen.
Am besten zippen und dann noch mal schicken. Meinetwegen hängst Du meine private Mail info@jerichos.de als CC mit dran, dann kommt es sicher an. ;)
Peter Heckert
24.01.2006, 21:57
ach ja - im Scheiben-Buch wird geschreiben,da ss das auch mit jps funktionieren sollte. Im PS die Ebenen mit "differenz" überlagen.
Könntest Du das mal mit Deiner RAW-Methode vergleichen?
Grüße
Hallo,
im Prinzip geht das. Ich habe aber keine überzeugende Ergebnisse erhalten. Mir war das zu ungenau, da dieDifferenz nicht im RAW-Bearbeitungsmodus von PS gemacht werden kann. Nur in der RAW Datei sind die Pixelwerte noch proportional zur Helligkeit, wie ich feststellte. Jeder RAW-Konverter "verfälscht" die Pixelwerte. Deshalb hat mich die Idee der RAW-Bearbeitung seit einigen Tagen nicht mehr losgelassen.
Gruß
Stuessi
Hallo,
Das sollte dann in PS oder Photoline 32 funktionieren, wenn man in 16 Bit convertiert und dann in einen linearen Arbeitsfarbraum convertiert.
Den gibt es hier:
http://home.arcor.de/peter.heckert/raw/RawSharpen/sRGBG1.icc
mit den sRGB Primärfarben
und hier noch einer, etwas grösser (aber viel grösser als notwendig):
http://www.aim-dtp.net/aim/download/aim_profiles.zip
Vorteil wäre, dass man die Ebenentransparenz dann interaktiv optimieren kann und eine Aktion erstellen kann.
Grüsse,
Peter
Hi,
habe die Datei erhalten und hochgeladen. Findet ihr hier (http://www.d7userforum.de/RAW/RAW-RAW6.zip).
Basti
Sicher gibt es Programmierer, die das in eine "moderne" Sprache übertragen und dann das Programm allen im Forum zur Verfügung stellen, mit Dateinamenseingabe ....
Auf meinem 900MHz Computer braucht ein Durchlauf unter W98 2 1/2 Minuten.
Hallo Stuessi,
ich habe mich mal dran gemacht und Dein Programm übertragen in: ...... (ich traue mich gar nicht es zu sagen) ...... also in :oops: Excel-VBA :oops: .
So jetzt ist es draußen.
Ich bin mir bewußt, dass das total verrückt klingt, aber: Versuch macht kluch (oh, was für ein Deutsch!). Also habe ich es einfach mal umgesetzt, dauerte so ca. eine viertel Stunde. Zu meiner Überraschung ist die Laufzeit auf einem P4 mit 2,4GHz mit rund 15 Sekunden recht kurz. Deine kompilierte Version lief bei mir etwa 2,5 Minuten.
Ein Vergleich der Ergebnisse auf Byte-Ebene sagte, dass die Ergebnisse identisch sind - ich habe aber noch einen klitzekleinen Fehler, dass meine Umsetzung ein Byte am Ende zuviel dran hängt. Sollte aber kein Problem sein das zu ändern. Ich will noch ein paar Tests mit beliebigen Dateien machen, die ich sowohl durch Dein raw-raw.exe bearbeiten lasse, dann durch die Excel-Version. Die Ergebnisse werde ich dann wieder vergleichen.
Falls die Ergebnisse positiv sind und Du zustimmst, würde ich die Excel-Datei gerne dem Forum zur Verfügung stellen.
Gruß
Eric
PS: Die Excel-Version ist 2003, sollte aber ab Excel 2000 laufen
Hallo Eric,
das ist Klasse! Warum sollte ich etwas dagegen haben?!
Meine Version habe ich ja als Anregung für schnellere Versionen ins Forum gestellt.
Gruß
Stuessi
Hallo Stuessi,
ich habe früher schon mal negative Erfahrungen in einer ähnlichen Sache gemacht, deshalb noch mal die explizite Nachfrage.
Ich denke, dass ich die Vergleiche zwischen raw-raw.exe und Excel-Proggi in den nächsten Tagen abschliessen werde. Den kleine Fehler will ich noch beseitigen. Er hat zwar scheinbar keine negativen Konsequenzen, zumindest kann RAW-Shooter und Helicon Filter die neue Datei (mit dem einen Byte am Ende zuviel) ohne Probleme öffnen und weiterverarbeiten, unschön ist es aber trotzdem.
Gruß
Eric
EDIT: Ähm, komm damit gerade auch nicht weiter, ist ein GZ-File! Hab gerade keinen passenden Entpacker parat ...
Hallo Torsten,
hast Du es schon mal mit WinRAR probiert?
http://www.pcwelt.de/downloads/tools_utilities/packer/129471/
Tom
TorstenG
31.01.2006, 10:39
Danke, werde ich mir fürs nächste GZ-File laden, aber zum Glück brauchte ich es für das RAW-Programm nimmer mehr! :top:
Hallo zusammen,
ich habe die Umsetzung von Stuessi's raw-raw.exe von Comal nach Excel-VBA abgeschlossen. Wie Stuessi angeregt hatte, gibt es einen Datei-Auswahl-Dialog. Ansonsten ist die Funktionalität übernommen worden.
Ich habe testweise unterschiedliche MRWs von einander abgezogen und die jeweiligen Ergebnisse (raw-raw.exe <-> raw-raw.xls) byteweise miteinander verglichen. Die Ergebnisse sind absolut identisch gewesen. Auch der kleine Bug (1 Byte am Ende zuviel) ist ausgemerzt.
Da ich nur Excel 2003 zur Verfügung habe konnte ich keine Tests mit älteren Versionen machen. Ich denke aber, dass es ab Excel 2000 laufen sollte.
Natürlich ist der Quellcode offen zugänglich, ich habe die Arbeitsmappe nicht geschützt.
Wer es haben möchte kann sich gerne per PN an mich wenden. Wenn die Nachfrage zu groß werden sollte, bitte ich die Moderatoren um Hilfe :crazy:
Gruß
Eric
gyroscop
08.02.2006, 18:51
Danke Elric,
es funktioniert nach der Umstellung der Auflösung auch mit den RAW-Daten der A1.
MfG
Bernd
Danke Elric,
es funktioniert nach der Umstellung der Auflösung auch mit den RAW-Daten der A1.
MfG
Bernd
Dann scheint sich an dem Dateiformat zumindest in der Hinsicht nicht viel getan zu haben. Die ersten vier Bytes sind "Magic Bytes" da steht nur "MRW" drin. Die nächsten vier Bytes geben an, wo die Bildinformationen beginnen. Der Rest dazwischen sind u.a. die Exif Informationen. Stuessis Algorithmus kopiert alle Daten bis zum Beginn der Bildinformationen 1:1 in die neue Datei. Die eigentlichen Bildinformationen werden durch Subtraktion neu berechnet und dann auch geschrieben.
Gruß
Eric
Hallo,
ich bin grade durch einen Link von Stuessi auf diesen Thread gestoßen.
Bestünde noch Bedarf an einer exe-Version des Programms? Ich habe schon ein kleines Framework für sowas in Java, da ich auch ab und zu kleine Tools schreibe, die auf Pixelebene arbeiten. Bisher allerdings nur JPGs. Ich habe aber schonmal was von einem RAW-Package in Java gelesen, da würde ich natürlich nochmal recherchieren.
Das Wrappen des Java-Codes zu einer exe sollte kein Problem sein, ansonsten gäbe es gerne noch zusätzlich den plattformunabhängigen Bytecode und auch gerne den Quelltext dazu.
Ein Frage an Stuessi: Das DFS-Bild muß tatsächlich nur Pixelweise vom Original abgezogen werden, oder? Habe mich jetzt nicht durch deinen Code durchgearbeitet, die Syntax ist mir doch etwas fremd :oops: ;) .
Gruß,
Justus
Ein Frage an Stuessi: Das DFS-Bild muß tatsächlich nur Pixelweise vom Original abgezogen werden, oder?
Hallo Justus,
in 3 aufeinanderfolgenden Byte (3x8 Bit = 24 Bit) sind die Helligkeitswerte für 2 Pixel (2x12Bit). Also erfolgt nach Lesen von 3 Byte die Umwandlung in 2 12-Bit-Typ-Werte, ebenso für das DFS-Bild, dann Subtraktion der Werte, zuletzt Umwandlung der beiden Ergebnisse vom 12-Bit-Typ in 3 Byte für die neue Datei.
Gruß,
Stuessi
Hallo zusammen! :)
Ein sehr interessanter Thread.
Ich habe das Programm gestern Abend testweise mal in C nachprogrammiert - läuft hervorragend. Auf einem CoreDuo mit 1,8GHz benötigt es weniger als 5 Sekunden, wobei man das Programm sicherlich noch verbessern kann.
Da ich sehr gerne Langzeitbelichtungen mache und mich bisher immer über die heißen Stellen innerhalb der D7D geärgert habe, freue ich mich natürlich sehr darüber, daß man das Problem so leicht beheben kann.
Bei einer 10-minütigen Belichtung bei Zimmertemperatur (ISO 200) ist das Ergebnis zwar immernoch ziemlich 'bunt', aber im Vergleich mit dem Original ist es dennoch eine unglaubliche Verbesserung.
Interessant ist es auch, wenn man einfach zwei unterschiedliche Bilder voneinander abzieht. ;)
Vielen Dank an Stuessi für diese sehr nützliche Idee! :top:
Gruß, eiq
PS: Ich werde meinen Code noch etwas optimieren und versuchen, ihn im Laufe des Tages hier einzustellen.
Hallo eiq,
auf das Programm in C freue ich mich schon.
Mein Programm in COMAL habe ich leicht verbessert durch folgende Zeilen:
0010 // save "RAW-RAW7"
0020 // Programm von : "Stuessi"
0030 // Datum : 27.12.2006
0101 gemerkt1#:=255
0102 gemerkt2#:=255
.......
......
.......
0700 IF wertfile2pix1#>2047 THEN
0701 IF wertfile3pix1#=0 THEN wertfile3pix1#:=gemerkt1#
0702 ENDIF
0703 IF wertfile2pix2#>2047 THEN
0704 IF wertfile3pix2#=0 THEN wertfile3pix2#:=gemerkt2#
0705 ENDIF
0706 gemerkt1#:=wertfile3pix1#
0707 gemerkt2#:=wertfile3pix2#
So werden einige "Löcher" durch (gleichfarbige linke) Nachbarwerte überschrieben.
Besser wäre eine Mittelung aus der Umgebung, in COMAL (DOS-Ebene!) bekomme ich aber nicht alle 6056128 Werte in ein 2-dim. Feld.
Eine weitere Verbesserung habe ich aber erzielt, indem ich nicht ein einzelnes Dunkelbild abziehe, sondern eines, das aus mehreren, gemacht mit gleichen Belichtungszeiten unter gleichen Temperaturverhältnissen, gemittelt wurde. Im Beispiel habe ich 5 Dunkelbilder zu je 5 Minuten genommen.
http://www.sonyuserforum.de/phpBB2/4images/data/thumbnails/6/Langzeit-1_Kopie.jpg (http://www.sonyuserforum.de/phpBB2/4images/details.php?image_id=35036) http://www.sonyuserforum.de/phpBB2/4images/data/thumbnails/6/Langzeit-2_Kopie.jpg (http://www.sonyuserforum.de/phpBB2/4images/details.php?image_id=35037)
Gruß,
Stuessi
Ah, ich wusste, dass ich etwas vergessen hab. :oops:
Werde mich gleich mal ransetzen und meinen Code aufräumen und vielleicht noch die Verbesserungen übernehmen. Das mit den benachbarten Pixel hatte ich mir auch überlegt, mal schaun in wie weit das realisierbar ist. Ich probiere ich es mal fensterbasiert, da man ja eigentlich nur die Umgebung des Pixels braucht.
Zur Not hab ich noch eine C-Bibliothek zur Arbeit mit Genomdaten, da kann man mehrere Gigabyte einlesen. ;)
Gruß, eiq
So... hier (http://christian-hoffmann.com/sonyuserforum/raw-tool.c) gibt es den Quelltext des kleinen C-Progrämmchens und hier (http://christian-hoffmann.com/sonyuserforum/raw-tool) gibt es eine für Intel-Macs vorkompilierte Version.
Das Programm wird ohne Parameter aufgerufen, nach den beiden RAW-Dateinamen wird gefragt. Die neue RAW-Datei wird derzeit noch als _altesraw.MRW abgespeichert - es kommt also nur ein Unterstrich vor den Dateinamen. Das werde ich noch ändern.
Wenn die Dateinamen der RAW-Dateien den Standardnamen der D7D entsprechen (PICT1234.MRW), kann man sowohl PICT1234 als auch (Shift/Capslock-schonend) pict1234 eingeben. Die Endung wird ergänzt, wenn sie fehlt.
Selbst kreierte Dateinamen müssen mit korrekter Groß/Kleinschreibung eingegeben werden (die Endung wird auch hier bei Bedarf ergänzt).
Das Mappen der 'Löcher' habe ich noch weggelassen, da ich mir da noch ein paar Gedanken zu machen muss. :)
Gute Nacht,
eiq
Edit: Es war bis grad eben noch ein kleiner Copy&Paste Fehler im Quelltext - wer er also bereits runtergeladen hat, sollte entweder neu runterladen oder in Zeile 65 raw in darkframe ändern.
Edit II: Ich hab mal noch eine kleine Fortschrittsanzeige eingebaut, auch wenn man die auf einem annehmbar schnellen Rechner nicht lange sieht. ;)
Edit III: (Wie oft darf man editieren? ;)) Jetzt kann der Name der Ausgabedatei frei gewählt werden und die Dateigröße ist nicht mehr hard-coded sondern wird aus der Datei gelesen (in der Hoffnung, dass die Größe bei anderen Formaten an derselben Position steht).
Hallo eiq,
ich bin beeindruckt, Dein Programm liest sich sehr gut! Leider kann ich es nicht laufen lassen, da ich keinen C-Compiler habe.
Meine oben angeschnittenen Gedanken möchte ich deshalb mit COMAL Zeilen erläutern, wo so große Felder leider nicht erlaubt sind.
Zunächst werden drei Felder deklariert für die drei RAW-Daten.
0090 DIM feld1#(-4:3011,-4:2003) //Original
0091 DIM feld2#(-4:3011,-4:2003) // Dunkelbild (evtl Mittelwert von mehreren Dunkelbildern)
0092 DIM feld3#(-4:3011,-4:2003) // Ergebnis
Es folgt das Lesen der Daten für file 1 und file 2 in der Art
0440 FOR y#:= -4 TO 2003 DO
0450 FOR x#:=-4 TO 3011 STEP 2 DO
0460 // step 2, da 3 Byte fuer 2 Pixel gelesen werden
0550 dwert1$:=""; dwert2$:=""
0560 FOR k:=1 TO 3 DO
0570 a$:=GET$(1,1)
0580 IF a$="" THEN a$:=CHR$(0)
0600 dwert1$:=dwert1$+a$
0610 ENDFOR k
0630 // aus drei 8-Bit-Werten werden zwei 12-bit-werte
0650 drei8_in_zwei12(dwert1$,wertfile1pix1#,wertfile1pi x2#)
0700 feld1#(x#,y#):=wertfile1pix1#
0710 feld1#(x#+1,y#):=wertfile1pix2#
0730 ENDIF
0740 ENDIF
0770 ENDFOR x#
0780 ENDFOR y#
Dann wird Feld 3 erzeugt durch Subtraktion.
Wegen der Organisation der Pixel auf dem Chip (x nach rechts, y nach unten, Startwerte jeweils -4)
rgrgrgrgrgrgrg
gbgbgbgbgbgb
rgrgrgrgrgrgrg
gbgbgbgbgbgb
rgrgrgrgrgrgrg
gbgbgbgbgbgb
müssen dann im Bereich 0<=x<=3007(***); 0<=y<=1999 "Löcher" im File 3 gesucht werden und durch Interpolation ersetzt werden.
Für BLAU (wenn x ungerade und y ungerade)
und für ROT (Wenn x gerade und y= gerade)
könnte man Mittelwerte von den Positionen x-2 und x+2 und y-2 und y+2 bilden.
Für die übrig bleibenden GRÜNen Pixel Mittelwerte aus den 4 umgebenden grünen Pixeln bei x+/-1, y+/-1.
Gruß,
Stuessi
(***) Wert korrigiert
Stephan Stoske
29.12.2006, 13:18
Hi,
anstatt mit hohem Aufwand subtraktiv zu arbeiten, wäre es um Längen geschickter, einfacher und auch qualitativ wesentlich besser, wenn man additiv arbeiten würde.
Anstatt also ein Bild mit sehr langer Belichtungszeit zu schiessen, wäre es besser sehr viele Bilder zu machen und aus diesen den Mittelwert zu berechnen.
Die Vorteile sind immens: Anstatt die sich addierenden Fehler zu sammeln und umständlich per Darkframe wieder zu entfernen, reduzieren sie sich bei der Vermittlung von alleine mit jedem weiteren Bild. Das Sensorglühen ist dann kein Thema mehr, ein Darkframe garnicht mehr nötig und das Rauschen kann um bis zu 10 dB verringert werden ohne auch nur das kleinste Quentchen des gewünschten Signals zu verlieren. Sinnvolle Programme zur Vermittlung sind NoiseRemove, PTAverage, ImageStacker, Giotto o.ä.
Grüße, Stephan Stoske
Anstatt also ein Bild mit sehr langer Belichtungszeit zu schiessen, wäre es besser sehr viele Bilder zu machen und aus diesen den Mittelwert zu berechnen.
Diese Programme funktionieren anders. Hier werden keine Aufnahmen addiert, sondern Durchschnitte gebildet. Das Ausgangsbild an sich ändert sich also nicht und bleibt von der Helligkeit gleich. Aus vielen kurz belichteten Bildern wird hier kein Bild berechnet, das einem Bild mit längerer Belichtungszeit entspricht. (Ich hab mir Deinen Text nochmal durchgelesen. Es kann sein, daß ich den Satz falsch interpretiert hab, und Du eigentlich genau das meinst, was ich weiter unten vorschlage. ;))
Es wird durch die große Stichprobe (mehrere gleiche Bilder) das zufällige Rauschen in den Bildern verringert. Die Hotpixel sind jedoch meist an der gleichen Stelle, sodaß sich diese mit dieser Methode nicht verringern.
Genau das hat ein Freund von mir (Physikstudent) vor einiger Zeit in einem Nikon-Forum mal ausgiebiger getestet: http://www.nikoninfo.de/discus/messages/11/88405.html (leider fehlen die meisten Bilder, da sein Arcor-Account wohl nicht mehr existiert)
Man könnte probieren, die Methoden zu kombinieren: x Aufnahmen und x Darkframes, welche jeweils gemittelt und dann voneinander abgezogen werden. Ich befürchte allerdings, daß keines der Programme mit RAW-Daten arbeitet (habe es noch nicht genau überprüfen können). Mit etwas Zeit ließe sich das aber sicher programmieren.
Gruß, eiq
Hi,
anstatt mit hohem Aufwand subtraktiv zu arbeiten, wäre es um Längen geschickter, einfacher und auch qualitativ wesentlich besser, wenn man additiv arbeiten würde.
Hallo Stephan,
da irrst Du, nur wenn die PhotonenStatistik das Rauschen in den einzelnen Bildern dominiert, wird durch Stacking das Signal zu Rauschen Verhältnis besser. Aber auch dann sollten möglichst viele Photonen erfasst werden, die einzelnen Belichtungszeiten also so lang wie möglich sein (natürlich ohne "Überlaufen" der Pixel).
Benötige ich 300 sec, um ein schwaches Bild einer Galaxie zu erhalten, dann ist auf einer 1 sec lang belichteten Aufnahme absolut nichts von der Galaxie zu sehen, wohl aber schon etwas vom Sensorrauschen.
Auf 300 Bildern zu 1 sec habe ich 300 mal Sensorrauschen, sonst nichts!
Gruß,
Stuessi
bleibert
29.12.2006, 23:11
anstatt mit hohem Aufwand subtraktiv zu arbeiten, wäre es um Längen geschickter, einfacher und auch qualitativ wesentlich besser, wenn man additiv arbeiten würde.
Anstatt also ein Bild mit sehr langer Belichtungszeit zu schiessen, wäre es besser sehr viele Bilder zu machen und aus diesen den Mittelwert zu berechnen.
Hallo Stephan!
Wie Stuessi schon erklärt hat, ist das nicht das gleiche: Mehrere kurz belichtete Aufnahmen ersetzen nicht eine lang belichtete.
Witzigerweise habe ich im Verlauf dieses Threads schon an Dich denken müssen:
Entfernung von bewegten Objekten (http://www.stoske.de/digicam/Experiment/nomov.html)
Bei dieser Lösung werden ja auch Mittelwerte gebildet, unter Ausschließung von Ausreissern. Gibt es denn da irgendwo ein lauffähiges Progrämmchen zum Download, so dass man damit mal ein wenig spielen kann?
Hallo,
bei der Arbeit an meinem Sternstrichspurenbild,
http://www.sonyuserforum.de/galerie/data/thumbnails/871/Sternstrichspur1620neu-01_g.jpg (http://www.sonyuserforum.de/galerie/details.php?image_id=42344)
das aus 20 jeweils 3 Minuten lang belichteten Bildern zusammengesetzt ist, kam mir die Idee, den Dunkelbildabzug im TIFF-Format in Photoshop vorzunehmen. Das Ergebnis hat mich aber veranlasst, doch 20 mal im RAW-Format die Subtraktion vorzunehmen.
Hier ein Vergleich:
http://www.sonyuserforum.de/galerie/data/thumbnails/6/Subtraktion_von_Dunkelbild_Kopie.jpg (http://www.sonyuserforum.de/galerie/details.php?image_id=42426)
Subtrahiert man erst im TIFF-Format, so entstehen schnell "Löcher", subtrahiert man im RAW-Format, so wird die Intensität einzelner Pixelwerte zwar auch schon mal auf Null gesetzt, bei der Konvertierung bleiben in 2 Farbkanälen aber immer noch Werte übrig, so dass keine "Löcher" entstehen.
Gruß,
Stuessi
cat_on_leaf
14.08.2007, 16:02
Ich finde das alles durchaus interessant, aber wie kann ich das jetzt als reinrassiger User, der nix Programmieren kann, nutzen? Ich würde es nämlich gerne nutzen.
Danke im Vorraus
Rainer
BodenseeTroll
14.08.2007, 19:49
Im Moment wohl noch nicht. Leider.
Aber das Ganze ist ja auch noch ausbaufähig: Im Grunde kann man auf diesem Weg ja Bilder addieren, dividieren und sonstwie verrechnen, man bekommt sozusagen einen Taschenrechner für Bilder.
Grüsse vom Bodensee,
Michael
Ich würde es nämlich gerne nutzen.
Hallo,
meine Programmierkenntnisse beschränken sich auf COMAL. Hier (http://www.sonyuserforum.de/forum/showpost.php?p=325331&postcount=20) wurde meine .exe Datei angeboten. In dieser auf DOS-Ebene basierenden Sprache habe ich für meine Zwecke auch schon mal Addition und Mittelwertauswertung programmiert.
Aber andere haben, wie oben zu lesen, das in anderen Sprachen nachprogrammiert. Elric (http://www.sonyuserforum.de/forum/showpost.php?p=327850&postcount=26) hat eine Exel VBA-Version entwickelt und eiq (http://www.sonyuserforum.de/forum/showpost.php?p=443791&postcount=31) berichtet von einer C-Version.
Vielleicht sollte man das mal alles ins Forum stellen!
Gruß,
Stuessi
the live
13.01.2008, 22:42
Funktionieren die von euch erstellten Programme auf mit dem Adobe-Farbraum???
Gruß
Andreas
Funktionieren die von euch erstellten Programme auf mit dem Adobe-Farbraum???
Gruß
Andreas
Die Programme bearbeiten die RAW-Daten. Die sind erst einmal frei von Farbräumen.
the live
27.03.2008, 09:44
So... hier (http://christian-hoffmann.com/sonyuserforum/raw-tool.c) gibt es den Quelltext des kleinen C-Progrämmchens und hier (http://christian-hoffmann.com/sonyuserforum/raw-tool) gibt es eine für Intel-Macs vorkompilierte Version.
Das Programm wird ohne Parameter aufgerufen, nach den beiden RAW-Dateinamen wird gefragt. Die neue RAW-Datei wird derzeit noch als _altesraw.MRW abgespeichert - es kommt also nur ein Unterstrich vor den Dateinamen. Das werde ich noch ändern.
Wenn die Dateinamen der RAW-Dateien den Standardnamen der D7D entsprechen (PICT1234.MRW), kann man sowohl PICT1234 als auch (Shift/Capslock-schonend) pict1234 eingeben. Die Endung wird ergänzt, wenn sie fehlt.
Selbst kreierte Dateinamen müssen mit korrekter Groß/Kleinschreibung eingegeben werden (die Endung wird auch hier bei Bedarf ergänzt).
Das Mappen der 'Löcher' habe ich noch weggelassen, da ich mir da noch ein paar Gedanken zu machen muss. :)
Gute Nacht,
eiq
Edit: Es war bis grad eben noch ein kleiner Copy&Paste Fehler im Quelltext - wer er also bereits runtergeladen hat, sollte entweder neu runterladen oder in Zeile 65 raw in darkframe ändern.
Edit II: Ich hab mal noch eine kleine Fortschrittsanzeige eingebaut, auch wenn man die auf einem annehmbar schnellen Rechner nicht lange sieht. ;)
Edit III: (Wie oft darf man editieren? ;)) Jetzt kann der Name der Ausgabedatei frei gewählt werden und die Dateigröße ist nicht mehr hard-coded sondern wird aus der Datei gelesen (in der Hoffnung, dass die Größe bei anderen Formaten an derselben Position steht).
Wenn ich mit diesem Programm von einem RAW-File ein Darfframe substrahiere und die Datei danach in LR importiere steht, dass die Datei fehlerhaft sei?
Gruß
Andreas