CHDKPTP remotshoot focus - General Discussion and Assistance - CHDK Forum supplierdeeply

CHDKPTP remotshoot focus

  • 28 Replies
  • 2626 Views
CHDKPTP remotshoot focus
« on: 29 / January / 2021, 11:34:02 »
Advertisements
It seems like sometimes manual focus doesn't work when using remoteshoot.

I'm trying to manually focus at infinity. Most of the time it works, but sometimes it's way, way off. (I'd attach a photo but it's too big - it's a DNG. The photo appears to be focused at about 20 cm from the lens.)

The commands I used for that were (generated by my Python script):

Code: [Select]
./chdkptp.sh -c -e"luar return get_mode()"
./chdkptp.sh -c -e"rec"
./chdkptp.sh -c -e"luar return get_mode()"
./chdkptp.sh -c -e"clock -sync -utc"
./chdkptp.sh -c -e"luar return set_capture_mode(5)"
./chdkptp.sh -c -e"luar return set_prop(5, 1)"
./chdkptp.sh -c -e"luar return set_prop(16, 2)"
./chdkptp.sh -c -e"luar return set_mf(1)"
./chdkptp.sh -c -e"luar return get_zoom_steps()"
./chdkptp.sh -c -e"luar return iso_market_to_real(80)"
./chdkptp.sh -c -e"luar return set_zoom_speed(100)"
./chdkptp.sh -c -e"luar return set_zoom(2)"
./chdkptp.sh -c -e"luar return get_max_av96()"
./chdkptp.sh -c -e"luar return get_min_av96()"
./chdkptp.sh -c -e"luar return set_iso_mode(5)"
./chdkptp.sh -c -e"luar return iso_market_to_real(800)"
./chdkptp.sh -c -e"luar return set_iso_mode(1)"
./chdkptp.sh -c -e"luar return iso_market_to_real(80)"
./chdkptp.sh -c -e'remoteshoot "/home/pi/Desktop/tl_images/2021-01-29 16h10m00s BIP (600s)_ec-2.0_ISO49_Uv+0.00_Bv+6.85" -dng -u=96 -tv=847 -av=384 -sv=381 -sd=2147483647mm'

(Note that 2147483647 is sys.maxint in 32 bit Python; I've been using that for "infinity".)
« Last Edit: 29 / January / 2021, 11:35:53 by Dave92F1 »

*

Offline reyalp

  • ******
  • 13440
Re: CHDKPTP remotshoot focus
« Reply #1 on: 29 / January / 2021, 13:10:48 »
It seems like sometimes manual focus doesn't work when using remoteshoot.
You're using A640 right?

One thing that comes to mind is on old cameras like this, if the camera goes into display off mode (either from using the display button, or power saving settings), the Canon firmware turns MF mode off.

You can try using -sdmode=MF in your remoteshoot commend, instead of setting MF separately.

The other thing I'd suggest trying to test is whether the camera actually using the SD override at all, or it's actually doing AF and the focus just happens to come out right most of the time. You can test this by putting something in the center of the field of view close to the camera, and then shooting at infinity. Or take a series of shots at different focus distances, like 10mm, 1000mm, 10000mm

FWIW, using python maxint should probably be OK, but you can also use -1mm for infinity (edit: actually, looking at the code, this probably doesn't work in remote shoot, use a large value).

Quote
I'm trying to manually focus at infinity. Most of the time it works, but sometimes it's way, way off. (I'd attach a photo but it's too big - it's a DNG. The photo appears to be focused at about 20 cm from the lens.)
The DNG isn't likely to help, but in any case, you could put it on a file hosting site like dropbox, google drive etc.
« Last Edit: 29 / January / 2021, 13:15:03 by reyalp »
Don't forget what the H stands for.

Re: CHDKPTP remotshoot focus
« Reply #2 on: 29 / January / 2021, 14:51:26 »
It seems like sometimes manual focus doesn't work when using remoteshoot.
You're using A640 right?

Correct.

Quote
One thing that comes to mind is on old cameras like this, if the camera goes into display off mode (either from using the display button, or power saving settings), the Canon firmware turns MF mode off.

You can try using -sdmode=MF in your remoteshoot commend, instead of setting MF separately.

Thanks. I'll try that.

BTW, in the command list in my other post I left one out:

Code: [Select]
./chdkptp.sh -c -e"luar press('shoot_half') repeat sleep(10) until get_shooting() return get_bv96()"
That goes just before the 'remoteshoot'. I use the bv96 value to calculate the exposure.

Quote
The DNG isn't likely to help, but in any case, you could put it on a file hosting site like dropbox, google drive etc.

OK, here are Google Drive links:

This one focused at "65.5 meters" (as it ought):
https://drive.google.com/file/d/19lIemfpM5HaRlJMRSVlSiVsV3bA6Oo99/view?usp=sharing

This one focused at 0.314 meters (exact same command line except for exposure values):
https://drive.google.com/file/d/19pXm1KmxiWVMasb7SZh0DbJaIRWA1y6-/view?usp=sharing

(Sorry, photo subjects are extremely boring; I promise prettier ones once I get this all working.)

BTW...any advice on dealing with hot pixels in the DNG files? I see the Canon JPG firmware takes care of it nicely, but I don't have access to the hot pixel list the firmware seems to be using internally.
« Last Edit: 29 / January / 2021, 15:07:38 by Dave92F1 »

*

Offline reyalp

  • ******
  • 13440
Re: CHDKPTP remotshoot focus
« Reply #3 on: 01 / February / 2021, 18:15:27 »
OK, here are Google Drive links:

This one focused at "65.5 meters" (as it ought):
https://drive.google.com/file/d/19lIemfpM5HaRlJMRSVlSiVsV3bA6Oo99/view?usp=sharing

This one focused at 0.314 meters (exact same command line except for exposure values):
https://drive.google.com/file/d/19pXm1KmxiWVMasb7SZh0DbJaIRWA1y6-/view?usp=sharing
What specific command and settings generated each shot?

I would strongly encourage you to narrow this down the simplest possible test case. The first thing we want to know is: Does set_mf() successfully put the camera in MF mode?
If so, you should be able to do set_mf(1) and then, watching chdkptp live view or the camera screen, see the focus change immediately as you call set_focus() with various values. If this works, shoot and verify that the same focus you set beforehand continues to be used.

If set_mf is broken, then it's a bug in the port that can potentially be fixed. If set_mf is working, but your script is still producing random out of focus pics, more debugging is needed (but my first guess would be the screen off issue mentioned earlier)

Quote
BTW...any advice on dealing with hot pixels in the DNG files? I see the Canon JPG firmware takes care of it nicely, but I don't have access to the hot pixel list the firmware seems to be using internally.
Are they really hot pixels, or are they 0 value? The Canon firmware sets (some) bad pixels to 0. They will generally show up as points of saturated color in DNG, since usually only one of the R G B color elements is 0.

For this case, you can use the -badpix option in your remoteshoot command. You can also fix them after the fact with the dngmod command.

If it's actually hot pixels (rarer, but more frequent with long exposures) You can make a list CHDK badpixel.txt list with chdkptp dnglistpixels, see https://app.assembla.com/spaces/chdkptp/wiki/DNG_Processing
 and https://chdk.fandom.com/wiki/CHDK_1.5_User_Manual#Manual_bad_pixel_removal
Don't forget what the H stands for.


Re: CHDKPTP remotshoot focus
« Reply #4 on: 01 / February / 2021, 20:18:04 »
What specific command and settings generated each shot?

The same as I listed above, except for exposure variations (the values for -tv -av and -sv). So:

Code: [Select]
./chdkptp.sh -c -e"luar return get_mode()"
./chdkptp.sh -c -e"rec"
./chdkptp.sh -c -e"luar return get_mode()"
./chdkptp.sh -c -e"clock -sync -utc"
./chdkptp.sh -c -e"luar return set_capture_mode(5)"
./chdkptp.sh -c -e"luar return set_prop(5, 1)"
./chdkptp.sh -c -e"luar return set_prop(16, 2)"
./chdkptp.sh -c -e"luar return set_mf(1)"
./chdkptp.sh -c -e"luar return get_zoom_steps()"
./chdkptp.sh -c -e"luar return iso_market_to_real(80)"
./chdkptp.sh -c -e"luar return set_zoom_speed(100)"
./chdkptp.sh -c -e"luar return set_zoom(2)"
./chdkptp.sh -c -e"luar return get_max_av96()"
./chdkptp.sh -c -e"luar return get_min_av96()"
./chdkptp.sh -c -e"luar return set_iso_mode(5)"
./chdkptp.sh -c -e"luar return iso_market_to_real(800)"
./chdkptp.sh -c -e"luar return set_iso_mode(1)"
./chdkptp.sh -c -e"luar return iso_market_to_real(80)"
./chdkptp.sh -c -e"luar press('shoot_half') repeat sleep(10) until get_shooting() return get_bv96()"
./chdkptp.sh -c -e'remoteshoot "/home/pi/Desktop/tl_images/2021-01-29 16h10m00s BIP (600s)_ec-2.0_ISO49_Uv+0.00_Bv+6.85" -dng -u=96 -tv=847 -av=384 -sv=381 -sd=2147483647mm'

Everything above except the last two lines is done once on camera boot, then not again.
The last two lines are done in a loop on every exposure. (I calculate -av -tv and -sv based on the get_bv96() reading.)

However the focus problem hasn't recurred since I added -sdmode=MF to the command line, so I consider this problem solved for myself.

Quote
Does set_mf() successfully put the camera in MF mode?
If so, you should be able to do set_mf(1) and then, watching chdkptp live view or the camera screen, see the focus change immediately as you call set_focus() with various values.

It doesn't seem to. Maybe because it's not half-pressed yet.

But -sdmode=MF works (or seems to so far), so I'm happy.

Quote
Are they really hot pixels, or are they 0 value? The Canon firmware sets (some) bad pixels to 0. They will generally show up as points of saturated color in DNG, since usually only one of the R G B color elements is 0.

They're points of saturated color - so maybe not real hot pixels.

Quote
For this case, you can use the -badpix option in your remoteshoot command.

I saw that in the documentation, but it says the default is 0 and the pixels weren't black so I didn't think it was useful without knowing the actual luminance values. But perhaps it's per channel (RGB)? I'll give it a try.

Quote
If it's actually hot pixels (rarer, but more frequent with long exposures) You can make a list CHDK badpixel.txt list with chdkptp dnglistpixels, see https://app.assembla.com/spaces/chdkptp/wiki/DNG_Processing
 and https://chdk.fandom.com/wiki/CHDK_1.5_User_Manual#Manual_bad_pixel_removal

Thanks; I haven't see that yet but I'm doing 15 second exposure at night (with the automatic dark frame subtraction turned on) so maybe I will.

I'm saving DNGs so I can fix this stuff in post-processing anyway. But the -badpix hint is useful - I'll try it.

*

Offline reyalp

  • ******
  • 13440
Re: CHDKPTP remotshoot focus
« Reply #5 on: 01 / February / 2021, 22:51:36 »
Everything above except the last two lines is done once on camera boot, then not again.
The last two lines are done in a loop on every exposure. (I calculate -av -tv and -sv based on the get_bv96() reading.)
OK, so you were doing set_mf() once at startup, and than a half press and shoot. What interval are the shots taken at?

The other stuff in your script shouldn't matter for focus.
FWIW you can use the propcase module to make it easier to see at glance what prop calls are doing, and also make them more portable. Instead of set_prop(5, 1) you'd use
Code: [Select]
./chdkptp.sh -c -e"luar return set_prop(require'propcase'.WB_MODE, 1)"

Quote
Quote
Does set_mf() successfully put the camera in MF mode?
If so, you should be able to do set_mf(1) and then, watching chdkptp live view or the camera screen, see the focus change immediately as you call set_focus() with various values.

It doesn't seem to. Maybe because it's not half-pressed yet.
Did you test as I suggested? set_mf(1) should take effect immediately, without requiring a half press, and calling set_focus() after that should update focus immediately. It should be really obvious, if you do
=set_mf(1)
=set_focus(100)
=set_focus(10000)
and watch the camera screen when you do the set_focus commands.
Quote
But -sdmode=MF works (or seems to so far), so I'm happy.
If set_mf is broken, then it's virtually certain -sdmode=MF is also broken.

Quote
Quote
For this case, you can use the -badpix option in your remoteshoot command.

I saw that in the documentation, but it says the default is 0 and the pixels weren't black so I didn't think it was useful without knowing the actual luminance values. But perhaps it's per channel (RGB)? I'll give it a try.
Yes, it operates on raw pixels individually.

If you use
Code: [Select]
set cli_verbose=2
before shooting, it will tell you how many pixels were patched. dngmod also reports this.
Don't forget what the H stands for.

Re: CHDKPTP remotshoot focus
« Reply #6 on: 02 / February / 2021, 14:40:02 »
OK, so you were doing set_mf() once at startup, and than a half press and shoot. What interval are the shots taken at?

10 minutes.

To be completely clear, I did the half-press in one "luar" command, then remoteshoot in another command. So the half-press was, I think, released when the remoteshoot happened.

Quote
Did you test as I suggested? set_mf(1) should take effect immediately, without requiring a half press, and calling set_focus() after that should update focus immediately. It should be really obvious, if you do
=set_mf(1)
=set_focus(100)
=set_focus(10000)
and watch the camera screen when you do the set_focus commands.

I have tested that now. Nothing happens. I think it's in auto-focus all the time (A640).

Quote
If set_mf is broken, then it's virtually certain -sdmode=MF is also broken.


Yes, it seems to be broken. I tried this, with the camera pointed at objects about 500mm away:

Code: [Select]
> luar return set_mf(1)
> remoteshoot "c:\\users\\dave\\desktop\\test500"  -sd=500mm
> remoteshoot "c:\\users\\dave\\desktop\\test50000"  -sd=50000mm
> remoteshoot "c:\\users\\dave\\desktop\\test50000MF"  -sdmode=MF -sd=50000mm

All 3 images look identical - all in focus (the last two shouldn't be).

I'm attaching the last one, slightly re-compressed in Photoshop to keep it under 2MBytes. (BTW, know any way to get rid of those vertical lines in the image - I have 1 of 3 cameras that does this sometimes...something wrong with it, I think.)
« Last Edit: 02 / February / 2021, 14:50:10 by Dave92F1 »

*

Offline reyalp

  • ******
  • 13440
Re: CHDKPTP remotshoot focus
« Reply #7 on: 02 / February / 2021, 16:10:47 »
10 minutes.
Does the camera screen turn off between shots? Or do you have it turned off before running script?

Quote
To be completely clear, I did the half-press in one "luar" command, then remoteshoot in another command. So the half-press was, I think, released when the remoteshoot happened.
Any keys pressed with lua press are automatically released at the end of the script. It's possible the if the commands close enough to together the Canon firmware won't have fully responded to the release, but I don't think this is likely to cause an issue.

Quote
I have tested that now. Nothing happens. I think it's in auto-focus all the time (A640).
OK, can you try the same thing with set_aflock(1) instead of set_mf? If that works, should be able to use -sdmode=AFL instead of -sdmode=MF

Also, please try the same sequence again, with
Code: [Select]
post_levent_for_npt('PressSW1andMF')
instead of set_mf. Please restart the camera between tests, to be sure the effects of the previous one don't confuse the results.

Quote
(BTW, know any way to get rid of those vertical lines in the image - I have 1 of 3 cameras that does this sometimes...something wrong with it, I think.)
My guess would be dying hardware, probably sensor electronics related. So, replace the camera, or if you have others for parts you could try mixing matching.

A stuck open mechanical shutter is another aging failure that can cause streaky artifacts, but your image looks different from what I'd expect in that case.
Don't forget what the H stands for.


Re: CHDKPTP remotshoot focus
« Reply #8 on: 03 / February / 2021, 22:59:53 »
10 minutes.
Does the camera screen turn off between shots? Or do you have it turned off before running script?

I'm running on AC power so have made no special effort to turn off the screen. However it's usually turned in to face the camera (so turns itself off; at least the backlight).

"Display off" is set to 3 minutes (which I think is the default).

However the failure to manually focus happened even with test shots taken within a few seconds of each other - display on all the time.

Quote
OK, can you try the same thing with set_aflock(1) instead of set_mf? If that works, should be able to use -sdmode=AFL instead of -sdmode=MF

Yes! That seems to work. In fact if I run the GUI and do set_aflock(1), then calls to set_focus() immediately change the focus on the live view.

That didn't seem to happen with set_mf(1).

Yet...today I tried it again and set_mf(1) seems to work. If I watch the liveview in the GUI, set_focus(1) and set_focus(10000) have obvious effect. I tried with both A640s I have here - same on both.

Today set_aflock(1) and set_mf(1) seem to both work (identically).

Quote
Also, please try the same sequence again, with
Code: [Select]
post_levent_for_npt('PressSW1andMF')
instead of set_mf. Please restart the camera between tests, to be sure the effects of the previous one don't confuse the results.

I did try:

Code: [Select]
> luar return set_prop(16, 2)
> luar return post_levent_for_npt('PressSW1andMF')
ERROR: :101: bad event name 'PressSW1andMF'
user code: 1
> post_levent_for_npt('PressSW1andMF')
ERROR: unknown command 'post_levent_for_npt'

I'm not sure what you were trying to do there.

Anyway, MF seems to be working OK now. I don't know what was going on before. (In practice I'm shooting a landscape timelapse from a fixed position, so autofocus ought to focus to infinity anyway.)

-------

This is really strange. I was testing things while drafting this post, and it took another misfocused image using:

remoteshoot "c:\\users\\dave\\Desktop\\testINF" -sdmode=MF -sd=2147483647mm

I'm going to play with it more to see if I can get it to do something reproducibly - will post later if I learn more.

*

Offline reyalp

  • ******
  • 13440
Re: CHDKPTP remotshoot focus
« Reply #9 on: 03 / February / 2021, 23:40:15 »
I'm running on AC power so have made no special effort to turn off the screen. However it's usually turned in to face the camera (so turns itself off; at least the backlight).

"Display off" is set to 3 minutes (which I think is the default).

However the failure to manually focus happened even with test shots taken within a few seconds of each other - display on all the time.
The screen being turned in might affect MF behavior, but as long as the manual tests were done with it one, you've confirmed that set_mf is broken.


Quote
Quote
Also, please try the same sequence again, with
Code: [Select]
post_levent_for_npt('PressSW1andMF')
instead of set_mf. Please restart the camera between tests, to be sure the effects of the previous one don't confuse the results.

I did try:

Code: [Select]
> luar return set_prop(16, 2)
> luar return post_levent_for_npt('PressSW1andMF')
ERROR: :101: bad event name 'PressSW1andMF'
user code: 1
> post_levent_for_npt('PressSW1andMF')
ERROR: unknown command 'post_levent_for_npt'

I'm not sure what you were trying to do there.
Woops, my fault, I didn't check that before I posted. It's case sensitive and should be
Code: [Select]
luar post_levent_for_npt('PressSw1AndMF')
This is used as an alternate implementation of set_mf() on some ports.

Quote
Anyway, MF seems to be working OK now. I don't know what was going on before. (In practice I'm shooting a landscape timelapse from a fixed position, so autofocus ought to focus to infinity anyway.)
I would like to understand what's wrong with the port, and fix it if possible.

Quote
-------

This is really strange. I was testing things while drafting this post, and it took another misfocused image using:

remoteshoot "c:\\users\\dave\\Desktop\\testINF" -sdmode=MF -sd=2147483647mm

I'm going to play with it more to see if I can get it to do something reproducibly - will post later if I learn more.
Not sure if it's a mispaste, but the above still has -sdmode=MF (which we appear to have verified as broken), not -sdmode=AFL
Don't forget what the H stands for.

 

Related Topics