Feedback wanted about Rapid Photo Downloader

I agree that multiple ounters can become cumbersome (I’m a software developer so I can imagine it in my mind), so take this suggestion really as a “nice to have”.

The second one does not need to be as complex as Photo Mechanic, imagine something as simple as this: an option in configuration to define a command that is executed when the import ends (with a few and well known substitution variables), so when an import finishes is easy to automate the execution of exiftool to set default keywords or labels, or even launch someone’s metadata editor or app to set geotagging, for example.

Given airnef has a command line interface, it probably wouldn’t be too difficult to incorporate it within Rapid Photo Downloader. After all, the two most basic steps are: (1) scan the camera to see what’s available and get the file name, size, modification time and thumbnail, and (2) copy the files to a local directory so that Rapid Photo Downloader can process them. Unless I’m mistaken, airnef command line version can do those steps already. I don’t own a camera with wifi, however, so it’s difficult to imagine me being the one to write and test the code. I’d be glad to assist someone who could do it, however.


I’ve been thinking about photo import, and here’s the features I’ve come up with for my ideal application

  1. it has the option to not show thumbnails. generally I know what I’ve shot, and usually thumbnails just slow you down.
  2. it lets me group photos based on how much time elapsed between consecutive photos. This is useful for example when you photograph at a music festival, so you can separate photos from each performance.
  3. it lets me name and tag each of the time-based groups
  4. it can name the files while copying, and you can use the name from the previous bullet point in the naming template
  5. it creates (darktable-compatible) xmp files with the tags
  6. after copying, adds the raw files to git-annex and the xmp files to the corresponding git repository

I would add #7. Provides for execution of another application after downloading.

Just an FYI, I’ve moved this topic into the Software category, as it seemed a better fit there. (Nothing has changed on your end - just an FYI).

This will be in the next version. The next version’s interface is undergoing major changes, most of which are yet to be written. Having said that, what I call proximity groups will look something like this:

In this example, the proximity is 1 hour. It could be practically anything at all, which the user will be able to define themselves within reasonable limits.

My intention is that grouping the photos/videos like this will make it easier to assign job codes to them. Job codes will be able to be assigned to sets of files before the download button is clicked.


Hello and thanks for your work. For my future use, when I’ll be familiar enough with darktable, I’m waiting for à feature of your FAQ: xmp import. I use rawvision on Android and i’d like to import stars and color labels (and sorry for m’y english…)

The current development code already imports and renames XMP files too, along with THM files. I didn’t realize some smart phone apps create XMP files. That’s interesting. I’m glad the code already works. Although one thing it doesn’t do is record the original file name in XMP, before renaming the file.

For me, the most wanted addition would be a tick box allowing me to delete contents on SD card once download has completed.

Keep up the awesome work Damon!

How is that different from the “move” files option, which is the same as auto-delete?

In other news, this is the what the latest development version looks like:

Eagle-eyed viewers may note the new presentation of devices.

Under the hood the biggest change has been code to generate thumbnails asynchronously and in parallel, using as many cores as the CPU has, up to 4. Working in parallel certainly helps speed aspects of the overall thumbnailing operation up, which is important for users who download thousands of files at a time. Not every aspect of thumbnailing can be made parallel, however. Reading the files from the drive/camera must be linear, because this part either cannot be made parallel (libgphoto2 limitation) or reading files in parallel results in lower performance because of disk thrashing. This bottleneck is not easy to work around.


I really like the path this app is taking! :smile:

I agree, this is looking awesome @damonlynch!

Screenshot of latest code:

The UI now explicitly differentiates between downloading from devices / memory cards / cameras, on the one hand, and a folder on the computer, on the other. I think that will make it easer for new users to figure out what’s going on.

The checkboxes beside a device and a folder This Computer can be used to select / deselect photos/videos.

The toggle switches beside Devices and This Computer turn on and off scanning/downloading from that source. I hope that will be obvious to users. Curious fact: Qt widgets provides no toggle switch, although QML does. So I had to wrangle a slider into what you see there :smiley:

If you want to download from both devices and a folder on your computer at the same time, you can. My guess is that the number of times anyone would want to do that is very small. If it confuses people, I may have to artificially limit that. Let’s see.

You can select cells in the Timeline and it will filter the display of thumbnails to show those only from that time period / day / month. You can of course select multiple cells. too. The one thing I still need to figure out is how to best handle deselect – that is when the user wants to see all of the photos, not just those from a particular time range. I’m not sure if I need to add a special button and make it prominent in the UI, or some other way, perhaps if the user clicks in a cell that’s already selected, it becomes deselected.

You can turn off individual panels, to maximise the thumbnail display area. Here both left-side panels are turned off:

The next major chunk of code to work on is the GUI for all the panels on the right side, which is yet to be written.


I’ve only just started to use Rapid Photo Downloader and as I have the latest version there isn’t a GUI way to set the filename template. This sort of defeats the object for me and is a major block - I have found the config file but there doesn’t appear to be any info on what the line for how a filename can look on your website.

While not a ‘feature’ could you let me know what the textual options are for renaming photo files (i.e. can it use info from the exif data etc).

I understand that this issue will be sorted out once you have enabled the filename rename setting part of the GUI but I ( and any new user) really can’t start to use your program without this info.


Hi, you can import program preferences from version 0.4.x into 0.9 alpha. Set your renaming rules in 0.4.11, for example, and then import them into 0.9.

Or else you can wait until I release alpha 5. The file renaming GUI has been written:

I’m doing the final code on displaying the example file names, which involves using a sample file from the download source. ETA is unknown right now as I just (1) changed country and (2) it’s the start of a new semester, hence I’m extremely busy.

If you like you can always download the latest code from launchpad. The sample file names issue is only for display purposes.

1 Like

Hi Damon,

Thanks for the fast response. Hope your new location is as good (or better than) the old one! To be honest I’m not in a great rush - just wanted to see your software working in all it’s glory. I’m currently just copying the SD card across to a ingest folder in the laptop and running a series of exiftool commands to rename and place the files in my target photo external drive.

Enjoy the new semester and I’ll await the next version!



I hadn’t seen this thread before, hope it’s not too late to add my two cents :slight_smile: I haven’t tried the alpha yet (is there a PPA?), so forgive me if some of this is already implemented, but I figured I should brain-dump before my expectations are influenced by the existing work.

I think these two points are good:

One of the very annoying things about 0.4.1 is how hard it is to select “only the last shoot”. We can’t rely on rpd to keep track of which files have already been downloaded, since we often end up renaming or maybe moving the folder after import (e.g. it downloads to ~/Photos/2016/2016-09-18 and then we move it to ~/Photos/2016/2016-09-18_birthday or ~/Photos/work/in-progress/2016-09-18_jamie-and-lees-wedding). But of course, this means having to do a lot of fiddly clicking on those tiny boxes, and there’s some bug or something which means the shift-click doesn’t work (or I’m not smart enough to figure out the UI), which means manually selecting, which means we end up using the file manager instead of rpd for those times when we’ve not emptied the memory card in between shoots.

So groups would help here, as would having a UI for selecting photos that corresponds more to how regular file managers do it. Before I found out you had to click the little box of one photo after clicking the photos themselves, I tried clicking the photos themselves and then hitting the “select all” button below, which of course did not do what I wanted. My girlfriend did the exact same thing. So the whole “two kinds of select” thing is confusing.

If you’re doing groups anyway, perhaps a speedy method of showing what’s on the card before downloading would be showing just the first 5 photos of each group, and then elide the rest, like

:arrow_down: 2016-09-12:
:frame_photo: :frame_photo: :frame_photo: :frame_photo: :frame_photo: :file_folder: (201 more in this group, click to load thumbs)
:arrow_down: 2016-09-19:
:frame_photo: :frame_photo: :frame_photo: :frame_photo: :frame_photo: :file_folder: (697 more in this group, click to load thumbs)

I don’t care about having rpd do backups (I have my own backup scripts), though having the ability to run a self-chosen command after import sounds like a good idea.

Regarding having separate download locations – I think it’d be hard to do this in a way that will be fast enough. We typically just want to get things in as quickly as possible to stop worrying about losing the card or whatever. But I suppose an easily accessible toggle somewhere between some presets might be useful (e.g. I can set up a work-preset and home-preset, with differing download folders and perhaps different after-import-scripts).

One thing that’d be nice is having a per-shoot format string in the download folder – is this what you mean by Job Code? E.g. setting the destination to ~/Photos/%Y/%Y-%M-%D_%P where %P is from a prompt showing after I hit the “Download” button (and where it’s OK to leave it empty). Or just a text field always showing right above the download button.

“Remember files that have already been downloaded.” – this won’t work if I move the folder, right? Or does it store exif info in some database?

This thread was started almost 12 months ago. There has been much development since then including several alpha releases, accompanied by often extensive release notes. Let me be abundantly clear: it’s much more productive, helpful and sensible to comment on the work I’ve actually implemented than to do a “brain-dump” that ignores all that.

The alternative is checking / marking a photo as soon as it’s selected, which is problematic for several important reasons which I won’t go into here.

I put a lot of time into the documentation for the version you have (0.4.x), and have started documenting the alpha release. The documentation contains the answer to this question.

1 Like

Wow somehow I didn’t notice/understand that the job code was already there in 0.4, will start using :slight_smile:

I’ve been playing with RPD 0.9.0a4 this week, and I am really impressed with the general layout and flow. So far, I’ve tried it with a Samsung Galaxy S5, a Canon point and shoot, a Nikon D7000, and a SD card removed from the Canon, and it has worked well for all of them (other than the known hassles you documented for the phone). The timeline with adjustable proximity setting is a super way to find the logical breaks between sessions. Once the job code is implemented, I think RPD will do exactly what I believe I need. It tries to do one thing well, rather than trying to do a mediocre job of a whole bunch of things.

I’d be interested to know how you plan to implement the job codes. The implementation probably matters more when importing a lot of historical work than it does once you’re settled in and just downloading a couple of sessions at a time. Personally, I think being able to do something like right-clicking on a grouping in the timeline to access a control to set the job code for that grouping would be a good way to go. That would allow you to label a large number of jobs, start the download, and just let it rip.

Two non-defect things I found less than ideal:

  1. I found the thumbnail size to be barely large enough for me to identify what a session was. It would be nice to have a setting to customize the thumbnail size (not necessarily freely, just having a few choices would do).

  2. I did not find a reliable way to select all the photos from a session, and only those photos. Clicking a session in the timeline caused only the photos from that session to appear as thumbnails, but doing common things like selecting the first of these and shift-selecting the last of these did not have the desired effect of selecting the entire group. I would either wind up with only those two photos selected, or the entire contents of the camera or card. This may be ignorance on my part, but I could not locate doc for selection and tried a lot of things and wound up individually selecting each thumbnail.

Overall, great package, and I’m looking forward to trying out the next alpha release.

1 Like