Magnus,

I may not have much time later today to look into it, but a quick initial look shows that:

Now I'm not sure if it's sortware or hardware.

it is asking the focuser to move to a certain position to start, and the focuser doesn't get there, and the Linear algorithm doesn't
reset to the new position that the focuser is insisting on.

For instance, in the first attempt.
Starts at 10760
Linear wants to start its sweep at 11160, but does this by planning to go out to 11660, then back in 500 to 11160 (It doesn't violate max position, but it is ignoring max travel)
So it requests that the moonlight go to 11660. Indi copies that. But the focuser reports getting to 10916.
*** Do you have some kind of backlash removal active or something like that that could be confusing it?
The Linear focus seems to ignore this discrepancy and then moves back in by 500 which gets it to 10416 (instead of 11660) and now things are messed up and Linear isn't recovering well.

2nd focus session:

Starts at 11000
Plans to go out to 11900 and back to 11400.
But only gets to 11134 and then goes back to 10634.
Same finish as above.

I'm not sure why your focuser is not going out to the position requested in the first outward movement.
It seems to work fine for the inward movements, but not the outward movements.

Does it all work well in polynomial?

Can you manually command it to move out to these positions and back in?

Hi!

No backlash removal that I know of... to the best of my knowledge, there is none in the MyFocuser Pro ver 1. And no mechanical stuff like that.

I can try tomorrow to see if I manually can move it to those positons. Right now it is imaging...

Polynomial works fine, and tonight even better than usual (if because we have real clear skies, or because I use full field with annulus set properly, I do not know.

I'll try tomorrow.

Magnus

Hi!

So, I have no problems in moving to those positions and positions beyond them (in the 12000 range) manually.

Magnus

Some focus problems are caused by outliers - hot pixels and extended sources such as galaxies. Would these be more effectively removed by changing the full field HFR determination to use the median rather than the average HFR value. This will cause extreme values to be ignored quite naturally.

Or even better discard the 5% smallest and biggest outliers and take the mean of the remaining detections.

With 50+ stars you might as well do a winzorized sigma clipping. Or maybe even linear clipping. For only one 'pixel' the computational overhead is not noticeable.

Better? Why? How does an arbitrary change to the data make it better?

In actual fact the current code has an undocumented feature where the full set of HFRs is averaged, the standard deviation is determined, values that are more than two standard deviations from the original mean are removed and a new 'average' is determined.
This is statistically dubious, not only does this reduce the mean but the amount by which it is reduced will depend on the data. Maybe extended objects will be included sometimes but not in others.

The median is at least a valid way to determine a central value.

What benefit does this have, other than be more complex?

From a look at the code the HFR array is already sorted so getting the median is easy.

If that is what is in the code then I would leave it as it is, in a binomial distribution 2 standard deviations within the mean would equate to 95% of samples, with those outside being discarded, so pretty much it is already discarding outliers then.

I'm not sure whether using an actual median value would be better in all cases, perhaps it would be nice to have the option to configure it either way.

I wonder if the HFR of stars on a field is always a Poisson distribution. There are probably not enough of them in a focus frame to determine that and use that statistical property.

I am trying to introduce PSF in the CCD simulator to better test the different focus algorithms. SExtractor support will be there too relatively soon. We also need to display an interface for the SEP settings.

We also need to better document the features in the tooltips that appear in the UI.

Anyone has unused work days to spare?

-Eric

Not really. This is standard, called sigma clipping. And the winsorizing I mentioned is an improvement on this for a better determination of the standard deviation. Both methods are quite well analyzed and accepted in statistics for removing outliers.

Something I heard of at work was that people were analysing the waste from gold mines to see how much residual gold was left and if it was worth reprocessing it using more modern methods.

Lots of analyses were done, and some came up with negative amounts of gold. You can't have less than nothing so they were set to zero and the results averaged - and there was enough gold to be worth processing. I'm not sure how much waste they got through before they discovered the error of their ways.

It looks as if this is just the same, one side of the distribution is being clipped and that will inevitably affect the average value.