chdkptp - alternative ptp client

reyalp

hairball
I noticed that when I plug the camera in the OS does not see it. All my other Ubuntu machines do. I don't think this has anything to do with chdkptp. I will reload the OS tomorrow and try again. I will let you know what happens. Thanks for trying. I really appreciate it.
John

Note for chdkptp to be able to switch to rec mode and shoot, you very much want the OS default software to not see it. If you previously had chdkptp working on this box, that may be why. See discussion under "Interactions with default software" in the linux of https://app.assembla.com/spaces/chdkptp/wiki/Install

On the output you posted, the libusb-0.1 stuff all seems good, but I notice errors related to libreadline.
You might want to install the readline6 package or similar.

hairball

I reloaded and downgraded to 12.04 32bit and now when I plug the camera in, with chdkptp off, at least the OS sees the camera. I fire up CHDKptp and it sees the camera but when I go to connect chdkptp goes grey and hangs. BTW, these tests are with a SD1400, if that makes any difference. I don't think it does. I think this laptop has an issue with its USB ports.
The only machines I have gotten to work have been with 12.04 32bit. I have a stack of laptops I hope to deploy with SD1400s for time lapse projects that I have planned. Although 16.04 would be great, I don't care, if 12.04 works I will go with that. Oh, and this test is back to r735. Since that is what I have on the Windows machines I have deployed in the field already. I would prefer that all of my set ups have the same ver of chdkptp, Ubuntu and other software.
I thank you again for you thoughts and efforts.

reyalp

hairball
I reloaded and downgraded to 12.04 32bit and now when I plug the camera in, with chdkptp off, at least the OS sees the camera.

As I mentioned before, if the OS software access the camera, this will cause problems with chdkptp.

This is unfortunately complicated, poorly documented, and distro/configuration specific. I've updated https://app.assembla.com/spaces/chdkptp/wiki/Install with the specific steps I needed to get it working on Ubuntu 16.04.

I fire up CHDKptp and it sees the camera but when I go to connect chdkptp goes grey and hangs.

I assume "goes grey and hang" means the GUI? If so, I'd suggest trying the cli, as there could be GUI problems independent of the PTP issues. It might also give more useful error output.

Sometimes system logs provide clues.

I personally prefer to pick a configuration and try to understand the problems rather than throwing every possible permutation of version at it. chdkptp works on Ubuntu 16.04 (and recent raspbian and debian), your challenge is to figure out how specifically it fails on your particular systems.

hairball

I agree. I only use the GUI to see if things are working before unleashing the Lua on it through the CLI. chdkptp has been solid. I never thought it was the problem. I was just hoping that you would have insight into what Ubuntu needed. Yes, going grey was in the GUI. I might just have to abandon this laptop and move on.

reyalp

User @ftm reports successfully building chdkptp with the GUI on OSX 10.13 (High Sierra) with macports.

Build and scripts to build at https://github.com/rprr/chdkptp

They report being able to use this without default software putting the camera in the "black screen, can't switch to rec" state. I'm not clear if this was a result of some specific configuration, or is the default behavior for 10.13. They previously used USB pass-through to a virtualbox VM, which may have affected configuration. There may also be relevant options in the "Image Capture" app.

I would like to make it easier for Mac users to build/use chdkptp, so I'd appreciate any feedback anyone else has on how usable this is, if any additional configuration is required and so on.

philmoz

While it build and runs, I have not been able to get any connection to a camera.

The MacOS PTPCamera app kicks in whenever a camera is connected and takes over the USB connection.
I can't see any options in Image Capture to stop this - you can prevent Image Capture from starting; but can't block PTPCamera.

There should be a way to do it as VMware and Virtual Box can both block the behaviour and allow the camera to connect to a VM. I just haven't found it yet.

The old tricks (in the README-OSX.TXT file) don't work anymore. You can't change the file mode on system files, and the database for PTPCamera has moved somewhere else so the gphoto script does not work.

FYI, to get this to build I had to install:
- gtk3, libusb, libusb-compat, ftgl and readline in MacPorts
- XQuartz

Phil.

ftm

I don't see any PTP Camera App on my Mac running 10.13.

When I start Image Capture, the camera shows up and then I can't run chdkptp. However if I quit the Image Capture, then chdkptp works.

In Image Capture, there is an option at the bottom "Connecting This Camera Opens". I have it set to "No Application".

Not sure if this helps. You may have already done this.

philmoz

ftm
I don't see any PTP Camera App on my Mac running 10.13.

When I start Image Capture, the camera shows up and then I can't run chdkptp. However if I quit the Image Capture, then chdkptp works.

In Image Capture, there is an option at the bottom "Connecting This Camera Opens". I have it set to "No Application".

Not sure if this helps. You may have already done this.

PTPCamera is a component of Image Capture - USB PTP driver. It manages the camera connection.
You can see the process running in Activity Monitor when you connect a camera.

The option in Image Capture only defines what app should open after MacOS detects a camera has connected.

If PTPCamera is not starting when you connect a camera then there is something else going on - I'm not aware of any supported way to stop this process auto-running since El Capitan.

Phil.

ftm

It's odd. When I look at Activity Monitor, PTP Camera does not seem to be running on my Mac. It only shows up when I start up an app like Photos/Image Capture etc.

reyalp

Not sure if this is relevant, but IIRC ftm mentioned having the Canon software installed an uninstalling it. ftm also used virtualbox, but I would expect that to only matter if virtualbox was actually running.

ftm

reyalp
Not sure if this is relevant, but IIRC ftm mentioned having the Canon software installed an uninstalling it. ftm also used virtualbox, but I would expect that to only matter if virtualbox was actually running.

That is a possibility. Maybe the Canon software install disabled the Mac PTPcamera App permanently. There was also no Uninstall option. Just drag the App into the Trash.

philmoz

ftm

reyalp
Not sure if this is relevant, but IIRC ftm mentioned having the Canon software installed an uninstalling it. ftm also used virtualbox, but I would expect that to only matter if virtualbox was actually running.

That is a possibility. Maybe the Canon software install disabled the Mac PTPcamera App permanently. There was also no Uninstall option. Just drag the App into the Trash.

Something odd going on.

Tried on three different Macs, two automatically start PTPCamera whenever a camera is plugged in, the third does not.
Of the two that auto-start PTPCamera, one has Canon Utilities, the other does not. The one that doesn't start PTPCamera does not have Canon Utilities.

Phil.

ftm

Are all of these Macs running 10.13? I assume that no other photos related app is running? How about iCloud photos?

philmoz

ftm
Are all of these Macs running 10.13? I assume that no other photos related app is running? How about iCloud photos?

Found the problem on my Mac's - seems like MacOS now behaves itself and does not take over devices like it used to.

On my systems, the culprit is the 'Google Backup and Synch' app (new version of Google Drive). Even though I have turned off the option to synch USB devices, the app is still opening a persistent connection to every USB device plugged in (hence the PTPCamera process).

I have sent feedback to Google; but I don't hold much hope of them ever fixing it.

Phil.

ftm

I'm glad this was solved.

With my script, I noticed some weirdness when running the build script versus directly running each of the build commands on the shell one by one. This was especially the case when compiling the 'cd' libraries. It wouldn't find gtk and cairo include files when running via the script and give some errors. However the build would not fail even though these errors were present. When I ran each line of the script directly on the shell, the errors went away.

I've also modified the script to use USK_PKGCONFIG=Yes.

philmoz

ftm
I'm glad this was solved.

With my script, I noticed some weirdness when running the build script versus directly running each of the build commands on the shell one by one. This was especially the case when compiling the 'cd' libraries. It wouldn't find gtk and cairo include files when running via the script and give some errors. However the build would not fail even though these errors were present. When I ran each line of the script directly on the shell, the errors went away.

I've also modified the script to use USK_PKGCONFIG=Yes.

I didn't have any weirdness with the script.

You can reduce the number of patches to the tecgraf stuff by using GCC (with openmp) instead of the XCode compiler, and adding USE_MACOS_OPENGL=Yes and GTK_BASE=/opt/local to the script.
The iupcontrols libs aren't used so don't really need to be built.

I've attached my version of the build script and patch file if you're interested.

Phil.

buildchdkptpwithlibs.sh

3.43KB

patchfile-teclibs-macports

3.49KB

ftm

philmoz

ftm
I'm glad this was solved.

With my script, I noticed some weirdness when running the build script versus directly running each of the build commands on the shell one by one. This was especially the case when compiling the 'cd' libraries. It wouldn't find gtk and cairo include files when running via the script and give some errors. However the build would not fail even though these errors were present. When I ran each line of the script directly on the shell, the errors went away.

I've also modified the script to use USK_PKGCONFIG=Yes.

I didn't have any weirdness with the script.

You can reduce the number of patches to the tecgraf stuff by using GCC (with openmp) instead of the XCode compiler, and adding USE_MACOS_OPENGL=Yes and GTK_BASE=/opt/local to the script.
The iupcontrols libs aren't used so don't really need to be built.

I've attached my version of the build script and patch file if you're interested.

Phil.

Thanks for making these improvements. Fewer patches is always better. Which gcc are you using? Was it built from scratch?

philmoz

ftm
Thanks for making these improvements. Fewer patches is always better. Which gcc are you using? Was it built from scratch?

Currently using GGC 8 installed with MacPorts.

Phil.

ftm

philmoz

Currently using GGC 8 installed with MacPorts.

Phil.

That worked great. Thanks.

Edit to add: I've incorporated your suggestions into my github page.

reyalp

Inspired by ftm's script, I decided to put together a quick script that worked for other platforms too. It uh... got a little out of hand 🤣

Anyway, misc/setup-ext-libs.bash in the chdkptp source is the result.

It probably doesn't work completely on mac, but I think it should be pretty close. Feedback would be greatly appreciated.

It should work out of the box for many linux platforms (including raspberry pi) and windows with msys or msys2

It tries to do the following

* Download required source and/or binary packages
* extract sources and apply any required patches
* build
* extract or copy files required by chdkptp build a standardize directory tree
* copy runtime shared libraries to chdkptp/lib

The script has a bunch of options, which can be seen by passing -help
Most of the steps above can be skipped by passing a -no* option.
-pretend prints what it would do without doing anything
By default, files are only downloaded if they don't exist in the archive directory.

The script in a standardized directory tree, which defaults to extlibs/ under the chdkptp source directory. The default makefile settings are set to use this tree, so a customized config.mk should no longer be required in most cases.

The chdkptp makefiles now attempt to build GUI if you pass GUI=1 on the make command line. You should make clean between GUI and non-GUI builds.

The extlibs tree contains
/archive : downloaded zip + tgz files.
/src : extracted and patched sources
/built : built or extracted libraries, includes etc, and logs from builds.

On windows, only pre-compiled CD and IUP are supported.

On intel Linux, it defaults to pre-compiled but this can be overridden with -force-tec-src. Tecgraph appears to have stopped distributing 32 bit binaries for later versions of IUP, so build from source will become the default for those at some point. On Ubuntu, I found building from source avoided some GUI uglyness.

On other platforms, it attempts to build the minimum CD / IUP components. IM and some of the opengl dependencies are no longer required.

Prerequisites
* Normal development stuff, i.e. build-essential on Debian distros
* wget - You can download manually using URLs listed by pretend
* unzip (Info-ZIP compatible)
* For GUI, the CD/IUP prerequisites. On Debian based systems, something like:
g++ libfreetype6-dev libgtk-3-dev libx11-dev libxpm-dev libxmu-dev libxft-dev
On non windows platforms, chdkptp also requires libusb-dev and defaults to using libreadline-dev
* On Windows, MSYS or MYS2 is assumed
* On Mac, python is required

« Previous Page Next Page »