PI Abbruch bei FITS Dateien der EOS

  • Ersteller des Themas Ersteller des Themas Ehemaliges Mitglied
  • Erstellungsdatum Erstellungsdatum
Status
Es sind keine weiteren Antworten möglich.

Ehemaliges Mitglied

Meine aktuellen Daten von IC1386, Cave Nebel und NGC869 lassen sich nicht mit PI verarbeiten. Jeweils 20 Bias, Darks, Flats und Lights haben für den Gesamtprozess mit MaximDL 20 Minuten benötigt. PI bricht nach 2 Stunden mit einer Fehlermeldung noch vor der Integration ab. Die Masterfiles für Bias und Flats sind in Ordnung, das Masterfile der Darks ist komplett weiss obwohl die Einzeldarks in Ordnung sind. Kommt PI nicht mit den Fits Dateien der EOS zurecht? Die werden ja statt der CR3 Files der Kamera von Asiair als Fits gespeichert. Hat jemand eine Idee?

CS Horst
 
Der Wortlaut der Fehlermeldung ist ein Geheimnis?
Für mich klingt das so, als wären die Bildtypen falsch zugeordnet. Wenn er z.B. in den Darks nach Sternen sucht, wird er scheitern. Dabei gehe ich davon aus, dass du das WBPP-Script verwendest, aber auch die Info bleibt unter Verschluss.
Gruß
Sebastian
 
Hallo Horst,
wenn Du WBPP verwendet hast, dann erstellt das auch eine sehr ausführliche Logfile. Die kannste ja mal hier zur Verfügung stellen.
Komplett weißes Dark klingt jedenfals komisch. Am besten nochmal wirkliche alle Dateien durchblinken, nicht nur die Lights.
Gruß
André
 
Ich mache noch einen Versuch und melde mich danach. Falsch zugeordnet ist jedenfalls nichts. Ich nehme aber nur jeweils 5 Files, sonst dauert es Stunden ?
 
Die Fits Header von Bias, Darks und Flats sind jedenfalls ok. Hätte mich auch gewundert, sonst hätte MaximDL auch gemeckert
 
Stimmt die Geometrie als Pixelanzahl X und Y der einzelnen Files?

Meine mich schwach zu erinnern, das es da mal was gab in Zusammenhang mit Canons. Kann aber komplett daneben liegen.
 
So hier das Ergebnis mit jeweils nur 5 Files

1723481849520.png


1723481866793.png


1723481901751.png


Logfile ist ziemlich groß, speichere es als Datei ab und verlinke hier
 
Zitat von astro_alex80:
Stimmt die Geometrie als Pixelanzahl X und Y der einzelnen Files?

Meine mich schwach zu erinnern, das es da mal was gab in Zusammenhang mit Canons. Kann aber komplett daneben liegen.
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Das stimmt. Das Problem hatte ich mal mit Ekos, als ich die Daten von der Canon als Fits gespeichert habe. Die waren dann ein paar Pixel kleiner oder größer als die CR Dateien mit denen ich später Kalibrieren wollte.

Also zum Logfile: Ich würde das sagen, da ist was mit der Kalibration schief gegangen. Schau dir mal die kalibrierten Frames an, ob die vernünftig aussehen. PI kann offenbar keine Noise Evaluation durchführen...vermutlich weil die Werte nach unten geclippt sind.
Gruß
André
 
Hallo Horst
Laut logfile konnte kein Referenz-frame ausgewählt werden.
Daher würde ich eines manuell auswählen und so testen.

Zweitens sind die Dateinamen ellenlang, in den Diagnostic Messages wird zwar nur auf Pfade grösser als 256 Zeichen verwiesen, aber auch das ist ein Versuch wert.
Gruss und viel Erfolg
Mike
 
Zitat von DerOndre:
Das stimmt. Das Problem hatte ich mal mit Ekos, als ich die Daten von der Canon als Fits gespeichert habe. Die waren dann ein paar Pixel kleiner oder größer als die CR Dateien mit denen ich später Kalibrieren wollte.

Also zum Logfile: Ich würde das sagen, da ist was mit der Kalibration schief gegangen. Schau dir mal die kalibrierten Frames an, ob die vernünftig aussehen. PI kann offenbar keine Noise Evaluation durchführen...vermutlich weil die Werte nach unten geclippt sind.
Gruß
André
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Ja, dass die Kalibrierung schief läuft sehe ich auch. Die Frage ist warum. Da ich auch die Kalibrierungsdaten als Fits und und nicht als CR Daten verwende, kann auch das oben genannte Problem nicht zutreffen. Die Pixelgrößen aller Files stimmen überein.
 
Zitat von Mike G:
Hallo Horst
Laut logfile konnte kein Referenz-frame ausgewählt werden.
Daher würde ich eines manuell auswählen und so testen.

Zweitens sind die Dateinamen ellenlang, in den Diagnostic Messages wird zwar nur auf Pfade grösser als 256 Zeichen verwiesen, aber auch das ist ein Versuch wert.
Gruss und viel Erfolg
Mike
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Ich denke, die Kalibrierung geht schief, weil das Masterdark Schrott ist. Das von MaximDL erzeugte Masterdark mit den gleichen Daten ist perfekt. Und mit den Dateinamen muss PI schon zurecht kommen. Ach so, einen manuellen Referenz Frame habe ich schon ohne Erfolg probiert.
 
Zuletzt von einem Moderator bearbeitet:
Du hast verschiedene bittiefen in deinen Kalibrierungs-dateien.
Woher kommt das?

Darks
2024-08-12 17:28:35] C:/Users/hjzie/Documents/Astronomie/DSLR_EOS77D/Dark/Dark_180.0s_Bin1_20240720-235215_0002.fit
[2024-08-12 17:28:35] 33 FITS keywords extracted
[2024-08-12 17:28:35] Reading FITS image: 32-bit floating point, 1 channel(s), 6024x4020 pixels: done
[2024-08-12 17:28:35] Rescaling sample values: [7564,65532] -> [0,1]: done
[2024-08-12 17:28:35] Computing image statistics: done

Und hier Flats
2024-08-12 17:29:15] [001] C:/Users/hjzie/Documents/Astronomie/DSLR_EOS77D/Flat/Flat_20.0ms_Bin1_20240729-181441_0004.fit
[2024-08-12 17:29:15]
[2024-08-12 17:29:20] * Loading target calibration frame: C:/Users/hjzie/Documents/Astronomie/DSLR_EOS77D/Flat/Flat_20.0ms_Bin1_20240729-181437_0003.fit
[2024-08-12 17:29:20] Reading FITS image: 16-bit integers, 1 channel(s), 6024x4020 pixels: done
 
Wow, das ist eine gute Frage. Ich habe eben einmal alle Darks überprüft, 6 von 10 haben 32 Bit, 4 haben 16 Bit. Alle am gleichen Tag mit Asiair gemacht. Muss ich überprüfen woher das kommt und ob es daran liegt. Auch alle anderen Files haben 16 Bittiefe, nur eben diese 6 Darks nicht. Strange.
 
Zuletzt von einem Moderator bearbeitet:
Hallo Mike,
danke, dein Hinweis war godrichtig. Ich habe die 32er Darks rausgeschmissen und den Prozess nochmal mit jeweils nur 4 Frames durchgeführt. Jetzt lief es durch, hat allerdings für diese paar Frames 1,35 Stunden gedauert. Danke nochmals, jetzt weiss ich wenigstens woran es lag, aber immer noch nicht wie es entstanden ist. Egal, bei diesen Laufzeiten ist es aber eh nicht machbar. Wahrscheinlich bräuchte ich die ganze Nacht, um meine jetzt 40 Lights durchzubekommen.
LG Horst
 
Ich vermute, dass ich die Darks zur Überprüfung einmal mit Fitswork aufgemacht und aus Versehen wieder abgespeichert habe. Das würde die 32er Version erklären.
 
Da ich doch einmal wissen wollte, wie lange PI für die 3x20 Kalibrierungsfiles und 77 Lights benötigt, habe ich heute morgen auf meinem Laptop, auf dem sonst nichts läuft das WBPP gestartet. Jatzt nach 7 Stunden ist das Proramm noch nicht einmal bei der Integration. Absolut unbrauchbar auf meinem Rechner. Mit MaximDL bin ich nach 1 Stunde fertig.

1723560828384.png
 
Hallo Horst,
brauchst Du denn wirklich die Local Normalization? Ich finde, wenn man jetzt nicht ganz kompliziierte Gradienten und Helligkeitsunterschiede im Bild hat, kann man da auch getrost drauf verzichten.
Gruß
André
 
Rein aus Neugier ! versuche mal unter WBPP und dann im Reiter Post Calibration und unter fast Intergration auf ENABLE zu setzen, vielleicht hilft es, schneller die Daten bearbeitet werden ?

CS

Martin
 
FBPP habe Ich noch nicht versucht, WBPP gefällt mir ( auch wenn Ich FBPP nicht ganz genau kenne ) sehr gut !!
Laut PI NEWSLETTER sollte FBPP auch sehr gut sein, muss aber voher das Video ansehen..

CS
Martin
 
So, das ging jetzt deutlich schneller. Allerdings sind die Farben sehr unterschiedlich.
FBPP Dauer 1h 37min,
MaxImDL Dauer 1h 3min

1723570410074.png

PI Master Light nach DBE und STF AutoStretch

1723570612937.png


MaxImDL Group77.Fits nach DBE und STF AutoStretch

Nochmals danke für die Tipps

CS Horst
 
Status
Es sind keine weiteren Antworten möglich.
Zurück
Oben