Warum ist Bayerpattern in Bias und Dark sichtbar

Status
Es sind keine weiteren Antworten möglich.

Bernd Limburg

Aktives Mitglied
Hallo,
habe eine Frage zu den "lichtfreien" Frames Bias und Dark: Warum sehe ich bei einer OSC (in dem Fall eine ASI294MC Pro) in diesen Frames das typische Bayer-Schachbrettmuster? Es fallen doch keine Photonen durch die Filter. Woher weiß ein Pixel im komplett Dunklen, welches Filter über ihm liegt?
CS
Bernd
 
Habe hier mal als Beispiel einen einzelnen Biasframe angehängt (Screenshot aus Pixinsight, mit ScreenTransferFunction gestreckt und stark herausgezoomt). Meiner Meinung nach darf man das Filterpattern in einem Biasframe (und auch in einem Darkframe) definitiv nicht sehen, die Pixel sind ja auch bei einer Color-Kamera alle gleichartig. Hier ist ja kein Photon im Spiel, dass durch die damüberliegenden RGB-Filter beeinflusst würde.

Bildschirmfoto 2020-01-28 um 08.29.43.jpg

Liegt das Ganze vielleicht an der speziellen RRGGBB-Struktur der ASI294MC und einer Vorverarbeitung des Raw-Bildes noch im Sensorchip? Werde auch mal im ZWO-Forum bei den Entwicklern nachfragen.
 
Hallo Bernd,

das sieht in der Tat merkwürdig aus. Ich habe mal einen entsprechenden Ausschnitt aus einem bias frame (gain 120, offset 30, 0.003 s, -15 °C) von meiner ASI294 angehängt, Auto Stretch mit PixInsights STF angewendet. Wie sieht denn das Histogramm aus? Zum Vergleich habe ich auch das Histogramm (unten: stark gespreizt, mit einem Horizontal zoom von 400) mit angehängt.

Bernd
BIAS_ASI294.JPG
Bias_ASI294_Histogramm.JPG
 
Hallo Bernd,
habe schnell mal bei meiner 294 100 Bias gestackt, kann das nicht nachvollziehen.Womit hast Du denn aufgenommen und welche Datenformate stehen da zur Verfügung ? Bist Du sicher, dass da nicht schon ein Debayern dabei war ?

Gruß
*entfernt*
 
Hallo,

danke für eure Antworten. Das bestätigt mir, dass da irgendwas faul sein muss. Ich habe die Bilder mit KStars/Ekos/Indilib (auf Raspi) im FITS-Format RAW 14bit aufgenommen. Werde mal in dem Forum dort nachhören. Vielleicht ein Bug im ASI-Treiber von Indilib.

Mein Histogramm sieht entsprechend meinem Schachbrettmuster aus, also 3 Peaks (2 sehr dicht beisammen, die dunklen Grautöne, und einer deutlich höher, das helle Grau). Histogramm und Bild passen also zusammen.

Ich hatte Gain 0 und Offset 14 eingestellt (für maximale Full-Well-Kapazität).

Viele Grüße
Bernd
 
Hi Bernd,
bist du sicher dass du da ein Bias genommen hast ?
Ich habe genau das Muster wenn ich ein Flat in PIX strecke, und voll ranzoome.
Bei den Bias sieht es aus wie bei Bulrichl...mmmhhhhhhhhh
Gruesse
Claude
 
Re, noch ein Bild dazu
Links das Flat ( wie bei dir Muster) und rechts das Bias.
Ist zwar von einer QHY10, aber das spielt ja keine Rolle
 

Anhänge

  • Screen Shot 01-28-20 at 02.06 PM.PNG
    Screen Shot 01-28-20 at 02.06 PM.PNG
    648,4 KB · Aufrufe: 256
Hi Claude,
genau das irritiert mich ja, das kann nicht sein. Ich habe definitiv ein Bias aufgenommen. Minimale Belichtungszeit (0.00032 s oder noch ein paar mehr Nullen nach dem Komma), Deckel auf dem Objektiv, Raum auch noch dunkel. Das nächste Photon war mindestens 5 Meter entfernt ;), zumindest im Sichtbaren. Das Muster ist ja auch extrem dunkel, es ist in dem ADU-Bereich, in dem ich auch das Bias-Rauschen erwartet hätte.
Sieht irgendwie aus, als ob da schon RGGB-Gains verrechnet worden wären...
Aber gut zu sehen, dass es bei euch allen so aussieht, wie man es erwartet. Habe schon an meinem Verständnis von Bias und Bayermatrix etc. gezweifelt...
Viele Grüße
Bernd
 
habe ich die fragestellung richtig verstanden?
die matrix kommt von der elektronik, welche den sensor ausliest. sonst würde ja ein bild ohne information die dateigröße 0 besitzen. also, auch wenn wenig photonen auftreffen (oder gar keine) hat das bild das typische pattern des sensors.
 
Ist der Offset von 14 automatisch eingestellt, wenn Du gain 0 wählst, oder hast Du das gewählt?

Am besten waäre es, wenn Du ein solches bias frame uploaden könntest (bei einem Filehoster) und den Link hier bekanntgäbest. Ich würde mir gerne mal das Histogramm und die Statistics anschauen.

Bernd
 
@andreasmax: Hallo und sorry, dass ich widerspreche, aber das stimmt so nicht. Klar kommt die „Matrix“ des Bildes, also hier in dem Fall das 4144x2822-Array, vom Sensor, der halt so viele Pixelzeilen und -spalten hat. Das typische Bayer-Pattern, das man auf Raw-Bildern (als Monochrom-Bilder interpretiert) sieht, kommt von den physikalischen Farbfiltern, die regelmäßig meist in RGGB-Anordnung über den Pixeln liegen, CFA-Pattern, Color Filter Array. Bei z. B. neutralweißem Bild zeigen die Rotpixel eine andere Intensität = Grauwert als die Grün- oder Blaupixel. Deswegen sieht man im Graustufen-Raw-Bild sozusagen das Abbild der Farbfilteranordnung, dieses schachbrettartige Muster. Durch “Debayern“ wird aus diesem Raw-Monochrombild dann das RGB-Bild mit den 3 Farbkanälen, aber das kommt hier ja noch gar nicht zum Einsatz. Die darunterliegenden Pixel sind alle gleich, das ist nur ein Monochrom-CMOS-Sensor. Zum Farbsensor wird er nur durch das CFA. Wenn man aber nun ein Bias- oder Dunkelbild aufnimmt, können die Filter über den Pixeln sein wie sie wollen, da kein Licht hindurchfällt entsteht auch nicht das Muster, das durch die unterschiedliche Absorption der Lichtwellenlängen entsteht. Da ja kein Licht da ist. Bei Darks nicht, und bei Biasframes schon gar nicht.

Und deswegen stimmt mit meinen Biasframes irgendwas nicht, momentan tippe ich auf einen Bug im Linux/Raspi-Treiber. Werde nachher mal Bilder mit der originalen ZWO-Software machen und posten.

CS
Bernd
 
Den Offset 14 habe ich so gewählt, dass im Biasframe das Pixelmittel bei etwa 1000 Counts liegt.
 
Hier sind Histogramm und Statistik:
Bildschirmfoto 2020-01-28 um 19.09.06.jpg
Bildschirmfoto 2020-01-28 um 19.05.14.jpg
 
Hier ist ein Biasframe mit der ZWO-Software ASIImg (unter MacOS). Das sieht plausibel aus.
Bildschirmfoto 2020-01-28 um 19.57.29.jpg
Liegt also anscheinend tatsächlich der Linuxumgebung (Raspi, KStars/Ekos/Indilib). Werde mich dort weiter umhören. Und bei ZWO im Forum auch (von denen ist der Linux-Indilib-Treiber). Aber da kriege ich aktuell niemanden, weil die chinesisches Neujahr feiern.
CS
Bernd
 
Ja, das könnte tatsächlich ein Software-Problem sein. Wurde das zuletzt gezeigte bias frame mit den gleichen gain- und offset-Einstellungen gemacht? Falls nicht, würde ich das mit der ZWO-Software ASIImg (unter MacOS) noch nachholen, zum Vergleich.

Bernd
 
Hallo Bernd,
ASIImg bietet nur Gain "low-medium-high", ich hatte "low" gewählt. Offset kann man gar nicht einstellen. Im FITS-Header steht Gain 0 und Pedestal 0. Pedestal klingt bisschen nach Offset. Aber bei einem Offset von 0 liefert der Sony-Sensor der ASI294 Bias-Frames aus reinen Nullen, zumindest unter meinem Linux-Setup.

Bildschirmfoto 2020-01-28 um 20.55.15.jpg
 
Ich glaube ich habe die Antwort! Im Indilib-Treiber gab es eine Einstellung "WB_R" und "WB_B" (white balance red und blue). Die Werte standen auf WB_R = 52 und WB_B = 95. Der Range ist anscheinend 0-100 und stellt einen Faktor dar, mit dem die Rot-Pixel (WB_R) bzw. Blau-Pixel (WB_B) noch im Raw-Bild multipliziert zu werden scheinen. Damit wird Blau rechnerisch fast doppelt so hoch gezogen wie Rot bzw. Grün (Blau = 95, Rot = 52, Grün = 50). Deshalb sind die Blau-Pixel im Noise-Bild deutlich heller und das Bayer-Pattern erscheint, allerdings künstlich erzeugt.

Habe die Werte jetzt beide mal auf 50 gesetzt:
Bildschirmfoto 2020-01-28 um 21.34.17.jpg
Und jetzt sieht der Bias-Frame ganz normal aus:
Bildschirmfoto 2020-01-28 um 21.30.38.jpg
Histogramm wie aus dem Bilderbuch:
Bildschirmfoto 2020-01-28 um 21.30.54.jpg
Und noch die Statistik:
Bildschirmfoto 2020-01-28 um 21.31.36.jpg
Sowas muss einem aber auch mal gesagt werden... ;)

Naja, bin froh, dass es sich so lösen ließ.

CS
Bernd
 
Hallo Bernd,

So etwas habe ich noch nie gesehen. Wenn die Rohdaten (Intensitätswerte) durch Einstellung der Werte WB_BLUE und WB_RED im Indilib-Treiber verändert und diese modifizierten Daten in die FITS-Datei geschrieben würden, dann enthielte die erzeugte Datei keine Rohdaten mehr. Ich kann mir besten Willen nicht vorstellen, dass der Indilib-Treiber dies macht -- in diesem Fall wäre er in der jetzigen Version völlig unbrauchbar. Ich glaube eher, dass dies vom Programm ASIimg verbrochen wird. In jedem Fall ist das ein gravierender Bug.

Der Weißabgleich muss immer NACH dem Preprocessing (bei einer OSC-Kamera: nach Kalibrierurung (mit MasterDark, MasterFlat), Debayern, Ausrichtung und Integration) erfolgen.

Ich vermute, dass ASIImg auch den FITS header schreibt. Über den kann ich mich ebenfalls nur wundern: da gibt es eine Reihe von keywords, die offenbar Neuschöpfungen sind, z. B.:

BRIGHT, EXPONIUS, WB_BLUE, WB_RED, CSTRETCH, INPUTFMT

Für mich ware das ein weiterer Grund, dieses Programm nicht zu verwenden. Ich halte es nicht für erstrebenswert, immer neue FITS keywords zu kreieren, die von Bildbearbeitungs-Software nicht verstanden werden.

An Deiner Stelle würde ich daher eine andere Software zur Aufnahme der Bilder verwenden und testen, ob eine Änderung von WB_BLUE und WB_RED Auswirkungen auf die Intensitäteswerte in der FITS-Datei haben. Das darf nicht der Fall sein.

=================================================

"Pedestal" ist nicht identisch mit "bias offset".

Der bias offset ist im Kameratreiber einstellbar. Er wird als konstanter Wert [in ADU] bei der A/D-Wandlung addiert, um ein Abschneiden negativer Werte zu vermeiden. Wie beim gain sind offset-Einstellwert und der addierte Wert [in ADU] nicht das gleiche. Bei der ASI294 verhält es sich folgendermaßen:

Aus Gain and Sub-exposure calculation spreadsheet for the ZWO ASI183 and 294 - Page 2 , post#49:
"For anyone using an ASI294 and looking at their Bias or Dark Frames, keep in mind that the delivered frames have been multiplied by 4 by the ASCOM driver (conversion into the 16 bit measurement space) so Offsets will appear to have a Scaling Factor of 64x ADU rather than only 16x."

Beispiel: Deine offset-Einstellung von 14 führt zu einem mittleren Intensitätswert in bias frames von 14*16*4 ADU = 896 ADU. Das ist genau der Wert, den Du in Deinen zuletzt gezeigten Statistics erhalten hast.
---
Manche Kameras (z. B. von SBIG) addieren zusätzlich ein konstantes pedestal auf die Intensitätswerte und schreiben ein FITS keyword PEDESTAL mit dem jeweiligen Wert.
---
Ein "output pedestal" wird manchmal beim Preprocessing in PixInsight benötigt, um negative Werte bei der Subtraktion des MasterDark zu vermeiden.

Bernd
 
Hallo Bernd,

danke für deine ausführliche Antwort!

Es ist aber definitiv so, dass der Indilib-Treiber WB_R und WB_B-Werte von 52 bzw. 95 defaultmäßig eingestellt hat und diese zu den erhöhten Blaupixeln (und auch leicht erhöhten Rotpixeln) führen. Also erfolgt diese Multiplikation mit 52/50 bzw. 95/50 vor der FITS-Ausgabe und damit sind das keine "reinen" Rohdaten, sehe ich auch so. Wenn man die Werte im Treiber auf 50 stellt, ist alles OK. Ich denke, dass mit WB_R und WB_B ein RGGB-Gain-Vektor erzeugt wird, der noch auf das undebayerte Bild losgelassen wird und der deshalb am Besten auf (1, 1, 1, 1) bzw. (50, 50, 50, 50) stehen sollte (wobei sich die beiden 50er für die beiden Grün-Pixel nicht einstellen lassen, ist ja auch nicht nötig). Und vermutlich geschieht das noch in der Firmware der Kamera, so dass ein Aufnahmeprogramm da keinen Einfluss drauf hat (außer vorher die Werte halt auf 50 zu setzen).

ASIImg benutze ich gar nicht, das war nur gestern, um zu sehen, wie da die Biasse aussehen. Und ASIImg hat es ja richtig gemacht!

Im Indilib-Forum habe ich das auch gepostet, aber da reagiert keiner. Ist relativ träge, dieses Forum.

Da ich mein ganzes Setup auf den Raspi mit KStars/Ekos/Indi ausgerichtet habe, um remote "vom Warmen aus" das Teleskop zu steuern, möchte ich kein anderes Programm benutzen, um die Bilder zu machen. Und mit WB_R und WB_B auf 50 passt es ja. Der ASI-Indi-Treiber kommt glaube ich auch von ZWO, wenn ich das richtig gelesen habe. Aber die feiern weiterhin Neujahr und haben mit ihrem Coronavirus momentan wohl andere Sorgen. Das Forum dort ist aktuell komplett verlassen, da kann ich mich noch nicht mal registrieren.

VG
Bernd
 
OK, dann interessieren mich wirklich die Antworten, die Du hoffentlich aus dem Indilib-Forum bzw. aus dem ZWO-Forum erhalten wirst.

Clear skies,

Bernd
 
Hallo Michael,

ja, das sind Gain-Werte für die Rot- und Blaupixel. Wenn man aber den Begriff "raw data" streng auslegt, sollte so eine Manipulation von Pixelintensitäten nicht im FITS-File gespeichert werden. Offensichtlich wird sie das aber.

Dem kann man begegnen, indem man die Gain-Werte auf 1 setzt (in dem Fall auf 50), quasi als Workaround, und so mache ich das aktuell auch, oder der Kameratreiber berücksichtigt im Raw-FITS-File die Werte nicht, wie es eigentlich korrekt wäre. Dann müsste aber jemand den ASI-Treiber in Indilib entsprechend ändern.

VG
Bernd
 
Gain ist eine Sensoreinstellung und die Sensoreinstellungen sollte man natürlich in den Metadaten speichern, damit man hinterher noch weiß, wie die Aufnahme zustande kam und welches e-/DN Verhältnis man hatte. Wenn man nicht mehr Licht bekommen kann, ist es absolut sinnvoll, Gain so einzustellen, dass man den ADC ausnutzt.

Michael
 
Da haben wir uns missverstanden. Der (analoge) Gain muss natürlich berücksichtigt werden. Das geht ja auch nicht anders. Wenn die Kamera einen Gain-Wert verwendet, wird die CMOS-Verstärkung noch auf analoger Seite entsprechend gesetzt und führt dann zu dem angesprochenen e-/DN-Verhältnis. Das ist in den Pixelwerten drin und auch im FITS. Hier geht es um separate, nachträglich eingerechnete digitale R- und B-Gains, also eher ein Postprocessing-Schritt (der Weißabgleich). Der sollte halt nicht im ursprünglichen FITS mit drin sein.
 
Also nach meiner Information hat der CMOS-Chip (zumindest der Sony IMX294CJK aus der ASI294MC) nur einen analogen Gain-Wert für alle Pixel und der setzt noch vor der AD-Wandlung an. Deswegen kann man damit ja auch das Verhältnis Elektronen zu DN steuern. Der Weißabgleich erfolgt über digitale RGGB-Gains, die auf dem bereits digitalisierten Bild angewendet werden. Meines Wissens kann man die Verstärker in den CMOS-Pixeln nicht individuell ansteuern (maximal zeilenweise).

Im FITS-File sehe ich nur einen Gain-Wert (in meinem Fall 0, ergibt bei der ASI294MC die größte Fullwell-Kapazität, was ich möchte) und einen Offsetwert.
 
Ich schaue es die Tage mal im Datenblatt nach. Nach meiner Erinnerung gibt es bei IMX2xx vier Gains, wobei analog den unteren Wertebereich abdeckt und digital den oberen Wertebereich, jeweils mit 8 bit, die 1/10 dB kodieren. Ich kann da aber falsch liegen.

Michael
 
Wenn das so wäre, würde es erklären, warum der Indilib-Treiber die Pixelintensitäten inkl. der WB_R- und WB_B-Korrektur im FITS speichert. Dann wären das tatsächlich Raw-Werte, weil WB_R und WB_B schon auf analoger Pixelspannung greifen.

Dann müsste es in der Sensormatrix aber 4 getrennte Gain-Leitungen zu den R-, G1-, G2- und B-Pixeln geben. Geht das? Rein layouttechnisch?
 
Bei anderen Sensoren ist das so. Du siehst das in deren Datenblättern. Schau Dir mal welche von Onsemi/Aptina/Micron an, die sind ganz lesbar. Aber wie gesagt, beim IMX2xx spreche ich nur aus der Erinnerung, weil Sony das Datenblatt nur unter NDA rausrückt und ich darum zu Hause nicht reinschauen kann.

Michael
 
Interessanter Punkt, schaue ich mir mal an.

Dieser analoge Weißabgleich ist vielleicht für Standardanwendungen sinnvoll, aber bei den typischen Low-Light-Astrophotos, bei denen man Bias' und Darks abzieht, denke ich (und auch andere) sollte man zunächst alle Pixel mit gleichem Gain versehen (sonst treten im lichtfreien Biasframe ja wieder die CFA-Patterns hervor, der Beginn dieses Threads) und den Weißabgleich später im Postprocessing durchführen.

Interessante Diskussion hier! :)
 
Status
Es sind keine weiteren Antworten möglich.
Oben