CHDKPTP remotshoot focus - page 3 - General Discussion and Assistance - CHDK Forum

CHDKPTP remotshoot focus

  • 28 Replies
  • 8356 Views
Re: CHDKPTP remotshoot focus
« Reply #20 on: 13 / February / 2021, 14:15:15 »
Advertisements
Whatever distance you want the camera to focus at. -sdmode is a modifier for -sd, not a way of setting the focus mode generally.

The background for this is that SD overrides only work in some modes on some cameras. Some only work in AF, some only work in MF, some have quirks that make one or the other preferable in some situations. By default, -sd will try to pick one defined as working in the port. -sdmode lets you pick instead.

I don' think it's important, but FYI I don't understand what you mean here.

What would it mean to say "-sdmode=AF -sd=100mm"? What would it mean to "autofocus" to a particular focus distance? (It's confusing, but since I'm hoping not to use AF it doesn't really matter to me.)

Quote
If you are using the last released version of chdkptp (r964), -1 in chdkptp shoot commands is broken. It's fixed in SVN, you can update the Lua files from https://app.assembla.com/spaces/chdkptp/subversion/source/HEAD/trunk if you want.

I did download it and have been comparing. There are a LOT of differences.

Which set of Lua files should be updated?

The entire ...\chdkptp-r964-raspbian-gui\chdkptp-r964\lua folder?

From what source? From ...\trunk\lua ?

*

Offline reyalp

  • ******
  • 14137
Re: CHDKPTP remotshoot focus
« Reply #21 on: 13 / February / 2021, 16:59:06 »
I don' think it's important, but FYI I don't understand what you mean here.

What would it mean to say "-sdmode=AF -sd=100mm"? What would it mean to "autofocus" to a particular focus distance? (It's confusing, but since I'm hoping not to use AF it doesn't really matter to me.)
It does not mean autofocus. It means force the focus distance to 100mm, while operating the Canon firmware in AF mode. The Canon firmware can be in MF, AF Lock, or AF mode. Depending on the camera, CHDK can set the focus distance in zero or more of these modes.

In AF mode, what will happen is the camera will auto-focus in half press, and then CHDK will change the focus distance after it's done, before the shot is taken. The only reason to do this is if the other modes aren't supported in the port or have some other undesirable behavior.

Quote
The entire ...\chdkptp-r964-raspbian-gui\chdkptp-r964\lua folder?

From what source? From ...\trunk\lua ?
Yes, copy the entire lua directory from the trunk into your install directory. I would recommend using the entire directory rather than trying to mix and much. I don't think the other changes are likely to impact you, they're mostly related to the optional GTK GUI and tests. There's also some fixes related to remoteshoot, which are more likely to be a benefit than harm.
Don't forget what the H stands for.

Re: CHDKPTP remotshoot focus
« Reply #22 on: 14 / February / 2021, 13:54:19 »
Yes, copy the entire lua directory from the trunk into your install directory. I would recommend using the entire directory rather than trying to mix and much.

OK, I did that. After doing so, I've run some tests today and learned some things.

All of this is re the A640.

1 - set_mf(1) is not necessary to get manual focus if using remoteshoot -sdmode=MF -sd<n>mm

(if you use that remoteshoot command, camera does manual focus regardless of set_mf)

2 - However, set_mf() does affect the result of "=press'shoot_half' repeat sleep(10) until get_shooting() return get_focus()".

If in set_mf(0), that appears to return the correct focus setting value (not actual distance) for the subject.

If in set_mf(1), that appears to return the current focus position (where the lens is now). It doesn't appear to be influenced by the actual subject distance.

3 - Results of experiments with remoteshoot -sdmode=MF -sd=<value>:

With set_mf(0) and set_zoom(0), and subject at infinity (~1000 meters):

=press'shoot_half' repeat sleep(10) until get_shooting() return get_focus()
returns 647 to 746 (may depend on aperture; not sure)

            Infinity           Post-shot
-sd= value  Sharpness (0..10)  get_focus()  Interpretation
  -1mm          0                 10        Focused at 10mm (closest focus?)
   -1           8               1023        Focused at 1.023m?
   65535mm      4              65535        Focus is well past infinity.
   ~700mm       10              ~700        Correct infinity focus.

   
With set_mf(0) and set_zoom(1), and subject at infinity (~1000 meters):

=press'shoot_half' repeat sleep(10) until get_shooting() return get_focus()
returns 65535

            Infinity           Post-shot
-sd= value  Sharpness (0..10)  get_focus()  Interpretation
  -1mm          2               264         Focused at 264mm?
   -1           8               964         Odd.
   65535mm      10              65535       Correct infinity focus.
   ~700mm       5              ~700         Focused near 700mm?


("~700" means any value close to 700 produces visually identical results.)

For my use (landscape images), the bottom line is that the "millimeter" based manual focus doesn't work - I need to make the camera attempt autofocus to get the correct focus setting for the lens. Once I get that, I can re-use that for all shots in the timelapse.

Two other things:

Using chkdkptp_gui, live view display of the viewfinder doesn't seem to work in record mode on the Raspberry Pi at all, or on Windows on about 1 in 3 camera boots (randomly).

It works OK in playback. When it fails (always on the Pi), the viewfinder display shows random-looking pixels. The random-looking pixels do update
to a different set of random-looking pixels after each shot. I can supply screenshots if it's helpful.

Finally, do you think a G-series camera (G9...G12) will produce better .DNG images than the A640?
« Last Edit: 14 / February / 2021, 14:00:54 by Dave92F1 »

*

Offline reyalp

  • ******
  • 14137
Re: CHDKPTP remotshoot focus
« Reply #23 on: 14 / February / 2021, 15:43:51 »
1 - set_mf(1) is not necessary to get manual focus if using remoteshoot -sdmode=MF -sd<n>mm

(if you use that remoteshoot command, camera does manual focus regardless of set_mf)
Correct. One of the things -sdmode=MF does is call set_mf(1)

Quote
2 - However, set_mf() does affect the result of "=press'shoot_half' repeat sleep(10) until get_shooting() return get_focus()".

If in set_mf(0), that appears to return the correct focus setting value (not actual distance) for the subject.

If in set_mf(1), that appears to return the current focus position (where the lens is now). It doesn't appear to be influenced by the actual subject distance.
This is exactly as expected. If the camera is in MF mode, then it shouldn't change the focus in half press, and will return whatever the last focus distance was (caveat: focus may change slightly after actually shooting. Or if "safety MF" is enable on cams that support it/) If it's in AF mode, it will AF, and the above code will return whatever distance it AFed at.

One note of caution, which I probably should have documented or mentioned earlier  :-[: The chdkptp shoot commands do not restore the previous focus mode. So if you do rs -sdmode=MF ... the camera will stay in MF mode until you call set_mf(0) or a different -sdmode


Quote
3 - Results of experiments with remoteshoot -sdmode=MF -sd=<value>:

With set_mf(0) and set_zoom(0), and subject at infinity (~1000 meters):

=press'shoot_half' repeat sleep(10) until get_shooting() return get_focus()
returns 647 to 746 (may depend on aperture; not sure)

            Infinity           Post-shot
-sd= value  Sharpness (0..10)  get_focus()  Interpretation
  -1mm          0                 10        Focused at 10mm (closest focus?)
   -1           8               1023        Focused at 1.023m?
   65535mm      4              65535        Focus is well past infinity.
   ~700mm       10              ~700        Correct infinity focus.

   
With set_mf(0) and set_zoom(1), and subject at infinity (~1000 meters):
Was this done with the r964 Lua files? If so, -1 is just broken and you shouldn't use it. In the current files, -1 and -1mm do *exactly* the same thing.

You can see how the value is interpreted using shoot -pretend -sd=...

Aside from that, I think these results are not unusual. On your camera, at wide angle, 65535 (camera "infinity") goes past the real best infinity focus. It higher zoom, it's closer.

You might find some value in between has slightly better focus. These cameras only have a limited number of focus positions, and don't always land on the same one for a given set_focus value. From A540
Code: [Select]
con 1> =set_mf(1)
con 2> =set_focus(500) return get_focus()
3:return:502
con 3> =set_focus(700) return get_focus()
4:return:693
...
con 18> =set_focus(9000) return get_focus()
19:return:7483
con 19> =set_focus(10000) return get_focus()
20:return:14518
...
con 23> =set_focus(20000) return get_focus()
24:return:14518
con 24> =set_focus(30000) return get_focus()
25:return:65535
...
con 27> =set_focus(20000) return get_focus()
28:return:65535
con 28> =set_focus(18000) return get_focus()
29:return:12347
Note you don't need to do the half press / get_shooting thing if you are in MF.

Quote
Two other things:

Using chkdkptp_gui, live view display of the viewfinder doesn't seem to work in record mode on the Raspberry Pi at all, or on Windows on about 1 in 3 camera boots (randomly).

It works OK in playback. When it fails (always on the Pi), the viewfinder display shows random-looking pixels. The random-looking pixels do update
to a different set of random-looking pixels after each shot. I can supply screenshots if it's helpful.
A screenshot would definitely be helpful.

Quote
Finally, do you think a G-series camera (G9...G12) will produce better .DNG images than the A640?
Really depends what the issue with the A640 DNG is. I'd expect the G series to have somewhat better image quality overall, but often issues people see with DNG are related to how the images are processed.

Most of the Canon G series support native Canon CR2 raw. The raw data is essentially the same as CHDK DNG, but raw processing software often renders CR2 better on default settings.
Don't forget what the H stands for.

Re: CHDKPTP remotshoot focus
« Reply #24 on: 14 / February / 2021, 16:59:34 »
One note of caution, which I probably should have documented or mentioned earlier  :-[: The chdkptp shoot commands do not restore the previous focus mode. So if you do rs -sdmode=MF ... the camera will stay in MF mode until you call set_mf(0) or a different -sdmode

Good to know, and not a problem. I just updated the wiki with that info at https://chdk.fandom.com/wiki/PTP_Extension#About_.27remoteshoot.27

Quote
3 - Results of experiments with remoteshoot -sdmode=MF -sd=<value>

Was this done with the r964 Lua files? If so, -1 is just broken and you shouldn't use it. In the current files, -1 and -1mm do *exactly* the same thing.

No, I did the experiments using the newer Lua files from the trunk.

So I'm a little confused now.

Quote
You can see how the value is interpreted using shoot -pretend -sd=...

Is -pretend documented somewhere? It's new to me.


Quote
Using chkdkptp_gui, live view display of the viewfinder doesn't seem to work in record mode on the Raspberry Pi at all, or on Windows on about 1 in 3 camera boots (randomly).

It works OK in playback. When it fails (always on the Pi), the viewfinder display shows random-looking pixels. The random-looking pixels do update
to a different set of random-looking pixels after each shot. I can supply screenshots if it's helpful.
A screenshot would definitely be helpful.

OK, four screenshots are attached.

These were all taken on the Pi. Each is timestamped (in the filename) with capture time - a few seconds apart.

The first one shows what I saw after connecting to the camera (camera was already in rec mode).

Second one is after taking a picture (pressed 'shoot' button). Note slightly different patterned looking noise.

Third one (see next reply - I can only post 2 attachments per post here) is after switching to play - you can see the image I just took.

Fourth and last one is after pressing "rec" to get back into rec mode.

Quote
Finally, do you think a G-series camera (G9...G12) will produce better .DNG images than the A640?
Really depends what the issue with the A640 DNG is. I'd expect the G series to have somewhat better image quality overall, but often issues people see with DNG are related to how the images are processed.

Actually the quality from the A640 is quite good - I'm happy with it. Just wondering if bidding on a G-series on eBay would be worthwhile.
« Last Edit: 14 / February / 2021, 17:05:01 by Dave92F1 »

Re: CHDKPTP remotshoot focus
« Reply #25 on: 14 / February / 2021, 17:00:34 »
3rd and 4th screenshots attachments.

*

Offline reyalp

  • ******
  • 14137
Re: CHDKPTP remotshoot focus
« Reply #26 on: 14 / February / 2021, 17:46:10 »
No, I did the experiments using the newer Lua files from the trunk.

So I'm a little confused now.
Me too. My first guess would be the newer Lua files were not actually installed in the correct location. If you do "help shoot" what do the lines for -sd and -sdmode say?

Quote
Quote
You can see how the value is interpreted using shoot -pretend -sd=...

Is -pretend documented somewhere? It's new to me.
help shoot
Note this option is only present for "shoot" not remoteshoot. Also, the full help text for all commands is included in USAGE.TXT

Quote
The first one shows what I saw after connecting to the camera (camera was already in rec mode).
Thanks. That definitely looks like the random garbage you see when viewport addresses are incorrect. Looking at the port code, it wouldn't be surprising at all if some of this were wrong.

One question: Is the camera screen on when you see this? If the screen is off, the camera probably doesn't update the display buffers. If you have the screen folded closed face to the camera, please check if behavior is the same with it open.

I would be very surprised if this were really a difference between pi and PC, but could perhaps be explained if the camera screen configuration were different.

Quote
Second one is after taking a picture (pressed 'shoot' button). Note slightly different patterned looking noise.
Note it's normal for the live view to show garbage like this briefly while a shot is in progress, but it definitely shouldn't look like this between shots if the camera live view is active.

Quote
Actually the quality from the A640 is quite good - I'm happy with it. Just wondering if bidding on a G-series on eBay would be worthwhile.
In that case, the difference would just be the general image quality difference between the cameras. You can samples from reviews of that era on sites like dpreview https://www.dpreview.com/products/compare/side-by-side?products=canon_a640&products=canon_g9&products=canon_g10&products=canon_g11&products=canon_g12 (though they likely won't include CHDK raw)
Don't forget what the H stands for.

Re: CHDKPTP remotshoot focus
« Reply #27 on: 26 / February / 2021, 16:28:17 »
Thanks. That definitely looks like the random garbage you see when viewport addresses are incorrect. Looking at the port code, it wouldn't be surprising at all if some of this were wrong.

One question: Is the camera screen on when you see this? If the screen is off, the camera probably doesn't update the display buffers. If you have the screen folded closed face to the camera, please check if behavior is the same with it open.

I finally got to experiment with another A640. Yes, the live viewfinder in rec mode works OK with the screen folded out, but not with the screen folded in.

Along the way I found some other things:

On Linux (Pi), this works OK: chdkptp -c -eremoteshoot "/home/pi/Desktop/"

On Windows, this doesn't work: chdkptp -c -eremoteshoot "c:\\users\\dave\\desktop\\test6"

Result:

Code: [Select]
(base) C:\Users\Dave\data\Projects\Photography - CHDK, CHDK PTP and Magic Lantern\CHDK PTP\chdkptp-r964-win-x86_64>chdkptp -i -eremoteshoot "c:\\users\\dave\\desktop\\test6"
ERROR: unrecognized argument c:\\users\\dave\\desktop\\test6
CHDK PTP control utility
Usage: chdkptp [options]
Options:
 -g  start GUI - default if GUI available and no options given
 -i  start interactive cli
 -c  connect at startup, with optional device spec e.g. -c"-d001 -bbus-0"
 -e  execute cli command, multiple allowed, e.g -e"u DISKBOOT.BIN" -ereboot
 -r  specify startup command file, if no file given skip default startup files
 -h  help
ERROR: not connected

This doesn't work on Windows either: chdkptp -c -eremoteshoot c:\users\dave\desktop\test6

(Same error message, "unrecognized argument".)

Yet, these both work OK on Windows:

chdkptp -i -c

...then...

remoteshoot "c:\\users\\dave\\desktop\\test6"
or
remoteshoot c:\users\dave\desktop\test6

...so:

On Windows, "remoteshoot" requires the escaped backslashes if the path is in double quotes.

It works with or without the escaped backslashes if the path isn't in double quotes (but then there can't be any spaces in the path).

Is there any way to get Windows to do remoteshoot from the Windows command line (using the -e switch)? I haven't found one.

=============

Added:

I found a way to make it work in Windows:

chdkptp -c -e"remoteshoot 'c:\users\dave\desktop\new folder\test2'"

That works. The remoteshoot command MUST be in double quotes. The path MUST be in single quotes if there is a space in the path. Escaped backslashes are not required.
« Last Edit: 26 / February / 2021, 16:40:34 by Dave92F1 »

*

Offline reyalp

  • ******
  • 14137
Re: CHDKPTP remotshoot focus
« Reply #28 on: 26 / February / 2021, 18:13:41 »
I finally got to experiment with another A640. Yes, the live viewfinder in rec mode works OK with the screen folded out, but not with the screen folded in.
Thanks, this make sense. When the screen is folded in, the sensor is off, and you just get whatever random garbage is in the live view framebuffer.


Quote
On Linux (Pi), this works OK: chdkptp -c -eremoteshoot "/home/pi/Desktop/"
This definitely should not work. The path is part of the -e command, so it must be in the same string as remoteshoot, like
-e"remoteshoot /home/pi/Desktop/"
This is described in USAGE.TXT
Quote
When using -e, -c or -r, the values must immediately follow the option, without
any space, e.g. -rmyfile or -r=myfile, not -r myfile. If any arguments include
spaces, they must be quoted.

Quote
On Windows, "remoteshoot" requires the escaped backslashes if the path is in double quotes.
I'd suggest using forward slashes everywhere. They generally work fine on windows (not just in chdkptp), and avoid all the vagaries of backslash escaping.

When you quote on the command line, the outermost quotes are interpreted by the shell (cmd on windows, bash on the pi) before it gets to chdkptp. chdkptp has it's own quoting rules for CLI commands, which are described in USAGE.TXT

Quote
The characters " or ' can be used to quote arguments or switch values that
contain spaces. Inside double quotes "",  backslash \ is treated as an escape
character.

To use a path with a space in it in chdkptp, the value must be quoted by quotes seen by chkdptp.
Don't forget what the H stands for.

 

Related Topics


SimplePortal © 2008-2014, SimplePortal