Warum ist Bayerpattern in Bias und Dark sichtbar

Status
Es sind keine weiteren Antworten möglich.
Man macht die Datenreduktion bei Farbe in den Subframes, d.h. es ist egal, wenn die Gains verschieden sind. Nicht egal ist der Gewinn an Auflösung und SNR, den man durch den analogen Gain bei Sony bekommt. Man nutzt den Detektor optimal aus, macht aber dennoch den Farbabgleich im Postprocessing.

Michael
 
Entzündet hat sich die ganze Fragestellung bei mir an der Superbias-Funktion von Pixinsight, die einen quasi rauschfreien Masterbiasframe erzeugt. Die Funktion sucht nach Strukturen im gestackten Masterbias, erhält diese, entfernt aber das statistische Rauschen. Und das geht schief, wenn die Pixel unterschiedlichen Gain haben, weil dann eben regelmäßige Muster entstehen, die aber nicht vom Ausleserauschen herrühren.
 
Vom IMX 294 habe ich kein Datenblatt, aber eigentlich sind sich die IMX2xx alle sehr ähnlich. Was soll ich sagen: Ich fand nur ein globales Gain. Allerdings heisst das nicht, dass es keine einzelnen Gains gibt, weil im Datenblatt nicht alles steht und ein Teil der Register nur in Application Notes beschrieben ist. Damit bin ich jetzt also auch nicht schlauer.

Von anderen Sensoren kenne ich so ein globales Gain auch: Das ist eine Abkürzung, die einzelnen Gains zu setzen, und für monochrome Sensoren nützlich, weil man dann nicht vier Register setzen muss.

Ich war mir sicher, so eine Konstruktion bei IMX2xx schon gesehen zu haben, aber vielleicht täusche ich mich da, oder ich find's nicht mehr.

Michael
 
Hallo Bernd,

gibt es zu dem bug in Kstars (WB_R und WB_B führt zur Skalierung der Intensitäten in FITS-Dateien) etwas Neues von den Programmierern?

Bernd
 
Hallo Bernd,

nein, habe nichts mehr dazu gehört. Aktuell habe ich WB_R und WB_B beide auf 50 stehen, wodurch die Darks strukturlos rauschen, kein Pattern erkennbar. Die Lights haben nun allerdings einen deutlichen Grünstich. Deswegen steht die Kamera möglicherweise defaultmäßig auf WB_B = 95 statt 50.

VG
Bernd
 
Der Grünstich ist völlig normal, meine Aufnahmen mit der ASI294MC (kein Linux, sondern Windows 10, SGP) haben das genauso. Für Aufnahmen, die einer Flatfield-Korrektur unterzogen werden (also alle Deepsky-Aufnahmen) spielt das aber überhaupt keine Rolle, weil die Flatfield-Korrektur bei jeder OSC-Kamera zu einer starken Farbverschiebung führt. Mithin ist eine Farbkalibrierung nach dem Preprocessing sowieso unumgänglich.

Was heißt das denn "nichts mehr gehört"? Hast Du das als Bug in Kstars gemeldet?
Was sagen die Programmierer dazu?

Bernd
 
Nichts mehr gehört heißt, dass es in dem Thread, den ich dazu im Indilib-Forum eröffnet habe, keine weiteren Beiträge gab. Tatsächlich gab es überhaupt keine Reaktion direkt zu dem Thema, nur ein Nebenkriegsschauplatz, wo sich einer über komplett schwarze Bias-Frames gewundert hat. Der hatte aber einen falschen Offset und damit komplett geclippte Biasframes.

Als Bug habe ich es nicht gemeldet. Bin mir auch nicht sicher, ob es einer ist. Die WB-Werte sind ja im ZWO-Treiber einzustellen, so wie Gain bspw. auch. Und wenn ich Gain ändere, wirkt sich das ja auch auf das FITS-Bild aus. Könnte es nicht sein, dass die ZWO-Firmware ein entsprechendes RAW-Bild zurückliefert, in das WB_R und WB_B quasi schon auf dem Chip eingerechnet wurden?

Wenn das so ist, halte es eher für einen Bug, dass WB_R defaultmäßig auf 52 statt 50 und WB_B sogar auf 95 statt 50 steht.

VG
Bernd
 
Zuletzt bearbeitet:
Habe im Indiforum nochmal auf das Problem hingewiesen, nachdem ich gesehen hatte, das hier im Forum auch jemand mit der ASI294 mit WB_B = 95 gearbeitet und sich über seltsame Bilder gewundert hat. Du hast ihm ja schon geantwortet, dass er WB_B und WB_R auf 50 stellen muss.

Vermutlich hast du Recht, dass das ein Bug in KStars ist. Wenn es ein gewolltes Verhalten der Kamerafirmware wäre, hätte ja jeder, der die ASI294 benutzt, das Problem, wenn er sich Bias- oder Darkframes genauer anschaut. Anscheinend hat das Problem aber niemand außer der kleinen Gruppe von KStars-Usern, die gleichzeitig diese Cam nutzen. Und vielleicht auch nur unter Raspbian? Würde die Menge der Betroffenen noch weiter einschränken.
 
Meine Meinung dazu ist:

Das ist auf jeden Fall ein Bug. Wenn ein Farbbild in der Aufnahmesoftware angezeigt werden soll, kann man natürlich zum Zweck der einigermaßen farbgetreuen Bildschirmdarstellung die Möglichkeit schaffen, Korrekturen vorzunehmen. Bei der ASI294 würde das helfen, den ansonsten starken Grünstich zu beseitigen. Diese Korrekturen dürfen aber nicht auch in den Intensitäten in der FITS-Datei vorgenommen werden, dort müssen die unveränderten Intensitätswerte abgespeichert werden. Wenn es denn als wirklich wichtig erachtet wird, könnte man die verwendeten Faktoren WB_R und WB_B im FITS-Header abspeichern. Alles andere ist aus meiner Sicht jedoch grober Unfug.

Bernd
 
Der Chefentwickler von KStars hat geantwortet und wollte mehr Details. Ich habe ihm die Problematik erläutert und mit Bildern belegt, s. Indilib-Forumsbeitrag. Mal sehen, wie es weiter geht.
 
Danke für diesen Link. Es interessiert mich doch, obwohl ich diese Software nicht nutze. Es kommen nämlich jetzt öfter Fragen zu genau diesem Thema.
 
Ich hatte die Sache für mich schon ad acta gelegt (in fact, vergessen...), weil ich mit der 50/50-Einstellung das Problem ja nicht mehr habe. Aber stimmt schon, in die Falle tappt jeder, der mit den Standardeinstellungen 52/95 anfängt, wie sie im ZWO-Treiber eingestellt sind.
 
Hast du es gelesen? Klingt schon recht angesäuert, die Antwort. Finde ich unangemessen, aber anderes Thema. Ist der Stil im Internet, es wird immer sehr schnell unfreundlich.

Jedenfalls sagt er das, was ich auch von Anfang an vermutet habe, dass die SDK (was ich als "Treiber" oder "Firmware" bezeichnet habe) Daten liefert, die von den WB-Parametern beeinflusst werden (das sei ganz normal und auch richtig so). Und Indi führt keine weitere Bearbeitung der Daten durch, speichert sie 1:1 als FITS.
 
Ja, ich hab's gelesen. Es ist übel, wenn solch ein Problem nicht mehr sachlich diskutiert werden kann.

ZWO hat ja 2 verschiedene Kameratreiber: 1. den "nativen" Treiber und 2. den ASCOM-Treiber. Ich verwende (mit der Aufnahme-Software SGP) den ASCOM-Treiber. Wenn ich nicht völlig falsch liege, hat der ASCOM-Treiber überhaupt keine Möglichkeit zur Einstellung von Weißabgleich-Faktoren, ich bin denen jedenfalls bisher noch nicht begegnet.

Grundsätzlich frage ich mich allerdings, wie ein Programmierer überhaupt auf die Idee kommen kann, solche Faktoren zuzulassen, wenn das Ergebnis anschließend im Zahlenformat 16-bit unsigned Integer abgespeichert wird. Das macht doch überhaupt keinen Sinn, weil das Ergebnis in aller Regel keine ganze Zahl ist, man muss also runden. Es mag sein, dass dies bei ZWO in ihrem SDK so programmiert wurde, aber man muss ja als Programmierer einer Aufnahmesoftware nicht jeden Blödsinn mitmachen, sondern könnte die Werte auf 50 setzen und sie für den User nicht zugänglich machen. Wenn man sich aber schon dazu entscheidet, die Werte veränderbar zu machen, sollte man wenigstens
a) die Default-Werte in der Software jeweils auf 50 zu setzen und
b) in der Dokumentation klar und deutlich darauf hinzuweisen, dass eine Veränderung dieser Werte dazu führt, dass die Daten skaliert und anschließend gerundet werden.

Bernd
 
Ich fand die Antworten eigentlich ganz sachlich und durchaus OK?

Ich habe das so verstanden: INDI bekommt von dem Treiber eine Liste von Optionen, die der Treiber versteht. Das sind dann einfach nur die Namen der Option, die Art (Zahl, Text, was auch immer...), der Default-Wert usw.
INDI nimmt dann diese Parameterliste und macht ein UI daraus oder erstellt die Konfiguration. Das ist alles völlig generisch, es ist gar nicht klar, welcher Parameter was bedeutet.
Insofern kann man da nicht viel ändern, außer evtl. dokumentieren, dass bestimmte Treiber blödsinnige Defaults haben. Die einzige Alternative wäre eine Spezialbehandlung, wenn bestimmte Treiber/Gerät-Kombinationen erkannt werden. Solche "Quirks" zu pflegen ist sehr aufwändig - mit jeder neuen Version kann die Spezialbehandlung hinfällig werden.

Beschweren müsste man sich bei ZWO, die das SDK liefern.

Grüße,
Steffen
 
Hallo Steffen,

stimmt, war eigentlich schon OK. Die erste Antwort klang etwas wie "da will mir einer an mein Ekos fahren", war aber vielleicht auch überinterpretiert von mir.

So, wie du es beschrieben hast, sehe ich es auch. ZWO ist da "verantwortlich", und als User muss man bestimmte Dinge halt wissen, sonst kommt Murks raus. Da gibt es ja noch 1000 andere Dinge bei diesem unserem Hobby... :cool:

Mit denn 50/50-Werten ist ja alles gut.

CS (momentan optimal!)
Bernd
 
Status
Es sind keine weiteren Antworten möglich.
Zurück
Oben