I'm trying to build remote follow focus and after some research I think that it is possible to build very accurate one. I know that there is Rack Focus option but it is very limited and not much accurate with my Canon 17-55 IS USM when focal is set to 55mm (when speed is set to 1 it has about 709 steps from shortest distance to infinity but 739 steps on the other way). Step size depends also on the selected focal so it's not much useful for me. I'm trying to build something that works like this:
1. you can use AF or manual focus to point to selected object
2. once focus is ok you can remember this position
3. you can select any remembered point and selecting one will always work and will be very accurate
It sounds to great to be possible but I discovered that there is some counter that shows relative position of the focus. When you change focus position using PROP_LV_LENS_DRIVE_REMOTE this counter is always accurate even when speed is set to 3. You can find it at 0x20-0x21 (Canon 60D) in structure given when handler for PROP_LV_LENS is executed. For my C17-55 it allows to distinct about 1500 positions, for C100mm it's about 3000!
Now it's time to describe the problem ;) Sometimes PROP_LV_LENS_DRIVE_REMOTE breaks some Canon code and some events are no longer sent (for example PROP_LV_LENS). To fix this you have to press shutter button or go to menu and go back to LiveView. I don't have any idea how to fix this from code so I thought that maybe I can find this counter in some other place. And after some memory scanning and disassembly of original firmware I can't find source of this value. I found some related values near 0x265FC and 0x549DC but there is only last step size (it's not correct when last step was shorter because of limit in focus range) and what's funny there is previous value of the counter I mentioned before (it's always one step behind). Even when PROP_LV_LENS is not sent and value of counter in structure related to this property is not updated the one step behind counter is always refreshed :)
So now I can ask my questions :) Does anyone know:
- how to fix LV notifications from code when PROP_LV_LENS_DRIVE_REMOTE breaks them?
- where can I find the origin of this counter, I tried to find this in disassembled code but it's not so easy for me (Java guy ;) ) because code related to this addresses has hundreds of subs and operates on SP with is hard to track for me (at least until someone will run original firmware in qemu ;) )
Nice find. But... I'm afraid I'm not able to answer your questions.
If you dig back into ml-devel, you'll find out an alternate implementation of focus commands, by sztupy (look for the first 60D porting attempts). It uses very fine increments, but seems more likely to become stuck.
Do you have a way to reproduce the broken LV? I know it happens sometimes on 60D, but don't have a clear pattern for reproducing the error.
Thanks for quick reply. I checked sztupy's code and it's great, now I can move focus with any step size I want. This allows me to reduce number of requests so there is less chance that LV will break.
The simplest way to reproduce broken LV is sending PROP_LV_LENS_DRIVE_REMOTE too often (without wait flag it occurs after few seconds). The same issue occurs when you use standard PTP service for this (0x9155). Unfortunately it also occurs when step wait flag is on and in theory the previous request was completed. But I don't know why and when it occurs in that case.
I found that shit ;) Now I now I was reinventing the wheel a little bit but if anyone is interested:
1. More accurate step size that doesn't depend on selected focal.
You can find in sztupy's code two versions, one that use AfCtrl_SetLensParameterRemote which does work but to get expected step sized you have to guess correct value for off_0x1D8 which is related to off_0x1D4 (that depends on given lens). So this method is not much portable because you have to hard code some values. The second version (which is commented) invokes prop_request_change for property PROP_LV_FOCUS and have one drawback - it doesn't work :) at least on my 60D 1.1.1. But you can change it a little bit and it will work fine:
uint32_t prop_focus_code = 0x80050001;
struct prop_focus prop_focus_data;
prop_deliver(&prop_focus_code, &prop_focus_data, 5, 0);
For C17-55 step size (0x01-0x02) can be set from 1 to about 1500 (from nearest point to infinity)
2. Getting access to counter that keeps relative focus position
The simplest way to get this is to handle value change for property 0x80050000 and read it from given structure at 0x20-0x21. This value is always refreshed but refresh is not instant, it takes few milliseconds before it is refreshed. If for some reason LV breaks handler for this property will not be invoked.
The second way is to invoke prop_request_change(0x8005001B, 0, 0x38) and handle value change for 0x8005001B - it returns the same structure as 0x80050000 but stored in different place. Counter value will be always correct in this method. Setting 0 (null pointer) to second argument doesn't break anything (at least on my 60D ;) )
3. Fixing broken LV on 60D
Just invoke prop_request_change(0x80050000, 0, 0x38) and it will magically work again. It looks like handler for 0x80050000 do some work and at the end it invokes prop_request_change for that property so there is infinite loop. Unfortunately on 60D this loop can be finite when this handler will crash :)
Hope this will help someone ;)
Very nice, I'll take a look. Did you find an easy way to tell when the LV is broken? (without using timeouts)
Low-level version of PROP_LV_FOCUS:
Quote from: a1ex on July 22, 2016, 10:43:28 PM
5D3: 0x08, 0x09, 0x01, num_steps_hi, num_steps_lo, 0x07, 0x00, 0x00: lens focus control in LiveView (also works in paused LiveView). Commands appear to be queued properly, but breaks focus distance reporting.
Quote from: sl0w0rm on April 08, 2013, 01:17:51 AM
2. Getting access to counter that keeps relative focus position
The simplest way to get this is to handle value change for property 0x80050000 and read it from given structure at 0x20-0x21.
On focus-by-wire lenses, this counter is updated when you focus manually as well.
This counter can give a very precise estimation of the focus distance. Here's what this property reports for the 24mm/28 STM lens:
(http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/focus-24mm-28-stm.png)
@A1ex @dmilligan
I am glad you posted this and restarted this topic !
I have been working on the same subject in Lua with lens.focus (open loop, relative focus positioning) and lens.focus_distance.
It would be very useful to be able to work in closed loop with absolute positioning as it would drastically simplify all what I have done so far !
I am very interested in trying to do it but I would need a guidance.
My aims are:
- to implement advanced stack focus after focusing on specific objects to be in sharp focus (or blurry) and after storing their absolute positions;
- to better stack focus in the near infinity range by working in the "nearly linear" image field;
- to position one's lens to hyperfocal distance or to position the lens on specific and previously set "infinity distances".
Those apps may need the use of companion file(s).
Many thanks in advance!
So far, if anybody is interested, I have tried (with incomplete results and success, given the very wide search field) to:
- scan different lenses with step sizes (in domains) 1, 2 and 3 (ex: EF 100mm f/2.8L MACRO IS USM : 4416 steps in domain 1, 396 steps in domain 2, the fp reporting didn't work in domain 3 but lens.focus moved the lens on 55, 56 times, EF 24mm f/1.4L II USM in domains 1, 2 and 3)
- to absolute position a lens in domain 1, after focusing it (automatically (AF) or manually (M)) on an object. The algorithm uses the properties of the step function by translating (projecting) the uncertainty zone to parts of the step function where there is more information in between (and while counting the steps done back and forth as the lens moves); at the beginning, the uncertainty range is the whole lens; with the "step" function, we can know on which "step" the fp lies; then, by using moves in domain 2, the uncertainty range can be divided by 2 at each "larger" step; after domain 2, projecting in domain 1 (still to be better studied), it is then possible to do the same with the finest steps until the uncertainty falls to a few fine steps (the number of moves in a domain is less than the log2 of the uncertainty range measured in steps). The problem is to optimize the algorithm to get the most precision as, in open loop, each move can add a one (or more) step(s) uncertainty.
It requires to store the step function in a file for the lens to be used.
Some primitive tasks :
1) Scan a lens with precision in domains 1 and 2 to get the step function and store the results in a reference file for that lens
2) find the absolute position of a lens using the reference file and store the position in another file for further use (with ancillary tasks : add, remove, clear all,...)
3) use later the positions stored in this last file to position the lens at will as accurately as possible
As said, the caveat is that the stepper motors can loose some steps erratically, so the more you move, the more there can be uncertainty on the positioning.
Research directions:
- Continue to check with different lenses as, until now, I have mostly used fine steps : how can domain 2 and 3 be projected in domain 1 ?
- Work in the « image domain » as the distance of the focal plane is nearly linear in function of the « stepper motor » step number; this can facilitate the use of the near infinity focal positions. Then, translate to « object domain » distance.
- Position uncertainty can be studied : electric power supply; low cost lens vs L lens (better mechanical qualities for moving parts ; perturbation torques; chocs) intervention à la main, frottements...
- measurements in reality : focus on target, measure absolute position, compute (interpolating with step function) a distance: compare computed with measured distance
I've exposed the focus motor counter in Lua (focus branch) as lens.focus_pos.
The focus test from api_test.lua reports:
lens = table:
name = "EF-S24mm f/2.8 STM"
Testing lens focus functionality...
Focus distance: 220
Focusing backward...
Focus distance: 655350
Focus motor position: 1209
Focusing forward with step size 3, wait=true...
..................
Focus distance: 160
Focus motor position: -597
Focusing backward with step size 3, wait=true...
..................
Focus distance: 655350
Focus motor position: 1209
Focus range: 18 steps forward, 18 steps backward.
Motor steps: 1806 forward, 1806 backward, 0 lost.
Focusing forward with step size 3, wait=false...
...................
Focus distance: 160
Focus motor position: -596
Focusing backward with step size 3, wait=false...
..................
Focus distance: 655350
Focus motor position: 1210
Focus range: 19 steps forward, 18 steps backward.
Motor steps: 1805 forward, 1806 backward, 1 lost.
Focusing forward with step size 2, wait=true...
...
Focus distance: 160
Focus motor position: -596
Focusing backward with step size 2, wait=true...
...
Focus distance: 655350
Focus motor position: 1209
Focus range: 120 steps forward, 119 steps backward.
Motor steps: 1806 forward, 1805 backward, 1 lost.
Focusing forward with step size 2, wait=false...
...
Focus distance: 160
Focus motor position: -598
Focusing backward with step size 2, wait=false...
...
Focus distance: 655350
Focus motor position: 1209
Focus range: 119 steps forward, 120 steps backward.
Motor steps: 1807 forward, 1807 backward, 0 lost.
Focusing forward with step size 1, wait=true...
...
Focus distance: 160
Focus motor position: -598
Focusing backward with step size 1, wait=true...
...
Focus distance: 655350
Focus motor position: 1209
Focus range: 453 steps forward, 453 steps backward.
Motor steps: 1807 forward, 1807 backward, 0 lost.
Focusing forward with step size 1, wait=false...
...
Focus distance: 160
Focus motor position: -598
Focusing backward with step size 1, wait=false...
...
Focus distance: 655350
Focus motor position: 1209
Focus range: 453 steps forward, 455 steps backward.
Motor steps: 1807 forward, 1807 backward, 0 lost.
Focus test completed.
So, the 24mm 2.8 STM has about 1808 steps, and it doesn't lose track of its position, even if I focus manually during the test. Nice :)
The small differences are probably given by the repeatability of the limit stops (the motor doesn't stop after a predefined number of steps, but when reaching some sort of switch, or when the lens appears stuck - including you stopping it forcefully).
Note: on EOS M and 6D, the location of this counter is unknown, so I need some help with reverse engineering (just print the contents of PROP_LV_LENS and find out which offset contains the focus motor position).
Very, very nice !
Can't believe it !
I can't wait to test it.
I have dowloaded the latest nightly (from today, the 24th).
magiclantern-Nightly.2016Aug24.5D3113.zip
Built on: 2016-08-24 01:11:02 +0200
Changeset: 96ca71e
If possible, where can I download your gem ?
(I have a 5Dmark3 so I won't be able to help you with reverse engineering on EOS M and 6D models)
It's not yet in the nightly, and it may take a while, since the current state would break the 6D and EOS M builds. Meanwhile, you can compile the focus branch (and once you manage to do that, you can start playing with the low-level code 8) ).
As @BBA says, really exciting stuff.
For me the real value will come when I can make use of the developments in a Lua script.
I have learned to wait and watch ML developments, i.e. ML has helped me hone my patience ;)
Cheers
Garry
55-250mm IS STM @ 55mm
lens = table:
name = "EF-S55-250mm f/4-5.6 IS STM"
Testing lens focus functionality...
Focus distance: 38000
Focusing backward...
Focus distance: 655350
Focus motor position: 579
Focusing forward with step size 3, wait=true...
......
Focus distance: 850
Focus motor position: -4755
Focusing backward with step size 3, wait=true...
......
Focus distance: 655350
Focus motor position: 579
Focus range: 6 steps forward, 6 steps backward.
Motor steps: 5334 forward, 5334 backward, 0 lost.
Focusing forward with step size 3, wait=false...
......
Focus distance: 850
Focus motor position: -4755
Focusing backward with step size 3, wait=false...
......
Focus distance: 655350
Focus motor position: 579
Focus range: 6 steps forward, 6 steps backward.
Motor steps: 5334 forward, 5334 backward, 0 lost.
Focusing forward with step size 2, wait=true...
........................
Focus distance: 850
Focus motor position: -4755
Focusing backward with step size 2, wait=true...
......................
Focus distance: 655350
Focus motor position: 579
Focus range: 24 steps forward, 22 steps backward.
Motor steps: 5334 forward, 5334 backward, 0 lost.
Focusing forward with step size 2, wait=false...
.......................
Focus distance: 850
Focus motor position: -4755
Focusing backward with step size 2, wait=false...
......................
Focus distance: 655350
Focus motor position: 579
Focus range: 23 steps forward, 22 steps backward.
Motor steps: 5334 forward, 5334 backward, 0 lost.
Focusing forward with step size 1, wait=true...
...
Focus distance: 850
Focus motor position: -4755
Focusing backward with step size 1, wait=true...
...
Focus distance: 655350
Focus motor position: 579
Focus range: 281 steps forward, 270 steps backward.
Motor steps: 5334 forward, 5334 backward, 0 lost.
Focusing forward with step size 1, wait=false...
...
Focus distance: 850
Focus motor position: -4755
Focusing backward with step size 1, wait=false...
...
Focus distance: 655350
Focus motor position: 579
Focus range: 281 steps forward, 273 steps backward.
Motor steps: 5334 forward, 5334 backward, 0 lost.
Focus test completed.
The very good news is that this new counter gives access to finer steps than what can be achieved with lens.focus and step sizes of 1 ( lens.focus(1,1) ).
This gives a common base of measure (let's say in sub-steps) for moves done with different step sizes (1,2 and 3).
For example, with the EF24mmf1.4LIIUSM, one step of size 1 gives 7 sub-steps (one step of size 2, 30 sub-steps, and 207/208 sub-steps for step size 3).
At each lens position measured in sub-steps, just add the measure in sub-steps of the move you want to do to know your new position in sub-steps (always some errors are possible, that don't matter when AF as there is a "consigne" (phase,contrast) that drives a closed loop).
There is an offset given by the initial position of the lens. So it is not absolute but relative to the initial lens position (hence the negative/positive numbers of sub-steps).
I don't know if turning the lens to one mechanical end (macro or infinity) will give a repeatable absolute scale from one experiment to the next.
Because of some errors, the total excursion of this lens (maybe is it faulty ?) can vary, particularly with step size 3. The sub-steps scale must then be "adjusted", if possible, to the ones of step-sizes 1 and 2.
I would like there were a mean to directly move the motor in sub-steps, like a lens.focus of "base" step size 0 !
It would then be easier to go to a given sub-step position.
Here are some graphs for this lens. The blue dots are for step-size 1 ( B column), red = step-size 2 ( E ), and yellow = 3 ( H ). The X axis is in sub-steps with offset = 0. The y axis represents the (object) focal point in mm. The step size 3 (yellow) curve was given a visual offset of -5 to better "adjust" it to the other dotted curves.
The near infinity (object) range is discarded.
https://www.dropbox.com/s/s60kaj63dpmptaw/EF24mmf14LIIUSM_1.jpg?dl=0
(https://www.dropbox.com/s/s60kaj63dpmptaw/EF24mmf14LIIUSM_1.jpg?dl=0)
https://www.dropbox.com/s/iickvs2t6qjzch9/EF24mmf14LIIUSM_2.jpg?dl=0
(https://www.dropbox.com/s/iickvs2t6qjzch9/EF24mmf14LIIUSM_2.jpg?dl=0)
https://www.dropbox.com/s/wmliyr46kevysz7/EF24mmf14LIIUSM_3.jpg?dl=0
(https://www.dropbox.com/s/wmliyr46kevysz7/EF24mmf14LIIUSM_3.jpg?dl=0)
I would like to share the graphical result of 88 lens.focus( num-steps, step-size) commands in the near infinity end.
The offset of the lens motor position is set to have 0 at infinity end. All the positions are negative numbers.
Axes:
X = number of the lens.focus command
Y = lens position in sub-steps
Labels = Y
Near infinity ( Y = 0 => X axis ), the sort of clipping is due to the fact that the lens position does not move anymore but commands are still sent until the lens.focus function returns the error message "false".
All the lens.focus commands are sent with wait argument = true.
The parameters of the lens.focus command are given near each command in the form : num-steps( step-size ) for instance : 2 steps of step-size = 3 is represented by 2(3).
You can see at the end of the curve the tricks used to move the lens motor of :
1 sub-step = 4(2) followed by 17(1)
4 sub-steps = 2(2) " " 8(1)
The move to infinity end are done one step at a time and delays in between which should not be that good for friction motors (one can hear each move distinctly as the friction surfaces are separated and comme back in contact).
For big jumps, I think it would be better to use big steps (step-size = 3) with ?maybe less precision? .
To be verified : use big num-steps of step-size = 1 or 2 (more precise?).
https://www.dropbox.com/s/h993qiouwhqvf60/Lenspath_2.jpg?dl=0
(https://www.dropbox.com/s/h993qiouwhqvf60/Lenspath_2.jpg?dl=0)
I have been using the lens.focus_pos counter for some time trough lua scripts with a compile of the focus branch (thanks @a1ex, @dmilligan, @dfort,...).
It is trial and error so nothing is definitely understood....
I will try to share more later as I can figure out some more correct hypotheses (The most annoying thing is the "random" or "not so random" variation of the step length during a scan from macro end to infinity end and as consequences, the repeatability and the final precision achieved).
There were a lot of surprises (at least for me).
To give one idea, I tested with the EF 17-40mm f/4 L: what is the length of one step (step-size=1) as given by lens.focus_pos (in sub-steps) :
- at a focal length of 40 mm, one step measures 4 sub-steps (it's pretty constant);
- at 17mm, one step measures 14 to 13 sub-steps.
Below, you can find the result of the scans from macro to infinity.
I tried to move the zoom barrel during the scan : the step lengths changed while zooming.
So, even if the total length of the lens in sub-steps is (nearly) constant, this length is achieved with steps of different length depending on the zoom factor.
https://www.dropbox.com/s/6cm5xqfe6j7zhay/EF17-40mmVarizoom.jpg?dl=0 (https://www.dropbox.com/s/6cm5xqfe6j7zhay/EF17-40mmVarizoom.jpg?dl=0)
I watched some videos of zoom disassembly on youtube : on some zoom lenses, there is a Gray encoder for the zoom barrel: IMHO, the lens can know an estimation of the zoom factor and therefore change the step length accordingly...
To try to sort things out, and try to find out what is a sub-step, I would like to test the sub-steps moves on a target with a 45° rule (the one that can be used to micro adjust lenses) and then send lens.focus commands and take pictures to see where the focus point (actually) moves away, and what value is returned by the lens.focus_pos.
The problem is that the "camera.shoot(64,false)" command refocuses each time before taking a picture (even with the "should AF" argument set to "false").
Even, I have tried to use stack focusing scripts that are working with the last unified branch. The same refocusing happens at each shoot.
Do you think something has been changed in the focus branch with camera.shoot ?
Maybe is my compile is faulty (last compiled on the 2016/10/10) ?
Any idea ?
Interesting find - the step size probably depends on the reported focal length. Unfortunately, that only serves to increase the complexity for those lenses...
My theory is that step commands are not very exact, and the error may add up. So, I suggest closing the feedback loop like this:
- "home" the lens: at startup, move the focus ring all the way in some direction (or both) until reaching the limit
- use the focus_pos counter to know how many step commands to give (don't assume anything about their actual step size)
To check the repeatability, I suggest moving the lens to random positions, and then back to some fixed lens.focus_pos (the one with perfect focus on the ruler), take a (silent) picture, read the AFMA value from the ruler (may be hard to automate), and plot the results.
Tip: if you focus the camera on the target, then restart, lens.focus_pos will be 0 at that point (where focus should be perfect). So, just send focus commands at the lowest speed (or maybe at higher speeds first) until lens.focus_pos crosses through 0.
To diagnose camera.shoot(64,false), you need to find out whether the focus argument arrives as AF_DISABLE in lens_take_picture.
@A1ex
Thank you for your answer! I mostly agree with you.
Quote
To check the repeatability, I suggest moving the lens to random positions, and then back to some fixed lens.focus_pos (the one with perfect focus on the ruler), take a (silent) picture, read the AFMA value from the ruler (may be hard to automate), and plot the results.
The mean error should be half a step (of step-size 1), am I right ?
I can do some experiments with the 5Dm3 and the EF 24mmf/1.4 L USM. With that lens (it is not possible with all lenses) I can use domain 2 and 1 moves to get, at least that's what I hope, a better precision. (There is a tradeoff speed/precision)(one step is 7 sub-steps in length, half a step is 4 sub-steps in length). The difference in precision is not that big at low distances : that's why the ruler test should be interesting. I don't know if the difference will be of any use when focusing for astrophotography.
Quote
To diagnose camera.shoot(64,false), you need to find out whether the focus argument arrives as AF_DISABLE in lens_take_picture.
I am not that used with compiling.
I don't know if it is relevant :
I have seen a problem in my Lua scripts with the value of the KEY.SET constant. The value returned by keys:getkey() when pressing the SET key (5Dm3) is 10 but the value of KEY.SET is 9.
Could there be a difference with AF_DISABLE constant too ?
Quote from: BBA on October 20, 2016, 04:35:59 PM
I am not that used with compiling.
How did you get the focus branch build? It is a development branch so it needs to be recompiled periodically as changes are committed.
You certainly have the technical ability to compile ML. I've written a few tutorials that make it relatively easy for both the Mac (http://www.magiclantern.fm/forum/index.php?topic=16012.0) and Windows (http://www.magiclantern.fm/forum/index.php?topic=15894.0).
Quote from: a1ex on August 24, 2016, 02:56:27 PM
Note: on EOS M and 6D, the location of this counter is unknown, so I need some help with reverse engineering (just print the contents of PROP_LV_LENS and find out which offset contains the focus motor position).
I tried to help with the EOSM but didn't quite understand how to find which offset contains the focus motor position (focus_pos). I recently found out that there is a difference between the way EF and EF-M lenses are handled by the camera. Apparently the data in lens.h is for EF lenses mounted via an active adapter. We should probably go back and revisit lens_step, focus_dist and focus_dist2 for EF-M lenses.
Are there instructions somewhere that details how to print out the contents of PROP_LV_LENS? I mean something on the level of explaining it to your grandmother?
Re: EOSM -- I somewhat remember @a1ex asking me to do the same earlier this year and believe it has to do w "Don't click me" and I tried to understand the riddles but couldn't get around it. Perhaps I should dive in along w you @dfort?
Quote from: DeafEyeJedi on October 21, 2016, 07:10:02 PM
Perhaps I should dive in along w you @dfort?
That would be great. If you can find those instructions please share. I was getting close a while back but didn't quite get there.
https://bitbucket.org/hudson/magic-lantern/pull-requests/748/focus-backend-updates-precise-focus/diff
@dfort
Quote
How did you get the focus branch build? It is a development branch so it needs to be recompiled periodically as changes are committed.
I compiled the branch.
On bitbucket.org, I found the focus branch. A1ex had written he had exposed the lens.focus_pos. I saw it as one of the last commits in the focus branch (on the 2016-08-24).
You made a very good job explaining how to set up a development setup on a macintosh ( for the unified ) and I want to thank you very much for that. I found it very helpful.
I found the hg commands to use to update the set of source files you have on your local computer and used those for the focus branch.
I must say I have been working with different systems/languages and, particularly, with HP-UX, but it was a long time ago and I have not used it enough : to be sure, I should dive into it again, and better know what I am doing...but I have preferred to get new skills in Lua and try to solve problems when focusing in the near infinity range as Garry23 was writing his stack focusing script.
I think the compilation went not too bad : I had 2 errors with the documentation generation that (I think) could be ignored.
The lens.focus_pos went very well on the 5Dm3 and all the lenses I used (I still have to share about them).
I got problems when I tried to use the camera.shoot(64,false) command after moving the focus position: the camera refocused automatically at each shot.
A1ex told me to check if the false argument arrives as AF_DISABLE in the lens_take_picture routine.
@dfort @DeafEyeJedi
I would very much like to work with you to find out how to trace/check the different values we have to find.
(sorry for my english)
@dort & @BBA --
Here's what I was able to find dating back to March/April of this year (from the EOSM thread (http://www.magiclantern.fm/forum/index.php?topic=9741.msg165120#msg165120from%20the%20EOSM%20thread)) and this is what he asked me to do...
QuoteDo you mind printing the value of get_current_dialog_handler() during movie playback? ML couldn't figure out that in the playback screen you actually have a video.
QuoteYou can't do it from Lua (or at least not yet), but you can put that in a printf or bmp_printf or NotifyBox somewhere (for example, in don't click me).
...and couldn't get my head around these two hints with my findings here (http://www.magiclantern.fm/forum/index.php?topic=9741.msg165131#msg165131here). So not sure where exactly should we take a dive into first?
@dfort
I know I have gone too fast and I have taken some risks (Sorry for disturbing others because of that).
I should first use the sourcetree app to be sure the sources are sync'd.
@DeafEyeJedi & @dfort
(Please correct me if I am wrong or if I go too fast or too slow for you)
To summarize:
1) I have seen there are too many debugging messages coming all the time on the screen.
2) You probably know you can give instructions to the compiler to skip (or not) given code chunks or to replace some character strings (cf. the lines beginning with the # symbol).
This is particularly useful when debugging or when the code to compile has to be different from one camera to the other.
This feature will help you stop those many debugging messages from messing your own messages.
3) You also probably know where the source files are located on your computer and how to find given character strings in those files (search field in the finder or "grep" instruction with the OS X console).
This will help you locate where to switch off those debugging messages from being compiled the next time you compile.
4) After you get rid of those debugging messages, you can put your own debugging instructions and define some character string to switch them on or off.
@BBA -- Your English is fine. Those documentation generation errors when compiling ML is normal--much of the documentation has been missing in the code for a long time. The SourceTree app makes it very easy to switch between branches but it is also possible to do it on the command line as you mentioned with the "hg update <branch>" command. Here's some Mercurial documentation on that (https://www.mercurial-scm.org/wiki/NamedBranches).
@DeafEyeJedi -- It looks like a1ex was trying to debug a problem with the cropmarks and framing moving around but his instructions were similar to what he was having me do with the lens properties. Note the comments from 2016-09-05 on the Focus backend updates - precise focus position and other tweaks (https://bitbucket.org/hudson/magic-lantern/pull-requests/748/focus-backend-updates-precise-focus/diff) pull request.
The way I was able to display something on the screen is by adding a "bmp_printf(FONT_MED, 50, 50, "%x %x", len, len/2);" to src/lens.c like this:
PROP_HANDLER( PROP_LV_LENS )
{
const struct prop_lv_lens * const lv_lens = (void*) buf;
lens_info.focal_len = bswap16( lv_lens->focal_len );
lens_info.focus_dist = bswap16( lv_lens->focus_dist );
// lens_info.focus_pos = (int16_t) bswap16( lv_lens->focus_pos );
bmp_printf(FONT_MED, 50, 50, "%x %x", len, len/2);
if (lens_info.focal_len > 1000) // bogus values
lens_info.focal_len = 0;
@BBA -- Note that in order to skip sections of C code you use "//" instead of "#".
I'm not sure if that's the right way to do it but that's where we left off. (Results circled in red in this image.)
(https://c1.staticflickr.com/9/8654/30454560616_439ab4c638_z.jpg)
@dfort -- Many thanks for your help.
I have used something like you:
bmp_printf( FONT_MED, 10, 2, "%d - %d ", should_af, AF_DISABLE);
but the message falls on the 1st line and gets wiped out very quickly.
Quote
To diagnose camera.shoot(64,false), you need to find out whether the focus argument arrives as AF_DISABLE in lens_take_picture.
Nevertheless, I could be able to see that the 2d argument in lens_take_picture has a value of 1 which corresponds to AF_enable ( AF_DISABLE has a 0 value in lens.h ).
I could use a "dirty trick" to force the value (for the time being it would be sufficient in my tests) but I would loose more important things on why the sources are incorrect.
@dfort & @DeafEyeJedi
dfort's solution is much more efficient than what I suggested to avoid many debug messages.
// is used to "comment out" what follows on the same line in C
# is used to give instructions to the (pre)compiler like #define #ifdef,...
I can also share with you the wiki page for debugging ML:
http://magiclantern.wikia.com/wiki/Debugging_Magic_Lantern
(http://magiclantern.wikia.com/wiki/Debugging_Magic_Lantern)
Quote from: BBA on October 22, 2016, 06:50:28 PM
...the message falls on the 1st line and gets wiped out very quickly...
Try changing your font settings to what I used: FONT_MED, 50, 50,
(That seems to set the position on the LCD where it is displayed.)
Thanks for those other tips!
Before going further in testing, those first test results with EF 24mmf/1.4 L II USM/5Dm3 @f/1.4 near target for short DOF.
5 shots in sequence (1 step of step-size=1 (=7 sub-steps) apart from each other) :
1st shot =7401 = focused (max contrast) on target https://www.dropbox.com/s/57zfc2u6sf4qodk/_GOR7401_CROPPED.jpg?dl=0 (https://www.dropbox.com/s/57zfc2u6sf4qodk/_GOR7401_CROPPED.jpg?dl=0);
2d shot = 7402 = one step behind https://www.dropbox.com/s/qtajrgs8flcfk78/_GOR7402_CROPPED.jpg?dl=0 (https://www.dropbox.com/s/qtajrgs8flcfk78/_GOR7402_CROPPED.jpg?dl=0);
3d = 7403 = one step to the front (should be focused again on target)https://www.dropbox.com/s/ypny9jp5c3cw0ca/_GOR7403_CROPPED.jpg?dl=0 (https://www.dropbox.com/s/ypny9jp5c3cw0ca/_GOR7403_CROPPED.jpg?dl=0) ;
4th = 7404 = one step to the front https://www.dropbox.com/s/a3ubgfu2k4jklzs/_GOR7404_CROPPED.jpg?dl=0 (https://www.dropbox.com/s/a3ubgfu2k4jklzs/_GOR7404_CROPPED.jpg?dl=0);
5th = 7405 = one step behind (should be focused again on target too) https://www.dropbox.com/s/mpm5hyiomf1jzab/_GOR7405_CROPPED.jpg?dl=0 (https://www.dropbox.com/s/mpm5hyiomf1jzab/_GOR7405_CROPPED.jpg?dl=0).
The log file gives the value of lens.focus_pos before/after moving and shooting : for that lens at least, the counter is incremented and decremented correctly even if the focus distance gets incorrect.
https://www.dropbox.com/s/ps7kfdmze97tc0o/7401_7405.log?dl=0 (https://www.dropbox.com/s/ps7kfdmze97tc0o/7401_7405.log?dl=0)
Seems the move from 7403 to 7404 did not move correctly. The error propagates to 7405.
This confirms A1ex thinking.
The following is speculative:
At least with step-size=1 and with this lens, the counter should not allow to close the focus loop. In the lens scans I had made with step-size=1, the counter returned results too good (all steps were 7 sub-steps) to be true.
Below are some results on scanning lenses with different step-sizes.
I wanted to share them but I was waiting till I had more experimental results on the actual motor move.
Take them with a grain of salt:
In sub-steps Stepsize=1 Stepsize=2 Stepsize=3 Total range
EF 24mm f/1.4 L Constant Constant Quasi constant
USM (ring) 7 (630 steps) (1) 30 (147 steps) (2) (4) From 208 to 207 (2) 4 413
EF 35mm f/2 IS Constant Small variation Small variation
USM (ring) 10 (824 steps) (1) From 42 to 39 (2) From 286 to 276 (2) 8 243
EF 50mm f/1.8 II Variation unavailable unavailable Problem
(not ring) From 2 to 6 with limits (3)
EF 100mm (4416 steps) (4) (396 steps)
limit = lens.focus( numsteps, stepsize)
(1)
- For lenses with ring ultrasonic motors (ring USM), the length of the steps in domain 1 (of step-size=1) seems to be pretty constant.
- This is even true with large values of « numsteps », even though when a move of numsteps>>1 is actually commanded, it is executed one step at a time (one can hear the friction surfaces separation and coming back in contact).
- I wonder whether the domain 1 is not simply done with a « count » of the number of sub-steps. Maybe the move is very/too small to be easily detected ?
- The EF 50mm f/1.8 II doesn't have a ring USM (lens intended to be cheaper): in that case, the length in domain 1 is very changing. Nevertheless, the targeted focusing precision of such a lens could be achieved, even in such a case, if the lens has a higher number of (maybe varying) steps.
(2)
- There may be a small variation which seems at first sight to be « random ». See for the EF 35mm.
- IMHO, there seems to be a trend which is more evident with step-size 3 : the mean step is longer at both ends.
- For the EF 24mm it is more easy to try to go to the exact target position in sub-steps as the step length in domain 2 (30 sub-steps) is not a multiple of the length in domain 1 (7 sub-steps).
- For EF 35mm the length of one step in domain 2 (near 40) is near a multiple of domain 1 (10).
- In theory, the mean error when using domain 1 steps should be a fraction of a step. This can be very good when there are many small steps.
- This raises a question about the usefulness of fiddling with sub-steps in regard to the precision already achievable with one lens in domain 1.
(3)
- With the EF 50mm lens I used, the lens.focus command did not return false at the infinity end. My script kept sending move commands (infinite loop).
(4)
The EF 100mm macro has a very high number of steps : it takes a very long time to scan as one has to wait enough (around 500ms) at each step for correct data to be available. The total duration is above 30 min and Lv can switch off. The scans were done before the lens_pos counter was available.
Thanks for your contribution!
There are 3 lenses matching "100mm macro":
1.) EF 100mm f/2.8 Macro (1990)
2.) EF 100mm f/2.8 Macro USM (2000)
3.) EF 100mm f/2.8L Macro IS USM (2009)
@Walter Schulz
Thanks!
You are right : it is the EF 100mm f/2.8 Macro IS USM.
There are still some errors but I have to leave now. I can add some graphs of the step variation too.
Don't hesitate to ask/criticize as we are in a community.
I would like to have your opinions on the following.
We will have to deal with a possible difference, hopefully kept to a small value, between the counter position (software view) and the actual hardware position.
One aim is to detect any difference as soon as possible.
At first sight, there are two opportunities at both ends to "home" = to resync software and hardware.
To do that, there must be some physical mean (electrical contact or optical detector) that is switched and allows to raise the soft limit error.
So, for this first reason, it would be better to know, as soon as possible, that the hardware end has been reached especially if the software counter does not report it.
But on the other end, is this hardware mean precise enough to be useful ? Can it be trusted ?
I am speculating, but I don't think it is precise enough at the sub-step level (the precision level of the counter).
Even at step-size 1 level, I am not sure because it is not necessary ...If it is only a hardware protection, it doesn't need to be that precise.
What do you think :-[ ?
With that in mind, should we keep to delay the focus error when the lens doesn't move after 2 retries :-\ ?
Here I can share with you the results of the moves back and forth of 6 steps (of step-size=2) apart from each other.
The camera is nearer to the target (almost the nearest focus distance).
https://www.dropbox.com/s/lu5v9vw57dgjuyv/7411_7415.log?dl=0
(https://www.dropbox.com/s/lu5v9vw57dgjuyv/7411_7415.log?dl=0)
https://www.dropbox.com/s/o24pw6pdswhq55s/_GOR7411_CROPPED.jpg?dl=0
(https://www.dropbox.com/s/o24pw6pdswhq55s/_GOR7411_CROPPED.jpg?dl=0)
https://www.dropbox.com/s/rtnlropnagcjstj/_GOR7412_CROPPED.jpg?dl=0
(https://www.dropbox.com/s/rtnlropnagcjstj/_GOR7412_CROPPED.jpg?dl=0)
https://www.dropbox.com/s/4b93tfgkgv9c22y/_GOR7413_CROPPED.jpg?dl=0
(https://www.dropbox.com/s/4b93tfgkgv9c22y/_GOR7413_CROPPED.jpg?dl=0)
https://www.dropbox.com/s/9gjxyt5rlb7cfj4/_GOR7414_CROPPED.jpg?dl=0
(https://www.dropbox.com/s/9gjxyt5rlb7cfj4/_GOR7414_CROPPED.jpg?dl=0)
https://www.dropbox.com/s/0fvok825ezroko5/_GOR7415_CROPPED.jpg?dl=0
(https://www.dropbox.com/s/0fvok825ezroko5/_GOR7415_CROPPED.jpg?dl=0)
Next time, I hope I'll be ready for moves from random starting points back to the same target using step-sizes= 3 for approaching, then 2 and 1 for precision.
I have simulated the algo which gives spot on results (error=0).
But the reality will be different for sure !
I think there should be something interesting here.
There seems to be a strong correlation between the position of the changes in the length of the step (expressed in sub-steps) and the position of the changes of the value of the focal distance. I mean they seem to change at the same position when scanning the lens from macro end to infinity end.
The values of the focus distance (as displayed on the liveview screen or given by lens.focus_dist in Lua) come from a data structure: they are read somewhere if I remember correctly. I would not be surprised if the values of the step length could be found there too, or nearby in the same data structure.
Being at a given position, one could then know what is the length (in sub-steps) of the step he can do and be able to calculate where he will get if he chooses to move with a given step-size. Companion files (with those step lengths data for each lens) would be unnecessary.
For those who are not afraid of spreadsheets, I put here under, the LibreOffice sheet I started to study the sub-steps scales of the EF 100mm f/2.8L Macro IS USM : with a little switch on the side of the lens it is possible to choose between a macro scale (30-50cm) a longer scale (50cm to infinity) and a full scale. The sheet « compar 30-50 and 50-infty scales » shows a beautiful correspondance : the scales can be superposed with an offset of 588 sub-steps.
https://www.dropbox.com/s/xw2zdd58ee7dm8p/EF100mm30_50macroA.ods?dl=0
(https://www.dropbox.com/s/xw2zdd58ee7dm8p/EF100mm30_50macroA.ods?dl=0)
What do you think ?
( just here to post a google drive (viewable online) link of your spreadsheet for those who doesn't have any *Office at disposal https://docs.google.com/spreadsheets/d/1GrJxwfLKgwH-DBR2c24viq5xQw1aiAGq-XoWC7WGcqE/ )
@knoodrake
Thank you for your initiative !
I wonder if what I have written is understandable...(sub-steps, step-size,...).
If you have any question, don't hesitate to ask!
I was asking myself why the step-lengths were changing and how one would have to do to store the values to use them in a Lua script (companion file).
When the step-length is constant on the whole range, it is rather simple...but when it changes from time to time, what data structure should I conceptually set up to store where a new step-length has to be taken into account. With some lenses like the EF 50mm f/1.8 II USM EF 35mm f/2 IS USM there are (little) changes on top of that. What are the real changes and the (possible) random changes (sort of hiccup) ?
The simultaneous variation of the lens.focus_distance and the step-length gives a clue to make a distinction between real changes (coupled with a change in the focus_distance value) and the random ones (when there is no simultaneous change of the focus_distance).
This simplifies to a limited number of intervals on which the step-length should remain the same.
This simultaneous variation gives better consistance to the step values as such : they acquire sort of real existence : they are specific to a given lens and have been decided when the lens was designed. With the EF 100mm f/2.8L Macro IS USM, the corresponding match between the different scales and the same length of the steps is really astonishing. It is difficult to speak of a coincidence.
There is still a conceptual problem as where the step-length changes, one would have to store two values : the value when going to macro end and the other value when moving to infinity end.
I will have to dig into lens.c and lens.h to try to find in the prop_lv data structure if there is some integer equal to the step-length I have seen.
struct prop_lv_lens
{
uint32_t lens_rotation; // float in little-endian actually
uint32_t lens_step; // float in little-endian actually
uint32_t off_0x08;
uint32_t off_0x0c;
uint32_t off_0x10;
uint32_t off_0x14;
uint32_t off_0x18;
uint32_t off_0x1c;
int16_t focus_pos; /* see lens_info.focus_pos */
uint16_t off_0x22;
uint32_t off_0x24;
uint32_t off_0x28;
uint16_t focal_len; // off_0x2c;
uint16_t focus_dist; // off_0x2e;
uint32_t off_0x30;
uint32_t off_0x34;
uint16_t off_0x38;
} __attribute__((packed));
Sorry, just following the post. :)
Modifications:
In my previous post, the mentioned EF50mm F/1.8 II USM should be better replaced by the EF 35mm f/2 IS USM : I already have a graph of the small variations of the step length to show you the problem of what variation should or should not be taken into account:
https://www.dropbox.com/s/dmx38e0ovu9jgeq/EF35mm_SCAN_dom2.jpg?dl=0
(https://www.dropbox.com/s/dmx38e0ovu9jgeq/EF35mm_SCAN_dom2.jpg?dl=0)
@Garry23
I think you can be interested by the following picture.
I can share the following picture :), but take it, as always, with a grain of salt :( .
It shows the results of scans of the EF24mm f/1.4L II USM lens with step-sizes 1, 2 and 3.
Each point represents the value of the lens.focus_distance in function to the position of the lens achieved with lens.focus() moves of step-size 1 (blue) 2(red) 3(yellow) beginning at macro end.
For red and yellow colors, the points are connected by straight line segments. For the yellow points it is like a linear interpolation. The graph is limited to an interval between positions 2000 to 4000.
https://www.dropbox.com/s/61awuv8q0y1u9gl/EF24mmf2ISUSM_SCANS123.jpg?dl=0
(https://www.dropbox.com/s/61awuv8q0y1u9gl/EF24mmf2ISUSM_SCANS123.jpg?dl=0)
What seems interesting (To be checked) to me is the yellow curve which goes from point to point as if it gave the positions for the pictures of a focus stack (with a big grain of salt as IMHO it does not change with the aperture value) . As you used step-size 2 in your optimized HFD script (for which I thank you for sharing : I will have too check how you found the best aperture), maybe you can go one step further ?
Quote from: BBA on November 16, 2016, 03:48:59 PM
https://www.dropbox.com/s/61awuv8q0y1u9gl/EF24mmf2ISUSM_SCANS123.jpg?dl=0
Just FYI: in this graph, plotting 1/focus_dist should give something closer to linear.
@a1ex
Thanks!
I think I understand you (tell me if I am wrong) : with the "lenses equation", it is possible to do the transform from the object to the image field. Here is what I have tried in this direction:
https://www.dropbox.com/s/adbpq6ryatrobs9/EF100mmf28LISUSMAv56_3.jpg?dl=0
(https://www.dropbox.com/s/adbpq6ryatrobs9/EF100mmf28LISUSMAv56_3.jpg?dl=0)
I thought the "infinity end" of the step function seemed "not linear enough" (if I can say that).
I am not sure there is a non linearity in the helicoidal barrel (in cylindrical coordinates, z = k*theta , transforming the rotation of the ring motor (theta) into a linear move (z) ) ?
I don't think so...
At least, it should give a more easy way to handle the infinity end.
I would like to ask you if you have any info on the C data structure above?
I wonder what is called "lens_rotation" and "Lens_step" ?
@BBA
Great investigative work :-)
Whilst I can see the potential benefits for macro shooters, I wonder that for landscape shooters, using wider lenses, such 'accuracy/precision' will be 'wasted'?
Of course, having said that, I can't wait to access such functionality in Lua ;)
Cheers
Garry
@Garry23
Thanks!
You put the finger on a good question.
You are a passionate to a certain level like many of us. I have seen an expression somewhere "for the theory of it". I think this is part of the answer.
Give me some more time for a better answer, but you are right : it can not be possible to do much better things than what the lenses have been designed for.
IMHO, from the little I know of the many different lenses, I think it will be possible to interpolate to get better precision for stack focusing or lens positioning, maybe in the infinity end.
I think there is a group on bitbucket to enable more precision via interpolation : this is a good thing.
Step-size 1 is precise : an important thing is to know where to stop.
It is where the position counter will give you something :
- you will not be "limited" by the "step length" of each step of the step function as you can be now... (still to be proved for landscape, as you say).
- you will know if it is better to move the lens one step further, or if it is better to stop where you are : this already reduces the error to a fraction of a step-size 1 step.
The hardware will never allow us to go to the sub-step precision level.
I have tried to figure out on a 45° target with the EF24mm f/1.4 L II USM lens at full aperture as close as possible to reduce the DOF.
The software gives a 0 error but on the hardware side, on the pictures taken of the target, it is very difficult to see.
That's why I turned to a macro lens.
I will share the results here with pictures.
Quote from: BBA on November 16, 2016, 06:22:07 PM
I wonder what is called "lens_rotation" and "Lens_step" ?
I didn't really look into them. On 24/2.8 STM, the first one stays at 0, while the second one changes from -6.3867 (macro) to -6.9453 (infinity) in sync with focus distance (same increments). So, at least on this lens, they don't give any new information.
BTW, just found a bug where the lens could still get stuck at one of the ends, even when giving the opposite focus command.
Seems to work fine now. Test script (the one used to create this figure (http://www.magiclantern.fm/forum/index.php?topic=4997.msg170048#msg170048)):
-- Focus position experiment
require("logger")
test_log = logger("FOCUS.LOG")
function printf(s,...)
test_log:writef(s,...)
end
-- focus to the macro end quickly
while lens.focus(1,3,true) do end
-- focus with tiny increments towards the tele end and back,
-- logging focus position counter and focus distance to a file.
for i,dir in pairs{-1,1} do
while lens.focus(dir,1,true,100) do
printf("%d %d %d\n", dir, lens.focus_pos, lens.focus_distance)
end
end
Can you check whether this script runs properly (performing a scan in both directions) on different lenses after this fix (https://bitbucket.org/hudson/magic-lantern/commits/48850d51207e)?
You may post the logs as well, as I'm curious about the hysteresis from the figure linked above.
I'm thinking to figure out somehow the relationship between focus position counter and focus distance from these logs, maybe store it for each lens, and use the focus distance transitions to figure out where we are (the offset for focus_pos, which we don't know at camera startup, and may be lost during manual focus).
We'll have some precision issues if the lens moves fast, as two subsequent reports will differ by a large number of focus_pos increments. Kalman filter may help (e.g. we could combine the info from more transitions and give higher weight to those transitions performed during slow movement).
Finding out the above relationship dynamically (as the user focuses the lens) may also be possible (some sort of machine learning). Need to think about it.
@a1ex
I'm back.
I will do that.
Here are the lenses I can use (some L and some primes/zooms) :
EF 24mm f/1.4 L II USM
EF 35mm f/2 IS USM
EF 100mm f/2.8 L Macro IS USM
EF 50mm f/1.8 II USM
EF 17-40 f/4 L USM
Which ones is it better to choose ? (the step lengths seem more constant with L)
How many times do you think I should repeat the same experiment (to see...) ?
If needed, I can share some results of experiments:
Homing strategies
I have tried some "homing" strategies to each end (go to the mechanical end and sync hardware and software : absolute position = relative position + offset - hw_error ), but as far as I have seen (EF24L step-size=3), the precision was not so good, even for a L lens (I felt it was better not to do that, even less systematically, even when the target is near to one end ; actually, it is not needed in normal camera precision use (AF) but only as a protection ). My last thinking about homing was to assume that there were sort of "reading errors" of a given level (dispersion) at both ends that we have to accept without any change to the offset I had taken at the beginning of the script. After a given number of moves (heuristic to be found), it could be interesting to home because the hw_error would be of a higher level than the acceptable reading errors...given that hw_error could also subtract themselves.
Transitions
I am in sync with you. These are the nearest source of information we have; (from experiments), I have seen "metastability" (taking the value of focus_distance at successive moments, it changed and went back to it's first value, not very bad : the only problem could be it can take more time in the worst cases (for a few step-size=3 the lens can take a little while to stabilize: the question is to wait just when needed and detect); I have not tested it but the position counter changes could be checked in this case until they don't move anymore, even more if lens.focus is used with wait argument=false); systematic errors could be eliminated by minimizing the sum of the differences between the current readings of transition positions and previously saved positions; the remaining errors ? random?
I have not yet tried to position the transitions at a higher precision then the step-size=1 when scanning.
Quote from: BBA on November 17, 2016, 12:52:44 PM
Which ones is it better to choose ? (the step lengths seem more constant with L)
How many times do you think I should repeat the same experiment (to see...) ?
If you don't mind, I'd like logs from all of them. Some of them can be inferred from your tables, but it's a bit error-prone, so it's best if you could run the test script on all the lenses and save the logs.
To check the repeatability, I'd say running an experiment 3 times should give a fair idea of what we can get.
Quotesystematic errors could be eliminated by minimizing the sum of the differences between the current readings of transition positions and previously saved positions; the remaining errors ? random?
The main unknown here is the origin (offset) of the focus position counter (focus_pos): we lose it on reboot and (with some lenses) on manual focus. This is a scalar variable.
As we move the lens using the focus motor, we can get some idea about this offset when encountering the first transition. If the speed is lower, the estimation will be more accurate. There may be systematic errors depending on the direction and speed of movement - need to check and model them, if any.
As we encounter more transitions, the Kalman filter kicks in: if we consider each measurement corrupted by Gaussian noise with known variance, it will be weighted optimally by 1/var (see kalman.pdf (http://robocup.mi.fu-berlin.de/buch/kalman.pdf)), iteratively (at each iteration, we get the optimal solution with what we know so far). If equal variances are assumed, the result becomes identical to least squares estimation. We can estimate the variance from the difference between two focus_pos reports (the focus distance transition can be anywhere in this interval). One issue is that our offsets (errors) are not normally distributed, so the Kalman filter will not be optimal (but hopefully a very close approximation).
The above assumes a priori knowledge about the real focus distance vs position counter. We can do some educated guesses (such as considering the position of each reported focus distance as the middle of an interval covered by that value). Calibrating the infinity focus point experimentally may be useful.
Many thanks for your answer !
I just had time to run two first tests : at first sight, the delay could be too short.
EF100mm f/2.8L Macro IS USM :
https://www.dropbox.com/s/uhb53tpjc16pzpf/100MacroIS.LOG?dl=0
(https://www.dropbox.com/s/uhb53tpjc16pzpf/100MacroIS.LOG?dl=0)
EF24mm f/1.4L II USM :
https://www.dropbox.com/s/d8b082myficge0n/24f14II.log?dl=0
(https://www.dropbox.com/s/d8b082myficge0n/24f14II.log?dl=0)
Results (including my lens):
(http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF-S%2024mm%20f2.8%20STM.png) (http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%2024mm%20f1.4%20L%20II%20USM.png) (http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%20100mm%20f2.8%20L%20Macro%20IS%20USM.png)
The 100/2.8 macro has some trouble, not sure why.
You can increase the delay if you think it will change the results.
Very nice find, the hysteresis !
Would have had problems for positioning the transition more precisely if moving back and forth. Would like to see with step-size=2 if the change of the step length at the transition position is still valid in the other direction.
For the 24mm, it should be somewhere near 45 fine steps ? (to "visually" make the curves best match each other) which is significant in relation to the step length of 7 fine steps.
Anyway, I can share the logs for the 2d and third test for the EF24mm f/1.4L II USM.
2d test: starting in-between (macro and infinity)
https://www.dropbox.com/s/kbj7irdaqab94jd/24f14II_2.log?dl=0
(https://www.dropbox.com/s/kbj7irdaqab94jd/24f14II_2.log?dl=0)
3d test : starting near infinity end (done after a rest time)
https://www.dropbox.com/s/0txw7b3rsa4z1r8/24f14II_3.log?dl=0
(https://www.dropbox.com/s/0txw7b3rsa4z1r8/24f14II_3.log?dl=0)
I will retry the test with the 100mm Macro (Fyi, it was in full range the first time)
You are right, I don't think the delay would be the cause of this sort of trouble.
Your script is very fast, but the position counter does follow and finally returns the good values even if they arrive later.
The hysteresis was present in my first test (http://www.magiclantern.fm/forum/index.php?topic=4997.msg170048#msg170048) as well.
Repeatability (24/1.4):
(http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%2024mm%20f1.4%20L%20II%20USM.png) (http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%2024mm%20f1.4%20L%20II%20USM%20try2.png) (http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%2024mm%20f1.4%20L%20II%20USM%20try3.png)
Probably it's worth increasing the delay in my script.
Quote
The hysteresis was present in my first test as well.
Yes, you are right (of course).
I made a mistake at that time : I thought it was like the clipping at each end (which is less than a step in length)...
I made :
- a second test with the 100 mm L macro IS USM (switch on full range as for the first test, same delay conditions = extra-delay set to 100ms) :
https://www.dropbox.com/s/k3xpj93srzyvvye/100MacroIS_2d_test.LOG?dl=0
(https://www.dropbox.com/s/k3xpj93srzyvvye/100MacroIS_2d_test.LOG?dl=0)
- a first test with the 35mmf/2 IS USM (extra-delay=100ms too).
https://www.dropbox.com/s/vlziuqejrkew2pd/35f2IS_1.LOG?dl=0
(https://www.dropbox.com/s/vlziuqejrkew2pd/35f2IS_1.LOG?dl=0)
What should be the strategy to increase the delay ?
What do you think of a loop for testing the value of the position counter ?
Note : the tests I have made till now are not a reference as I use very large delays to avoid problems (500ms for scans and seconds for the tests I have made with the 24mm to reach a target from random starting positions) which is unusable in practice.
These tests didn't attempt to model dynamic behavior in any way, so 500ms is fine. The hysteresis is probably mechanical backlash (just a guess).
(http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%20100mm%20f2.8%20L%20Macro%20IS%20USM%20try2.png) (http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%2035mm%20f2%20IS%20USM.png)
100/2.8 still has large difference between the two directions, but different: this time, the focus position counter appears to catch up when the lens returns back to macro end.
35/2 looks very clean (as does 100/2.8 in the first test, on the areas that overlap).
The Extradelay in Lens.focus() has been set to 500 ms.
You can find here the repeatability tests for the 35mm f/2 IS
https://www.dropbox.com/s/8waglc2nc96pyhf/35f2IS_2.LOG?dl=0
(https://www.dropbox.com/s/8waglc2nc96pyhf/35f2IS_2.LOG?dl=0)
https://www.dropbox.com/s/nevqdg1stxqugjp/35f2IS_3.LOG?dl=0
(https://www.dropbox.com/s/nevqdg1stxqugjp/35f2IS_3.LOG?dl=0)
and the first one for the zoom EF17-40mm F/4 L USM @ 40mm
https://www.dropbox.com/s/xmaf82vmuhz4us3/17-40f4L%4040_1.log?dl=0
(https://www.dropbox.com/s/xmaf82vmuhz4us3/17-40f4L%4040_1.log?dl=0)
I will retry the test of the 100mm Macro IS, but with 500ms delay, Lv will probably shut down I am afraid : I will try to dim Lv display,...
Quote from: BBA on November 18, 2016, 07:36:13 PM
I will retry the test of the 100mm Macro IS, but with 500ms delay, Lv will probably shut down I am afraid
Press some key every now and then to wake it up (just make sure it won't have side effects, such as autofocusing or exiting LiveView).
35/2 repeatability:
(http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%2035mm%20f2%20IS%20USM.png) (http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%2035mm%20f2%20IS%20USM%20try2.png) (http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%2035mm%20f2%20IS%20USM%20try3.png)
17-40/4 @ 40:
(http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%2017-40mm%20F4%20L%20USM%20at%2040mm.png)
This morning, I had time to do the 2 repeatability tests with the EF 17-40mm f/4 L USM @ 40mm with a rest time between them (to be sure, as I don't know about the temperature of the friction surfaces) :
https://www.dropbox.com/s/75oety1f5fh6w77/17-40f4L%4040_2.log?dl=0
(https://www.dropbox.com/s/75oety1f5fh6w77/17-40f4L%4040_2.log?dl=0)
https://www.dropbox.com/s/ctohymzgak84f8o/17-40f4L%4040_3.log?dl=0
(https://www.dropbox.com/s/ctohymzgak84f8o/17-40f4L%4040_3.log?dl=0)
and do a first try with the EF 50mm f/1.8 II : I think it went in an infinite loop with the first loop on lens.focus command (step-size=3) as there is nothing in the log file:
https://www.dropbox.com/s/6l8xo5lxjr5r1vt/50f18II_0.LOG?dl=0
(https://www.dropbox.com/s/6l8xo5lxjr5r1vt/50f18II_0.LOG?dl=0)
The 100mm will need more time.
17-40 has some small surprises on repeatability side:
(http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%2017-40mm%20F4%20L%20USM%20at%2040mm.png) (http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%2017-40mm%20F4%20L%20USM%20at%2040mm%20try2.png) (http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%2017-40mm%20F4%20L%20USM%20at%2040mm%20try3.png)
For 50/1.8, I think there are no limit switches at the end, so this condition is detected only by noticing the motor no longer advances (or its current increases above some threshold). This matches the focus hunting noises made by this lens. The same focus error is reported when you try to stop the focus ring with your hand, or if the lens ring gets a little stuck for some reason.
The retry mechanism from ML currently checks whether focus_pos gets changed after each focus command (and if there's no change, it allows 2 retries). On 24/2.8, this is well-behaved. On 50/1.8, I assume the motor is trying to drive the focus ring past its limit, and the encoder just goes back and forth (because of those retries), therefore reporting changes in focus_pos (which confuses my algorithm and allows it to retry over and over).
With this retry mechanism, I'm trying to cover 3 issues:
- PROP_LV_FOCUS_DONE reporting error during normal movements (without reaching the limits); in this case, retrying the focus command in the same direction usually works; without the retry mechanism, some lenses have issues such as stopping a focus stack for no apparent reason
- lens refusing to go back with small steps after reaching a limit switch (after going back one small step, the limit switch is still active, so even if the movement was successful, PROP_LV_FOCUS_DONE reports error)
- when reaching the limit, the last step executed may be smaller than usual, and PROP_LV_FOCUS_DONE reports error even though the focus ring was moved (although not by one full step, because the limit was reached). In this case, I want a focus stack to take the last picture, even if that step was smaller, without reporting error (and I want an error to be reported for the next focus attempt in the same direction, if any). In other words, I want this half-complete motion to be considered a successful one (see this issue (https://bitbucket.org/hudson/magic-lantern/issues/2452/soft-focus-limit-incorrectly-reached-when)).
Maybe I should also check the focus direction of each command somehow before allowing retries.
Can we assume positive correlation between focus command, focus_pos and focus distance (or at least between the first two)? I remember reports about some third party lenses that moved in opposite direction (though I don't remember exact models).
We also need some focus tests (e.g. in api_test.lua) that cover the above cases. The test script that created the above logs checks for #2 at one of the ends. For #3, one could focus at one end with step size 3, then go back with step size 2, then forward with step size 3, forcing the last step to be incomplete (thus turning a seemingly random issue into a deterministic one). #1 is tricky, as it requires user actions that are not exactly friendly to the focusing mechanism (or, a lens with poor mechanical condition, that reports false errors very often).
Many thanks for those informations as well as the very interesting paper on the Kalman filter (I would like to look at closely).
The next test for the 100mm Macro IS was difficult to get done. During the first run, the position counter and focus distance were stuck on the first values for the whole length of he file. I had to try and find out what went wrong. I think there are false electrical contacts. I still don't know where actually (a Gray encoder ?). Maybe this lens needs servicing.
Anyway, I could finally get a correct run (but the results for this lens will have to be taken with greater care given the troubles we have had with it) :
https://www.dropbox.com/s/d7ujp5buqwoff1m/100MacroIS_5th_test.LOG?dl=0
(https://www.dropbox.com/s/d7ujp5buqwoff1m/100MacroIS_5th_test.LOG?dl=0)
(http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%20100mm%20f2.8%20L%20Macro%20IS%20USM%20try5.png)
It doesn't look that bad, but I'm also wondering what's going on. Anyone else having this lens?
After some homework, here are the 2 first test results for the 17-40 @ 17mm :
https://www.dropbox.com/s/0fj4rinhm6z56xc/17-40f4L%4017_1.log?dl=0
(https://www.dropbox.com/s/0fj4rinhm6z56xc/17-40f4L%4017_1.log?dl=0)
https://www.dropbox.com/s/j0prhh637yrwh94/17-40f4L%4017_2.log?dl=0
(https://www.dropbox.com/s/j0prhh637yrwh94/17-40f4L%4017_2.log?dl=0)
I have tested the 50mmf/1.8 II after commenting out the first loop and turning the "front barrel" to mechanical end (macro):
Note : this lens does not report the distance to ML
Note : when reaching the infinity mechanical end, the sound changes from louder to fainter indicating the motor does not work anymore; only the mechanical end protection (micro switch?) maybe.
I have left it working a few times at the mechanical end.
I guess the position conter counts and stops counting when the end protection enters in action because the same position should have been repeated more often.
The step length varies but there is no focus distance reported.
https://www.dropbox.com/s/qwp7drl7euz5n2z/50f18II_MI_1.LOG?dl=0
(https://www.dropbox.com/s/qwp7drl7euz5n2z/50f18II_MI_1.LOG?dl=0)
https://www.dropbox.com/s/z9tczx173ajycmg/50f18II_MI_2.LOG?dl=0
(https://www.dropbox.com/s/z9tczx173ajycmg/50f18II_MI_2.LOG?dl=0)
Quoteonly the mechanical end protection (micro switch?) maybe.
There's no such thing on 50/1.8 II as far as I could tell. When my 50/1.8 was still functional, I remember the motor trying to force the ring past its limit, and just hunting there.
Does the loop stop when reaching the end, or it just stays in some infinite loop?
The step count difference between the two attempts (1275 vs 1424) is pretty high. If it was repeatable, we could estimate the focus distance from this counter, as long as the lens is moved only from software and we know one of the limits (maybe with the lens equation, which I don't fully understand yet, but your experiment (http://www.magiclantern.fm/forum/index.php?topic=4997.msg175026#msg175026) looked quite linear).
Quote
Does the loop stop when reaching the end, or it just stays in some infinite loop?
It stays in some infinite loop. As the lens is moving, it is possible to see when the end is reached. The sound changed too. I left it continue a little while and then switched the camera off.
Quote
The step count difference between the two attempts (1275 vs 1424) is pretty high
I wonder: as far as I can remember (Youtube video ?), the piezo electric motor present in this lens is not a ring motor which would directly move the helicoïdal lens barrel without intermediate piece. Moreover there are other external moving parts as the protruding lens, the manual focusing ring in front that is rotating : more friction ?
I wonder if this is not only an electronical counter not related to the actual position of the lens barrel.
Quote
but your experiment looked quite linear
I think I am misleading people with that picture: the red and yellow are only my attempts to adjust a straight line via the least squares method (linear regression); the only measured points correspond to the steps of the decreasing blue stair function.
I know what happened : this picture has been plotted against the number of steps (step-size=1) ! so, with the assumption that the step length was constant (at that time (july), I had not yet used the position counter : I just counted the number of steps); as the length step decreases towards the infinity end, the curve gets "compressed". My apologies :-[ !!! I am working on another comparison picture.
Note : I only used the "thin lenses" formula : 1/p + 1/p' = 1/f where p, p' and f are in the same unit (mm), p is the focus distance, p' the image distance = distance from lens optical center to the sensor and f the focal distance.
Here are the results of the last test of the 17-40@17mm:
https://www.dropbox.com/s/82je0peg7tchqzw/17-40f4L%4017_3.log?dl=0
(https://www.dropbox.com/s/82je0peg7tchqzw/17-40f4L%4017_3.log?dl=0)
I have tested @ 28mm (in between):
https://www.dropbox.com/s/24bxn4obfyv09uf/17-40f4L%4028_1.log?dl=0
(https://www.dropbox.com/s/24bxn4obfyv09uf/17-40f4L%4028_1.log?dl=0)
If you like, I can also test an EF 70-200 f/2.8 L IS II USM (quite a wonderful one)...I have never dared to put it in test :-\ .
Quote from: BBA on November 21, 2016, 05:22:00 PM
the piezo electric motor present in this lens
The 50/1.8 II has a simple DC motor (see http://web.media.mit.edu/~bandy/rgb/disassembly.pdf p15) and an optical encoder (p18-20).
In AF mode, I would expect the encoder to be in sync with the focus ring position (even if you turn the focus ring manually and you hear the motor turning forcefully; be careful if you want to try that, as you can damage the focusing mechanism).
Quote from: BBA on November 21, 2016, 05:22:00 PM
If you like, I can also test an EF 70-200 f/2.8 L IS II USM (quite a wonderful one)...I have never dared to put it in test :-\ .
Why not?
Quote from: BBA on November 21, 2016, 01:00:29 PM
17-40 @ 17mm
(http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%2017-40mm%20F4%20L%20USM%20at%2017mm.png) (http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%2017-40mm%20F4%20L%20USM%20at%2017mm%20try2.png) (http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%2017-40mm%20F4%20L%20USM%20at%2017mm%20try3.png)
Quote from: BBA on November 21, 2016, 05:22:00 PM
@ 28mm (in between)
(http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%2017-40mm%20F4%20L%20USM%20at%2028mm.png)
It focuses faster at 17mm, right?
For information purposes, here is a comparison chart between the stairs functions obtained:
- in function of the actual position counter value with actual varying steps (red)
- in function of the number of steps as if the step length were constant(blue).
https://www.dropbox.com/s/9w0vtwmp4h1nyvk/100MacroIS_5th_test.jpg?dl=0
(https://www.dropbox.com/s/9w0vtwmp4h1nyvk/100MacroIS_5th_test.jpg?dl=0)
Notes:
X axis : position counter during the scan (the scan starts at macro mechanical end = 0) (in sub-steps)
This lens has many sub-steps : about 14426 sub-steps for about 3866 steps.
Y axis : focus distance in the image field (absolute value in mm)( the thin lenses formula has been used to project distances from the object field to the image field)
BLACK points : the same Y scale has used to display the step length in sub-steps. The scaling formula is : displayed_length = 110 + step_length*10. The values have a visual trend : go down from the macro end to a minimum and then, a little upwards near infinity end. The reason (if any) is not known.There are many outliers especially near infinity end (unknown reason heretoo).
RED points : The focus distance in the image field is displayed in function of the actual position counter values : at infinity, the distance between the focal lens centre and the sensor is equal to the lens focal length = 100mm. The position counter value giving the position of the focal distance is not known.
RED curve : it is possible to ask LibreOffice to calculate automatically a trend curve : a 2d degree polynomial has been chosen : the formula and the regression coefficient (least squares fitting) have been displayed near the curve. Actually, the curve should be forced to pass on the point (x,y) where x = lens focus image ( in french = n° du sub-step correspondant à la distance focale image) , and y = lens focal distance ( in french = distance focale image de l'objectif) but as written above, the position counter value corresponding to the focal distance is not known. Note : the coefficients of x and x2 seem tiny but the values of x and x2 are big !
BLUE points : for comparison purposes, the focus distance in the image field is displayed as if the step-length was constant from macro to infinity end (which it is not the case : see black points above) : the mean value of the step length has been calculated and taken as constant step length.
BLUE curve : a 2d degree polynomial curve has been fitted to the points automatically.
The curvature/concavity of the blue curve is less then the curvature of the red one.
@A1ex
Here are still the results of a few tests:
1)Last repeatability tests for the EF 17-40 @ 28mm
https://www.dropbox.com/s/pksd0mw62ts2mg5/17-40f4L%4028_2.log?dl=0
(https://www.dropbox.com/s/pksd0mw62ts2mg5/17-40f4L%4028_2.log?dl=0)
https://www.dropbox.com/s/vvvo0onl5nvlzlg/17-40f4L%4028_3.log?dl=0
(https://www.dropbox.com/s/vvvo0onl5nvlzlg/17-40f4L%4028_3.log?dl=0)
2) First test for EF70-200mm f/2.8L IS II USM @ 70mm ;)
(after a run with the same values at all steps) Next time I will switch console on !
https://www.dropbox.com/s/kekr4h78aa77goo/70-200f28ISII%4070_1.log?dl=0
(https://www.dropbox.com/s/kekr4h78aa77goo/70-200f28ISII%4070_1.log?dl=0)
Thanks for the disassembly paper of the 50mm 1.8 II !
The DC motor + optical encoder are there with a lot of little gears !
There is not so much mechanical backlash though...
Trying to get a linear graph.
If I understand the thin lens equation (http://hyperphysics.phy-astr.gsu.edu/hbase/geoopt/lenseq.html), when the subject is at infinity, the image distance is equal to focal length.
When focusing towards macro, the image distance increases, and therefore, the lens must be moved a little far away from the sensor in order to keep the subject in focus.
If we assume the linear lens movement is proportional to the focus_pos counter, we should get a linear graph if we plot the image distance (instead of the focus distance). I'm just going to distort the axis (so the plot will show image distance, but the axis labels will show focus distance).
The Y axis transformation should be something like 1 / (1/f - 1/o), where f is focal length and o is focus distance (object distance in the above link).
(http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%20100mm%20f2.8%20L%20Macro%20IS%20USM%20try5%20lin100.png) (http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%20100mm%20f2.8%20L%20Macro%20IS%20USM%20try5%20lin200.png) (http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%20100mm%20f2.8%20L%20Macro%20IS%20USM%20try5%20lin250.png)
I've played a bit with the focal length in the above formula, and if I use 200mm instead of the real value of 100mm, the graph is pretty much linear.
Is this because the thin lens equation doesn't quite apply here, or I'm just misunderstanding the whole thing and, and that linear graph was pure luck?
The 24/2.8 STM also gives a more linear plot with twice the actual focal length in the thin lens formula.
(http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF-S%2024mm%20f2.8%20STM%20lin24.png) (http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF-S%2024mm%20f2.8%20STM%20lin48.png)
For 70-200/2.8 II, it's a tie.
(http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%2070-200mm%20f2.8L%20IS%20II%20USM%20at%2070mm%20lin70.png) (http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%2070-200mm%20f2.8L%20IS%20II%20USM%20at%2070mm%20lin140.png)
For 35/2, 2*f looks better, and 3*f looks even better:
(http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%2035mm%20f2%20IS%20USM%20lin35.png) (http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%2035mm%20f2%20IS%20USM%20lin70.png) (http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%2035mm%20f2%20IS%20USM%20lin105.png)
The 17-40/4 looks best when linearized with f=80mm, at all focal lengths.
(http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%2017-40mm%20F4%20L%20USM%20at%2017mm%20lin17.png) (http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%2017-40mm%20F4%20L%20USM%20at%2028mm%20lin28.png) (http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%2017-40mm%20F4%20L%20USM%20at%2040mm%20lin40.png)
(http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%2017-40mm%20F4%20L%20USM%20at%2017mm%20lin80.png) (http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%2017-40mm%20F4%20L%20USM%20at%2028mm%20lin80.png) (http://a1ex.magiclantern.fm/bleeding-edge/focus-dist/EF%2017-40mm%20F4%20L%20USM%20at%2040mm%20lin80.png)
Food for thought:
1. Assuming we can find a good linearization transform (e.g. by choosing the "fake focal length" to minimize linear fit errors or similar), which is a better approximation for the actual focus distance? The linear regression line, or the line connecting the center points of the horizontal segments in the above graphs?
This can be answered by somebody who can set up a test environment with known focus distances (e.g. a linear axis of a CNC machine or similar, that can be moved at known distances). One needs to get a log similar to the previous ones, with an extra column: the real focus distance.
2. Most lenses can focus past the infinity, and this is visible in the above graphs as well. Can we find the real infinity focus point without actually using a distant object to focus on? (assuming the focus distance markers are calibrated from factory).
These are probably nitpicks, not sure how useful they are in practice.
I am not a specialist in optics but I will try to help. If you think I am wrong, don't hesitate to tell it !
For an authorized advice, I would ask help from specialists ...in our community...or from academic people...
As you know, real lenses are complex optical instruments.
For me, the thin lenses formula is to be considered as a simplified but convenient transform from the object field to another field not far from the image field ; in that meaning, the transform can be used with different parameters (like another focal lens value), and adapted according to our best needs.
I also thought of the « focus breathing », where the « apparent » focal distance changes when the focus distance changes....Cine lenses avoid that problem, but most picture lenses don't when they use inner focus. In this case, even if the lens has only one focal distance in it's name, it is only valid when focusing to infinity.
But one must take care of the fact that this simplified model can lead to errors depending on what we want to infer from it and with which precision.
For instance, the actual object distance will be an approximate without calibration as a1ex explains it in his previous (#63) post.
Anyway, I think there will always be an uncertainty relative to the precision of the actual position of the hardware, even if the software has done it's job. This is true if we can only work in open loop (cf. focus backlash, motor errors...) and will always limit precision.
All depends on what the community wants to do. Is it:
1) positioning the lens at a given target position
2) focus stacking
3) display more/very accurate current focus distances in Lv
For each choice:
1) positioning the lens at a given target position
- If the target position is determined through auto focusing and if we just want to go back to that target, the position counter is just sufficient. The precision may go from one step to maybe one half of a step (step-size=1) (which is to be converted to the object field).
- If the target position is given by the object distance, IMHO, it will be difficult, at least without calibrating the lens.
2) focus stacking
The Canon focus_distance can be used to build a continuous function of the position counter (this may be a step forward over the discontinuous stair function available now). According to DOF calculations, the position of the shots needed can be calculated. Then we have to move the focus position to each of the calculated positions as in 1) above.
3) display more/very accurate current focus distances in Lv
Display more accurate focus distance may be possible (not near infinity), but very accurate display will need a lens calibration as a1ex explained in his previous post.
@BBA/@A1ex
I'm away from home at the moment, but watching your developments with much interest.
As I alluded to before, as a stills (non-macro) photographer, this feature would be a nice to have, but non essential for me.
My Lua landscape bracketing scripts operate with a move from here-2-here rationale, ie FP2Inf, FP2HFD or FPa2FPb, and based on checking that overlap from the ML DoF variabes, eg DoF-near and -far.
As I overlap the focus brackets, being a few% out is not that critical.
Thus, I wonder, if the lens repeatably or linearalization gets 'better' between focus points, ie rather than trying to drive the lens over the entire possible movement capability.
Just a thought?
Cheers
Garry
I have been following this thread with great interest, but there is something that has been worrying me from the beginning; perhaps I have not understood the target of this study, or perhaps I have not understood how all this works.
On one side we have the focusing distance, as reported by the encoder in the lens; this distance is used to inform a field in the EXIF data, so the user knows the focusing distance. On the other hand we have some commands to move the lens back and forth, and a counter that stores the current position of the lens; these commands are used by the camera to focus the lens on a subject. And now we are trying to find a method to match the focusing distance to the lens position, so we can (for example) tell the lens to move the focus to a specific distance.
What I was wondering is whether that function does even exist at all.
When the camera focuses, it uses the info from the AF sensors to determine if the subject is focused, how far from being focused it is, and what direction must move the lens to gain focus. With this information, the camera sends some commands to the lens, the lens moves the focus, and the camera checks the focus again. In this process, the focusing distance is not needed at all; in fact, the focusing distance reported is way coarser than the focusing abilities of the lens, and some lenses does not even report any focusing distance.
My thought is that if I was Canon, I would not bother to make any connection between the focusing distance and the focusing steps, because the camera does not need it: as far as I know, there is no official method (buttons, menus, PPTP, ...) to tell the camera to focus to a specific distance, and the AF does not need it either.
If I had to implement a method to move the focus to a specific distance, I think I would employ a trial-and-error approach: check focusing distance, move lens a large step, check focusing distance again, move lens a small step, ... All the info gathered in this thread can probably be used to speed up this process (for example, with a look-up table with some values from known lenses). But I do not think we can obtain a function to determine the lens position from the desired focusing distance.
Just my two cents (or perhaps a clueless comment).
That's correct - autofocus doesn't care about focus distance. Another example: my 18-55 II kit lens no longer reports focus distance properly (it's stuck at some value), yet this hasn't interfered with autofocus.
I guess the focus distance info is just for EXIF. It can be used for corrections such as vignetting, but these depend on the focus distance as well. In particular, on a 24/2.8 STM mounted on full frame, the focus distance and the aperture make a big difference in the vignette pattern.
Quote from: eduperez on November 24, 2016, 01:22:05 PM
And now we are trying to find a method to match the focusing distance to the lens position.
[...]
What I was wondering is whether that function does even exist at all.
Probably not. We are creating one from scratch.
The result would be just a higher precision in the focus distance indicator, or when moving to a specific focus distance. It might also add some rough focus distance indication to the lenses that don't have one.
Whether this will be useful in practice, I don't know.
In the process, we have also found some bugs in the focus backend, and fixed some of them. This is useful, right?
Also, we can now record focus positions and later return to them, with fewer constrains. Previously, we were able to do so only if we moved the lens in single steps of the same size (and even then, the position errors would accumulate, resulting in drift). With the fine position counter, we can probably return to saved focus points no matter how we move the lens, as long as the encoder records the movement (autofocus, or by sending focus commands of any size/speed. It's still not perfect - some lenses will lose the position during manual focus.
In other words, nitpicks :P
According to Canon focus distance is used by E-TTL II.
But I never tested through if and in which respect results differ between lenses with/without encoders.
There were "problems" with the EF70-200 f2.8L IS II USM too, like with the EF 100 f2.8L IS USM. It doesn't seem to be due to the lens itself as I suspected before with "electrical false contacts".
This tests @200mm seems special too: lots of steps (high precision) and different step-lengths for the two directions A focal length change has modified the step length between the two directions (nothing unknown):
- macro to infinity: 4 fine steps, then 3 fine steps,
- infinity to macro : only 3 fine steps,
though the step length graph is very clean (no outliers) !
Repeatability tests will maybe shed some light...
https://www.dropbox.com/s/7dmhieso4hc4b54/70-200f28ISII%40200_1.log?dl=0
(https://www.dropbox.com/s/7dmhieso4hc4b54/70-200f28ISII%40200_1.log?dl=0)
I had to modify my previous post as the step length change observed is due to a tiny rotation of the focal length barrel.
I will try to show the variation of the step length according to the focal length.
It also occurred during the following (2d repeatability) test : the barrel has to be at mechanical end.
https://www.dropbox.com/s/ub68gt6l0u0u9ae/70-200f28ISII%40200_2.log?dl=0
(https://www.dropbox.com/s/ub68gt6l0u0u9ae/70-200f28ISII%40200_2.log?dl=0)
It should be noted that the number of steps is very high (more than 8000) and that these are very tiny step length (3 fine steps) for step-size=1.
Found lens.focus_pos on 5D3 1.2.3, likely the same on 6D and other recent models. Also added it on EOS M, but not tested. Test builds on the Experiments (http://builds.magiclantern.fm/experiments.html) page.
Couldn't reproduce the issues with 50/1.8 (http://www.magiclantern.fm/forum/index.php?topic=4997.msg175171#msg175171) (mine is broken, and after trying to repair it the n'th time, the motor no longer gives signs of life). As I don't have any other use for this lens, other than checking the focus backend in ML, I hope to get away with tester feedback.
Therefore, I'm looking for a log to see what happens when you attempt drive this lens past its limit (with either follow focus or Lua commands). If weird things happen, please open the console and take a screenshot.
The focus backend in this build is also different from the others, so I'm looking for similar feedback with other lenses. In particular, the behavior of follow focus at the end points: it should stop driving the lens (it should not keep forcing the motor past its limit), and it should allow moving the lens in the opposite direction, even at small speeds.
Also please check whether this issue (https://bitbucket.org/hudson/magic-lantern/issues/2452/soft-focus-limit-incorrectly-reached-when) is still valid.
Quote from: a1ex on January 25, 2017, 02:31:09 AM
...Also added it on EOS M, but not tested. Test builds on the Experiments (http://builds.magiclantern.fm/experiments.html) page.
EOSM lua Script API Tests results uploaded to Dropbox (https://www.dropbox.com/sh/m17imm8wqavd1q3/AADOhSg95KRemu6WGc9zRqgaa?dl=0).
Ran tests using EF-S 17-55mm f2.8, EF-M 11-22mm f4-5.6 and EF-M 22mm f2 lenses using the build posted on the Experiments page. The camera was able to control the EF-S lens through the active adapter but the EF-M lenses didn't move. The 22mm lens is easy to tell because it makes a noise and the front element moves but the zoom lens is all internal. I thought it was working at first but it was only the autofocus tests that moved the lens. Note that it takes much longer for the tests to complete with the EF-M lenses--about 20 minutes compared to just a couple of minutes with the EF-S lens.
Quote from: a1ex on January 25, 2017, 02:31:09 AM
Also please check whether this issue (https://bitbucket.org/hudson/magic-lantern/issues/2452/soft-focus-limit-incorrectly-reached-when) is still valid.
I was trying to figure out how to test that when I realized that it isn't on the EOSM features list. Since the camera
can control EF lenses is there any harm commenting out these undef statements?
/* Some Hope Yet */
#undef FEATURE_TRAP_FOCUS
#undef FEATURE_FOLLOW_FOCUS
#undef FEATURE_RACK_FOCUS
#undef FEATURE_FOCUS_STACKING
Yeah, I know--try it and find out. That was the case with FEATURE_AUDIO_REMOTE_SHOT a while back. So I did and it looks like the EOSM can do Focus Stacking along with the other focus tricks.
I ran the tests for Issue #2452 (https://bitbucket.org/hudson/magic-lantern/issues/2452/soft-focus-limit-incorrectly-reached-when), Soft Focus Limit Incorrectly Reached When Using Focus Stack, though I don't quite understand this line in the instructions:
Quote3. Set Num Pics In front to 0 4 Set Focus steps / picture to 1
Perhaps the '4' is a typo or does it have some significance?
With the EOSM I got the 'Soft Focus Reached' in the first test at the end and on the third exposure with the second test.
Since I'm not familiar with these focus settings I also ran the test on the 700D. On that camera the focus steps are much larger than the EOSM. In fact on the EOSM the focus increments were so tiny that I had to set Focus steps / picture to 10 to see that it was indeed moving the lens. That same setting on the 700D would get the 'Soft Focus Reached' error because the of the larger steps.
So--it looks like the EOSM is moving EF lenses but at a much finer increment (the lua "Script API Tests" did move the lens through the entire range) but the native EF-M lenses are still unresponsive.
Finally--reproducing Soft Focus Limit Incorrectly Reached When Using Focus Stack as far as I understand it on the 700D did not bring up the 'Soft Focus Reached' on either the first or the second test so it looks like that issue was resolved.
Thanks for the tests.
Quote
Autofocus outside LiveView...
I wonder how this one worked on the M. Best guess: pressing the half-shutter enabled LiveView, and it autofocused there.
QuoteSo--it looks like the EOSM is moving EF lenses but at a much finer increment (the lua "Script API Tests" did move the lens through the entire range)
Focusing forward with step size 3, wait=true...
Focusing backward with step size 3, wait=true...
Focus range: 6 steps forward, 6 steps backward.
Motor steps: 2291 forward, 2291 backward, 0 lost.
Focusing forward with step size 2, wait=true...
Focusing backward with step size 2, wait=true...
Focus range: 35 steps forward, 31 steps backward.
Motor steps: 2291 forward, 2291 backward, 0 lost.
Focusing forward with step size 1, wait=true...
Focusing backward with step size 1, wait=true...
Focus range: 126 steps forward, 125 steps backward.
Motor steps: 2291 forward, 2291 backward, 0 lost.
These look fine, focus position counter works, so I guess changing step size actually makes a difference in speed. Adding some timestamps to the log should help answering this.
Quote
but the native EF-M lenses are still unresponsive.
Not sure what to do about that, but some dm-spy logs in LiveView during autofocus and during ML focus commands (e.g. follow focus) might give some clues.
Quote
Finally--reproducing Soft Focus Limit Incorrectly Reached When Using Focus Stack as far as I understand it on the 700D did not bring up the 'Soft Focus Reached' on either the first or the second test so it looks like that issue was resolved.
If you can reproduce the issue on the regular nightly or on the lua_fix branch, that's a good sign!
Not adding much here, other than another tester ;)
Just tried my simple lens move test on the EOSM with a Canon adapter and 24-105 F4/L. Plus with latest experimental Lua fix build.
function test_lens()
local lens_ok = false
local start = lens.focus_distance -- position lens near macro end
repeat
lens_ok = lens.focus(-1,3,true)
until lens.focus_distance >= lens.hyperfocal
-- take a picture
camera.shoot(false)
-- now go back
repeat
lens_ok = lens.focus(1,3,true)
until lens.focus_distance <= start
end
function my_test(k)
if k == KEY.PLAY then
test_lens()
return false
else
return true
end
end
event.keypress = my_test
Tried it with step 3 (above) and step 1. Both drive at the same slow speed. Neither make the return trip.
Quote from: garry23 on January 25, 2017, 09:05:05 PM
Tried it with step 3 (above) and step 1. Both drive at the same slow speed. Neither make the return trip.
Does it help if you no longer take a picture?
If yes, make sure the camera returns to LiveView before attempting to send more focus commands.
(should this trigger a Lua error?)
@A1ex
No: I'm afraid not.
The api_test log from dfort showed the lens moved in both directions. Can you reproduce?
@A1ex
Just ran api_test and all is OK until the first lens move test.
Lens moves, with very small/slow steps, towards infinity then just stops.
@A1ex
Forgot to say the end of the log is:
Quote......
Focus distance: 655350
...I wonder if Dan and I have different Canon settings?
Quote from: garry23 on January 25, 2017, 09:58:51 PM
Forgot to say the end of the log is:
Quote......
Focus distance: 655350
On the EF-S 17-55mm f2.8 one end was 340 and the other end was 655350. It moved at about the same rate as on the 700D so I'm not sure if that's slow or not. Did you get an error message or did you just give up waiting? Note that on my tests with the EF-M lenses it took about 20 minutes or maybe even more. I connected an AC adapter to make sure the batteries wouldn't run out before the end of the test.
Quote from: garry23 on January 25, 2017, 10:05:34 PM
...I wonder if Dan and I have different Canon settings?
We can try "Clear settings" on the 4th Canon wrench menu and run another test if you want.
I'm now running tests on the 700D now as per a1ex's instructions and am seeing some very different results.
@dfort
As I said, I'm testing with a 24-105 and I also tried a Sigma 10-20.
Once the lens is driven to the infinity end it just stops and there is no error message.
Right, and how long did you wait?
Quote from: dfort on January 25, 2017, 10:45:19 PM
Right, and how long did you wait?
If it waits several minutes before turning back, that's not OK.
Quote from: a1ex on January 25, 2017, 02:31:09 AM
Therefore, I'm looking for a log to see what happens when you attempt drive this lens past its limit (with either follow focus or Lua commands). If weird things happen, please open the console and take a screenshot.
Just tried it again.
Lens drives to infinity and then stops (I left it for 2 mins).
During this time the light below the on/off switch pulses (quickly).
Ran tests on the 700D using both the current nightly and lua_focus_pos Experimental Jenkins builds. (I didn't compile any of the builds I'm testing here.) Uploaded to the same dropbox (https://www.dropbox.com/sh/m17imm8wqavd1q3/AADOhSg95KRemu6WGc9zRqgaa?dl=0) folder and archived the EOSM tests.
Interesting that with the nightly build the focus distance ranges from 410 to 655350 with a maximum focus range of 99 steps forward, 99 steps backward while with the lua_focus_pos build the focus distance ranges from 340 to 655350 with a maximum of 341 steps forward, 298 steps backward.
Also ran the Soft Focus Limit Incorrectly Reached When Using Focus Stack (https://bitbucket.org/hudson/magic-lantern/issues/2452/soft-focus-limit-incorrectly-reached-when) issue tests with both of these builds and came up with different results. On the first test the nightly (unified) build will stop on exposure 27 with the 'Soft Focus Reached' while on the second test it will stop with 'Soft Focus Reached' before the first exposure. Seems to me that maybe the EF-S 17-55mm f2.8 lens I'm using has a shorter focus throw than the 24-70 ƒ4 used in the bug report. Switching over to the lua_focus_pos build, which I tested previously but wanted to double check, it passed both tests without reaching the 'Soft Focus Reached'. So at least with this equipment the issue seems to be resolved.
Other than the 'Soft Focus Reached' warning I didn't observe any "weird" things happening.
@A1ex
Could have been me, but as soon as I got up this morning I redid the api_test from Lua focus experiments (lens.focus_pos).
I can confirm the lens moves correctly and api test seems to complete ok.
I don't what went wrong yesterday.
@A1ex
Off to work now, but one strangeness (but could be due to my scripting) is that, although the api_test runs OK, the following script moves the lens very slowly to the HFD, takes a picture and doesn't move back as expected.
onoff = false
function test_lens()
local lens_ok = false
local start = lens.focus_distance -- position lens near macro end
repeat
lens_ok = lens.focus(-1,1,true)
until lens.focus_distance >= lens.hyperfocal
-- take a picture
camera.shoot(false)
-- now go back
repeat
lens_ok = lens.focus(1,1,true)
until lens.focus_distance <= start
end
function check_4_test_lens(arg)
if onoff == true then
test_lens()
onoff = false
return false
else
return true
end
end
function my_test(k)
if k == KEY.PLAY then
onoff = true
return false
else
return true
end
end
event.keypress = my_test
event.shoot_task = check_4_test_lens
Does a larger step size help?
@A1ex
I just tried changing the step size and the lens is still driven at the same slow and very small step size, and will not drive backwards.
This is strange, as the api_test appears OK.
It looks like there is something in my script that is influencing the lens.focus.
Cheers
Garry
@A1ex
I just tried my test script again and explicitly calling lv.start() before lens moves.
Still no luck.
What I think I see, after the slow move to the HFD and the image capture is one step back then a freeze.
@A1ex
Just reset Canon settings.
I just can't get a consistent response, but something seems fishy between a Canon setting and lens.focus...maybe?
BTW I'm using M mode, AF on and continuous focus disabled.
@A1ex
I think I can help.
Sorry if I am late, I have many things "on the fire".
With the EF 50mm/1.8 II USM on the 5DmIII, the FOCUS menu reports at the bottom, either:
"Your lens does not report focus distance"
or
"Focus distance is only available in Liveview".
Now, hereafter, the results of the API_TEST.LUA :
https://www.dropbox.com/s/pf71t0rc372e3ls/LUATEST.LOG?dl=0 (https://www.dropbox.com/s/pf71t0rc372e3ls/LUATEST.LOG?dl=0)
https://www.dropbox.com/s/k1p90e06s5li30u/VRAM0.PPM?dl=0 (https://www.dropbox.com/s/k1p90e06s5li30u/VRAM0.PPM?dl=0)
https://www.dropbox.com/s/8jpogrj3p3ymuop/MAGIC.CFG?dl=0 (https://www.dropbox.com/s/8jpogrj3p3ymuop/MAGIC.CFG?dl=0)
https://www.dropbox.com/s/q9fptenoefw7u8a/api_test.lua?dl=0 (https://www.dropbox.com/s/q9fptenoefw7u8a/api_test.lua?dl=0)
I hope it can help.
I can send you the lens (I live in Belgium), it will be more effective : PM me.
Cheers!
Did the camera have something to lock focus on?
Also, please remove the ROM links, as you don't have the permission to redistribute them (see FAQ).
@A1ex
Quote
Did the camera have something to lock focus on?
I was holding the camera, pushing the buttons,... so there was no stable "object" to lock focus on but as I have not taken care to that, this answer is not binary.
Quote
Also, please remove the ROM links, as you don't have the permission to redistribute them (see FAQ).
I thank you A1ex.
@BBA
I see the latest Lua includes focus_pos, but as this is 'only' a get call, am I right in saying it has no lens control value?
In fact, based on the step 'curves' I've seen in this thread, I'm a little at a loss to see the use of focus_pos.
Or have I got it wrong?
Cheers
Garry
@garry23
Quote
I see the latest Lua includes focus_pos, but as this is 'only' a get call, am I right in saying it has no lens control value?
You are right.
Quote
In fact, based on the step 'curves' I've seen in this thread, I'm a little at a loss to see the use of focus_pos.
The main purpose is to get a precise and repeatable indication of the lens focus position in the image field. It would then be possible :
- to know the lens position at a given moment and
- to be able to get back to that same position later (for instance with lens.focus() Lua commands), even if the camera is switched off in between.
The focus_pos value is one candidate.
Tests have been carried out to know more about it.
Carefully read the posts, especially a1ex ones.
Trying to summarize:
1) The variation of the focus_pos value is more precise than the number of steps of length 1 (obtained with lens.focus() Lua command) : this means this value varies faster, but the ratio
( focus_pos(2) - focus_pos(1) ) / (number of steps of length 1 to go from position 1 to position 2)
is not strictly constant (this may be even worse with length 2 and length 3 lens.focus steps).
2) It is not so repeatable because:
- the value is reset each time the camera is switched off;
- there is significant hysteresis between forward and backward moves : one guess is this hysteresis could be due to mechanical backlash.
This makes it is not easy at all to get back to a given focus_pos position and explains why there is still no available command to do so.
@BBA
Thanks for the quick response.
I'm sorry, I still don't get it.
Say I zero out focus_pos and then use lens.focus to move X steps at, say, step size 2.
I then check ficus_pos and find it is y units, i.e. y 'micro steps' from zero.
If I then say attempt to move back using, say, step size 1, this time how does knowing I moved y micro units help me control the lens return position, as I can not position the lens using the finer units.
@Garry23
I am back :) (thanks g3gg0) !
Quote
Say I zero out focus_pos
note that you cannot change the value of focus_pos as it is only a "returned" value.
Quote
If I then say attempt to move back using, say, step size 1, this time how does knowing I moved y micro units help me control the lens return position, as I can not position the lens using the finer units.
I think of focus_pos as a higher resolution ruler which gives (returns) you a finer value of the lens position, the 'micro units' position as you call it.
Till now, the only way to have an idea of the lens focus position was to question for the lens.focus_distance which is in the « object field » and which is not so precise as there are only few values, i.e.:
(m) 0,3.....1.....3.....10.....infinity depending on the lens, as can be seen on the lens barrel.
The focus_pos ruler is now in the image field, it has a lot of graduations (ticks ?) but you can only move the lens as before using lens.focus commands with step sizes 1,2 and 3.
Nevertheless, it is a great tool to know where the lens has moved (relative information, after a move) or where it is (absolute info - only known after you have found the ruler position (offset) when the camera was switched on and the total number of micro units for that lens from macro to infinity).
You can add or subtract micro units as you use lens.focus commands :
Let's take a simplified example:
To simplify, let's assume that all the moves of
- step size 1 with lens.focus are equal to 7 micro units in length in the image field.
- step size 2 ... moves are equal to 30 micro units in length....
Let's assume there is no hysteresis.
We can then compute the position of the lens in micro units.
If the starting position = 0 micro units
If I ask, say, 7 times a move of step size 2 towards infinity, the position of the lens should be
0 + 7 x 30 = 210 micro units (or -210, if it is negative towards infinity, depending on the lens)
The returned value of focus_pos should then also be 210 micro units.
If I then ask a move of step size 1 towards macro end, the position of the lens should be
210 - 7 = 203 micro units.
Lest's now imagine I want to go to the very precise position of 150 micro units.
I have to go towards macro end by
203 - 150 = 53 micro units.
53 is not a multiple of 7 and
53 is lower than the Lowest Common Multiple (LCM) (in french « plus petit common multiple » PPCM) of 7 and 30
the remainder of the integer division of 53 by 7 is not 0
53 < LCM(7,30)
So it is impossible to go directly to position 150 exactly without changing the direction (the hysteresis would have an effect here because the direction of the move would have to be changed)
I can decide to make a move of 7 or 8 stepsize 1 steps towards macro end.
The position should then be
203 - 7 x 7 = 154 micro units (error = 4 micro units from the target of 150)
or
203 - 8 x 7 = 147 micro units (error = 3 micro units from the target of 150 : better solution)
IMHO those errors are « normal » for such a lens (to be confirmed).
I also think this example is a typical move when autofocusing in liveview.
The lens makes a big move in one direction and then comes back, one step at a time, in the opposite direction until it "crosses" the maximum contrast and then stops.
This avoids the hysteresis problems.
As you can see, because lens.focus_pos is a returned value, the only way to go to a position given in 'micro units' is by "trial and error" especially as the stepsize can change more or less in the general case (more constant with L lenses).
With a trial and error algorithm, it should be possible to develop a goto function in Lua.
IMHO the number of micro units crossed when moving might be given by a sensor: say some Canon lenses have optical sensors (I am speculating here: light emitted, reflected or not, and sensed back); magnetic sensors (GMR) are present in Nikon lenses (AF-S DX NIKKOR 18-105mm f/ 3.5-5.6G ED VR) and even Tamron, Tokina.
As one might think, it is necessary to measure a few impulses from such sensors to get a precise enough move of the lens barrel.
@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.
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 (http://www.magiclantern.fm/forum/index.php?topic=17596.0) - 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).
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.
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.