Hello Jasem,
thank you for the time and effort you put into the development and improvement of indi / ekos /kstars. And thank you for your patience with beginners like me.

Today I kept experimenting with Autofocus and Canon DSLR and it urned out that some of the issues I reported yesterday seem to result from overexposures.
When I set substancially smaller apertures than yesterday, the autofocus works flawlessly with my Cannon 600d - at least for my artificial star and given I set the camera to viewfinder mode. In the fits preview I didn‘t recognize the overexposure; today I got aware of it, when I tested image transfer in native format in the capture module.
It looks like autofocus with Canon DSLR is absolutely possible if you know how to do it.
Though it would be nice to have buttons to control the DSLR aperture directly from the ekos gui in the capture module and in the focus module, these don‘t seem to be critical features - it can be done from the indi control panel. Automatically enabling viewfinder mode, whenever focus control ist needed, would be a real improvement.

Thank you again

Christian

Hello Jasem,
yes, it is fixed. The issue of brightness changes were due to overexposed frames. In the fits preview I wasn‘t aware of that. When I set the aperture to 9, the autofocus is working flawlessly. There was no „fix aperture“-issue - I apologize!

Thank you for all your effort!

Can the change for the view finder already be tested?

Yes it's in GIT if you can build from source. Or wait for nightly update.

Yesterday I was testing again and as reported before, focusing did not work with a 5D Mk2. I'm currently compiling a fresh GIT and will report whether things have changed.

Something is not right. After compiling the latest GIT Ekos starts slooOOOOOOwly. Once I start Ekos it takes more than a minute for 3 simulator devices to come online!

After removal of KStars and re-installation via apt the problem has disappeared. After re-installation of the compiled GIT version it re-emerges. So it looks like the issue was present in GIT but not in the nightly build.

Today I continued testing the (auto) focus module with my Conon 600d and an artificial star.

First of all thank you, Jasem, for making the changes.

The focus in/out buttons are working now and the auto focus routine is operating, i.e. the focus position is being changed automatically according to the measured HFR.
Sometimes the algorithm reports to have successfully focused. However, when I crosscheck the result with a bahtinov-mask or by taking an image, in the majority of cases it turns out that the artificial star is not really focused.

With at least the smae frequency, the algorithm terminates unsuccessful, i.e. the algorithm‘s condition for „good focus reached“ could not be reached. In these cases, it was true that the image was not focussed.

If or if not the agorithm terminates successful in the sense of fulfilling the condition for „goog focus reached“ strongly depends on the iso, aperture and exposure time. This may have to do with saturation in the center of the stellar image, though the profiles never look saturated at all. Do the profiles really show the measured variation of flux along the stellar image? They rather look like a gaussian with the measured HFR...
Is it possible that the algorithm, which - I guess - is working fine for telescope focussers, cannot be applied to dslrs in the same way? In my tests, the algorithm often changed the step-size too really small steps long before the actual focus position had been reached and then iterated around a non-focus position. It also occured often that the focus direction changed though from the behaviour of the HFR one could easily see that it would rather be a good idea to move on in the same direction to keep HFR decreasing.

In the end, the autofocus algorithm not being reliable would‘t really bother me, if I could use either the DSLR live preview or the images taken in the focus module to adjust the the focus position manually with a bahtinov mask.
Unfortunatelly, when I try to do this, in the fits viewer the brightness is being auto-adjusted in a way that I can hardly see the bahtinov-spikes. In the live preview, the resolution is too low, and I don‘t find a way to adjust the brightness either, so I can‘t see the spikes properly in live preview either. If I set image transfer format to native (in the capture module), I can see the spikes but I cannot zoom in to magnify the star, so this does not seem to be a solution, either.

I finally did bahtinov focussing by disconnecting the dslr indi driver and connecting to the camera by dslr dashboard remote control on the Ipad. There the spikes are clearly visible in the live preview and I can find the focus position in no time. However, I would really like to be able to do the focussing within ekos.
I am almost sure that there must be a way to control the image brightness in the fits preview? Can anybody tell me, how bahtinov-focussing can be done within ekos?

OK, I found the checkbox to deselect auto-scale. The german translation was somewhat misleading.

Now I can see the bahtinow-spikes in the image preview.
I don‘t know why, but focussing is easyier with the far3, far2, far1, near1,near2,near3 in the indi panel than with the timer based focussing method used in the focus module. Maybe that is a matter of practice.

Thanks for the valuable feedback. The timer based one could be wrong approach to this. Basically, it calls the focus (near1, near2, far1, far3..etc) every 50 ms until the timer is over. Maybe 50ms is too short? Maybe there should be a "sleep" after each call before the next one is made?

So for 1000ms, that's 20 calls. The behavior can be made to mimic a relative focuser. So we can assign weight for each one. near1=10, near2=20=, near3=50 (same for far1=-10, far2=-20..etc) and so you request step 110, it calls near3 twice and then it call near1. I'm not sure what are the relative weights of each call is. But if something like this could work out in principle, it doesn't hurt to try it out.

How if e.g. far3 takes more than 50ms?

I keep thinking about the strange behaviour of the slope of the HFR-curve: Usually there comes a point when the focus algorithm „tries“ a big step in „counter-direction“. When this leads to a substancial increase of HFR, why doesn‘t the algorithm try an even bigger step back? Instead it usally does change direction but in far smaller steps. The effect is that a so far minimal HFR that already has been reached in previous steps can never be reached again nor can it be improved.