Rapid Photo Downloader

"Plugin" (or script) feature

Reported by Damon Lynch on 2010-01-23
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Rapid Photo Downloader
Wishlist
Unassigned

Bug Description

It would greatly add to the program's flexibility if the user could have the option to run a script or plugin at the conclusion of a download, or possibly for each image even as the download is occurring. These scripts / plugins could do things like:

* set file permissions
* run some kind of conversion on each file
* create user defined directories
* whatever else the user wants

Damon Lynch (dlynch3) on 2010-01-23
tags: added: wishlist
Damon Lynch (dlynch3) on 2010-05-23
Changed in rapid:
status: New → Confirmed
Mirek Rewak (mrewak) wrote :

I'm really missing this option. I have a broken camera which doesn't store proper date and time on photos so I'd fix them automatically after importing from a camera.

Damon Lynch (dlynch3) wrote :

In terms of the actual coding, this looks like the way to go: http://live.gnome.org/Libpeas

However, it seems like it would require that the Rapid Photo Downloader code, which is written in pygtk, be switched over to the new pygobject system. This is something that will need to be done eventually in any case, but it could be quite a bit of work.

Ech (ech1965) wrote :

I'm too missing this option ( at least just to be able to compute the photo filname. for now, here is a small script I use to rename the photo before feeding it to RPD.

#!/bin/bash
CAMERA_ID=400D
CURRENT_PREFIX=C
DIR=.
#DRY=echo
$DRY exiftool -FileName\<${CAMERA_ID}_${CURRENT_PREFIX}\$filenumber.\%e $DIR/*
for fic in `ls`
do
  from=$fic
  to=${from/-/_}
  $DRY mv $from $to
done
If I could ask RPD to call such a script to get the destination file name ... that would be great !!!

Thanks for your great tool !

It seems you have programming skills. Would you like to plan and write the
plugin functionality for Rapid Photo Downloader?

Another thing: I'm curious what your script does in terms of file renaming
that Rapid Photo Downloader currently cannot do. Perhaps another renaming
option needs to be added to Rapid Photo Downloader.

Oleg Yermakov (epushiron) wrote :

I have the whole picture of the easy way the plug-in system could work. I can write it down here or as a blueprint, or you can just wait (or not wait ☺) for the day I get less lazy&busy and just develop it.

As of programming skills — I'm still learning Python and know a little about GTK. A fair example of my code (which I use pretty every time after RPD and would like to get plugged in) you could see in attachment.

Damon Lynch (dlynch3) wrote :

Thanks everyone. Here are some thoughts:

1. libpeas

For plugins, Gnome 3 uses libpeas. It is based on the experience and insights of the gedit developers. It seems like the ways to go. To use it, Rapid Photo Downloader must be using python gobject introspection and gtk3. Rapid Photo Downloader currently does not do that--version 0.4.0 currently uses regular pygtk. I stuck with that because it's very mature, and the changes I'm currently making to the code are so complex and invasive that I didn't want to add yet another layer of change and complexity.

2. plugin planning

The best way of handling plugins needs proper planning. Let's for a moment assume that Rapid Photo Downloader is updated to use python gobject introspection and gtk-3. Planning would involve (a) doing a code review of other projects to find the best practices, and (b) thinking about the different ways in which plug-ins generally would need to engage with the photos and videos as they are being downloaded.

For (b), at various stages in the download process, a plug-in might want to manipulate various aspects of the download, perhaps by changing filenames, converting file formats, manipulating file permissions, copying files to other locations, inserting metadata etc. The plug-in may want to work on individual files, or entire directories. I anticipate that the plug-in interface would need to be flexible enough to cope with these kinds of issues.

A blueprint on launchpad is a very good way to handle this. Let me know if anyone is interested and we'll figure out how to put it up here on the Rapid Photo Downloader launchpad page (I've not yet thought about it).

Ech (ech1965) wrote :

My script renames the files using the "whole" number present in the Canon400D exif data:
When the 400D writes images on the card, it stores them in directories. the directories names get numbered too.
the "filennumber" variable returned by exiftool is structured: XXXX-YYYY ( XXXX is the number in the directory, YYYY is the same number as in the image filename: IMG_YYYY).
In RPD, I can only use the numbers from the file name and not the one from the exif metadata ( I can understand this behavior because the filenumber is specific to the Canon ).

The "CURRENT_PREFIX" variable in my script let me deal with resetting the file counter in the camera. If I decide to reset the file counter in the camera, I just have to change the prefix and I'll keep unique filename against my collection.

As of programming experience.. indeed I have some but not yet in python... nor with the plugin infrastructure you mentioned.
I'd be glad to contribute and help to enhance RPD. In my previous like using Windows, I coded a "poor man rpd" in C# (see http://prono.svn.sourceforge.net/viewvc/prono/trunk/Renamer/ for some code) running as a command line program. ( it still runs perfectly on mono)

As a quick "hack", I was thinking about a variation of the "text" part of the RPD user interface combined with a mechanism comparable to the ` (backtick) operator of the shell: execute the expression as command or python function and pass a few context parameters in the environement ( dir of current picture, name of file,...). use the standard output as value for the field.

Another kind of thing I'd like to do with RPD is create a directory with a sequence number in the name. BUT having the sequence being incremented based on the total size of the files presents in the directory ( eg: increment the sequence when 4gb of pictures are present in one folder. That could be handy when burning backups on dvd)

Thanks for you great piece of software !
Etienne

Oleg Yermakov (epushiron) wrote :

Damon: I'd like to see Blueprints enabled.
Ech: would some kind of "custom EXIF field" fix the problem?

2011/4/7, Ech <email address hidden>:
> My script renames the files using the "whole" number present in the
> Canon400D exif data:
> When the 400D writes images on the card, it stores them in directories. the
> directories names get numbered too.
> the "filennumber" variable returned by exiftool is structured: XXXX-YYYY (
> XXXX is the number in the directory, YYYY is the same number as in the image
> filename: IMG_YYYY).
> In RPD, I can only use the numbers from the file name and not the one from
> the exif metadata ( I can understand this behavior because the filenumber is
> specific to the Canon ).
>
> The "CURRENT_PREFIX" variable in my script let me deal with resetting
> the file counter in the camera. If I decide to reset the file counter in
> the camera, I just have to change the prefix and I'll keep unique
> filename against my collection.
>
> As of programming experience.. indeed I have some but not yet in python...
> nor with the plugin infrastructure you mentioned.
> I'd be glad to contribute and help to enhance RPD. In my previous like using
> Windows, I coded a "poor man rpd" in C# (see
> http://prono.svn.sourceforge.net/viewvc/prono/trunk/Renamer/ for some code)
> running as a command line program. ( it still runs perfectly on mono)
>
> As a quick "hack", I was thinking about a variation of the "text" part
> of the RPD user interface combined with a mechanism comparable to the `
> (backtick) operator of the shell: execute the expression as command or
> python function and pass a few context parameters in the environement (
> dir of current picture, name of file,...). use the standard output as
> value for the field.
>
> Another kind of thing I'd like to do with RPD is create a directory with
> a sequence number in the name. BUT having the sequence being incremented
> based on the total size of the files presents in the directory ( eg:
> increment the sequence when 4gb of pictures are present in one folder.
> That could be handy when burning backups on dvd)
>
> Thanks for you great piece of software !
> Etienne
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/511646
>
> Title:
> "Plugin" (or script) feature
>
> Status in Rapid Photo Downloader:
> Confirmed
>
> Bug description:
> It would greatly add to the program's flexibility if the user could
> have the option to run a script or plugin at the conclusion of a
> download, or possibly for each image even as the download is
> occurring. These scripts / plugins could do things like:
>
> * set file permissions
> * run some kind of conversion on each file
> * create user defined directories
> * whatever else the user wants
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/rapid/+bug/511646/+subscribe
>

Ech (ech1965) wrote :

Oleg: a custom exif field would indeed solve the problem..( except for the string replacement ( - -> _) )
 maybe a "Python Expression" in the rename format together with a function returning a spécific exif tag would be "the best"

Damon Lynch (dlynch3) wrote :

Oleg: see https://blueprints.launchpad.net/rapid/+spec/rpd-plugins

Ech: the file renaming problem you're describing does not have to be done in a plugin and should ideally be handled by the GUI. Please file a feature request that describes the renaming problem in a generic sense that fits with the way the program currently renames files, without reference to quick hacks. Everything should be done via point and click, without the need to enter codes.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers