set_zoom behavior (was Re: chdkptp - alternative ptp client) - General Discussion and Assistance

nod5

4

set_zoom behavior (was Re: chdkptp - alternative ptp client)

« on: 18 / September / 2018, 16:49:46 »

Advertisements

Hi reyalp and others. Two questions I've run into while working on TwoCamControl, a windows frontend that uses chdkptp.

1. question about set_zoom_rel(+1)

In my tests the chdkptp command set_zoom_rel(+1) works once but if repeated has no effect until some other zoom action is performed inbetween.

For example

Code: [Select]

set_zoom_rel(+1)
set_zoom_rel(+1)

will actually only make the camera zoom one step, the second command has no effect.
But on the other hand this works as expected

Code: [Select]

set_zoom_rel(+1)
set_zoom_rel(-1)
set_zoom_rel(+1)

as this also works as expected

Code: [Select]

set_zoom_rel(+1)
set_zoom_rel(+5)
set_zoom_rel(+1)

and this also works

Code: [Select]

set_zoom_rel(+2)
set_zoom_rel(+2)

Now the question: is this a general issue with chdkptp/CHDK/Canon cameras and set_zoom_rel(+1) ? Or merely something specific to my setup/cameras?

2. question about special (not A-Z) characters after the path command when in rsint mode

What characters are supported after the path command? Could support be added for characters such as the german ü ?

For example if we start rsint mode and then enter the commands

Code: [Select]

path C:/1ü2/1
s

one would expect the file

Code: [Select]

C:/1ü2/1.jpg
But in my tests the image is instead saved as

Code: [Select]

C:/12/1.jpg
where the character between 1 and 2 is https://unicode-table.com/en/search/?q=%C2%81 , a character not visible in File Explorer in Windows 10

(edit: corrected name of set_zoom_rel command, I had confusingly written zoom_set_relative)

« Last Edit: 24 / September / 2018, 14:04:32 by nod5 »

Logged

reyalp

14000

Re: set_zoom behavior (was Re: chdkptp - alternative ptp client)

« Reply #1 on: 19 / September / 2018, 17:35:12 »

Quote from: nod5 on 18 / September / 2018, 16:49:46

1. question about zoom_set_relative(+1)

zoom_set_relative is not a CHDK or chdkptp function.

testing set_zoom_rel on elph130 and elph180, I see similar behavior to what you describe.

=set_zoom(get_zoom()+1) behaves similarly, as expected, since this is how set_zoom_rel works.

I believe this is a camera / CHDK issue, where set_zoom on cameras with a lot of zoom steps doesn't necessarily end up on the exact step requested. e.g.

Code: [Select]

con 28> =set_zoom(get_zoom()+1) return get_zoom()
29:return:6
con 29> =set_zoom(get_zoom()+1) return get_zoom()
30:return:6

On this camera, doing +2 actually seems to give one unit steps (but probably isn't 100% reliable):

Code: [Select]

con 30> =set_zoom(get_zoom()+2) return get_zoom()
31:return:7
con 31> =set_zoom(get_zoom()+2) return get_zoom()
32:return:8

This is a CHDK / Canon firmware camera specific issue. It shouldn't have anything to do with chdkptp.

On old cameras with only a few steps, +1 works as expected.

I'd suggest if you want to move zoom in small increments on cameras with a lot of steps, use something a bit bigger than 1.

Quote

2. question about special (not A-Z) characters after the path command when in rsint mode

What characters are supported after the path command? Could support be added for characters such as the german ü ?

Unfortunately, chdkptp currently isn't unicode aware at all, so I'd recommend sticking to straight ANSI for now. Maybe I can fix this in the future.

Logged

Don't forget what the H stands for.

nod5

4

Re: set_zoom behavior (was Re: chdkptp - alternative ptp client)

« Reply #2 on: 20 / September / 2018, 05:31:53 »

Quote

This is a CHDK / Canon firmware camera specific issue. It shouldn't have anything to do with chdkptp.

On old cameras with only a few steps, +1 works as expected.

I'd suggest if you want to move zoom in small increments on cameras with a lot of steps, use something a bit bigger than 1.

Thanks for the reply. In the latest TwoCamControl I work around the issue roughly by zooming in +2 increments if get_zoom() returns >100 and otherwise +1. Though the >100 criterion is just a hunch. For all I know there might be a 90 zoom step range camera out there with the same +1 problem.

Do you know of a complete list of zoom ranges for the different CHDK supported cameras? I couldn't find one when searching, only scattered remarks like this http://chdk.wikia.com/wiki/Script_commands#get_zoom_steps writes "For example on the A620 it will return 8, on the S3IS it will return 128."
(Perhaps I should take this question to the general CHDK forum?)

BTW I started using set_zoom_rel and get_zoom , and then ran into the issue above, because

Code: [Select]

luar click('zoom_in') doesn't always zoom the same number of steps.

Quote

Unfortunately, chdkptp currently isn't unicode aware at all, so I'd recommend sticking to straight ANSI for now.

Ok, I'll make users stick to A-Z 0-9 Space in paths for now.

(edit: fixed typo in name of command: set_zoom_rel )

« Last Edit: 24 / September / 2018, 14:05:50 by nod5 »

Logged

reyalp

14000

Re: set_zoom behavior (was Re: chdkptp - alternative ptp client)

« Reply #3 on: 20 / September / 2018, 13:44:57 »

Quote from: nod5 on 20 / September / 2018, 05:31:53

Thanks for the reply. In the latest TwoCamControl I work around the issue roughly by zooming in +2 increments if get_zoom() returns >100 and otherwise +1. Though the >100 criterion is just a hunch. For all I know there might be a 90 zoom step range camera out there with the same +1 problem.

Do you know of a complete list of zoom ranges for the different CHDK supported cameras?

For most cameras, NUM_FL in platform/<camera>/main.c should tell you. You can also find the sig finder detected value in a comment in stubs_entry.S. There may be some exceptions.

Quote

Code: [Select]
luar click('zoom_in') doesn't always zoom the same number of steps.

Yes, this has been observed before. Some discussion in https://chdk.setepontos.com/index.php?topic=11667.msg117838#msg117838

You might also get bitten by the other issue discussed in that thread: On some cameras, using set_zoom causes the Canon jpeg distortion correction to be applied incorrectly. We have a fix that can be applied in many cases, but it may not be applied to all cameras that need it, and IIRC there can still be some difference with the fix applied.

Quote

Ok, I'll make users stick to A-Z 0-9 Space in paths for now.

You can allow other ASCII symbols if you want (_-+= etc), excluding any the OS disallows of course.

Spaces may be a problem in some contexts, but as long as you've tested that it works it should be fine. For most normal chdkptp commands (download, rs etc), spaces would need to be quoted, but rsint has it's own parsing.

Logged

Don't forget what the H stands for.

nod5

4

Re: set_zoom behavior (was Re: chdkptp - alternative ptp client)

« Reply #4 on: 22 / September / 2018, 15:30:07 »

Quote from: reyalp on 20 / September / 2018, 13:44:57

For most cameras, NUM_FL in platform/<camera>/main.c should tell you. You can also find the sig finder detected value in a comment in stubs_entry.S. There may be some exceptions.

Ok. I quickly extracted this incomplete list of camera zoom range values from the source mirror at https://github.com/c10ud/CHDK

Code: [Select]

a1000 8
a1100 8
a1200 8
a1300 64
a1400 64
a2000 15
a2200 8
a2300 64
a2400 64
a2500 64
a2600 64
a3000 8
a3100 8
a3200 12
a3300 12
a3400 64
a4000 127
a480  7
a490  7
a495  7
a580  8
a590  8
a720  15
a800  7
a810  64
d10 7
d30 129
d20 129
g10 14
g11 14
g12 14
g15 121
g1x 101
g9  14
ixus1000_sd4500 101
ixus100_sd780 7
ixus115_elph100hs 10
ixus110_sd960 10
ixus120_sd940 10
ixus125_elph110hs 64
ixus132_elph115 101
ixus130_sd1400  8
ixus135_elph120 101
ixus140_elph130 101
ixus150_elph140 101
ixus145_elph135 101
ixus160_elph160 101
ixus200_sd980 12
ixus220_elph300hs 64
ixus240_elph320hs 64
ixus230_elph310hs 127
ixus255_elph330hs 101
ixus300_sd4000  64
ixus310_elph500hs 64
ixus80_sd1100 7
ixus85_sd770  7
ixus860_sd870 8
ixus90_sd790  7
ixus95_sd1200 7
ixus960_sd950 8
ixus970_sd890 12
ixus980_sd990 8
s100  121
s110  121
s90 10
s95 10
sx1 6
sx10  6
sx100is 23
sx110is 23
sx120is 23
sx130is 128
sx150is 128
sx160is 127
sx170is 127
sx20  6
sx200is 126
sx210is 126
sx220hs 126
sx230hs 126
sx240hs 101
sx260hs 101
sx280hs 101
sx30  201
sx400is 127
sx410is 122
sx40hs  201
sx500is 127
sx50hs  201
sx510hs 127
sx520hs 195
sx60hs  201
sx530hs 201

A lot of variation! I hope someone with access to a 64 zoom range camera reads this and reports back if it has the problem with two zoom_set_relative(+1) commands in a row described in my first post above, https://chdk.setepontos.com/index.php?topic=6231.msg138146#msg138146

Quote from: reyalp on 20 / September / 2018, 13:44:57

You might also get bitten by the other issue discussed in that thread: On some cameras, using set_zoom causes the Canon jpeg distortion correction to be applied incorrectly. We have a fix that can be applied in many cases, but it may not be applied to all cameras that need it, and IIRC there can still be some difference with the fix applied.

Thanks, didn't know about that issue. Hm, I started out thinking using zoom_set_relative would be a general improvement over click('zoom_in'), but now I'm less sure about that.

Logged

reyalp

14000

Re: set_zoom behavior (was Re: chdkptp - alternative ptp client)

« Reply #5 on: 22 / September / 2018, 16:54:49 »

Quote from: nod5 on 22 / September / 2018, 15:30:07

Ok. I quickly extracted this incomplete list of camera zoom range values from the source mirror at https://github.com/c10ud/CHDK

FWIW, I'd suggest using the official svn: https://subversion.assembla.com/svn/chdk/trunk

That github mirror is not associated with the core CHDK developers and appears not to have been updated since Feb.

Quote

A lot of variation! I hope someone with access to a 64 zoom range camera reads this and reports back if it has the problem with two zoom_set_relative(+1)

Just guess, I'd expect the 64 and up to be affected, and the ones under 20 not. In between, I'd flip a coin

You could also check at runtime like (untested)

Code: [Select]

old_zoom=get_zoom()
set_zoom_rel(1)
if old_zoom == get_zoom() then
 set_zoom_rel(2)
code

You might need some delay after the first set_zoom_rel()

Quote

Thanks, didn't know about that issue. Hm, I started out thinking using zoom_set_relative would be a general improvement over click('zoom_in'), but now I'm less sure about that.

Yeah, there's no obviously "right" solution. Unfortunately, this kind of thing comes up pretty often when you have a hack that covers > 100 platforms spanning over >12 years of hardware.

Logged

Don't forget what the H stands for.

nod5

4

Re: set_zoom behavior (was Re: chdkptp - alternative ptp client)

« Reply #6 on: 24 / September / 2018, 14:24:34 »

Quote from: reyalp on 20 / September / 2018, 13:44:57

You might also get bitten by the other issue discussed in that thread: On some cameras, using set_zoom causes the Canon jpeg distortion correction to be applied incorrectly. We have a fix that can be applied in many cases, but it may not be applied to all cameras that need it, and IIRC there can still be some difference with the fix applied.

I've read the page you linked and some nearby pages such as

the multi-camera thread
https://chdk.setepontos.com/index.php?topic=11667.250
earlier in same thread
https://chdk.setepontos.com/index.php?topic=11667.220
https://chdk.setepontos.com/index.php?topic=11667.230
https://chdk.setepontos.com/index.php?topic=11667.240
a2500 thread
https://chdk.setepontos.com/index.php?topic=10626.140

From what I've read the problem results in images with a kind of fish eye lens like distortion. In other words what should be straight lines are somewhat curved.

The A2500 thread says cameras A2500 and elph130 were affected by the jpeg distortion correction problem after set_zoom

In the A2500 thread waterwingz writes

Quote

I suspect it's something that may affect many other CHDK equipped cameras but has not been noticed yet.

Unfortunately, this might be difficult to fix. The zoom and focus code controlling the lens mechanisms seems to vary a lot between camera models. Most likely somebody will need to do some serious debugging and reverse assembly - perhaps on a per camera basis - and that take time. A lot of time.

Later in the same thread A2500 firmware is reportedly patched in late August 2014.

However in the multicamera thread a user reports the same problem with A2500 in October 2014, apparently after the above mentioned patch was added to the firmware. That makes me unsure about the current status of that patch.

I didn't find any other forum posts about the issue that are more recent or cover other cameras.

Am I missing some additional information/changes between 2014 and now or is that about it? No list of cameras where the problem is confirmed existing / not existing / effectively patched?

Quote from: reyalp on 20 / September / 2018, 13:44:57

Unfortunately, this kind of thing comes up pretty often when you have a hack that covers > 100 platforms spanning over >12 years of hardware.

Yeah, I'm amazed by all the great work you and others here have done to get CHDK/chdkptp to work on so much hardware.

« Last Edit: 24 / September / 2018, 14:26:37 by nod5 »

Logged

reyalp

14000

Re: set_zoom behavior (was Re: chdkptp - alternative ptp client)

« Reply #7 on: 24 / September / 2018, 16:26:07 »

Quote from: nod5 on 24 / September / 2018, 14:24:34

Am I missing some additional information/changes between 2014 and now or is that about it? No list of cameras where the problem is confirmed existing / not existing / effectively patched?

The MoveOpticalZoomAt define was added to a2500 in r3586, on Aug 21 2014.

IIRC, there was some question whether this completely resolves the problem, that is: With the fix applied, does a jpeg taken at a given zoom level set by set_zoom look that same as one taken by setting the same zoom with keys. I'm going from memory here, so it's possible I have something mixed up.

If you want to do a controlled test, I'd suggest rebooting the camera between tests with the different methods.

You can check for CAM_USE_ALT_PT_MoveOpticalZoomAt to see which cameras use this, but but beware that cameras which need it might not have it, and it might have been blindly set on cameras that don't need it.

See around line 200 in generic/wrappers.c for some background https://app.assembla.com/spaces/chdk/subversion/source/HEAD/trunk/platform/generic/wrappers.c#ln186
It's likely that most (if not all) cameras after the ones mentioned there need the workaround.

Logged

Don't forget what the H stands for.