Support for WiFi-enabled Canon cameras in gphoto
I have a Canon PowerShot S120, which allows for browsing / copying photos over WiFi. There are apps for Android, iOS, and Windows to do that. The protocol uses upnp to discover the camera and the smartphone/computer and them some HTTP-based protocol. I have some code using libupnp for the discovery and a perl script that is capable of transfering one file, but it's far from complete. Plus, I need to refresh my memory, because the last commit is from January :-(. Now, there seems to be some support for such cameras in gphoto already. So the plan is to dive into gphoto and use what I learned about the protocol to fix the gphoto support.
If you own some other WiFi-enabled Canon camera supported by the CameraWindow software, let me know.
This project is part of:
Hack Week 11 Hack Week 12
Activity
Comments
-
-
about 11 years ago by michal-m | Reply
I tried the Windows version of the CameraWindow software once more, but I still couln't get it working. The camera does discover the machine via UPnP, but it does not proceed further. It probably should continue by transfering the images via PTP/IP, because the camera opens port 15740 in this mode. But it's not working for some reason, so I'll continue with implementing the IMINK protocol used to share images with phones.
-
about 11 years ago by michal-m | Reply
I'm writing a gphoto2 camlib driver. Today, I ported the upnp handshake in it. It works if the imink.pl script is started in parallel. Now I'm going to implement filelist and file download in the camlib driver.
I'm going to skip the file receive feature (i.e. transfer initiated by the camera) for now, because gphoto2 has no api for this mode of operation.
-
-
-
-
Similar Projects
pudc - A PID 1 process that barks to the internet by mssola
Description
As a fun exercise in order to dig deeper into the Linux kernel, its interfaces, the RISC-V architecture, and all the dragons in between; I'm building a blog site cooked like this:
- The backend is written in a mixture of C and RISC-V assembly.
- The backend is actually PID1 (for real, not within a container).
- We poll and parse incoming HTTP requests ourselves.
- The frontend is a mere HTML page with htmx.
The project is meant to be Linux-specific, so I'm going to use io_uring, pidfs, namespaces, and Linux-specific features in order to drive all of this.
I'm open for suggestions and so on, but this is meant to be a solo project, as this is more of a learning exercise for me than anything else.
Goals
- Have a better understanding of different Linux features from user space down to the kernel internals.
- Most importantly: have fun.
Resources
Port OTPClient to GTK >= 4.18 by pstivanin
Project Description
OTPClient is currently using GTK3 and cannot easily be ported to GTK4. Since GTK4 came out, there have been quite some big changes. Also, there are now some new deprecation that will take effect with GTK5 (and are active starting from 4.10 as warnings), so I need to think ahead and port OTPClient without using any of those deprecated features.
Goal for this Hackweek
- fix the last 3 opened issues (https://github.com/paolostivanin/OTPClient/issues/402, https://github.com/paolostivanin/OTPClient/issues/404, https://github.com/paolostivanin/OTPClient/issues/406) and release a new version
- continue the rewrite from where we left last year
- if possible, finally close this 6 years old issue: https://github.com/paolostivanin/OTPClient/issues/123