Messages

There should be a way to get better resolution even on older bodies because in 5x/10x zoom on 60D I get dng 2520x1764, usable 2520x1080

If you can control the height and make it 2080x535 we could just shoot with the anamorphic lens the other way around. Yeah the buffer is the key, the card write speed shouldn't be a problem.

Height can be changed by changing resolution in movie mode.

On 60D in movie mode I get:
1080p/720p: buffer 1888x1321, usable 1736x1154
480p: buffer 1888x1321, usable 1736x694
480p crop: buffer 920x644, usable 768x598

c0f26208 also works for 60D, thanks 1%

It should work on 600D because it does work on my 60D. I didn't know how to find edmac address so I used "lv_raw_dump2" which saves raw data as "*.mm1" file (it's just a memory dump).

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

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