Feedback wanted about Rapid Photo Downloader

Hi Joao,

I’m not sure about separate sequence values per job name. The GUI could become quite difficult. I’ll have to think about it.

Regarding your second point, you’re asking for a free software version of Photo Mechanic,which is a massive job. I don’t see myself doing that. Maybe someone else might.

Best,
Damon

1 Like

Hi Damon,

bit rod is not the only concern, files could be accidentally overwritten or there could be hardware defects. They even could be accidentally deleted. Checksum files are useful in many ways. The per file checksums (IMG_0815.CR2.md5) could also be used to verify file transfers over a network or provided along the original file for downloads etc. And, of course, it’s always good to know that the integrity of the files is intact.

File system based integrity checks as, e.g., ZFS implements do not help because there could still be errors while copying files to the backup locations. The checksum files provide evidence that everything is transferred well.

Of course, one could argue that copying with rsync would be safe, but still, having the checksum files is transparent through all copy processes and media and operating systems etc.

Anyway, if this is beyond RPDs scope, a hook to run a script after an import could still be handy for many use cases. If you have no idea what I mean, then have a look at the git hook scripts: Git - Git Hooks. Besides automatic checksum generation, use cases could be to automatically trigger a rescan of the base directory by the image management software, to trigger external backup solutions, to add files to git-annex or similar tools, to automatically generate contact sheets etc. I guess there would even be people nowadays that would love to automatically post to facebook that they have downloaded 748 images of the last holiday from the camera :wink:.

Even João Almeidas wish of automatic xmp generation could be solved with a little scripting and without altering RPD by using this hook script idea. It would allow a lot more flexibility for those users that do not fear a little bit bash/zsh/python/whatever scripting.

Best regards

Chris

Just reading through thread and didnt see it mention yet: any thoughts on airnef?

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.

Hi,

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.

2 Likes

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.

2 Likes

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.

5 Likes

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.

Thanks.

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!

Cheers,

John

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?