The way I see the code, those parameters are not stored in the FITS header. They are store in a side database.
See saveDarkFile:
invent.kde.org/education/kstars/-/blob/m...darklibrary.cpp#L139
So, I think, the system has a record in its permanent storage of the CCD, binning, temperature, duration, filename.
When it wants a dark, it looks through all of the possibilities in this storage for a match. If it finds one, it tries to load the fits file from the filename.
If that fails, it destroys the record. If that succeeds, it uses the file it loaded.
To hack around the lack of a good dark-frame estimate, I think you'd
- capture a single dark frame with KStars using existing code with the right name, binning, temperature and duration.
- capture other files somehow, outside the KStars dark-frame framework.
- generate your averaged (or median'd) dark frame outside the KStars framework.
- replace the KStars file with your new file.
- adjust those options related to temperature range and longevity.
- give it a try!
BTW--just looking this over again, I'm worried that the dark estimate and the light frames you'd later want to improve need to be the same data format (e.g. you might not be able to have a 16-bit light frame and a floating point dark frame). See
invent.kde.org/education/kstars/-/blob/m...darklibrary.cpp#L222. Since your lights are likely 8-bit or maybe 16-bit unsigned integer format, If I were you, I'd start with generating a similar dark-frame fits.
For sure, this is a hack, and the right thing to do is implement an improved dark-frame scheme. [Also, I can't be sure I'm right
about the above procedure, as I just looked at this quickly.]
The better solution may happen at some point. One of the developers (or you if you can) could implement things could pick up this project.
However, doing this hack and demonstrating improved performance with a good dark estimate would be valuable in motivating
someone to do the work.