I think I submitted a PR on the new repo.

Changed the colors for the "out" segments to match the colors in the drift graphics

I'd say yes, it would be useful for folks trying to tweak their focus parameters. I think is common among non-developers.

You can see the request here
https://indilib.org/forum/general/6167-for-those-with-focus-issues.html?start=96
from dmsummers on 5/4/2020.

Comments and cosmetic changes

I agree whole-heartedly with the need for doc for the state machines, but I am not on top of them, nor have I made any real changes to them. If you like, we can collaborate on some doc for mount and capture, but I think that's outside the scope of this PR.

Looks good. Thanks!

Also don't draw overlays for the stretch preview image

Honestly, I don't know and can't test. However, it shouldn't fail. See line 161 in fitsview.cpp.
If the system call on Windows doesn't support the _SC_PHYS_PAGES request,
it should return -1 according to http://man7.org/linux/man-pages/man3/sysconf.3.html
and then we should get the 300% default.

Jasem, as requested, I added several lines in the constructor to see if the amount of physical memory is known, and if so, I created max zoom values based on that. See lines 154-177 in fitsview.cpp. Could have gone further and made it a function of the image W*H*C and physical memory, but honestly I'm not sure that's a good idea. Let me know if you disagree and if so, how much zoom for how much physcial memory and image size. Now, you can zoom up to 600% if you have 16Gb of memory. On my 32Gb MacbookPro, this is now limited by CPU more than memory. Tested on 32Gb Mac/Catalina (where the limit is 600%) and on Raspbian RPi4 4Gb (where the limit is 300%). According to online doc, some systems may not reveal the amount of physical memory. In that case the limit should be 300%.

Adjust the maximum permissible zoom based on the amount of physical memory.

Forgot to add the URL to the example image in my last comment.
It's https://photos.app.goo.gl/tG5yheZyfxHWoJ788
and it's also at the bottom of the album with all the images:
https://photos.app.goo.gl/CHgXVZBREA19LVgN8

Eric, I apologize but I don't fully understand your suggestion. I haven't changed it from an ellipse to a circle. It was a circle before, and I've kept it a circle. What I was trying to do is remove the noise from using the poor width estimate as a radius and replace it with double the HFR, which is much more consistent, as my images show. I didn't intentionally change where the center was, so if the center is off now, it was likely off before, e.g. note in the images I sent, the images on the right, offsets are noticable on some stars, is the "before" picture, that doesn't have my changes. Note, one thing I did change, though, is now I give Qt a float for the coordinates, whereas previous it was truncated to an int. Do you think that had an adverse affect? If you see an error in my code for centering these circles, please let me know and I'd be happy to fix it.

Adjust the center position of circles drawn around stars by half a pixel.

Rob, I actually disagree that you get the accurate saturation value. E.g. your technique wouldn't work for signed shorts or signed bytes or floating point where the range is 0 to 1.0, or for that matter, cameras where Indi would put out 0-4K values, etc. In the end, I think we'll need a user-supplied input for this, but all that, I think, should get worked out when you complete your Sextractor parameter integration, and this could be one of the parameters that we offer the user the ability to modify. Until then, I believe this will be good enough. It shouldn't do any harm, and it might improve the situation over the current system. I did, though, modify my code to check to see if it was a byte type, and if so, change the saturation threshold to 250.

Modified saturation value if the data type is byte.

Reduced the disk footprint of the test fixtures.

Added tests at 3 different HFRs

Addressing your comment for line 789 of fitsview.cpp.
> I disagree : it was like this before, but small stars ellipses become offset because of rounding issues on the pixel center.

Thanks. I'll discuss your other comments in a bit, but first here is detail on the speedup. The basic idea is that previously the code was calling sep_flux_radius, an expensive call, on all detections unnecessarily. Instead, I first sort of the detected stars' oval size, since we are only keeping the largest stars, and only call sep_flux_radius on the stars we intend to keep. I checked and sorting by HFR after calling sep_flux_radius on all stars vs first sorting by oval radii and only calling sep_flux_radius on those give almost the same set of stars. 

I am abandoning these changes.
Eric has refactored the code, and I have sent in the updated https://phabricator.kde.org/D28767 to replace this PR.

@TallFurryMan Thanks Eric. I assume that at this point, I'm waiting for you to contact me and give me instructions on how to proceed.
Happy to add the test, but may need some hand-holding this first time.

Added a significant bug fix and speedup.

Reverted back to CENTROID as findStars default, still use SEP for mark stars, added hfr to status

I'm happy to drop this, or to fix it as you suggest. Let me know your preference and if you do recommend the change, which other parameters should be affected as well.

Jasem, I understand you sentiments, but in this case I respectfully disagree.
Here, the first 3 debug log statements will add at most one line per initiation of autofocus, and most likely nothing at all.
That's 0-10 or 20 lines in logs that can be > 100K lines. The final log statement would add one one line per capture.
While that could be a hundred lines per log, again, a tiny percentage, and could help us debug a hard-to-find bug.

Restored the conditions for the emit to what existed before https://phabricator.kde.org/D27274

Made the filename arg passed to writeImageFile a const.

Made sure the filename was not overwritten when waiting for the thread to complete

Previous submission had bad user.email, trying again.

Made the background white.

Updates for i18n/i18np and for author header.

Thanks for the review and testing Jasem.
I addressed your tooltip-concern in my latest update.
I don't quite understand how to respond to your other concern (re hiding the contols).

Adjusted stretch button tooltips depending on their state.

The difference is subtle and IMHO it would not be obvious to many users.
I think this is much clearer.
You can try it by disabling the clear--comment out line 184 in fitstab.cpp

Rob, That's working as intended. I clear the button and disabled it when selecting it didn't make sense. It only appears when there's something to do.
I tried it the way you suggest and it was confusing--the user could hit the button and nothing really would happen (e.g. I made an info pop-up, but in the end, I though the better thing to do was this).

Moved from QCheckBox to QPushButton for the stretch and auto buttons.
Auto button is only enabled when it makes sense.
Sorry, the blank auto-button is a little wider when disabled,
couldn't figure out how to avoid that.

Rob: Thanks for describing the bug related to the slider value display. I was able to reproduce and fix. You should not see that behavior anymore.

Fix bug related to updated slider text value when auto is checked.

I implemented Rob's suggestion to disable the sliders and their labels and the auto checkbox when stretching is disabled.
I think this was a good idea.

Disable most of the stretch UI when stretching is disabled.

Rob, thanks for all the suggestions and questions. Let me respond before I make any code changes.

Thanks again for testing and checking out the interface.

Fixed issue when stretching float or double fits file.

BTW, I see the problem with the floating point file.
The issue is that I need to normalize the number--the values needed to stretch are 1/64K as big as the 64K-scale-shorts, and so they underflow the 10000 scale I was using.
I will address this in the next couple days.

Jasem & Rob, thanks for the initial comments.

Fix bug that hid the labels.

This is out-of-date, I guess abandoned, and the new scheme is an improvement, IMHO.
Is there something I need to do to delete/abandon it?

Perhaps I'm missing the obvious, but I don't see it. I don't want to overwrite secondsLabel. How would I use a fall through?

Added secondsLabel update to current change.
Capture should show that it's focusing while waiting for the filterManager.

Wolfgang: Makes sense.
I assume what you mean is that I should do something like this:

secondsLabel->setText( i18n("Focusing..."));

just before the call to QTimer::singleShot(), where the text is dependent on filterManagerState.
E.g. if filterManagerState == FILTER_FOCUS then "Focusing...", if FILTER_CHANGE then "Changing Filters...", if FILTER_OFFSET then "Changing Focus Offset...".
I'll modify my change and do that.

That's true, though, as far as I know, that shouldn't happen.

Sorry for not filling that out. Here's what to check.

Fixed file permissions, which were accidentally set wrong.

Removed some of the templating and refactored to simplify code.
Added highlighting to the stretch buttons when the image is stretched.
Needed to run initDisplayImage always in rescale, and not sure why.
Will continue to investigate.