alternative ptp client

  • 916 Replies
  • 92154 Views
*

Offline reyalp

  • ******
  • 10055
Re: alternative ptp client
« Reply #200 on: 05 / July / 2012, 01:41:35 »
Advertisements
Thanks, I d/l'd the unstable trunk version of chdk that you referenced.  Now the program works (e.g. shutter release, etc).  However it still gives the same error message that the live view is not supported.
thx
Either you aren't using the correct version of chdkptp, or you aren't using the current trunk. You should be using the r248 build of chdkptp from http://www.assembla.com/spaces/chdkptp/documents

edit:
typo corrected, thanks Microfunguy :D
« Last Edit: 05 / July / 2012, 14:34:18 by reyalp »
Don't forget what the H stands for.

Re: alternative ptp client
« Reply #201 on: 05 / July / 2012, 04:35:35 »

You should be suing the r248 build of chdkptp

Quite right !

Sue them for every penny they have got  :)

*

Offline reyalp

  • ******
  • 10055
Re: alternative ptp client
« Reply #202 on: 09 / July / 2012, 03:22:28 »
Uploaded snapshot r272 to http://www.assembla.com/spaces/chdkptp/documents

See http://www.assembla.com/spaces/chdkptp/wiki/Changelog for details. This includes the file / message size upload fix related from http://chdk.setepontos.com/index.php?topic=4338.msg87348#msg87348 so upgrading is recommended.
Don't forget what the H stands for.

Problems with shooting RAW over PTP.
« Reply #203 on: 11 / July / 2012, 11:10:03 »
Greetz everyone,

For the past few weeks I have been developing software to automatically find chromaticity deviations in strips of LEDs. I've written some software in Ada to read the Bayer Filter .CRW dumps, and a perl script to connect the chdkptp interface to a set of buttons and indicator lights via my computers parallel port.

The one problem I have not been able to overcome is shooting RAW over the chdkptp interface. Here is the basic setup:

Canon PowerShot A570 running CHDK release_1 SUB101a, with "save RAW" selected and all other settings default.
chdkptp -c -i: Interactive shell successfully opened.
=switch_mode_usb(1): Camera transitions to capture mode.
=shoot(): Camera takes picture, crashes, and dies seemingly right after the .CRW has been saved to disk.

The chdkptp interface is thrown an unexpected return code: 0x2fd
After dumping the ROM log I find an ASSERT at FsIoNotify.c line 292.
After turning the camera back on I can find the XXX.CRW file on disk and of the correct size.

The A570 has the smallest amount of free RAM out of any other supported cameras and at first I assumed this was a problem, but after loading CHDK into extended memory I had the same results. The most interesting part here is that if I enable DNG format and have the camera convert the RAW dump to DNG right on board the camera no longer crashes and everything goes as expected. I don't know how to explain this last observation with DNG.

I'll be publishing my libraries and source at the end of this project, any help would be greatly appreciated.

-Mike

ROM Dump:
Code: [Select]
ASSERT!! FsIoNotify.c Line 292
Occured Time  2007:01:27 00:52:32
TCB: 00151574
Task: tFsIoNotif
SP: 0x001511FC
StackDump:
0x00000000
0x37303032
0x3A31303A
0x30203732
0x32353A30
0x0032333A
0xFFE47248
0x00000005
0x00000000
0x00000000
0x001512E4
0xFFF17BE0
0x00000007
0x00151340
0xFFECA848
0x00000000
0xFFE47560
0x00000000
0x00000005
0x00000061
0x001512C4
0x00000000
0xFFE46BC4
0x001512E4
0x00144F94
0xFFE491C8
0x00151348
0x001512E4
0xFFE2F764
0x00000000
0x00000005
0xFFEFA05C
ShootConDump:
01 02 07 08 09 0f 0f 0f 0f 0f
CameraConDump:
08 0b 02 0e 0a 01 0f 0f 0f 0f
00260650: LogicalEvent:0x112c:adr:0x0,Para:0

00260650: SSAPI::GetMFBarData

00260660: DSIC:f,0

00260670: EXPLockCon_Start

00260680: DSIC:c,0

00260690: Window:EffectiveLockPhysicalScreen

00260690: Window:IneffectiveLockPhysicalScreen

00260690: LogicalEvent:0x3135:adr:0x0,Para:0

00260690: _ManagePTMProperty

00260710: DSIC:e,0

00260730: DSIC:e,0

00260750: SSAPI::CaptureModeChange

00260750: SSAPI:: EvfMode = 2

00260750: SSAPI:: CaptMode = 0x8001

00260760: SSAPI::CompleteCaptureModeChange

00260760: _DecideCaptureMode

00260760: _StartStill

00260770: SSAPI:: UsingRaw[0]

00260770: DSIC:b0,3

00260780: DSIC:b2,1

00260780: DSIC:41,6

00260820: Window:IneffectiveLockPhysicalScreen

00260820: _MuteOffStitch

00260820: TerminateDeliverToZoomController

00260830: DSIC:e,0

00260830: OPTICAL_ZOOM_MIN_POS

00260840: ST_OPTICAL_WIDE_TERM

00260840: UnpressZoomLever

00260840: DispSwCon_TurnOnDisplayDevice

00260840: LogicalEvent:0x313d:adr:0x0,Para:0

00260840: _EntryStartRecMode

00260840: CaptModeChanger_CheckRTCRrepared

00260840: DispSw: Unlock

00260840: DispSwCon_MuteOffPhysicalScreen

00260840: MuteOffPhysicalScreen

00260840: _DecideModeDial

00260850: LogiEvnt_NotPowerType:0x09a4:adr:0x0,Para:0

00260850: LogiEvnt_NotPowerType:0x09a2:adr:0x0,Para:0

00265800: PressSwOne

00265800: SSAPI:: UsingRaw[0]

00265800: ShootState:0x1

00265800: ShtCon_Activate

00265800: ShtCon_PrepareCapture

00265800: DispSw: Lock

00265800: DSIC:61,0

00265800: DSIC:e,0

00265810: DispSwCon_TurnOffDisplayDevice

00265810: DispSwCon_TurnOffBackLight

00265810: TurnOffBackLight

00265810: TurnOffDisplay

00265900: Window:EffectiveLockPhysicalScreen

00265900: Window:IneffectiveLockPhysicalScreen

00265900: LogicalEvent:0x3135:adr:0x0,Para:0

00265900: DSIC:e,0

00265910: SSAPI::PrepareCapture

00265910: ShootState:0x2

00265910: ClearEventComp

00266530: ShootSeqToUI:0x2006:adr:0x25e9b4,Para:2484660

00266530: ShtCon_SetPreCapt

00266530: DSIC:62,0

00266530: Window:EffectiveLockPhysicalScreen

00266530: DispSwCon_TurnOffDisplayDevice

00266540: DispSwCon_TurnOffBackLight

00266540: Window:IneffectiveLockPhysicalScreen

00266550: ShtCon_ResetShtMode

00266550: _EntryPrepareShoot

00266550: ShootState:0x7

00266760: PressSwTwo

00266760: SSAPI:: UsingRaw[0]

00266760: ShootState:0x8

00266760: ShootState:0x9

00266760: DSIC:14,0

00266760: _MuteOn

00266760: DSIC:42,0

00266760: DispSwCon_MuteOnPhysicalScreen

00266760: MuteOnPhysicalScreen

00266760: TurnOnDisplayForStartup

00266760: SSAPI::ShootPicture

00266780: DSIC:63,0

00266800: UnpressSwTwo

00266800: UnpressSwOne

00266810: ShootSeqToUI:0x2022:adr:0x0,Para:0

00266830: DSIC:64,0
« Last Edit: 11 / July / 2012, 11:14:49 by smike1020 »


*

Offline srsa_4c

  • ******
  • 3165
Re: alternative ptp client
« Reply #204 on: 11 / July / 2012, 11:52:22 »
After dumping the ROM log I find an ASSERT at FsIoNotify.c line 292.
This is a well known problem, put
#define CAM_STARTUP_CRASH_FILE_OPEN_FIX 1
into platform/a570/platform_camera.h
http://chdk.setepontos.com/index.php?topic=6179.0
It will be fixed soon based on your report.

Re: alternative ptp client
« Reply #205 on: 11 / July / 2012, 16:49:03 »
Thank you for the quick reply! I will make the edits and give it a shot. In the meantime I patched the procedure for writing DNG files to exclude the DNG header and reversing of the bytes in main.c

-Mike

*

Offline reyalp

  • ******
  • 10055
Re: alternative ptp client
« Reply #206 on: 22 / July / 2012, 21:05:44 »
edit July 4 2015: For the most recent instructions see README-RASPI-LIBS.TXT in the chdkptp SVN


I managed to build the gui for raspberry pi. I've uploaded a build to the files area http://www.assembla.com/spaces/chdkptp/documents which includes the gui libs along with chdkptp

This will *only* work on the raspbian distro (or possibly other hard float distros if they exist).

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.

Since there was some trial and error and I didn't restart from the beginning with each change, the notes that follow may not be complete.

I did this using the raspbian distro announced here http://www.raspberrypi.org/archives/1605, most of it should apply to building the libs on other Debian based distros, on pi or pc.

Add  the following packages (in addition to the ones required to build chdkptp without gui)
libx11-dev
libxpm-dev
libxmu-dev
libxft-dev
libgtk2.0-dev
libgl1-mesa-dev
libwebkitgtk-dev
libglu1-mesa-dev
libncurses5-dev

These are mostly from the list found at http://www.tecgraf.puc-rio.br/iup/en/building.htm except
- I left out the motif related ones, since I don't care about motif.
- libglu1-mesa-dev was not mentioned, but is required for GL support.
- libncurses5-dev was not mentioned, but was required for something in iup.
libwebkitgtk-dev may have been a mistake, since I couldn't get the iupweb component to build and ended up commenting it out. From what I could tell, USE_PKGCONFIG=Yes giving the wrong location.

Get and extract the IM, CD and IUP sources:
wget http://sourceforge.net/projects/imtoolkit/files/3.8/Docs%20and%20Sources/im-3.8_Sources.tar.gz
wget http://sourceforge.net/projects/canvasdraw/files/5.5.1/Docs%20and%20Sources/cd-5.5.1_Sources.tar.gz
wget http://sourceforge.net/projects/iup/files/3.6/Docs%20and%20Sources/iup-3.6_Sources.tar.gz
tar -xzf im-3.8_Sources.tar.gz
tar -xzf cd-5.5.1_Sources.tar.gz
tar -xzf iup-3.6_Sources.tar.gz

Note, I used the liblua5.1-0-dev package to provide lua. This caused me some problems, it might be better to build lua along with the rest of the libs. In this case, you'd probably also want to link chkdptp with the locally built instead of the debian package.

Now build the libraries in this order IM, CD, IUP
The documentation mentions that you can build individual libraries. However, for IM and CD, it's not immediately clear which are needed to support IUP, so I just tried to build everything, running make in the top level src directory.

To the distro lua package, the following needs to be set
export LUA_SUFFIX=
export LUA_INC=/usr/include/lua5.1

IM built with just
make

CD
needs to be built with
make USE_PKGCONFIG=Yes
to find the correct GTK stuff

IUP
I had multiple problems with this one.
Edit the to level makefile to remove iupweb from do_all
create the following symlink to allow the distro installed lua lib to be found
ln -s /usr/lib/arm-linux-gnueabihf/liblua5.1.a /usr/lib/liblua.a
In srcconsole/Makefile, comment out the @$(TECMAKE_CMD) USE_LUA52=Yes in the iuplua5 target

in the IUP directory
make USE_PKGCONFIG=Yes

Only building the iup libraries actually needed by chdkptp would probably be a smarter approach.

chdkptp doesn't currently use IM, but some of the CD and IUP stuff depends on it. It might be possible to build whats needed for chdkptp without building IM at all.
« Last Edit: 04 / July / 2015, 23:13:37 by reyalp »
Don't forget what the H stands for.

Re: alternative ptp client
« Reply #207 on: 22 / July / 2012, 21:38:11 »
I managed to build the gui for raspberry pi. I've uploaded a build to the files area http://www.assembla.com/spaces/chdkptp/documents which includes the gui libs along with chdkptp
Well,  there goes all the spare time I have available in the next week to ten days ....


Re: alternative ptp client
« Reply #208 on: 23 / July / 2012, 13:56:59 »
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.

Thanks

*

Offline reyalp

  • ******
  • 10055
Re: alternative ptp client
« Reply #209 on: 23 / July / 2012, 16:10:59 »
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
Don't forget what the H stands for.

 

Related Topics