×
INDI Library v1.8.5 Released (19 Apr 2020)

April 2020 release of INDI Library v1.8.5 introduces new drivers while providing fixes and improvements to existing devices and core framework.

Image HFR History

5 months 3 hours ago
rlancaste
Platinum Boarder
Platinum Boarder
Posts: 2251
Karma: 22
More
Image HFR History #47407
So the reason I mentioned comparing hfr values with focus frames vs light frames is because the current functionality uses a focus frame between each light frame to keep track of the hfr to determine if an autofocus is necessary. The simplest implementation of the idea that was proposed would be to just take what is already there and just log the results on a graph. But if we want to change that to make it use the light frames instead to keep track of the hfr we would need to think about this so that we don’t break the autofocus monitoring that works right now.

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

5 months 2 hours ago
Ihoujin
Platinum Boarder
Platinum Boarder
Posts: 862
Karma: 3
More
Topic Author
Image HFR History #47408
I was not aware the autofocus monitoring worked that way. I suppose I can understand why, but it must take a fair amount of idle time to capture and download additional frames.
We must also consider the graph will be used by those who do not have motorized focusers to tell them when to manually focus. How does the current HFR monitoring system work if no focus driver is running?
However, I do see an advantage of taking separate focus frames that will be less likely to have any star trail issues of guiding is not used or was poor polluting the measurements.

INDI/KStars on Raspberry Pi 4, 4gb
Raspbian Buster with AstroPi3 script configuration
Skywatcher HEQ5 Pro Mount
Canon 600D Camera
Orion SSAG/ASI120mm @280mm Guide Scope
PHD2
Adafruit Motor Hat shield
Adafruit GPS Module
Generic Bluetooth Joystick.
Startech 7 port powered USB Hub.

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

4 months 4 weeks ago
rlancaste
Platinum Boarder
Platinum Boarder
Posts: 2251
Karma: 22
More
Image HFR History #47414
I am not sure because I only found how the current hfr monitoring function works when I started looking into adding the hfr monitoring graph that started this thread. I knew that the checkbox was there, but I don’t tend to use that feature because I typically just start the autofocus myself when I feel it is needed. So I didn’t realize that it mostly did what we were looking for already, except that what I would like personally is a graph with a report as to how the hfr has progressed over time and I do not want it to autofocus itself automatically when the hfr gets to a certain value like the checkbox says currently. I still want to decide myself when to autofocus.

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

4 months 4 weeks ago 4 months 4 weeks ago by Herrhausen.
Herrhausen
Platinum Boarder
Platinum Boarder
Posts: 631
Karma: 3
More
Image HFR History #47427
So we agree on almost everything. A HFR value derived from a light frame would do more than just check the focus. It would provide a comprehensive measurement of image quality and make users aware of problems other than just a deteriorating focus (like guiding issues for instance). The important thing IMO is to become aware of such problems as soon as possible (certainly before doing image processing the day after as it happens now) in order to avoid taking useless light frames and wasting precious observing time. The focus module could be left totally unchanged and do re-focusing as it does now. In addition to it, the "global" HFR value would be calculated and displayed (with or without graph) whenever a light frame is received. It would be 100% up to the user to perform re-focusing, check guiding, or take other measures in order to improve image quality then.

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

4 months 4 weeks ago
DerPit
Platinum Boarder
Platinum Boarder
Posts: 398
Karma: 1
More
Image HFR History #47429
Yes, this is what I currently do. I run an external program that watches for new files, analyzes some (preselected) stars by fitting a 2D moffat model and then plots FWHM and ellipticity. (It also aligns images and gives a live stack view). Ellipticity usually points at guiding errors and/or wind, FWHM obvious focus errors, but also seeing quality. I do get a very good correlation between the FWHM variations and seeing measurements using a DIMM (Differential Image Motion Monitor).

The latter is one reason I don't use the automatic monitoring by EKOS anymore. There is no real way to decide if the focus drifts or the seeing gets worse, unless you also include the temperature plot (unless of course your focus system has slip). So a general monitoring module definitely should also include the temperature (but I think that is already on the wishlist, is it?).

As for monitoring in EKOS: How much work would it be to grab the (full field) star selection and HFR fitting from the focus module, and put it into the FITS viewer? I know it even already has a 'HFR' slot in the statistics which is always -1. So it seems the evaluation part is (still) missing...

openSUSE Tumbleweed KStars git INDI git
GPDX+EQMOD, CEM60EC, ASI1600+EFW+EAF+ASI290 mini

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

4 months 4 weeks ago
Herrhausen
Platinum Boarder
Platinum Boarder
Posts: 631
Karma: 3
More
Image HFR History #47438
Is this external program open source so its functionality could be implemented in Ekos easily?

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

4 months 4 weeks ago
DerPit
Platinum Boarder
Platinum Boarder
Posts: 398
Karma: 1
More
Image HFR History #47442
In principle it's not secret (though not published anywhere). But I do all my image processing stuff in IDL (Interactice Data Language), so as-is it's not really helpful to others. Last time I tried GDL wasn't able to run all needed stuff in there. It's anyhow only an ugly hack (comparable to some shell script) that likely only works for my camera, screen and data organization :(
As always, the difficult part is not the core math (Levenberg-Marquardt fit), but the effort to make it work on any image, and nicely display the results.

openSUSE Tumbleweed KStars git INDI git
GPDX+EQMOD, CEM60EC, ASI1600+EFW+EAF+ASI290 mini

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

2 months 3 days ago 2 months 3 days ago by Herrhausen.
Herrhausen
Platinum Boarder
Platinum Boarder
Posts: 631
Karma: 3
More
Image HFR History #51226
I recently found that han.k's ASTAP offers HFD functionality.



Currently I use astap to check the quality of my images during a session. As soon as the latest light frames show deteriorating HFD values, a re-focus is initiated. I think it would be handy if FITSViewer could show the HFD value of the picture it currently displays, too. Also, the summary screen should display the same number. I don't know if han.k's code is in the public domain but if so, it shouldn't be too complicated to implement it in Fitsviewer and the summary screen.
Attachments:

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

2 months 3 days ago
DerPit
Platinum Boarder
Platinum Boarder
Posts: 398
Karma: 1
More
Image HFR History #51227
Well, in principle everything needed is already in EKOS, in the focus tab. The full field mode is what you look for. That is likely easier to use than converting Hans code - AFAIR he is writing in Pascal :) (but yes, it's OS - not PD though)

openSUSE Tumbleweed KStars git INDI git
GPDX+EQMOD, CEM60EC, ASI1600+EFW+EAF+ASI290 mini

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

2 months 3 days ago 2 months 3 days ago by Lead_weight.
Lead_weight
Platinum Boarder
Platinum Boarder
Posts: 386
Karma: 4
More
Image HFR History #51234
I wanted to add a quick comment about this. I'm pretty sure one of the reasons SGP does this (and stores the focus setting in the Fits header) is to that it can make appropriate flats at different focus settings for the prior nights imaging session using it's automated flats wizard.

I use an EDGE 11", and focus changes enough overnight that my flats don't often work to remove all dust motes. The main reason for this is the flats are often at the last focus point, and not at any in between focus points or the starting focus point for the entire imaging session. On refractors this will be less of a problem, but on large scopes, this is a huge deficiency in EKOS right now. It seems EKOS has really hit its stride, and has very few non-driver related bugs. 3.4.0 is awesome. So now, my primary problem when using EKOS is flats don't always correct out properly due to focus changes over night. It would be awesome if instead of just graphing it, the log could be looked at to better automate flat creation.

-Andrew
––––––––––
Mac Observatory - All about using the Mac for Astrophotography: www.macobservatory.com
Astrobin: www.astrobin.com/users/Lead_Weight/

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

Time to create page: 1.148 seconds