INDI Library v1.9.4 Released (17 Jan 2022)

Bimonthly Stable INDI Library release introduces new drivers and fixes for existing ones. Some highlights:

Selective image calibration and stacking in memory to allow deep-sky lucky imaging with optimal disk usage.

  • Posts: 4
  • Thank you received: 3
This feature request is, I suppose, for EKOS rather than INDI but I guess the development team is the same or similar?

So my request is for EKOS to have a tab dedicated to the technique of deep-sky lucky imaging (DSLI). The DSLI technique is explained here: www.cloudynights.com/articles/cat/cn-rep...-lucky-imaging-r3220

DSLI basically allows you to remove some of the effects of atmospheric turbulence for deep-sky observations, allowing higher resolution imaging.

Deep-sky imaging cannot employ standard lucky imaging techniques as the exposure times typically used are too short to capture enough photons for image selection and stacking. So the idea behind DSLI is to use exposures of a few seconds, shorter than typically used for most deep-sky imaging but long enough to gather enough photons on brighter stars in the field to assess image quality. For many urban observing sites seeing is dominated by thermal currents near ground level that vary on timescales of several seconds. Removing these variations can therefore bring big improvements to image quality. Removing such variations can be done by selecting the subset of short exposure subs with the best FWHM or HFR and discarding the rest.

However, restricting exposures to a few seconds would entail producing a lot of images that would  quickly fill up a hard drive during a nights observing, and most of these exposures would be unused due to their poor image quality. The optimal solution is to capture images, measure their image quality and selectively stack the good ones in memory, then write the stack out to disk after some predetermined cumulative exposure. For example a user could request a series of 30-sec stacked images to be created from 3-sec individual exposures that pass some user specified thresholds on FWHM or HFR size.  Poor quality images would be discarded from memory and not written to disk.

To do this each captured image needs to be calibrated in memory with darks and flats before being measured for FWHM/HFR and added (or rejected) from the cumulative stack being held in memory. Once the stack reaches the requested cumulative exposure (or some minimum number of high quality subs) it is written to disk and a new stack is initialized. This continues until all requested stacks have been obtained or the session reaches some user-specified time limit. The resulting output will be a set of stacks of guaranteed image quality and that are already full calibrated. Obviously all this assumes the user is autoguiding or has an extremely accurately aligned setup so that subs do not need to be geometrically aligned within a given stack. (I guess if WCS is enabled then it could be possible to use this to align if needed?)

The DSLI tab would need to be able to allow the user to input/select the individual image exposure as well as either the output stack exposure or, equivalently, the number of subs per stack. It also would need to be told what dark and flat calibration frames to use and it would be useful to be able to specify the max number of stacks to output and a session time limit as well as have a button to gracefully terminate an ongoing session. A live graph showing the HFR or FWHM distribution of all images obtained so far (good and bad) would be useful to inform the user FWHM/HFR selection. There could even be an "preview" mode where EKOS just loops exposures and updates the HFR/FWHM distribution to allow the user to work out what the best FWHM/HFR cut might be. In preview mode there would be no outputting to disk (a bit like the loop mode in the camera tab) and the user just terminates it when they want to. Some live percentile stats would be useful here too.

I imagine the DSLI tab being perhaps a self-contained alternative to the standard camera exposure tab in EKOS. But it could equally be more minimal by inheriting all other camera values (camera device, gain, binning, filter etc) from the camera tab, in which case the user would need to fill out information in both the Camera and DSLI tabs to fully set up a run.

ok, so that's it. Unfortunately I have no C++ experience so cannot help to develop this but if someone wants to take it on I'd be happy to test it.
The following user(s) said Thank You: Jasem Mutlaq
Last edit: 4 months 2 weeks ago by Eamonn Kerins.
4 months 2 weeks ago #75047

Please Log in or Create an account to join the conversation.

Time to create page: 0.181 seconds