Support for renaming Darktable / Digicam XMP sidecar files

Bug #1642027 reported by Ari
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Rapid Photo Downloader
Won't Fix
Undecided
Unassigned

Bug Description

One use case that I wish Rapid Photo Downloader would support is renaming photo folders that had already been imported to Darktable/aftershot etc and that already have some valuable info stored in the XMP / sidecar files that DT / ASP / etc create, so I need to preserve that file (and rename it appropriately together with the photo).

So in these cases, for each photo file (e.g. DSC_05123.NEF) there is also an xmp file (DSC_05123.NEF.xmp) and in my use case, I need to be able to apply rapid-photo-downloader to e.g. move all NEFs to a NEF folder and rename based on EXIF data (e.g. 20161110-081010-EventName-05123.NEF) but also move and rename the sidecar xmp file (20161110-081010-EventName-05123.NEF.xmp)

Revision history for this message
Damon Lynch (dlynch3) wrote :

Version 0.9 should be doing that already, so I'm marking this bug as invalid. Change the bug status if version 0.9a5 doesn't do this as expected.

Changed in rapid:
status: New → Invalid
Ari (ari-reads)
Changed in rapid:
status: Invalid → New
Revision history for this message
Ari (ari-reads) wrote :
Download full text (5.5 KiB)

I installed 0.9a5, looks great, thanks!!

Tested it: it renames the pictures and videos but it ignores the xmp "sidecar" files in the source directory, so it doesn't really address the problem.

I checked the man pages and can't find any command line switch to activate "renaming sidecar files" or anything similar.

Here's a typical directory content that Darktable produces (note that in this case I was shooting JPEG and not NEF)

DSC_0001.JPG.xmp
DSC_0001.JPG
DSC_0002.JPG.xmp
DSC_0002.JPG

Here's RPD's 0.9a5 output:

20141208-145133-WeddingFotoman-0001.jpg
20141208-145158-WeddingFotoman-0002.jpg

No xmps...

I was expecting to find also:
20141208-145133-WeddingFotoman-0001.jpg.xmp
etc...

Is this what RPD 0.9a5 is expected to do? am I missing a command line switch or something else?

Another question: the sidecar files contain a reference to the original file:

   xmpMM:DerivedFrom="DSC_0001.JPG"

Not sure if when renaming the picture this xmp content needs to be changed as well, or if the field is only informative / not relevant

-----------------------------------------
rapid-photo-downloader --help

Downloads, renames and backs up photos and videos from cameras, phones, memory
cards and other devices

positional arguments:
  path

optional arguments:
  -h, --help show this help message and exit
  --version show program's version number and exit
  --detailed-version Show version numbers of program and its libraries and
                        exit.
  -v, --verbose Display program information when run from the command
                        line.
  --debug Display debugging information when run from the
                        command line.
  -e, --extensions List photo and video file extensions the program
                        recognizes and exit.
  --photo-renaming {on,off}
                        Turn on or off the the renaming of photos.
  --video-renaming {on,off}
                        turn on or off the the renaming of videos.
  -a {on,off}, --auto-detect {on,off}
                        Turn on or off the automatic detection of devices from
                        which to download.
  -t {on,off}, --this-computer {on,off}
                        Turn on or off downloading from this computer.
  --this-computer-location PATH
                        The PATH on this computer from which to download.
  --photo-destination PATH
                        The PATH where photos will be downloaded to.
  --video-destination PATH
                        The PATH where videos will be downloaded to.
  -b {on,off}, --backup {on,off}
                        Turn on or off the backing up of photos and videos
                        while downloading.
  --backup-auto-detect {on,off}
                        Turn on or off the automatic detection of backup
                        devices.
  --photo-backup-identifier FOLDER
                        The FOLDER in which backups are stored on the
                        automatically detected photo backup device, with the
                        folder's name being used to identify whether or not
                        the device is used for ba...

Read more...

Revision history for this message
Damon Lynch (dlynch3) wrote :

It doesn't ignore XMP sidecar files. I coded it so that when it finds DSC_0001.JPG it will look for DSC_0001.XMP, not DSC_0001.JPG.XMP. That's how cameras name XMP files they create, and as far as I know that's the Adobe spec.

Is naming system above Darktable's convention or have you configured Darktable that way? If it's not the Darktable way of doing things, can you point to the place in the Adobe spec where that naming convention is considered valid?

Changed in rapid:
status: New → Incomplete
Revision history for this message
Ari (ari-reads) wrote :

I'm using Darktable's defaults, and found this documented here:

https://www.darktable.org/usermanual/ch02s02s07.html.php

For a given source image, multiple editing versions, called duplicates, can co-exist, sharing the same input (RAW) data but each having their own metadata, tags and history stack. Each duplicate is represented by a separate XMP sidecar file with a filename constructed in the form “<basename>_nn.<extension>.xmp”, where nn represents the (minimum two-digit) version number of that edit. Information for the initial edit – the “duplicate” with version number zero – is stored in the sidecar file “<basename>.<extension>.xmp”.

Note that in some use cases there could be a version number, but in my use case, I have never seen that.

Before Darktable, I have been using Bibble / AfterShot Pro on Linux since at least 7-8 years ago. I checked photo backups from many years ago: it's the same as darktable. Documented here:

http://product.corel.com/help/AfterShot/540111115/Main/EN/Doc/index.html?background_editing.html

The XMP filename is created by simply adding ".xmp" to the end of the complete filename of the image file it describes (while many other applications build the XMP filename by first dropping the image file extension (like "jpg", "nef" or "cr2") before adding "xmp"). So a Corel AfterShot Pro XMP file would look like img_0000.jpg.xmp while an XMP from other applications for the same image would simply be img_0000.xmp.

I tested Digikam, another popular Linux raw development/photo management software. It also uses XMP sidecars with the exact same convention.

I notice that Adobe Lightroom (non-Linux) uses a different naming convention, without the extension.

I looked into the XMP spec for external files.

All it's says is this: "For applications that need to find external XMP files, look in the same directory for a file with the same name as the main document but with an .xmp extension. (This is called a sidecar
XMP file.)"

For some reason, the major linux photography apps went in one direction, Adobe went in a different direction.

So here is my ask for RPD to support Linux's Darktable/Digikam/AfterShot/etal in addition to Adobe's naming convention, so that we can have an all-Linux workflow without having to resort to custom scripts.

Revision history for this message
Damon Lynch (dlynch3) wrote :

See this discussion:

https://discuss.pixls.us/t/linux-applications-and-their-non-standard-xmp-sidecar-naming-convention/2688

In short, I will not be modifying Rapid Photo Downloader to handle the use case you present. You can use ExifTool or exiv2 to move or rename your files that you've already downloaded onto your computer and used Darktable to process.

Changed in rapid:
status: Incomplete → Won't Fix
summary: - Support for renaming photos + sidecar / xmp files
+ Support for renaming Darktable / Digicam XMP sidecar files
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.