chdkptp - alternative ptp client - page 82 - General Discussion and Assistance - CHDK Forum supplierdeeply

chdkptp - alternative ptp client

  • 1097 Replies
  • 388436 Views
*

Offline KNEi

  • *
  • 37
  • sx230hs
Re: alternative ptp client
« Reply #810 on: 07 / June / 2015, 03:57:46 »
Advertisements
I suppose this error doesn't connect with CHDK. Something was wrong with camera settings, but I don't know what it could be. Anyway this error can be corrected by restoration to factory settings.

Re: alternative ptp client
« Reply #811 on: 30 / June / 2015, 18:26:27 »
I'm having problems running chdkptp with my A3200IS.

The 1.00C is running just fine but the 1.00A fails to initialize rsint. (error: init failed)

After looking at the code, I noticed that this error is thrown by:

Code: [Select]
if not init_usb_capture(opts.fformat,opts.lstart,opts.lcount) thenBut I'm not very familiar with lua or this level of programming so I'm not sure what to do with that. :\

Has anyone experienced this as well? Any suggestions on how this can be fixed?

Additional background information:
I'm trying to use TwoCamControl or Spreads for a DIY Book Scanner. One of the cameras (C) seems to work just fine, while the other one (A) continues to give errors.

*

Offline reyalp

  • ******
  • 13391
Re: alternative ptp client
« Reply #812 on: 01 / July / 2015, 00:45:26 »
I'm having problems running chdkptp with my A3200IS.

The 1.00C is running just fine but the 1.00A fails to initialize rsint. (error: init failed)

After looking at the code, I noticed that this error is thrown by:

Code: [Select]
if not init_usb_capture(opts.fformat,opts.lstart,opts.lcount) then
The two ports should work the same, but camera settings may be a factor. For example:
1) You requested raw, and raw doesn't work in the current capture mode (for example "low light" or "auto" on some cameras)
2) The canon firmware is set to continuous mode, but CHDK has known problems with remote capture and continuous mode on that camera. I think this applies to to a3200

If neither of those is it, make sure you are using the same CHDK version on each camera.
Don't forget what the H stands for.

Re: alternative ptp client
« Reply #813 on: 08 / July / 2015, 20:55:04 »
Here's a quick hack that might help. Just replace the existing  lua/gui_live.lua from chdkptp with the attached.

It adds a new sub-tab where the frame rate and debug tabs are called "onion"

The "grab" button makes a copy of whatever is currently displayed.  The grabbed image is blended with the live display, with the amount controlled by the slider. All the way to the left shows only the live image, all the way to the right shows only the grabbed image.
Is this already in the latest version or do I have to do a manual patch?
Does the live view always blend with the previous grab or it's possible to specify an image?
I'm thinking of the (very popular) re-enact photos  :-)  In that case I want to blend the live view with an old photo.


*

Offline reyalp

  • ******
  • 13391
Re: alternative ptp client
« Reply #814 on: 08 / July / 2015, 22:40:40 »
Is this already in the latest version or do I have to do a manual patch?
It's a one-off hack, not included in chdkptp at the moment. I might include it at some point, but it seemed like something with very limited interest.
Quote
Does the live view always blend with the previous grab or it's possible to specify an image?
I'm thinking of the (very popular) re-enact photos  :-)  In that case I want to blend the live view with an old photo.
In the existing code, you cannot load an image from your PC. If the old images is on your camera as a jpeg, you could "grab" it in playback mode. As long as you turn off "autograb" you can take as many shots as you want after that.
Don't forget what the H stands for.

Re: alternative ptp client
« Reply #815 on: 14 / July / 2015, 10:15:36 »
Hi,

I'm trying to script liveview+remote shoot/capture (ie: shoot and somehow grab the result), but I have issues.

Regarding the message below:

I tried with Linux: 3.19.2-1-ARCH #1 SMP PREEMPT Wed Mar 18 16:21:02 CET 2015 x86_64 GNU/Linux
..and also under Windows 7
Under linux, it's quite likely that you will have problems with some other programs automatically accessing the camera on connect. There is some information in the "interactions with default software" section on https://www.assembla.com/spaces/chdkptp/wiki/Install

Again
Quote
2) Does the physical camera screen go black
This would happen when you plug in the camera. If it happens, then you  almost certainly have the problem above.

In any case, this probably isn't your whole problem, because windows 7 generally doesn't have the same issue.

There is another problem some vxworks cams suffer from. Can you try the following in the chdkptp console
Code: [Select]
=set_levent_script_mode(1)
=set_levent_active(0x10a5,0)
=switch_mode_usb(1)
If this works, we can fix it in the CHDK code.

I'm having similar issues.

* The setup:
Ubuntu 14.04
Powershot SX260HS with CHDK 1.3
chdkptp version reports: chdkptp 0.5.0-alpha, host:2.6, cam:2.6
(I can give more details if necessary)

* The issue:
I'm trying to do remote shooting, but it is extremely unstable, and behaviour does not seem deterministic. I got it to work maybe 2 times on more than 50 tries.
I tried with:

   chdkptp.sh -c -e'rec' -e'shoot'
   chdkptp.sh -c -e'rec' -e'rs'

and also from Python, using chdkptp.py (version 0.1.2)

   import chdkptp
   camera = chdkptp.ChdkDevice(chdkptp.list_devices()[0])
   camera.switch_mode('record')
   camera.shoot()

The error messages vary, "I/O error, attempted to close a non-present device 002:017", and maybe another one.
The camera seems to crash (it disappears from USB, 'lsusb' does not show it anymore)
With python, the error messages are usually "767" (similar to these ones https://github.com/DIYBookScanner/spreads/issues/166 or 173)


I tried the instructions above (set_levent... etc.) but when doing:
   =switch_mode_usb(1)
I get:
   ERROR: :80: attempt to call global 'switch_usb_mode' (a nil value)
   user code: 1

I've checked the udev rules and the should be nothing interfering with the camera, however, the camera screen does turns black when I plug it.
Nevertheless, I am able to do live view and that works fine, it is just the remote capture/shooting that fails.

While there are a few examples on live view on chdkptp's USAGE.txt I have not found much information about remote shooting.

Also, according to this:

   https://github.com/c10ud/CHDK/blob/master/platform/sx260hs/platform_camera.h

and an earlier message on this thread, the sx260hs should support remote shooting.

Does anybody knows what am I missing? Is remote shooting unstable?

Thanks!

*

Offline srsa_4c

  • ******
  • 4426
Re: alternative ptp client
« Reply #816 on: 14 / July / 2015, 11:21:25 »
I've checked the udev rules and the should be nothing interfering with the camera, however, the camera screen does turns black when I plug it.
Disabling the gphoto2 gvfs volume monitor did the trick for me on opensuse (I have revoked file permissions from /usr/share/gvfs/remote-volume-monitors/gphoto2.monitor).

*

Offline reyalp

  • ******
  • 13391
Re: alternative ptp client
« Reply #817 on: 14 / July / 2015, 15:53:15 »
I'm trying to script liveview+remote shoot/capture (ie: shoot and somehow grab the result), but I have issues.
By "grab" do you just mean save the file, or onion skinning like  KNEi?
Quote
I'm having similar issues.
I don't think your issue is very similar to the post you quoted, but there are some question in my reply that would help be sure.

Your camera is not a vxworks camera, so that stuff doesn't apply.
Quote
* The setup:
Ubuntu 14.04
Powershot SX260HS with CHDK 1.3
chdkptp version reports: chdkptp 0.5.0-alpha, host:2.6, cam:2.6
(I can give more details if necessary)
Since no svn revision is shown, I assume this is self built? If so, including the actual svn revision used might be helpful. Also whether you built with Lua 5.1 or 5.2 (ver -l will say).

Quote
I'm trying to do remote shooting, but it is extremely unstable, and behaviour does not seem deterministic. I got it to work maybe 2 times on more than 50 tries.
I tried with:

   chdkptp.sh -c -e'rec' -e'shoot'
   chdkptp.sh -c -e'rec' -e'rs'
I would suggest using chdkptp interactively until you get a sequence of steps that works, and then try to turn it into a command line.

My first guess would be that there needs to be some additional delay between switching to rec and shooting. You can insert a 100 millisecond delay in chdkptp with -e'exec sys.sleep(100)'. rec tries to wait for the mode switch to complete, but it wouldn't be surprising if a small additional delay was needed.

The fact that you can connect at all and sometimes can shoot probably means you are *not* suffering from the gvfs related problems.

Quote
The error messages vary, "I/O error, attempted to close a non-present device 002:017", and maybe another one.
The "attempted to close..." just means the camera went away probably due to the crash. I/O error probably means the same thing.

Quote
I tried the instructions above (set_levent... etc.) but when doing:
   =switch_mode_usb(1)
I get:
   ERROR: :80: attempt to call global 'switch_usb_mode' (a nil value)
   user code: 1
If that error message is a direct copy/paste, it appears there was a typo, the correct function name is switch_mode_usb not switch_usb_mode.

As noted above, the vxworks stuff does not apply to your cameras, so there's no need to try the post_levent etc.

Quote
Nevertheless, I am able to do live view and that works fine, it is just the remote capture/shooting that fails.
Does it only fail when you attempt to do it directly in the command line? Or does it fail if you launch the gui, switch to rec, and then use rs?
Don't forget what the H stands for.


Re: alternative ptp client
« Reply #818 on: 15 / July / 2015, 03:16:02 »
I've checked the udev rules and the should be nothing interfering with the camera, however, the camera screen does turns black when I plug it.
Disabling the gphoto2 gvfs volume monitor did the trick for me on opensuse (I have revoked file permissions from /usr/share/gvfs/remote-volume-monitors/gphoto2.monitor).

Thanks for the tip.
Actually I had done that (ie: chmod -x the file you mention) because I am also scripting PTP with gphoto2 to control a DSLR on the same computer.
I had also used gsettings as shown here:

https://github.com/markvdb/diybookscanner/issues/12

However, since you mentioned this, I investigated more and did found that gvfs was indeed launching every time I plugged the camera.
Since all the above solutions had not disabled it, I just removed /usr/share/gvfs/remote-volume-monitors/gphoto2.monitor

After that the screen of the SX260HS stopped turning black! yay!
Now I get past the remote shooting, but the camera crashes further down. I will make a new post with more details.

Thanks a lot!

Re: alternative ptp client
« Reply #819 on: 15 / July / 2015, 03:54:09 »
I'm trying to script liveview+remote shoot/capture (ie: shoot and somehow grab the result), but I have issues.
By "grab" do you just mean save the file, or onion skinning like  KNEi?

I mean save the file.
I guess I could do the onion skinning with some ImageMagick commands.

Quote
I'm having similar issues.
I don't think your issue is very similar to the post you quoted, but there are some question in my reply that would help be sure.

Your camera is not a vxworks camera, so that stuff doesn't apply.

In that case I'm sorry for creating confusion.

Quote
* The setup:
Ubuntu 14.04
Powershot SX260HS with CHDK 1.3
chdkptp version reports: chdkptp 0.5.0-alpha, host:2.6, cam:2.6
(I can give more details if necessary)
Since no svn revision is shown, I assume this is self built? If so, including the actual svn revision used might be helpful. Also whether you built with Lua 5.1 or 5.2 (ver -l will say).

Yes, I built it myself.
svn info reports:
Last Changed Author: reyalp
Last Changed Rev: 668
and ver -l reports Lua 5.2

Quote
I'm trying to do remote shooting, but it is extremely unstable, and behaviour does not seem deterministic. I got it to work maybe 2 times on more than 50 tries.
I tried with:

   chdkptp.sh -c -e'rec' -e'shoot'
   chdkptp.sh -c -e'rec' -e'rs'
I would suggest using chdkptp interactively until you get a sequence of steps that works, and then try to turn it into a command line.


Actually my goal is to use a python wrapper (chdkptp.py https://pypi.python.org/pypi/chdkptp.py/0.1.2 ) because in that case I don't need to save the live view images to disk nor spawn a process for each frame of the live view.
The live view part seems to be working just fine by the way (with the python wrapper or with chdkptp CLI).

My first guess would be that there needs to be some additional delay between switching to rec and shooting. You can insert a 100 millisecond delay in chdkptp with -e'exec sys.sleep(100)'. rec tries to wait for the mode switch to complete, but it wouldn't be surprising if a small additional delay was needed.

Thanks, I will try that as well.

The fact that you can connect at all and sometimes can shoot probably means you are *not* suffering from the gvfs related problems.

Actually, it seems that I did. I mean, gvfs was indeed launched every time I plugged the camera, so the measures I had taken to disable it had not worked.
After more drastic measures regarding gvfs I now see that the camera screen does not turns black when plugging it to the computer and the remote shooting is more consistent now. I have another issue though. See further below.

Quote
The error messages vary, "I/O error, attempted to close a non-present device 002:017", and maybe another one.
The "attempted to close..." just means the camera went away probably due to the crash. I/O error probably means the same thing.

Quote
I tried the instructions above (set_levent... etc.) but when doing:
   =switch_mode_usb(1)
I get:
   ERROR: :80: attempt to call global 'switch_usb_mode' (a nil value)
   user code: 1
If that error message is a direct copy/paste, it appears there was a typo, the correct function name is switch_mode_usb not switch_usb_mode.

As noted above, the vxworks stuff does not apply to your cameras, so there's no need to try the post_levent etc.

Ok, I see. Thanks for the explanations.
By the way, if when plugging each and every camera the screen should not turn black for chdkptp to work, what do you think about writing that somewhere (maybe it is, though I did not see it) as a basic debug step?

Quote
Nevertheless, I am able to do live view and that works fine, it is just the remote capture/shooting that fails.
Does it only fail when you attempt to do it directly in the command line? Or does it fail if you launch the gui, switch to rec, and then use rs?

I did not build the GUI because it required more dependencies.
As I stated a bit earlier, after getting rid of gvfs I get more consistent behaviour.
However, the camera is still crashing, when changing to 'record' mode again. The led blinks periodically and chdkptp.sh -c -i reports:

open_camera_dev_usb: ptp_opensession failed 0x2ff
Device status OK
connected: Canon Powershot SX260 HS, max packet size 512
con> rec
ERROR: a script is already running

I need to remove the battery to fix the camera crash.

The sequence is the following:

1) connect
2) enter record mode
3) grab some live view images
4) shoot
5) enter playback mode (I do this to save power)
6) sleep for a while
7) go to 2)

Currently going back to 2) fails (ie: the python call never returns)

The steps above should be very similar to what chdkptp's GUI does, right? Or am I missing some obvious step?

One more question, do you guys suggest to disable all powersaving (ie: auto turn off or whatever) on the camera before attempting any of the above? Because sometimes the live view does not work properly (ie: it's not live) and it seems it is because the camera shuts down the sensor (chdkptp connection seems alive, and a physical half press will automatically resume live view)

Thanks a lot in advance!

 

Related Topics