Wow, this new algorithm fits perfectly what I was proposing here only 4 months ago (and you also had already in your mind by then) and even more that I didn't think of!! (different curves, weighting by HFR stdev, ...) Last night I gave it a try and it went quite smooth! I can afford to make focus exposures longer to get better SNR and even so, autofocus takes way less than before. Thanks so much for your effort, for me this is quite an improvement.

Playing with the parameters I occasionally ended up with a failed autofocus, that was quite expected as I pushed some of them. But although the log reflects the failure, it doesn't show why it failed:In this case, I guess it didn't meet the minimum R² I configured, but I think it would be desirable if the failure reason gets logged.

Also, the Analyze tab didn't plot any HFR measurements in the graph, and "Iterations: 0" is shown under Details (in the log I see that this particular autofocus run took 9 HFR measurements).

Thanks again!

Thanks very much for the feedback Sergio. If you configure logging like this:


Then you'll get all the focus related messages. For an R2 failure you should get:
2022-06-26 12:49:09.983722+0100 kstars[11402:2349276] [org.kde.kstars.ekos.focus] "Linear Curve Fit check failed R2=0.999893 R2Limit=1 retrying..."

After the rerun you'll get something like this...
2022-06-26 12:50:00.620048+0100 kstars[11402:2349276] [org.kde.kstars.ekos.focus] "Linear Curve Fit check failed R2=0.997972 R2Limit=1, but continuing..."

I suppose your point is that it could be a bit more obvious as to why the rerun happened (as opposed to having to go hunt through a detailed log file). Good point, I'll have a look at this.

In the Analyze tab you should get a focus entry for each autofocus run. If the run is successful it should log all the datapoints. If it fails, it will log the fact that there was an autofocus run but not the datapoints. L1P just fits in with the existing Analyze workflow here. This is how it works for the existing focus algorithms.

If you post the log here I can take a more detailed look.

Thanks John for your prompt answer. Truth is I even didn't think of enabling the debug logs... I was expecting these messages to appear in the status (bottom) panel of the Focus tab.
Yes, in the Analyze tab I do see the successful runs correctly. Sorry I didn't compare the failure case with the other algorithms, of course you're right.
Thanks for your time!

I've added the R2 fail messages to the status panel. I need to go through the other msgs and review where they are going. I don't know how long it will be before this gets into the nightly builds.

No problem at all, the algorithm is totally useable as is.
Many thanks John!

I used L1p yesterday for my (automated) observations. Looking at the analyze log, it always found a reasonable focus, even in bad conditions (I did have quite a lot of wind last night ). I strongly doubt any of the other algorithms would have found something better. For that, probably some machine learning would be needed (my brain BI would have picked slighly different values in some cases )

All in all a very valuable addition!

Just did quick test of this and it is really good addition.

Just doing a first session with the Linear 1 pass and it works like a charm! First time I get really reproducible focus values and a focus run takes only half the time… Also, using weights for fitting is really a good thing to do!

Thanks John for the valuable extension!

CS, Bernd

Do we know when this will make it from nightly to stable PPA please ?
I'd love to try the Linear 1 Pass but I cause enough problems of my own with my rig, without adding the nightly code into the picture

The plan is that 3.6.0 (which will include L1P) is released 29th July.

Fabulous. Thank you John

John, I have a question.
Actually, it was more than one, fortunately I first read through your PDF more carefully, which answered them...
I've been running L1P for a while now, with one instance being an OSC camera connected to an oldish Canon FD lens that has some longitudinal CA issues.
It turned out that I got a nice and sharp red channel, with the other two being mildly and strongly defocused. That is an issue that Rob Lancaster had spotted (and, AFAIR, taken care of) that for debayered images the first channel (=R) was used for focusing, which was changed to using the second one (=G). And I was quite sure I had tested it successfully before (at that time with Linear)
So my question is whether you do handling of image types in your code (and use the first channel), or if something else went wrong with that patch. Or I'm doing something wrong of course....
Pit