I'd like a CCD frame to be able to provide information on the quality of orthogonality or disturbance against the optical axis. Something like what CCDInspector does probably, in terms of collimation, or field graphs showing the evolution of FWHM over the frame. This would be useful for a mobile setup installation where the optical chain is assembled on the go, focus sharpness verification...

I was wondering if this implementation could be done like the astrometry driver currently is. That is, import of suitable libraries and snooping on CCD to calculate and provide a final frame. This might also open the door to setups instantiating chained post-treatments, eventually on separate indi servers.

What do you think?
-Eric

Michael Fulbright informed me he was interested in implementing this aspect in the FITS Viewer. I'll ask him about his progress.

Agreed, this would be a feature well suited for a client program such as Ekos. I was experiencing with the idea of integrating the feature lower in the chain, in order to touch more client applications. This would thus be more readily available for say Android client apps.

Based on this architecture idea, we could also develop things like automated image stackers (thinking about Atik Infinity there), or correlation analyzers for minor planet detection, or even storage backends. But I'm probably getting too imaginative there

-Eric

I started to look at it but got side-tracked by other commitments. Can't say when I might start on this.
I believe this should be a high priority. Among other things I think it gives a more robust way to focus automatically. I've seen the current auto star selection get fooled by a double star, for example, which leads to bad results. If you are using the median of several dozen or more stellar profiles you are probably going to get a more reliable result.

This would also help the case that seems to happen often of a star being selected at the very edge of the field. Strange things can happen there vs closer to the center of the field.

Stars selected on the edges is also my problem. The root cause is indeed not so in the focus process than in my setup physical configuration. Hence the need.

@mikefulb: what was your design idea? Where would you implement that feature, and with which tools? I'm currently experimenting with astropy and photutils.

-Eric

Ekos can already get the HFR of multiple stars in the field, but it is slower because:
1. Requires larger frame, it is useless to subframe.
2. Requires a lot more computational power.
3. Algorithm might pick up false positives.

I can enable this back but most likely you will be disappointed with the results.

Well, I wonder actually. It's the only reason why I still switch to SGP for an initial focus and then back to Linux, that focus routine is very robust in my experience. It may require more power, but if it provides better results I'm totally fine with that. False positives can happen, but can be rejected as outliers if you get data from many more stars. In Ekos my problem is similar to the ones above, it works fine in certain star-fields, but if I get unlucky Ekos selects double stars or a way too bright one or one at the edge, that happens just too often in my case.

Ok so I added "Full Field" option. It works fine under simulation, but I doubt it will be useful as full-frames are _slow_ and star-detect algorithm is quite susceptible to noise, but hey, it's there now. I also started researching wavelet-based approaches to measuring focus, but it's still in the early stages. If anyone has any good pointers on how to proceed in that regard, let me know.

If it is error prone, how difficult would it be to have the auto select algorithm for a single star to choose one from the center 50% of the frame?

It was selecting between 5% and 95%, now changed it from 15% to 85% of the field. Might make it configurable later.

I guess you found lots of research about it already, but I stumbled on this paper which I thought was nice: ojs.cvut.cz/ojs/index.php/ap/article/viewFile/1462/1294