IMX571 Sprung in Linearität bei 1sec

  • Hallo,

    Wie kann ich diese von dir herausgefundene / errechnete Korrektur anwenden?

    Ich nehme mal an, die Sensoren sind alle doch ganz leicht unterschiedlich. Ich kann also nicht empfehlen, einfach die von mir ermittelten Werte zur Skalierung zu übernehmen. Die sollten für den gegebenen Sensor neu ermittelt werden.


    Es gibt da mehrere Schritte. Bzw. man kann sich die Arbeit einteilen.

    1. Ermitteln / Überprüfung das die Zeiten <1sec linear aus dem Ursprung kommen.
      Also adu= m_<1 * t (t Belichtungszeit und m Steigung, Einen Y-Achsen Offset gibt es ja hier nicht)
      Ich hab das mit der Belichtungs / ADU Tabelle in Exel gemacht. Da gibt es die Funktion 'Trendlinie' in Plots. (Excel Anleitungen dazu gibt es viele)
    2. Die selbe Messung für Zeiten >1sec. Ich denke mal, dass muss nicht mal mit der selben Flat Intensität gemacht werden.
      Kann da jemand nochmal drüber nachdenken und bestätigen/korrigieren? Es geht darum m und b für die langen Belichtungszeiten zu bestimmen.
      Also adu= m _>1 * t + b_>! (anderes m als unter #1!!)
    3. Man hat jetzt eine Geradengleichung für <1sec und eine >1sec. Die >1 ist nicht korrekt, weil sie nicht den Ursprung trifft.
      Also muss die zweite Geradengleichung auf die erste abgebildet werden. Für >1sec gibt es eine Gleichung zur Neuberechnung der adu:
      adu_>1_neu= mx * adu_>1_alt + bx.  Mit ein wenig Geradengleichung Rechnerei findet man
      mx= m_<1 / m_>2, bx= -b_<1 * m_<1 / m_>1
      Das ganze für R,G, und B.
    4. Von jetzt an nur Flats <1sec nehmen
    5. Bei Lights >1sec, jedes Light vor der Anwendung des Flats. Mit der adu Gleichung neu berechnen. (z.B. PixelMath)

    Es müsste mal jemand eine Fehlerbetrachtung machen. Wenn ZWO von 20k bis 40k für Flats spricht, wie groß ist der Fehler, den wir machen, wenn wir die Flats <1sec und Lights >1sec nehmen? Ich meine, wenn am Ende von einer Vignettierung von (ich rate mal) 1000adu in der Bildecke, ein Fehler von 10adu überig bleibt (unterkorrigiert / überkorrigiert wird) das ist dann 1% im Hintergrund. Wie viel ist das? Und kann man das nicht eh mit GraXpert AI platt machen? Ich hab mich z.B. noch nicht entschieden meine Flat-Belichtungen und Verarbeitung wegzuschmeissen. Background Neutralisation oder GraXpert muss ich immer machen. Ich habe genug Himmelsgradienten, die Flats nie weg kriegen.


    Clear Skies,

    Gert

  • Wie viel ist das? Und kann man das nicht eh mit GraXpert AI platt machen?

    Gute Frage. Ich stehe auch gerade vor dieser Frage. Im Moment bin ich gerade an ein paar Projekten, die aber noch nicht abgeschlossen sind. Die zwischenzeitlich getesteten Sachen mit GraXpert AI sehen aber nahezu perfekt aus. Insofern ist schon die Frage, wie kritisch Flats wirklich sind. Ein Punkt, der mit Flats aber sicher besser zu fixen ist, sind kleine Probleme wie z.B. Staub auf dem Sensor. Da haben Flats ganz sicher einen Vorteil.

  • Also ich möchte hier meinen für die Berechnungen sinnlosen aber für die Praxis wie ich finde doch relativ relevanten Senf dazu geben, ich hoffe das wird jetzt nicht falsch verstanden:


    Ich kann also


    1. mit diesen Formeln jonglieren und muss jedes Light neu berechnen mit dem Kladaradatsch und es ist sogar nicht allgemeingültig sondern für jeden Sensor anders (hier noch ein Stichwort, "Sensoralterung") ODER

    2. ich belichte meine Flats länger als eine Sekunde und benutze ebenso lange Dark Flats, so wie es sich bei mir seit Jahren bewährt hat


    Dass die Sensoren sich so verhalten ist lange bekannt, das ist auch nicht meine Erkenntnis gewesen, ich war nur mit einer der ersten, der die neuen IMX Sensoren im Einsatz hatte und mir fiel sofort auf, dass die kurzen Flats unter 1 Sekunde nix mehr taugen. Hierfür wurde innerhalb der Community eben diese pragmatische Lösung erstellt, die - so mir bekannt - immer zum gewünschten Ergebnis führt. Dass es nach wie vor Leute gibt, die das Verhalten der Sensoren nicht kennen, hatte ja Torben im anderen Beitrag bewiesen. Ist ja aber nicht schlimm, man kann hier ja Aufklärung betreiben. Ich hoffe er liest hier auch noch mit und probiert es einfach mal mit den längeren Flats aus, auch wenn er im anderen Beitrag vehement gegen mich war.


    Spannend finde ich das Thema Lights neu berechnen mit PI auch, aber in der Praxis nicht zielführend. Was machen Leute ohne PI? Siril, APP, Photoshop usw.? Wie können die sich helfen?


    ----------------------------------------------------------------


    Hier mache ich den Cut, jetzt nehme ich wieder an der "Forschung" teil.

    Gert, du hast wohl herausgefunden, dass es sich um einen hardwareseitig angewandten Offset handelt.

    Ich kann mir hier vorstellen, dass das in der R&D Abteilung von Sony durchaus absichtlich so gemacht wurde. Der Offset soll ja verhindern, dass Pixel ins komplett Schwarze (bzw. Signal = 0) clippen. Bei kurzen BLZ unter 1 Sekunde sollen so vielleicht sehr dunkle Bereiche eines Tageslichtfotos vor dem Clipping bewahrt werden? Sony Sensoren sind ja für ihren hohen Dynamikumfang bekannt. Hier wird dann vielleicht genau in diese Tasche rein getrickst?

  • Hallo Drehn,


    ...1. mit diesen Formeln jonglieren und muss jedes Light neu berechnen mit dem Kladaradatsch und es ist sogar nicht allgemeingültig sondern für jeden Sensor anders (hier noch ein Stichwort, "Sensoralterung")...


    Außerhalb von Sensoralterung sind die Rechenschritte fixiert sowie einmal die Faktoren ausgerechnet sind.


    ...2. ich belichte meine Flats länger als eine Sekunde und benutze ebenso lange Dark Flats, so wie es sich bei mir seit Jahren bewährt hat...


    Mathematisch (Haarspalterei) ist die adu Gleichung für die kurzen Belichtungen korrekt. Für lange Belichtungen ist die Division light/flat mathematisch nicht mehr korrekt. Aber siehe meine Frage nach Analyse der Größe des Fehlers. (Ironiemodus) Also wäre die korrekte Behandlung Flats und Light Belichtungen <1sec zu machen. (Ist natürlich Blödsinn)


    Was ist meine Schlussfolgerung:

    • Ich war/bin etwas sauer auf den Sensor/Camera Hersteller, dss sowas nicht in der Spezifikation erklärt wurde. OK vergeben und vergessen.
    • Ich sehe de-facto, dass mein Flow mit Lights>1sec und flats<1sec plus Background platt klopfen gut klappt. Mit GraXpert sogar noch besser wird.
    • Ich bleibe bei meinem Flow. Spez. da die Zwischenschaltung der 'Korrektur' im Flow knifflig ist. Man müsste zwischen Darkabzug und Flatdivision die Korrektur machen. Ich sehe da kein Interception-Point in PI, wie ich das machen kann. Es sei denn ich schreib mein eigenes WPBB Skript, wozu ich keine Lust habe.
    • Langfristig bin ich jetzt zu dem Them 'vorgewarnt' und behalte das im Auge. Das ist aber auch alles.

    Wie sehen die Experten das?


    Clear Skies,

    Gert

  • Hallo Gert, hallo alle,


    ich habe mir das CCDCiel runtergeladen und es nach einigem hin und her geschafft, die Kamera damit zu verbinden. Hier meine CCDCiel Auswertung von der ASI2600MM Monokamera, die ich für kurze Zeit vom Kumpel zum testen habe. Die Kamera war am RC8"f/8 mit Reducer und L-Enhance Filter montiert. Das Teleskop war gegen meinen weißen Computerbildschirm als Flatpanel gerichtet:


    Wir sehen den gleichen Knick bei 1 s wie bei Gert mit der Farbversion. Tests mit Gain 60 und Gain 200 und anderen Filtern zeigten genau dasselbe Verhalten.


    Und jetzt die ToupTek TS2600CP Farbkamera, die ja denselben Sony IMX571 Sensor verbaut hat, gleiches Setup wie oben:


    Kein Knick zu sehen! Daraus schließe ich, dass der Effekt doch nicht am Sony Chip "fest verdrahtet" ist, da er nur bei der ASI2600 Farb- und Monoversion auftritt. Alex, welche Mono Kamera hast du vermessen? Ich nehme an, es ist die QHY268M? Die zeigt ja auch keinen Knick, genau wie die diese TS2600CP Farbkamera.


    Als Flat Problem geplagter mit der ASI294MC lese ich hier aufmerksam mit. Ich nehme die Erfahrungen von Drehn und Seraphin zur Kenntnis, muss jedoch gestehen, dass ich es nicht verstehe. Für mich sind Flats dazu da, die Inhomogenitäten in der Bildausleuchtung auszugleichen, also in erster Linie Vignettierung und Kringel durch Staubkörner. Was soll da ein kleiner Knick in der Linearität für eine Rolle spielen? Wenn bei mir die Flats nicht gepasst haben, dann war es egal, ob ich kurz oder lang belichtet habe, ob SkyFlats, oder mit Leuchtpanel oder T-Shirt. Ich gehe inzwischen davon aus, dass es bei mir ein Problem mit der Kamera selbst ist und werde mal ein separates Thema dazu machen, da das hier nicht mehr hinpasst.

  • Hallo Stathis,


    ..., muss jedoch gestehen, dass ich es nicht verstehe. Für mich sind Flats dazu da, die Inhomogenitäten in der Bildausleuchtung auszugleichen, also in erster Linie Vignettierung und Kringel durch Staubkörner.

    das geht mir, wie oben schon geschrieben, genauso. Aber der TO hat auf meine Beiträge nicht reagiert.


    ... Was soll da ein kleiner Knick in der Linearität für eine Rolle spielen? ...

    Ich meine, er spielt gar keine Rolle. Niemand - nicht einmal ZWO - bestreitet, dass die ASI2600er im unteren Belichtungszeitfesnter nicht linear sind. Aber das ist irrelevant, wenn man die Flats (und Darkflats) > 1 Sekunde belichtet. Diesen Ratschlag kann man überall im Netz finden. Es mag ja interessant sein, den Knick zu dokumentieren, aber im realen Leben spielt das keine Rolle - in Bezug auf die Flats es ist eine Gespensterdiskussion.

    ... Ich gehe inzwischen davon aus, dass es bei mir ein Problem mit der Kamera selbst ist und werde mal ein separates Thema dazu machen, da das hier nicht mehr hinpasst....

    Ich hatte anfangs auch Probleme mit Fehl-/Überkorrekturen, die sich meist in großen, konzentrischen hellen und dunklen Ringen äußerten. Das ist kein Thema mehr, seitdem ich beim Stacken zusätzlich zu einem Bias auch Darkflats verwende (ich stacke mit APP).


    CS Peter

  • Hallo,


    ich habe eine ZWO ASC533 MC Pro und ebenfalls diesen Knick gemessen. Verstanden habe ich die Probematik jedoch auch nicht.

    Zitat von pete_xl

    in Bezug auf die Flats es ist eine Gespensterdiskussion.

    Ohne diese Diskussion wäre ich gar nicht auf die Idee gekommen, Flats > 1 Sec zu machen. Ich habe welche angefertigt und festgestellt, dass sich die Qualität der Stacks verbessert hat.


    Gruß Jürgen

    :cyclone: Deepsky:  TS-Optics Photoline 80 mm f/6 FPL53 Triplet-Apo+TS-Optics  0,8x Korrektor für TS 80 mm

    :camera: Kameras:ZWO ASI 533 MC Pro Color, ZWO ASI533MM Pro, ZWO EFW 7*36mm, ZWO Filtersatz LRGBSHO

    :telescope: Montierung:Skywatcher HEQ5 Pro Goto    :level_slider:Autoguiding:ZWO SW Astrokamera ASI120MM Mini    :fireworks: Focuser:ZWO EAF
    :desktop_computer: Teleskop-Rechner: Dell Optiplex+Win11 :control_knobs: Teleskop-Steuerung:N.I.N.A+ASCOM :sparkles:Bildbearbeitung:PixInsight, AstroPixelProcessor

  • Hallo Stathis & All,

    Was soll da ein kleiner Knick in der Linearität für eine Rolle spielen?

    Ich will mal die Berechnung zeigen wie sie ideal aussieht und wie mit Camera mit Knick. Für die mitlesenden Experten, wen ich einen Fehler gemacht habe, bitte korrigieren.


    Zuerst den Fall einer Camera ohne Knick. Wie berechnet sich das Signal in einem Light Pixel?

    Light= M1 * Flux + Dark

    ( M1 ist sowas wie die Steigung in den Plots, die CCDiel macht )


    Jetzt ziehen wir das Dark ab.

    Bleibt:

    Light_D= M1 * Flux


    Beim Flat auch nach Abzug von Dark oder Bias (macht keinen Unterschied bei CMOS) (Man bemerke selbes M1!)

    Flat_D= M1 * Flat_Flux


    Bei Division:

    Light_D / Flat_D = Flux / Flat_flux (genau das was wir wollen)


    Nun eine Camera mit Knick in der Optik, wo sagen wir mal die Flats <1scec und die Lights>1sec belichtet wurden.

    Light2= (M2 * Flux + OFF) + Dark

    (OFF is der Offset der bei Belichtungen >1sec dazu kommt. Und M1 != M2 wie wir bei den Plots gesehen haben!)


    Dark Abzug.

    Light2_D= M2 * Flux + OFF


    Jetzt ein Flat <1sec mit Dark.

    Flat_d= M1 * Flux_flat


    Division:

    Light2_D / Flat_D = (M2 * Flux + OFF) / (M1 * Flux_flat)

    Da kommt nie und nimmer Flux / Flat_flux raus. Da geht kein Ausmultiplizieren, Bruch erweitern oder sonstwas. Es passt einfach nicht!


    Chance: Aus Light2_D wieder ein Light_D machen wenn man M1, M2 und OFF kennt. Ich denke man kann das einmal aus so einem Plot bestimmen.


    Wenn wir uns nochmal den Plot ansehen. Die Lücke zwischen der Belichtung >1sec und der extrapolierten von <1sec ist nicht nur ein Offset oder nur eine Skalierung. Es ist eine Geradengleichung mit Skalierung UND Offset. Es ist nicht so, dass wir z.B. bei einem Flat bei 20k adu nur um 50adu als Offset verrechnen. Die Lücke wird mit steigender Belichtung immer größer.


    Vielleicht kann das mal jemand ausrechnen.


    Hier ein Beispiel (Zahlen aus der Luft gegriffen und nicht nachgerechnet ob's stimmt):

    Wenn wir Lights mit 100sec machen mit sagen wir mal 10k adu und Flats mit 0.1sec und sagen wir mal auch 10k adu. Die Lights haben am Rand 10% Vignettierung, also statt 10k adu 9k adu. Wenn wir jetzt die 0.1sec Flats anwenden um wieviel falsch ist die Korrektur der Vignettierung am Rand?


    Also im Idealfall dividieren wir 9k adu / 9k adu = 1.000 (normieren wir mal auf 1.0)

    Mit dem>1sec Knick sind die Lights jetzt nicht 9k adu sondern sagen wir mal 9k5 adu.

    (Achtung: nicht einfach 500 addiert, sondern die 9k adu mit einem Skalierungsfaktr multipliziert und einen Offest addiert!)


    Ergibt dann 9k5 adu / 9k adu = 1.0555. Also der Rand ist 5% heller als er sein müsste. OK, doe Mitte ist auch heller aber um einen anderen Betrag. Also erscheint ein Gradient im Bild!


    Also die Zahlen eben habe ich aus der Luft gegriffen. Vielleicht kann das mal jemand richtig duirchrechnen? Die Messdaten sind ja in der Exeltabelle drin. Irgendwie muss man nur ein Light bei 100sec erzeugen.


    Clear Skies,

    Gert

  • Nachdem ich die Rechnung von Gert in Beitrag #33 nachvollzogen habe, finde ich das keine "Geisterdiskussion" mehr. Sie zeigt nämlich, warum durch den Knick in der Linearität die kurzbelichteten Flats gegen die langbelichteten Lights nicht mehr passen. Ich finde das eine wichtige Erkenntnis und ehrlich gesagt sehe ich das als Mangel bei den ASI2600 an. Die anderen Fabrikate zeigen ja, dass es auch ohne Knick geht. Bin etwas erstaunt, dass da kein Aufschrei erfolgt.


    Aus Interesse habe ich mal meine ASI294MC mit CCDCiel ausgewertet, Sie zeigt keinen Knick, der Verlauf ist jedoch nicht ganz so linear, wie bei der TS2600:


    Das erklärt jedoch nicht die Flatprobleme, die ich mit dieser Kamera in Verbindung mit Schmalbandfiltern aus der Stadt habe, das ist eine andere Baustelle (Bei Interesse siehe in Cloudynights Word of warning: ASI294MC Pro and OPT Triad and NB).

  • Hallo in die Runde,


    auch wenn gebetsmühlenartig die Irrelevanz des Linearitätsproblems des IMX beschworen wird, gibt es doch ausreichend Interessengebiete abseits des Schmalbandfilter-Nebel-Ablichtungsmainstreams, welche eine bestmögliche Linearität einfach erforden, wie beispielsweise Spektroskopie, Photometrie usw. Ich kann zwar jetzt zur aktuellen Problematik mit dem IMX571 nichts beitragen, da ich keine solche Kamera habe, aber ich habe eine Nikon D5100 mit dem Vorgängerchip IMX071. Diese war auch ziemlich problematisch bezüglich Darks/BIAS und Linearität, da der EXPEED-Kamerabildprozessor ziemlich stark selbst in die eigentlichen RAW-Daten des Kamerasensors eingegriffen hat. Eigentlich sind nämlich die Sony-Sensoren recht gutmütig. Es gab sogar einen Firmware-Hack, welcher unter dem Namen Dark-Current-Enabling-Tool firmiert hat und einen versteckten Modus aktivieren konnte, bei welchem die Kamera-Prozessoreingriffe abgeschaltet werden.

    Eine Kurzfassung der Geschichte, wen es interessiert:

    Der Sensor besteht aus den eigentlichen Bild-Pixeln, aber es gibt auch spezielle Pixelreihen, welche zur Kalibration dienen. Diese sind beispielweise mit einer intransparenten Schicht abgedeckte normale Pixel und es gibt auch Reihen, wo die Pixelelektronik ganz ohne Photodioden drauf ist. Ohne Photodioden kann man den BIAS recht gut korrigieren und die abgedeckten Pixel sammeln nur Dunkelstrom auf, sodass man hier den Dark-Current-Offset korrigieren kann. Die Expeed-Prozessoren haben hier recht kreativ diese Kalibrierpixel ausgewertet und den Dunkelstromoffset gnadenlos herauskalibriert. Teilweise so konsequent, dass das Dunklerauschen exakt auf 0 gesetzt wurde und der Gauss-Peak halbseitig abgeschnitten wurde. Bei meiner Kamera war interessanterweise hauptsächlich der Blaukanal betroffen, warum auch immer. Deshalb konnte man selbst bei warmen Sensor keinen Dunkelstromoffset messen, da der Prozessor diesen immer aufgrund der Kalibrierpixelauswertung weggeschnitten hat. Es kam dann natürlich ein perfekter Sensor mit unglaublich niedrigen Dunkelstrom heraus und Schwarz war dann per Definition immer Schwarz. Zumindest war das beim eigentlichen Absatzmarkt, der Tageslichtfotografie, ein toller Gimmik. Geärgert hats nur die Astrofotografen.

    Inwiefern die IMX571er Astrokameras da auch so kreativ bezüglich Offset und Darkabzug herangehen, kann ich leider nicht einschätzen. Zumindest gabs bei der alten Nikon auch einen Umschltpunkt bei etwa 1s, ab dem der Bildprozessor automatisch eine Rauschunterdückung zugeschaltet hat, ob man wollte oder nicht.


    Lg Tino

  • Hallo,


    auch wenn gebetsmühlenartig die Irrelevanz des Linearitätsproblems des IMX beschworen wird, gibt es doch ausreichend Interessengebiete abseits des Schmalbandfilter-Nebel-Ablichtungsmainstreams, welche eine bestmögliche Linearität einfach erforden, wie beispielsweise Spektroskopie, Photometrie usw.

    Mit dem Begriff "Linearität" werden leider (auch hier in diesem Thread) unterschiedliche Dinge bezeichnet, weil 2 verschiedene Parameter vermischt werden: Belichtungszeit und Lichtstrom.

    Der Sensor ist scheinbar nicht linear bei verschiedenen Belichtungszeiten. D.h. wenn ich das gleiche Objekt bei 0.5s und 1s aufnehme, sind die Pixelwerte nicht doppelt so hoch. ABER: Wenn ich bei konstanter Belichtungszeit Objekte mit unterschiedlichem Lichtstrom belichte, arbeitet der Sensor linear. Ein Objekt, das doppelt so viele Photonen liefert, gibt dann den doppelten Pixelwert (abzüglich Offset und Dunkelstrom). Damit hat das hier beschriebene Verhalten keine Relevanz für die genannten Einsatzfälle, so lange immer mit der gleichen Belichtungszeit gearbeitet wird - und wenn jemand ernsthaft irgendwelche Messungen durchführt, würde ich ganz klar erwarten, dass er die Belichtungszeit konstant hält.

    CS, Daniel

  • Sehe ich genauso, ist halt nicht einfach zu realisieren. Aber ob dann alles linear ist, muss sich ja auch erst noch zeigen. Bei den FLI Kameras mit Gpixel chip gab es auch schon andere Meinungen dazu, weil dort die ADC Dynamik durch Kombination zweier nativer ADCs auf ein paar bit mehr gemappt wird, da gibts dann auch den Knick bei korrekter Linearitätsmessung, nur eben bei bestimmter Intensität.


    Gruß

    Norbert

  • Hallo Beisammen,


    Ich habe mal eine Simulation zu dem Thema gemacht.


    In Photoshop ein Bild erzeugt, was die Fluxrate für ein Flat (mit Dust Donut) und für ein Light darstellen soll.

    Dabei ist die Light Fluxrate die selbe vom Flat nur ein Objekt is oben drauf addiert.

    Die beiden Bidler stellen also den Signalfluss in den beiden Aufnahmen dar.


    Jetzt machen wir daraus Belichtungen.

    Für das Flat müssen wir den Flux mit der Belichtungszeit multiplizieren und noch die Signalantwort des Sensors als Steigung dazu nehmen.

    Dabei nehmen wir den Fall an dass die Belichtung (bei ZWO) unter 1sec liegt. Es kommt kein Offset dazu.


    Für das Light (bei ZWO) mit Belichtung >1sec haben wir die Berechnung wie in einem älteren Post gezeigt.

    Die Sensor Antwort hat eine andere Steigung und es kommt ein Offset hinzu.


    Jetzt nehmen wir noch den Fall, den Forumkollege Drehn vorgeschalgen hat. EIn Flat mit Belichtung >1sec.

    Ich hatte eigentlich nicht erwartet, dass das kompensiert. Aber es scheint so zu sein. Da muss mal jemand draufschauen, der die Rechnung besser versteht.


    Hier das Ergebnis. (Die Bidler sind mit autostretch. Deswegen sind die Grauwerte nicht die selben. Aber es kommt ja auf das Verhäkltnis an!)


    Auf jeden Fall sieht man, dass ein Flat <1sec nicht zum Light >1sec passt.


    Die Sache mit dem Flat >1sec ist mir noch unklar. Ich verstehe nicht warum das funktioniert.


    Falls jemand mit den Daten werkeln will. Das PI Projekt ist bei meinem kleinen Server gespeichert.

    https://www.skywatcher.space/download/linearity_gap_simulation2.pxiproject.zip


    Clear Skies,

    Gert

  • Hallo beisammen,


    Ein Posting beim PI Forum hat der Sache neue Hilfe gegeben.


    Mein erstes Modell, den Offset zu der ADU Messung zu addieren war falsch. Das verschiebt den Ursprung des Kurvenfächers aus den Plots entlang der Y Achse. Das stimmt nicht mit den Auswertungen der Camera überein!

    Falsch -> Light2= (M2 * Fluxrate * texp + OFF) + Dark


    Richtig ist es den Offset als Addition zur Belichtung anzusehen. Genau das verschiebt dann den Kurven-Fächer entlang der X-Achse!

    Richtig ->

    Light2= (M2 * Fluxrate * (texp + OFF) ) + Dark


    Wenn man diesem Weg folgt ergibt sich korrekte Kalibrierung von Light (>1sec) und Flat (<1sec).


    Ich zeige das nochmal in der PI Simulation.

    Ganz oben das Flat. Da ändert sich nichts da <1sec und kein Linearitätsoffset.

    Zweite Reihe ein Light mit flascher Simulation. Die Korrektur rechts oben ist falsch. Diese Simulation wieder vergessen!

    Dritte Reihe ein Light mit richtiger Simulation. Gute Korrektur von Light (>1sec) und Flat (<1sec)




    Für die, die immer noch nicht genug haben, habe ich eine Simulation in Gnuplot geschrieben.


    Hier die korrekte Simulation. Oben die Funktionen für ADU in Abhängigkeit von Belichtungszeit für <1sec (Ursprung des Fächers bei 0,0) und >1sec (Ursprung des Fächers auf der t-Achse nach links verschoben). So wie es in den Camera Messungen gezeigt wurde. Der zweite Plot ist eine Simulation wie ein Flat und ein Light korrigiert werden. Die X Achse ist eine Ortsachse und es sind Pixelhelligkeiten in Flat und Light eingetragen, wie sie mit der korrekten Formel bei einer gegebenen Belichtungszeit herauskommen. Stellt Euch ein Objekt am Bildrand mit Vignettierungsgradienten vor. Im Light habe ich sogar noch eine kleine Modulation eingezeichnet, das soll ein Objekt im Bild sein. Wichtig ist, dass man sieht, dass das Ergebnis der Kalibrierung (light/flat) eine flache Linie ist. Keine Flat-Artefkte im Hintergrund. Nur das Objekt ist registriert.


    Zum Schluss das Gegenbeispiel. Das ist die falsche Simulation. Die bitte sofort wieder vergessen. Man sieht die falsche Position des Ursprungs des Kurvenfächers und die nicht korrekte Kompensation in der Kalibrierung.


    Wer will kann gerne den Gnuplotcode kriegen.


    Zusammenfassung:

    Nach anfänglichem Zweifel und mathematischen Fehlern ist mir nun klar, dass die Verwendung von Flats <1sec und Lights >1sec bei ASI Cameras OK ist. Dann immer noch vorhandene Artefakte kann ich mit diesem effekt nicht erklären. Die müssen andere Ursachen haben. Seufz.


    Clear Skies,

    Gert

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!