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

chdkptp - alternative ptp client

  • 1106 Replies
  • 438215 Views
Re: alternative ptp client
« Reply #210 on: 23 / July / 2012, 17:46:37 »
Advertisements
I wasn't sure if this should go into a separate thread or not - but here goes:

I am a developer of open-source software for controlling microscopes:
www.endrov.net
www.micro-manager.org

There is some interest in being able to use consumer grade cameras instead of the very expensive regular cameras. I wonder if I should build this on chdkptp or not? Can it be used as a library from my C code, or would you agree if we make it such that it can be used both as a library, and a CLI/GUI?

Our requirements are very specific - we want to have a well-performing live view, with the ability to change camera settings now and then. All the storage and processing will be on the computer side. How optimized is the library for this currently e.g. is it possible to download one frame while capturing the next? (is this possible to implement at all otherwise?)

Sorry for the n00bish approach - I don't yet own a canon camera I can play around with

/Johan

*

Offline reyalp

  • ******
  • 13745
Re: alternative ptp client
« Reply #211 on: 24 / July / 2012, 00:27:08 »
Interesting project.
There is some interest in being able to use consumer grade cameras instead of the very expensive regular cameras. I wonder if I should build this on chdkptp or not? Can it be used as a library from my C code, or would you agree if we make it such that it can be used both as a library, and a CLI/GUI?
It currently isn't a library, but it has always been my intention split out the PTP code into a one. It's pretty modular already, the C code just provides a low level API and all of the cli and gui code is in Lua. The lua code is broken into modules that provide higher level functions for dealing with the camera, handling the CLI, GUI and so on.

If you only want to use the C code, you might find yourself re-implementing some of the higher level stuff that is done in Lua. However, there's no reason you couldn't build a library that used the lua code, either from external files or included in the binary.

You should be aware that the current code is in a pretty rough state, and I don't have a whole lot of time to work on it. It's functional for the things it does, but there's a lot of stuff that was just thrown together to get something working.
Quote
Our requirements are very specific - we want to have a well-performing live view,
This would depend on what you mean by "well performing". There's a few things to consider:
1) Resolution: the camera live view resolution is quite low, generally 240 or 480 lines (width depends how you count it, but you could say 720-960). You can capture and download stills at much higher resolution of course, but lower frame rate.
2) Frame rate: On a modern PC, without spending a lot of effort optimizing, 10 FPS is easy, much over 20 is unlikely. I'm not sure how fast the live view itself updates, I doubt it's over 30 in most cases.
3) Visual artifacts: Transmitting the frames isn't synchronized with viewport updates, so you can get tearing. This might be fixable, with some frame rate cost.

Quote
with the ability to change camera settings now and then.
Camera control is done by sending Lua code (or messages to an already running script) to the camera, meaning that all the exposure parameters that normal CHDK scripts can control are available. This gives you pretty complete control over shooting. Camera side scripts can also send arbitrary data to the PC side, so the PC code can get any values that are available to camera side scripts.
Quote
All the storage and processing will be on the computer side. How optimized is the library for this currently e.g. is it possible to download one frame while capturing the next? (is this possible to implement at all otherwise?)
I'm not sure exactly what you are asking.

The live view is separate from still image capture. The actual process of shooting a still will briefly disrupt the live view: on many cameras, the full frame raw buffer overlaps the viewport framebuffer, so you will see "snow" in the live view. At a minimum, the live view will not get updated with valid data while shooting is in progress.

Currently, we can't capture stills directly over USB, you'd have to let the still capture process save it on the camera card and then download it. Getting the raw data out of RAM is doable, but would only make sense if you want to work with raw, otherwise you'd be better of letting the camera save a jpeg and then download it as a file. Getting jpeg data from the camera is also probably possible, but would require some reverse engineering.

If you are talking about downloading a still while the next one is capturing, that's probably doable (assuming you are downloading files, probably not if you are getting raw from RAM) I tried running live view at 20 fps (~9 mbyte/sec) while doing some long exposures, and didn't see any problems or significant drop in throughput. I also tried shooting in continuous mode, and surprisingly that didn't seem to hurt anything or affect throughput much either.

The current code is single threaded, so long running USB operations like downloads block the rest of the application. However, having the USB stuff in a separate thread or process should be fine, and is on my TODO list.
Don't forget what the H stands for.

Re: alternative ptp client
« Reply #212 on: 24 / July / 2012, 14:27:09 »
I managed to build the gui for raspberry pi.
...
Add  the following packages (in addition to the ones required to build chdkptp without gui)
FWIW,  unlike the Arch and Debian Squeeze Raspberry pi images that needed lots of packages added,  the only things I needed to do with raspian were :

Code: [Select]
>svn co http://subversion.assembla.com/svn/chdkptp chdkptp
>sudo apt-get install libusb-dev
>cd chdkptp/trunk
>cp config-sample-linux.mk config.mk
>mk
Ported :   A1200    SD940   G10    Powershot N    G16

Re: alternative ptp client
« Reply #213 on: 24 / July / 2012, 23:58:07 »
I managed to build the gui for raspberry pi.

I only tested of remote X (~1 fps) and VNC (~3fps). These were unable to do live view at more than a few frames per second. Local display should be better. If the target framerate is too high, the program will become unresponsive, so you should set it before enabling live view.

Got it to build and run tonight in live view mode on my raspberry pi after the  usual struggles getting paths correct.

The live view screen reported a little over 13 fps  (with the target FPS control left at the 10 it defaults to).

Very nice !

Ported :   A1200    SD940   G10    Powershot N    G16


Re: alternative ptp client
« Reply #214 on: 02 / August / 2012, 14:17:53 »
Hi I was messing around with chdkptp code, studying and trying to figure out how everything works. So I was looking to the chdk_get_live_data() function and I was wondering in what kind of image the buf->bytes is written? I know that is not jpg  :). Just want to know how to write/deal with this byte array.
This is not a single image, it's a full frame of the live view protocol, described in http://trac.assembla.com/chdk/browser/trunk/core/live_view.h
It can contain two different kinds of frame buffers (viewport and UI overlay) a palette (for the UI) plus various information required to reproduce the size and positioning of the different elements.

It's important to know that much of the meta data can change from frame to frame, you cannot assume the viewport will have a fixed size or aspect ratio. Generally you should assume that everything except the version can change at any time (although in practice a few other things don't)

The individual frame buffers are the native camera formats, which differ between the viewport and overlay (and the palette format varies between camera models). See http://chdk.wikia.com/wiki/Frame_buffers for some information.

Example code for decoding this into RGB can be found in http://trac.assembla.com/chdkptp/browser/trunk/liveimg.c liveimg_get_viewport_pimg and liveimg_get_bitmap_pimg
Note that this is set up for the CD library, which wants a planar image (R, G, B and possibly A each in their own contiguous buffer).

Note that if you want to work on this without running a real USB connection, chdkptp has the capability to record the data stream from chdk_get_live_data() to a file. The format is simple: the dump file has a small header, then for each frame it contains the length of the following frame data, followed by the data itself. See lua/chdku.lua con_methods:live_dump_start and con_methods:live_dump_frame

Hi reyalp, thank you very very much for this reply, it help a lot and now I'm able to display a live preview of the viewport inside my Qt application.

I would also like to know if someone here had already mapped the properties/values to set on stuff on camera, via lua script with the set_prop(). Like to set flash always on I run set_prop(some number, some value).

Tnx again!

*

Offline reyalp

  • ******
  • 13745
Re: alternative ptp client
« Reply #215 on: 02 / August / 2012, 16:00:29 »
I would also like to know if someone here had already mapped the properties/values to set on stuff on camera, via lua script with the set_prop(). Like to set flash always on I run set_prop(some number, some value).
There are two places you can look:
1) The wiki http://chdk.wikia.com/wiki/PropertyCase
2) The propsetN.h files in the chdk source http://trac.assembla.com/chdk/browser/trunk/include which in turn are available in lua via the propcase module (see  http://chdk.wikia.com/wiki/Lua/Lua_Reference#get_prop )
Don't forget what the H stands for.

Re: alternative ptp client
« Reply #216 on: 06 / August / 2012, 18:51:19 »
I get segmentation fault after running ./chdkptp-sample.sh -i -c or in gui trying to press connect button:

Code: [Select]
./chdkptp-sample.sh: line 7:   497 Segmentation fault      "$CHDKPTP_DIR/chdkptp" "$@"
./chdkptp-sample.sh: line 7:   678 Segmentation fault      "$CHDKPTP_DIR/chdkptp" "$@"

I don't have such problems with older chdkptp version. When I do ./chdkptp-sample -i and then try to check for the version:

Code: [Select]
___> ver
host:2.3 cam:not connected

Here is my config.mk file:
Code: [Select]
IUP_SUPPORT=1
CD_SUPPORT=1
LUA_INCLUDE_DIR=/usr/include/
DEBUG=1
IUP_LIB_DIR=/home/streznik/iup
IUP_INCLUDE_DIR=/home/streznik/iup/include
CD_LIB_DIR=/home/streznik/CD
CD_INCLUDE_DIR=/home/streznik/CD/include

And here is my chdkptp-sample.sh file:
Code: [Select]
#!/bin/sh
# adjust the following to your configuration
CHDKPTP_DIR=/home/streznik/chdkptp/chdkptp/trunk
# only need if you have compiled IUP support and have NOT installed the libraries to system directories
export LD_LIBRARY_PATH=/home/streznik/iup:/home/streznik/CD
export LUA_PATH="$CHDKPTP_DIR/lua/?.lua"
"$CHDKPTP_DIR/chdkptp" "$@"

CD download file: cd-5.5.1_Linux32_lib.tar.gz
iup download file: iup-3.6_Linux32_lib.tar.gz

libusbx 1.0.12-2

OS: Arch linux.

Any ideas what might cause this? With other username on the same box with older ptpcam version I'm able to connect to a camera.




*

Offline reyalp

  • ******
  • 13745
Re: alternative ptp client
« Reply #217 on: 06 / August / 2012, 22:51:09 »
I don't have such problems with older chdkptp version.
If you can identify the older version which doesn't have the problem, that may be helpful.

If you can chdkptp under gdb and get a stack trace, that might also be helpful.

Some other users have reported a segfault under the raspberry pi arch distro and gentoo. From the stack trace, the segfault was somewhere deep in the usb code, and I haven't pursued it further yet. Finding out what those distros do different from debian based distros might also help.
Don't forget what the H stands for.


Re: alternative ptp client
« Reply #218 on: 07 / August / 2012, 05:56:46 »
If you can identify the older version which doesn't have the problem, that may be helpful.

cat ptpcam/svn/trunk/version.inc on older build says: BUILD_NUMBER := 1.1.0

But my chdkptp-sample.sh is located in ptpcam/svn/chdkptp/chdkptp and ./chdkptp-sample.sh -i -c and then ver when in interactive shell: host: 2.3 cam: 2.3

I can not find version.inc on newer build (the one I tried yesterday). Is tere a specific way to tell version of the build and if it is, can you please write it here.

If you can chdkptp under gdb and get a stack trace, that might also be helpful.

How do I start gdb with chdkptp-sample.sh if I start that script like this: ./chdkptp-sample.sh

Thanx for your  great work reyalp!

*

Offline reyalp

  • ******
  • 13745
Re: alternative ptp client
« Reply #219 on: 07 / August / 2012, 17:15:25 »
cat ptpcam/svn/trunk/version.inc on older build says: BUILD_NUMBER := 1.1.0

But my chdkptp-sample.sh is located in ptpcam/svn/chdkptp/chdkptp and ./chdkptp-sample.sh -i -c and then ver when in interactive shell: host: 2.3 cam: 2.3

I can not find version.inc on newer build (the one I tried yesterday). Is tere a specific way to tell version of the build and if it is, can you please write it here.
What I would want to know is what SVN revisions work/don't work.

You can use svn update with the -r switch to switch to a particular revision. svnversion will tell you what revision(s) a working copy is at. If you want to test previous versions, I would suggest the ones that correspond to snapshot builds listed here http://www.assembla.com/spaces/chdkptp/wiki/Changelog

version.inc is a chdk thing, it has nothing to do with chdkptp. The old build setup instructions included using a copy of the CHDK source for the headers, but copies are now included in chdkptp. The ver command just tells you the protocol versions. In the most recent versions of chdkptp, ver -p will give you a full version, but this won't help you identify older version.
Quote
How do I start gdb with chdkptp-sample.sh if I start that script like this: ./chdkptp-sample.sh
You can put the gdb command in the script, with
gdb --args "$CHDKPTP_DIR/chdkptp" "$@"

Once it loads, type 'run' to start chdkptp, and after it crashes, type bt to get a stack trace.
Don't forget what the H stands for.

 

Related Topics