Programmatic focus control and absolute/relative focus position

Started by sl0w0rm, March 30, 2013, 07:35:14 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

a1ex

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?)

garry23


a1ex

The api_test log from dfort showed the lens moved in both directions. Can you reproduce?

garry23

@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.

garry23

@A1ex

Forgot to say the end of the log is:

Quote......
Focus distance: 655350

garry23


dfort

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.

garry23

@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.


a1ex

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.


garry23

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).

dfort

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 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 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.

garry23

@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.

garry23

@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

a1ex


garry23

@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

garry23

@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.


garry23

@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.


BBA

@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/k1p90e06s5li30u/VRAM0.PPM?dl=0


https://www.dropbox.com/s/8jpogrj3p3ymuop/MAGIC.CFG?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!

a1ex

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).

BBA

@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.

garry23

@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

BBA

@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.


garry23

@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.

BBA

@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.