Programmatic focus control and absolute/relative focus position

[BBA]

@a1ex

Trying to
- build statistics on the distances in sub-steps between transitions for a given lens and, if possible,
- learn how liveview AF works.

Would it be interesting/possible to "trap" (*) some focus moves in usual photo liveview mode (**) to get infos, save them in a file and use them later to build statistics/check them ?
To be useful, the moves should be low level to be as "clean" as possible: a focus move from A to B without submoves inside (to avoid mechanical backlash, for instance).
To get infos on how AF works, the low level can be embedded in a start AF/end AF wrapper.
Everyday life shooting in LV could then be used to somehow "learn" the lens characteristics.
What do you think ?
If too difficult or inappropriate, don't bother!

(*) each time a given event is detected, an "interrupt" is made to execute some home made code and then return back.
(**) I don't see much of them except AF moves in Liveview, which makes it difficult ; follow focus moves seems easier but doesn't give infos about AF.

[a1ex]

With my lens (24/2.8 STM), the focus position counter also resets during autofocus, so it's not really helpful. However, since this lens uses focus by wire, it is possible to build statistics on the manual focus movements.

The cleanest way to catch such events would be IMO with a property handler (which is fired very soon after receiving a message from the MPU - which sends the lens position periodically, among many other things), but it does have to wait for DryOS to switch to the PropMgr task - so this method will give some additional delays.  It is possible to use property handlers in Lua, but I prefer using plain C here.

If these delays (from DryOS multitasking) are interfering with the result, it is possible to hook the mpu_recv routine (see the dm-spy-experiments branch) and get the position as soon as it reaches the main CPU.

If the delays are still unacceptable, and you want to check the encoder status as soon as it's updated, understanding the MPU code (TX19A on some models, unknown on others) would be the only way to go. That alone can easily take months of full-time work (or years, for a project done in nights and weekends), but it's doable (there is documentation available from Toshiba, and there are also emulators for similar - but not identical - microcontrollers).

[BBA]

Thank you a1ex for your very interesting answer.

I'll leave it for now as I have other priorities for the moment, but as it seems appealing to me, I'll dig into it later.

[garry23]

I've started playing around with lens.focus_pos in Lua, but have stumbled at the first hurdle.

I'm using an EOSM with a M lens.

The lens.focus_pos doesn't appear to update when manually focusing: reports 258.

Is this a limitation, or me?

Hope someone can throw some light on this.