Kalibration der Rohdaten

pem.bn

Mitglied
Diejenigen, die meinen Thread verfolgt haben, wissen, dass ich an einer Optimierung meiner Flats arbeite. Eine korrekte Kalibration macht einen Hintergrundabzug unnötig, war meine Annahme.

Nach allgemeiner Auffassung wird die Kalibration der Rohdaten (Lights), die aus dem CCD bzw CMOS kommen, folgende:

Bild = (Light - Masterdark) / Masterflat

Das kann man auch so schreiben: Bild = Light/Masterflat - Masterdark/Masterflat
Das bedeutet aber, dass das Masterdark auch flatkorregiert wird, was aber eigentlich Quatsch ist, weil das Dark ja nicht durch die Optik geht.

Das Licht fällt durch die Optik auf das CCD/CMOS, also Light * Vignet,beim Auslesen kommen noch Dark0 und Bias dazu:
Light = Light(Teleskop) * Vignet + Dark0 + Bias

Dann wird das Dark gemessen, da ist aber automatisch das Bias enthalten: Dark = Dark0 + Bias
Die Vignettierung wird durch das Flat wieder aufgehoben, so die Theorie und Praxis. Also Vignet = Flat, wenn das Flat im Integram auf 1 normiert wird.

Damnach müßte Bild = Light/Flat + Dark die richtige Transformation sein.
Was denkt ihr?
 

nobby

Mitglied
Hallo,
siehe Anmerkungen in Kursiv:

Diejenigen, die meinen Thread verfolgt haben, wissen, dass ich an einer Optimierung meiner Flats arbeite. Eine korrekte Kalibration macht einen Hintergrundabzug unnötig, war meine Annahme.

Nach allgemeiner Auffassung wird die Kalibration der Rohdaten (Lights), die aus dem CCD bzw CMOS kommen, folgende:

Bild = (Light - Masterdark) / Masterflat

ja, wenn das Masterflat entsprechend mit Flat dark oder Bias korrekt angelegt ist

Das kann man auch so schreiben: Bild = Light/Masterflat - Masterdark/Masterflat
Das bedeutet aber, dass das Masterdark auch flatkorregiert wird, was aber eigentlich Quatsch ist, weil das Dark ja nicht durch die Optik geht.

Nö, das bedeutet es nicht. Der erste Term stimmt stellt ja auch nicht das flat-korrigerte Bild dar, und der zweite Term korrigiert genau das. Die Mathematik stimmt schon so.

Das Licht fällt durch die Optik auf das CCD/CMOS, also Light * Vignet,beim Auslesen kommen noch Dark0 und Bias dazu:
Light = Light(Teleskop) * Vignet + Dark0 + Bias

warum führst Du hier die neue Variable Light(Teleskop) ein ? Das wäre doch einfach das kalibrierte Bild ???
Dann formst Du um und kommst auf Bild = (Light -(Dark+bias)) / vignet und damit Bild = (Light -Dark) / flat


Dann wird das Dark gemessen, da ist aber automatisch das Bias enthalten: Dark = Dark0 + Bias

stimmt für sich, aber der Rest unten nicht

Die Vignettierung wird durch das Flat wieder aufgehoben, so die Theorie und Praxis. Also Vignet = Flat, wenn das Flat im Integram auf 1 normiert wird.

Damnach müßte Bild = Light/Flat + Dark die richtige Transformation sein.
Was denkt ihr?


Gruß
Norbert
 

pem.bn

Mitglied
Stimmt, da hast Du recht. Ich darf nicht Light und Dark getrennt sehen. Ich bekomme ja aus der Kamera Light + Dark als eine Einheit. Deshalb kann man das nicht auseinander ziehen L/F - D/F. Mathematisch geht das schon, aber physikalisch ist das unsinnig. Die Interpretation ist falsch.

Light(Teleskop) soll das Licht sein, das durchs Teleskop kommt. Light ist hingegen das Ausgelesene. Aber es stimmt schon, das darf man physikalisch nicht trennen.

Funktioniert denn bei Dir die Kalibration so, dass Du keinen Hintergrundkorrektur mehr durchführen mußt?
 
Zuletzt bearbeitet:

GalaxieFinder

Mitglied
Hallo Peter!

Eines kann dir das Flat nicht korrigieren: Gradienten, die der Himmel verursacht. Sei es durch Lichtverschmutzung oder sonst was. Das Flat kann diese Gradienten ja nicht kennen, zumal die in unterschiedlichen Himmelsrichtungen auch unterschiedlich ausgeprägt sein können.
Das heißt, eine Hintergrundkorrektur (= Gradientenentfernung) kann trotz gutem Flat erforderlich sein.
Die Gradientenentfernung soll aber kein Ersatz für ein Flat sein... ;-)

LG, Markus
 
Zuletzt bearbeitet:

pem.bn

Mitglied
Hallo Markus,

im Prinzip stimmt das mit der Lichtverschmutzung. Da kann ich mitreden. :( Es ziehen ja auch mal Wolkenschleier durch.
Aber für kleine Felder ist das eher unkritsch, weil konstant über das Feld.

Ich habe aber den Fehler gefunden.

Zuerst habe ich die Datenrduktion mit Fitsworks gemacht. Das ist zwar im Prinzip ein gutes Programm, es hinterläßt aber auch Restvignettierung in meinen Summenbildern.

Dann habe ich mich selbe daran gemacht, eine Reduktion zu schreiben und gelangte mehr oder weniger zu gleichen Ergebnis. Das brachte mich ins Grübeln. Ich habe vieles probiert und bin bei der Monoversion auch zu einem guten Ergebnis gekommen. Den Weg dahin konnte ich mir mathematisch nicht erklären. Bis ich beim Ausdrucken der Diaginale der Chip-Matrix bemerkt habe, dass es Integer Werte (ganz Zahlen) sind in den Fits-Files.

Da dämmert es mir und ich habe die Daten erstmal in Floats (Gleitkommazahlen) umgewandelt. Und siehe da, es hat funktioniert. Sowohl bei Mono, wie auch in bunt. Vermutlich hat Fitswork die gleich Problematik.

Wenigsten brauche ich nun nicht mehr viel am Hintergrund arbeiten.

Gruß,
Peter
 

Hoschie

Mitglied
Light/Masterflat - Masterdark/Masterflat

Das bedeutet aber, dass das Masterdark auch flatkorregiert wird, was aber eigentlich Quatsch ist, weil das Dark ja nicht durch die Optik geht.

Was denkt ihr?
Nein, bzw ja, bzw. Moment!
Wenn du das so auseinanderklamüserst mit den Klammern, verknotest du gleichzeitig den Gedankengang. Aber dann ist es ja so, dass das Dunkelbild im Light anfangs enthalten und implizit Flatkorrigiert wird, und anschließend abgezogen wird (und weil es implizit ja flatkorrigiert wurde, muss auch das abzuziehende Dunkelbild flatkorrigiert werden).

In Pixinsight kann man bei bestimmten Dateiformaten auswählen, ob man sie als Integer oder Float abspeichern will, mit signed/unsigned Option. Da köntne schonmal was durcheinandergeraten, besonders wenn man unterschiedliche Programme drauf loslässt, z.B. Fitswork und Matlab, oder was du da machst.

1567619840520.png


Ein Punkt der noch nicht zur Sprache kam, ist das Aufaddieren der Flat-Subs. Da kann man sich einen Fehler einhandeln, wenn man nicht mit einer konstanten Lichtquelle arbeitet (Himmel in der Dämmerung) und die dunkelkalibrierten Flats additiv stackt. In PI kann ich auch multiplikativ stacken. Bzw - gemeint ist die Normierung. Was es in Fitswork gibt oder wie das dort gemacht wird weiss ich nicht.

CS Hoschie
 
Zuletzt bearbeitet:

pem.bn

Mitglied
Hallo Hoschie,

mein Fehler war die falsche Wahl der Zahlen. Integer sind halt zum rechen nicht gut geeignet. Beim Abspeichern brauchen sie dafür viel weniger Platz auf der Platte.

Mittlerweile habe ich mein Programm angepasst und aus den Integern Floats gemacht und siehe da, es bewirkt "Wunder":

M74_Dark_Flat_Median.png

Jetzt ist auch das Dark neu berechnet. Glatter geht's nicht mehr. Ohne Abzug eines Hintergrunds. Bin sehr zufrieden, dass Theorie und Praxis übereinstimmen. Das Dark ist allerdings noch mit -15°C aufgenommen. Da sieht man aber mal, dass es ab -10°C kaum noch was bringt, tiefer zu kühlen. Ich hatte gestern irrtümlich das Farb-Dark (gebayert) verwendet, deshalb gab es gestern die Störungen am rechten Rand. Die sind mit dem richtigen Dark nun weg.

M27_Dark_Flat_RGB_Median_ABE.png

Auch hier habe ich keinen Hintergrund abgezogen. Das Farb-Dark neu berechnet bzw mit 32bit Float abgespeichert. ;)
Allerdings sieht man noch Farbstrukturen, die man aber leicht mit DBE wegbekommt. Woher die Farbstrukturen kommen, weiß ich nicht. Da kann ich nur spekulieren. Vielleicht vorbeiziehende Wolken, Lichtverschmutzung, FlatFieldBox, .... ?

Gruß,
Peter
 

GanymedRN

Mitglied
Hallo Zusammen.
Ich möchte gern eine Bemerkung zu Float vs. Integer machen.
Integer auf dem PC ist 32bit und auch Float ist 32bit. Ausser man wählt die Typen größer bzw. kleiner. Bei der Bildverarbeitung wird oft mit 16bit Integer gerechnet und dann stimmt die Aussage das Integer weniger Speicherplatz benötigt. Man kann aber auch in 32bit Integer speichern und dann wäre die Größe gleich.
Generell gilt bei gleicher Anzahl von Bits: Float Zahlen haben einen größeren Dynamikumfang da 23 bit Mantisse und 8 bit Exponent. Integerzahlen eine höhere Präzision oder Auflösung da 31bit nur Mantisse. Das letzte Bit bei beiden ist das Vorzeichen.
Generell teilt das FITS Format dem Programm mittels Metadaten mit in welchen Format es gespeichert wurde. Pixinsight zB. beachtet diese Informationen und rechnet das entsprechend um, daher sollte es nicht zu Problemen kommen wenn man verschiedene Formate kombiniert.
Ich mache das dauernd weil ich z.B. mit verschiedenen Kameras arbeite und auch bereits bearbeitete Bilder mit neuen kombiniere. Manche haben unterschiedliches Zahlenformat.

Das sind die Formeln zur Kalibration die ich im Kopf habe. Ich hoffe das ist korrekt. Falls nicht bitte um Feedback.
Flat = Vignettierung + Darkflat0 + Bias
Bild = Light * Vignettierung + Dark0 + Bias
Dark = Dark0 + Bias
Darkflat = Darkflat0 + Bias

Echte Bildinformation wie z.B. der Himmelshintergrund können nicht kalibriert werden.
 

pem.bn

Mitglied
Meine ASI1600 speichern die Fits-Daten mit int16. Allerdings wird der Dynamikumfang künstlich auf 16bit angehoben, indem man die 12bit, die der AD-Wandler der Kameras eigentlicht liefert, mit 8 multipliziert. Es gibt also Löcher, die Zahlen sind nicht kontinuierlich. Jede Zahl in der Fits-Tabelle ist durch 8 teilbar ohne Rest.

Ich programmiere in der Programmiersprache Python. Da gibt es ein Fits-Modul pyfits (mittlerweile bei astropy eingebunden). pyfits liest die Daten so ein, wie sie von der Kamera (oder von wem auch immer) herausgeschrieben wurden. Solange ich die nicht beim einlesen konvertiere (.astype(float)), beiben die Zahlen int16, wie von der Kamera herausgeschrieben. Das ist nicht gut für die Rechengenauigkeit. Besonders nicht bei einer Division.

Wegen der kurzen Belichtungszeit ( << 1s) meiner Flats, verzichte ich auf das DarkFlat und nehme stattdessen das Bias. Der Unterschied, ob man das Bias mitnimmt oder nicht, ist irrelevant, weil die Bias-Werte recht klein sind im Vergleich mit denen des Flats. Meine Flats bewegen sich im Wertebereich um die 40000ADUs.
 
Zuletzt bearbeitet:

pem.bn

Mitglied
Ein Punkt der noch nicht zur Sprache kam, ist das Aufaddieren der Flat-Subs. Da kann man sich einen Fehler einhandeln, wenn man nicht mit einer konstanten Lichtquelle arbeitet (Himmel in der Dämmerung) und die dunkelkalibrierten Flats additiv stackt. In PI kann ich auch multiplikativ stacken. Bzw - gemeint ist die Normierung. Was es in Fitswork gibt oder wie das dort gemacht wird weiss ich nicht.
Wenn Du die Flats einfach mittels (mean) ist es doch egal. Wenn Du eine andere Mittlungsart nimmst außer mean, z.B. den Median, mußt Du normieren. Bei Darks und Flats nemeich ich immer das arithmetische Mittel (mean). Da kann man nichts falsch machen.
 

pem.bn

Mitglied
Ich möchte gern eine Bemerkung zu Float vs. Integer machen.
Integer auf dem PC ist 32bit und auch Float ist 32bit. Ausser man wählt die Typen größer bzw. kleiner. Bei der Bildverarbeitung wird oft mit 16bit Integer gerechnet und dann stimmt die Aussage das Integer weniger Speicherplatz benötigt. Man kann aber auch in 32bit Integer speichern und dann wäre die Größe gleich.
Generell gilt bei gleicher Anzahl von Bits: Float Zahlen haben einen größeren Dynamikumfang da 23 bit Mantisse und 8 bit Exponent. Integerzahlen eine höhere Präzision oder Auflösung da 31bit nur Mantisse. Das letzte Bit bei beiden ist das Vorzeichen.
Das ist zwar im wesentlichen richtig (in modernen PCs mit 64bit Betriebsystemen sind Interger und Floats sogar 64bit lang), Du vergißt aber einen wesentlichen Punkt: Bei Rechenoperationen mit Integern ist das Ergebnis auch wieder eine Integer.
Deshalb gibt es bei der Division ein Problem mit der Genauigkeit.

9+10 = 19, 9-10 = -1, 9*10 = 90, aber 9/10 = 0. Das ist bei allen Programmiersprachen so, die zwischen Integer und Float unterscheiden. Für alle Integer N, M ist N/M = 0 wenn M > N. Es ist auch z.B. 5/3 = 1

Da kann man sich gut vorstellen, dass die Division (Light-Dark)/Flat kein genaues Ergebnis liefern kann, was ich dem Ergebnis auch angesehen habe. Es blieb noch eine Restvignettierung übrig.
 
Zuletzt bearbeitet:

Hoschie

Mitglied
Wenn Du die Flats einfach mittels (mean) ist es doch egal.
Dann schon, aber ich benutze normalerweise Clipping. Neben Betateilchen kann ich ja auch Flugzeuge, Wolken, Ungeziefer und durchaus Sternspuren in den Rohdaten haben. Für das Clipping muss ich die Frames normieren, zumindest bei nichtkonstanter Lichtquelle. Aber jetzt lass mal die Katze aus dem Sack, was benutzt du? Rechnest du deine Kalibrierung selber, und wenn ja was nutzt du dafür?

Wenn du dich beim Flat-Kalibrieren im Bereich von 3 oder 5 ADUs bewegtest, dann hättest du gunrdsätzlich schon kein gutes Ergebnis, alleine wegen des Photonenrauschens. Wenn die Rechengenauigkeit eine Rolle spiele würde beim Flatkalibrieren, dann müsstest du ja Quantisierungseffekte sehen in deinen Bildern!

CS Hoschie
 
Zuletzt bearbeitet:

pem.bn

Mitglied
Ich dachte, Du würdes mindestens ein (sauberes ;)) weißes T-Shirt über die Optik legen. Klar, wenn Du so an den Himmel gehst, kann natürlich alles passieren.

Ja, ich rechne die Kalibration selber, dann kann ich mehr experimentieren und Einfluß nehmen. Ob letzteres immer so gut ist, wird sich zeigen. ;) Jedenfalls kann ich mir so jeden Menge Datenmüll ersparen, den ich sonst bekommen, weil die Zwischenschritte auch alle abgespeichert werden. Ich speichere dann nur noch das Endergebnis. Momentan mache ich das Alignen aber noch mit Fitswork.

Ich habe das in Python programmiert, da geht das sehr einfach. Es gibt sehr gute und effektive Module und Bibliotheken für fast alles, was man so braucht. Da muß man nicht jedesmal das Rad neu erfinden. Es gibt ein astroalign von Martin Beroiz, das werde ich vermutlich benutzen. Jedenfalls erst einmal testen.

Prinzipiell gibt es solche Quantisierungseffekte, wenn man mit Integer auf kleinem Niveau arbeitet, die verschwinden aber wieder, wenn das Alignment und Mitteln gemacht wird. Aber letztlich hast Du ja auch schon eine Quantisierung in den Daten selbst. Insbesondere, wenn die (bei ASI) alle 8 Einheiten auseinanderliegen. Das sieht man übrigens im Histogramm. Das sieht dann aus wie ein Kamm, wenn es fein aufgelöst ist.

Ich habe den ersten Entwurf des Programms (Linux) angehängt für die Mono-Kalibration:

Python:
#!/usr/bin/env python

import numpy as np
import pyfits
import sys, os
import colour_demosaicing

def Input(Object, mydir="./"):
    dlist = []
    for file in os.listdir(mydir):
        #if file.startswith(filename):
        if file.find("L_"+Object) >= 0:
           dlist.append(os.path.join(mydir, file))
    dlist.sort()
    return dlist

def main(argv):
    prefix = argv[1]
    dlist = Input(prefix)
    caldir = "/home/peter/Astro/Calibration/Mono/"
    biasname = "MasterBias_0_50.fits"
    darkname = "MasterDark300_0_50.fits"
    flatname = "MasterFlat.fits"
    hdub = pyfits.open(caldir+biasname, ignore_missing_end=True)
    print hdub[0].header['INSTRUME']
    mbias = hdub[0].data.astype('float')
    hdud = pyfits.open(caldir+darkname, ignore_missing_end=True)
    mdark = hdud[0].data.astype('float')
    print hdud[0].header['INSTRUME']
    if os.path.exists("Masterflat.fit"):
       hduf = pyfits.open("Masterflat.fit", ignore_missing_end=True)
    elif os.path.exists("Masterflat.fits"):
       hduf = pyfits.open("Masterflat.fits", ignore_missing_end=True)
    elif os.path.exists("MasterFlat.fit"):
       hduf = pyfits.open("MasterFlat.fit", ignore_missing_end=True)
    elif os.path.exists("MasterFlat.fits"):
       hduf = pyfits.open("MasterFlat.fits", ignore_missing_end=True)
    else:
       print "default Flat used"
       hduf = pyfits.open(caldir+flatname, ignore_missing_end=True)
    print hduf[0].header['INSTRUME']
    flat = hduf[0].data.astype('float')
    mflat = flat - mbias
    mflat /= np.sum(mflat)
    num = 0
    hdub.close()
    hdud.close()
    hduf.close()
    sdata = 0.0*flat
    for filename in dlist:
        hdul = pyfits.open(filename, ignore_missing_end=True)
        header = hdul[0].header
        raw_image = hdul[0].data.astype(float)
        hdul.close()
        data = (raw_image - mdark) / mflat
        num += 1
        outfile = str("%s_Dark_Flat_%4.4i.fits" % (prefix, num))
        if os.path.isfile(outfile):
           os.remove(outfile)
        header['DATAMAX'] = np.nanmax(data)
        header['DATAMIN'] = np.nanmin(data)
        header['OBJECT'] = prefix
        #header['EXPTIME'] =
        header['NIMAGES'] = len(dlist)
        pyfits.writeto(outfile, data, header, clobber=True)
        print outfile, data.min(), data.max()
        sdata += data.astype(float)
    outfile = str("Aver_%s.fits" % (prefix,))
    if os.path.isfile(outfile):
       os.remove(outfile)
    pyfits.writeto(outfile, sdata/num, header, clobber=True)

if __name__ == '__main__':
   main(sys.argv)
 

pem.bn

Mitglied
Die Flat-Normierung habe im Programm noch mit dem Integral (np.sum) stehen. Das sollte aber durch np.mean, den Mittelwert ersetzt werden. Das macht zwar prinzipiell keinen Unterschied, weil es nur eine Skalierung ist, aber die Werte werden ziemlich groß dadurch. Zumidest für int16 zu groß. ;)

Natürlich kann man das Dark auch noch mit dem Verhältinis von ft = Light-Zeit/Dark-Zeit skalieren, also
data = (raw_image - ft*mdark) / mflat
Falls man gerade kein passendes Dark zur hand hat. Ist dann nicht ganz so sauber, aber besser als nix abziehen.
 

pem.bn

Mitglied
Hallo nochmal.

Prinzipiell klappt die Reduktion der Mono-Bilder sehr gut mit meinem Programm. Mittlerweile habe ich das Alignment auch integriert. Allerdings habe ich noch unschöne Grünstrukturen im Farbbild, wenn ich meine ASI1600MCPro auswerte:

M74_FlatRGB.png

Das Bild kommt so als Endergebnis aus dem Programm. Lediglich STF in PI (mit oder ohneFarbverkettung ist identisch) wurde angewendet. Auf der linken Seite sieht man deutlich einen grünen Schleier, den ich auf alten Farbaufnahmen auch schon bemerkt hatte, die ich mit Fitswork reduziert hatte. Das ist ärgerlich, weil man einen Hintergrund abziehen muß. In diesem Fall kein Problem, wenn man aber großflächige Strukturen hat (Plejaden, M31) wird das schon schwieriger.

Daraufhin habe ich mir das MasterFlat in den einzelnen Farbkanälen angeschaut:

MasterFlat_RGB.png

Man sieht im mittleren Bild, dem Grün-Kanal, dass die Krümmung des Flats deutlich geringer ist, als in den beiden anderen Kanälen R und B. Keine Ahnung, woran das liegt. Ich benutze die Lacerta FlatFieldBox mit Dimmer.

Um den Grün-Kanal zu umgehen, habe ich als "Workaround" einfach mal R und B gemittelt für G im MasterFlat eingesetzt. Das funktioniert dann schon besser:

M74_FlatRGB.gif

In dieser Animation sind die beiden Flatfield-Korrekturen im Blinkmodus zu sehen. Der grüne Schimmer verschwindet, wenn ich [R , (R+B)/2, B] als Flatfieldkanäle benutze.

Ist das eher kameraspezifisches Verhalten (Bayermatrix), oder liegt es an der FlatFieldBox?
Die ASI1600MCPro hat "Griechenland-Bulgarien" als Pattern (GRBG).

Wie ist Eure Erfahrung mit der Kamera oder generell mit Farbkameras und Flat-Korrektur?

Gruß,
Peter
 

Hoschie

Mitglied
Moin Peter,
genau solche Sachen wundern mich auch immer. Vielleicht hat es auch was mit dem Emissionsspektrum der Folie zu tun (ist ja ein LED-Spektrum, kontinuierlich nur mit Zudrücken aller Augen incl Hühnerwelchen)? Anderes Spektrum, anderes Streuverhalten am Tubus? Oder mit einer nichtisotropen Lichtabgabe von der Folie?
Eine Wissenschaft für sich...

CS Hoschie
 

pem.bn

Mitglied
Hallo Hoschie,

ich tendiere zu einer Refexion an der FlatFieldBox. Das ist ja eine Plexiglasscheibe. Allerdings habe ich keine Ahnung, warum die nur das grüne Licht refelktieren soll. Ich werde mir mal im Bastelladen einen dünnen, weißen Karton besorgen und den dazwischen legen. Mal sehen, obs was hilft. Wenn meine Vermutung richtig ist, lasse ich mir das patentieren. ;)

Gruß,
Peter
 

Michael_Haardt

Mitglied
Sind die Pixelwerte im geposteten PNG linear oder gammakodiert? Der Grünkanal ist deutlich heller als die anderen beiden Kanäle und er hat eine ganz andere Helligkeitsverteilung: In R und B ist das eher ein Halbkreis, während es bei G vom Rand her linear zur Mitte ansteigt. Wenn die Pixelwerte linear sind, dann stimmt da etwas gar nicht, und Dein Bild mit dem korrigierten Flat legt nahe, dass es so ist. Die Helligkeit sollte etwas reduziert werden, um auf keinen Fall in den nichtlinearen Bereich zu kommen.

Wie wäre es, zum Vergleich ein Flat am Tageshimmel im rechten Winkel zur Sonne zu machen?

Es ist nicht einfach, homogene Lichtfelder zu erzeugen und sehr einfach, bei der Erstellung von Flats irgendwas falsch zu machen. Das Optimum wäre eine große Ulbrichtkugel, denn genau das hat man am Himmel. Oder man nimmt eben gleich den Himmel. :)

Michael
 

pem.bn

Mitglied
Sind die Pixelwerte im geposteten PNG linear oder gammakodiert?
Das kann ich Dir nicht genau sagen. Ich habe STF (Boosted) in PI verwendet.

Meine Nachbarin Linda (5) hat mir liebenwerterweise ein paar DIN A3 Blätter aus ihrem Malbuch überlassen. Damit habe ich mir einen Kreis ausgeschnittem, der auf die Plexiglasscheibe der FlatFieldBox passt. Den Dimmer brauchte ich durch die entstandene Lichtdämpfung nicht mehr. Ich habe ein Masterflat mit 64 x 0.21s erzeugt. Das hat aber keine Verbesserung gebracht. Das Ergebnis sieht genau so aus, wie das ohne Papier.

Deshalb habe ich mir aus dem alten Masterflat den (R + B) Kanal genommen und als Mono-Flat genutzt und die Farbbilder damit korregiert. Das hat noch das beste Ergebnis geliefert:


Damit kann ich leben.
 
Oben