Color Picture Module

[dietmar]

Moin Carsten,

Und nun kommst Du mit der Lösung um die Ecke. Danke. Ich dachte schon an alles Mögliche, wie ich das beherschen könnte. Und nun ist es so einfach.

Bitte, bitte.
Und Du verwendest auch Canon-Kameras? Hattest Du da keine Probleme mit grünen Bildern?

Gruß
Dietmar

[moos]

Und Du verwendest auch Canon-Kameras? Hattest Du da keine Probleme mit grünen Bildern?

Hi Dietmar, nein es ging zunächst nur bei EOS 500, nicht aber bei der 1200D, weil theli eine ungerade Anzahl an Spalten erzeugt hatte. Mischa hat dann das Erzeugen der Camera ini überarbeitet und nun ist es ok.
Kann es sein, dass deine Kamera.ini schon älter als etwa zwei Wochen ist?
Ich hatte deine ini mit meiner verglichen und gesehen, dass beide identisch sind. Daher wundert es mich noch mehr, dass deine grün sind. Haben die den gleichen Sensor?

[moos]

Trotzdem ist das mit der Bayer-Matrix komisch. dcraw sagt nämlicht RGGB und so hab' ich das auch irgendwoanders gelesen.
Stimmt das CUTY vielleicht nicht? Denn das overscan geht bis 51, CUTY ist aber 53.
Ich weiss nicht ob es was zu bedeuten hat, ist mit nur aufgefallen.

( ich dachte ich hätte das gerade bereits geschrieben, aber esist nicht da)

Die Bayermaske des Sensors und das was die Software daraus macht ist völlig von einander unabhängig. die ifstreams können das Bild von oben nach oder von unten nach oben aufbauen oder von rechst nach links. Dabei verändert sich immer das Mosaik. Siehe Bild im Anhang. Hast Du einmal eine Kombination aus cutx, cuty und Bayer-Maske für deine Kamera.ini gefunden, bleibt es so. Ganz egal wie der Sensor aufgebaut ist.

Das debayer.cc schneidet das Bild im Speicher zunächst auf gerade Anzahl an cols und rows. Dann schneidet es nach der Angabe der Bayermaske das Bild im Speicher immer auf eine RGGB - Maske, So funktionieren die Algorithmen für alle Mosaike gleich.

[mischa]

wieso heißen die fits .mosiac.? Das ist bei mir bisher nicht gewesen.

Das war schon immer so, zumindest seit Tag v3.0.0, ist in https://github.com/schirmermischa/THELI/blob/master/src/processingInternal/processingCollapse.cc hardcoded.

Ihr meint 'mosaic'? Die werden erstellt, wenn man "binned preview" macht. Da werden bei Multi-chip Kameras die chips in ihrer ungefaehr korrekten relativen Orientierung zu einem Bild zusammengesetzt und gebinnt, sodass man einen besseren Ueberblick ueber die Datenqualitaet einer Aufnahme bekommt. Manche unserer Kameras haben zwischen 36 und 100 Detektoren, da kommt einiges zusammen. Daher auch das "mosaic".

Bei single-chip Kameras braucht man das nicht. Die kann man in 'iview' auch einfach rauszoomen.

[mischa]

Hi Dietmar,

Das war schon immer so, zumindest seit Tag v3.0.0, ist in https://github.com/schirmermischa/THELI ... ollapse.cc hardcoded.

Das rettet mich. Ich muss zugeben, dass wusste ich nicht, habe ich aber vermisst.

Nun verwende ich nur noch die EOS 1200D und manchmal eine EOS 500D und da passiert es, dass es diese horizontalen Streifen gibt, im Dark und im light.

Hi Carsten, das sind Bias-Instabilitaeten beim readout. Dazu gibt es den Overscan. In THELI v3 wird der auch bei RAW Daten korrigiert falls vorhanden, ich hab aber nicht viel Erfahrung damit. Mit der "collapse correction" kriegt man solche Streifen auch weg, da muss man aber vorsixhtig sein, wenn man signifikant ausgedehnte Objekte mit diffusen Halos hat, die z.B. mehr als 5-10% der Bildbreite einnehmen. Wenn man die Halos nicht maskiert bekommt, dann gehen sie in das Hintergrundmodell mit ein und dann kommt es zu einer (eventuell sehr leichten) Ueberkorrektur. Oft merkt man das erst am koaddierten Bild, wenn ein dunkler Streifen durch eben dieses Objekt laeuft.

msicha

[mischa]

Trotzdem ist das mit der Bayer-Matrix komisch. dcraw sagt nämlicht RGGB und so hab' ich das auch irgendwoanders gelesen.
Stimmt das CUTY vielleicht nicht? Denn das overscan geht bis 51, CUTY ist aber 53.
Ich weiss nicht ob es was zu bedeuten hat, ist mit nur aufgefallen.

Hi Dietmar,

ich werde dem nicht weiter auf den Grund gehen. THELI schneidet das ab, was in den RAW Daten als overscan (nicht belichtete Pixel, physisch oder virtuell) angegeben ist. Anschliessend wird geschaut, ob ein geradzahlig dimensioniertes Bild ueberbleibt. Falls nicht, wird nochmal eine Zeile oder Spalte abgeschnitten und dann die Bayercodierung angenommen, die du im kamera.ini vorgegeben hast. Da muss man als Benutzer im schlimmsten Fall halt 4 mal probieren, bis im koaddierten Bild die richtigen Farben rauskommen. Oder man laedt drei FITS nach dem HDU-reformatting in Photoshop oder aehnliches, dann sieht man auch gleich ob die Farben stimmen.

Nachdem es jetzt bei dir geht, wuerde ich es nicht mehr anfassen. Die Pixelskala, Namen usw kannst du im kamera.ini ja anpassen, aber die Geometrie nicht.

LG,

mischa

[moos]

Hi Carsten, das sind Bias-Instabilitaeten beim readout. Dazu gibt es den Overscan. In THELI v3 wird der auch bei RAW Daten korrigiert falls vorhanden, ich hab aber nicht viel Erfahrung damit. Mit der "collapse correction" kriegt man solche Streifen auch weg, da muss man aber vorsixhtig sein, wenn man signifikant ausgedehnte Objekte mit diffusen Halos hat, die z.B. mehr als 5-10% der Bildbreite einnehmen. Wenn man die Halos nicht maskiert bekommt, dann gehen sie in das Hintergrundmodell mit ein und dann kommt es zu einer (eventuell sehr leichten) Ueberkorrektur. Oft merkt man das erst am koaddierten Bild, wenn ein dunkler Streifen durch eben dieses Objekt laeuft.

Habe ich gemerkt und neue Streifen bekommen.

[mischa]

Habe ich gemerkt und neue Streifen bekommen.

Du kannst versuchen, den detektionsthreshold (DT) runterzusetzen. Aber dann laeufst du eventuell Gefahr, den stoerenden Streifen selbst zu maskieren und nicht nur einen echten Objekthalo, mit dem Ergebnis, dass er nachher umso deutlicher in Erscheinung tritt. Um das zu vermeiden, kannst du einen hoeheren threshold setzen, und dann die Groesse der Objektmaske zu skalieren, (zum Beispiel "mask expansion factor = 2 ... 3"). Das braucht etwas an Erfahrung.

mischa

[dietmar]

Und Du verwendest auch Canon-Kameras? Hattest Du da keine Probleme mit grünen Bildern?

Hi Dietmar, nein es ging zunächst nur bei EOS 500, nicht aber bei der 1200D, weil theli eine ungerade Anzahl an Spalten erzeugt hatte. Mischa hat dann das Erzeugen der Camera ini überarbeitet und nun ist es ok.
Kann es sein, dass deine Kamera.ini schon älter als etwa zwei Wochen ist?
Ich hatte deine ini mit meiner verglichen und gesehen, dass beide identisch sind. Daher wundert es mich noch mehr, dass deine grün sind. Haben die den gleichen Sensor?

Nein, ich meinte, dass, meiner Kenntnis nach, alle Canon-Kameras das Pattern RGGB verwenden und Du deshalb ähnliche Probleme hättest haben sollen.
Da jedoch alle auf RGGB normiert werden ist das egal.

Der Release Tag v3.0.0 ist mir erstmal mit einem segmentation fault abgesemmelt, weil in der automatisch generierten kamera.ini eine ungerade sizey stand. Das ist aber längst gefixt.

Angesichts eines Bayer-Patterns (auf Wikipedia, Google-Bilder oder sonstwo) und dem Zweck von CUTX und CUTY, laut der Dokumentation von Theli v2 ("first pixel that receives light"), dachte ich, ein Heraufsetzen von CUTY um 1 (oder irgendeine andere ungerade Zahl) würde aus einem RGGB-Pattern ein GBRG-Pattern machen (wie Du es auch in deinem Post beschreibst).
Ich hab' daraufhin mit CUTY rumgespielt, ohne dass sich augenscheinlich etwas geändert hat. Daher vermute ich, dass es ignoriert oder irgendwo überschrieben wird.

ich werde dem nicht weiter auf den Grund gehen.
mischa

Gut, dann ist das so.
Meine H-alpha-Filamente sind jetzt rot, statt grün, meine M-Sterne auch, mehr wollte ich ja gar nicht

Viel Spaß noch
Dietmar

[mischa]

Code: Alles auswählen

Ich hab' daraufhin mit CUTY rumgespielt, ohne dass sich augenscheinlich etwas geändert hat. Daher vermute ich, dass es ignoriert oder irgendwo überschrieben wird.


So ist es, zumindest beim HDU reformatting wird die Bildgeometrie anhand der Informationen im RAW header bestimmt. Wenn man ein RAW heranzieht, um die Kamera erstmalig aufzusetzen, wird der gleiche Algorithmus verwendet, die beiden sind also identisch.
Die informationen im kamera.ini werden nur dann herangezogen, wenn man THELI zu einem spaeteren Zeitpunkt schliesst und dann dann wieder oeffnet. Dann sind keine RAW Dateien mehr vorhanden, sondern die teilweise oder komplett vorreduzierten FITS Dateien. da verlaesst sich THELI dann beim erstellen des datenmodells auf das was im kamera.ini drinsteht. Wenn das manuell geaendert wird und dann nicht mit der tatsaechlichen Geometrie uebereinstimmt, kracht es. Aber das war auch schon bei v2 so.

mischa

[moos]

Du kannst versuchen, den detektionsthreshold (DT) runterzusetzen. Aber dann laeufst du eventuell Gefahr, den stoerenden Streifen selbst zu maskieren und nicht nur einen echten Objekthalo, mit dem Ergebnis, dass er nachher umso deutlicher in Erscheinung tritt. Um das zu vermeiden, kannst du einen hoeheren threshold setzen, und dann die Groesse der Objektmaske zu skalieren, (zum Beispiel "mask expansion factor = 2 ... 3"). Das braucht etwas an Erfahrung.

Hi Mischa,
Standard war mit DT =1.5 und Mask Correction Faktor =6 (default )
Ein Probelauf mit DT =1.1 und Mask Correction Faktor =6 (default ) ist kein erkennbarer Unterschiede zu Standard
Ein Probelauf mit DT =1.5 und Mask Correction Faktor =0 (default ) ist kein erkennbarer Unterschiede zu Standard

Jetzt meine Frage: meinst Du mit höherem threshold DT auf 2 und meinst Du mit "Mask expansoin Factor = 2...3 " mal soviel wie default ( also 12-18)?

[mischa]

Hi Carsten,

Code: Alles auswählen

Standard war mit DT =1.5 und Mask Correction Faktor =6 (default )
Ein Probelauf mit DT =1.1 und Mask Correction Faktor =6 (default ) ist kein erkennbarer Unterschiede zu Standard
Ein Probelauf mit DT =1.5 und Mask Correction Faktor =0 (default ) ist kein erkennbarer Unterschiede zu Standard

Jetzt meine Frage: meinst Du mit höherem threshold DT auf 2 und meinst Du mit "Mask expansoin Factor = 2...3 " mal soviel wie default ( also 12-18)?


Der default des "mask expansion factor" ist "leer", also nichts, nicht "6". Mit DT=2 waere die Maske kleiner, das koenntest du gut mit einem mask expansion factor von 2-3 korrigieren (nicht 12-18).
Musst halt ausprobieren, das ist fuer jedes Objekt anders.

mischa