Not quite groundbreaking but a nice feature to have. Before this, each module implemented its own dark subtraction routine separately. Furthermore, when a dark is required, it will be captured right then, saved for the running session and discarded when KStars is closed.

Now with the dark library, all your darks at different frames/binning/temperatures settings are saved to disk. So if a dark is needed, and is found on disk, then it is used. You can configure how many days a dark is used before a new one is captured (default 30). Moreover, you can configure how much temperature difference is deemed "too much" that would trigger a new dark frame. All these settings in the Ekos settings pan of KStars settings screen.

Finally, when you first take darks, it will ask you if you have a shutter of not for this particular camera, so it can know whether to prompt you later to cover your CCD/scope or capture the dark right away if there is a shutter.

Hopefully it works well. Enjoy!

Nice job Jasem!

I just played with it a little, it looks like it works well. Is there any easy way to see what image duration, binning, and temperature darks you have on file and how close to expiration they are? Maybe the easiest thing is to just look at what darks are present. They are stored here is that correct? ~/.local/share/kstars/darks

I must say that there are an impressive number of changes today. Awesome Work Jasem!!!

In the Capture Module, I notice that dark subtraction is not supported in the sequence. Is the plan for that module to just have darks work with the preview or to eventually have darks get subtracted from all the images in the sequence as they are being saved? What about auto flat division in the capture module? Any thoughts? I know flats are not as stable as darks because of dust movement and camera placement.

Yes they're stored in ~/.local/share/kstars/darks. We'll see about adding a view on that. And there are no plans to do auto-dark or auto-flat in the sequence for now.

Ok, I can see that being a good idea, at least for now. That would add a whole other level of complexity with stacking darks and flats, plus the extra processing time and RAM required to process the images with the master dark and master flat as you go. And then it might be a good idea to save the original and the processed image (just in case), so that would also take up more space while you are taking data. Plus the code and user interface to manage it. So yes, good call.

There is maybe an issue with the dark library. See my topic on (logfile in 2nd post):
indilib.org/forum/ekos/1518-fits-viewer-...g-main-ccd-chip.html

Maybe this is only an issue with the SBIG dual chip cameras, as my other problems point out in that direction.