supplierdeeply

alternative ptp client

  • 889 Replies
  • 82205 Views
*

Offline reyalp

  • ******
  • 9860
  • Publish
    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.

  • Publish
    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

    • ******
    • 9860
  • Publish
    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.

  • Publish
    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

    • ******
    • 3118
  • Publish
    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.

  • Publish
    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

    • ******
    • 9860
  • Publish
    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.

  • Publish
    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 ....


  • Publish
    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

    • ******
    • 9860
  • Publish
    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