One thing that supports your „weight idea“ is that different lenses have differently fast focusers. (e.g. my Tamron has a rather slow focuser.) Therefore a step size in terms of a distance may be more apropriate ...

I really don't want to rain on your parade but focussing does not work here, neither with a 20D, 40D, nor 5D Mk2. After opening the LiveView windows the lense's reaction to a click at "focus in" or "focus out" is totally random. From nothing happens at all to moving several steps in one direction. Unfortunately the next press on the same button delivers a totally different result. When I close the LiveView window, the cam's mirror is stuck. Even switching off the camera won't help. I have to remove the batteries and only when I switch the cam back on, the mirror will be released to its normal position.

Ok I've disabled turning view mode to ON when in live view. I think the important thing now is to figure out a deterministic method to change the focus position instead of relying on timers. In the current implementation, you see three speed settings 1 to 3. Focus IN would make speed negative while focus OUT is positive. then the driver calls gphoto_manual_focus with the speed (-3 fastest in, 3 fastest out). I don't have an artificial star to test this, so the relative strength of each can be figured out (unless it's already documented somewhere). I believe this is also specific to Canon only, nikon uses a different range.

Darktable tethers/focuses perfectly with 40D and 5DMk2. Maybe their code should be looked at?

Can we make the LiveView window in focus tab stay "always on top"?

Are the changes you made already in the newest nightly build?

Not sure about nightly, but check GIT as I just pushed another update after a couple of hours of work on it. Now, at least on 600D, focusing works with live view on or off. It now uses the timer to figure out the speed, so anything > 1000ms will either be far 3 or near 3, while anything > 250 (and less than 1000) will be far 2 or near 2, and anything below that is far 1 and near 1. I don't know how this will fair in autofocus exactly, but try it out. The division here is rather arbitrary so it can be tuned, or it can be turned into fake steps with relative weights as I proposed before.

Thank you, Jasem. I am not at home tonight, so I‘ll get the nightly build tomorrow and test that on the artificial star. Translating time steps to far3, far2 ... may be a good approach to mimic the linear focuser.

A vast improvement! Many thanks for devoting time on this!



Two observations:

1. The focuser did not fully shape the V which he normally would do. This may have made it difficult to determine the optimal focus.
2. The points should be further apart from each other. Although I chose step size 1100 thus made sure near3 and far3 were used at the beginning, it took many iterations to get close to optimal focus.

I've had several runs with varying tolerance, starting points, etc. Although these attempts ended close to optimal focus, they were reported as unsuccessful.
The 300mm Tele that I used would benefit from lower thresholds for far3/near3 and far2/near2, maybe something like 500ms and 100ms. This on the other hand could be too low for wide field lenses.

I aimed at an LED at 5m distance. Some problems that I experienced may stem from the fact that no real star was used. Also, with real stars it should be easier to start the process very close to the optimal focus which would drastically reduce the number of iterations.

This is looking great. But just a disclaimer folks. Live View will cause the camera sensor to heat up resulting in more noise until it has a chance to cool down. I suggest not leaving it on for too long.

Thanks for testing! I'm open to any suggestions. Before, the timer was calling this 20 times in 1000ms, so maybe this explains why it was moving more?

Right now, the speed parameter for the focsuser is not used as the speed is set according to the timer. Another approach is to fake a relative step focuser with different weights.. for example, it should be like this:

100s: far 3 / near 3
10s: far 2 / near 2
1s: far 1 / near 1

So if you move 347 steps outward, it would call this:

1. 3x far 3
2. 4x far 2
3. 7x far 1

or something similar to this scheme.

Hello,
I have not yet tested the last changes - tonight I will.
From my experiences with the timer-based version and with manually focussing with far3/near3 ... far1/near1 I can say the following:

far1/near1 corresponds to really really small steps. If the algorithm makes the focusser change far2 in one direction I would guess it takes more than 10 (20?) far1 steps to balance this move in counter-direction.

maybe one could try something like

>1600 3xfar3
<1600 2xfar3 + far2
<1400 far3 + 2x far2
<1200 3xfar2
<1000 2xfar2+far1
<800 far2+2xfar1
<600 3xfar1
<400 2xfar1
<200 far1

If it turns out that the really small moves should only be used in the very last steps, one can try a non linear scaling between time and step-size.