Import ignores tags in Apple Aperture's sidecar files

Hi folks. I’m finally retiring Apple’s Aperture software, and making the switch to darktable. I’ve got 260GB of images to move over, and am keen to maintain as much metadata as possible.

I’ve fallen at the first hurdle. When exporting files into per-project folders, I’ve got Aperture making sidecar files named <basename>.xmp, adjacent to <basename>.jpg and <basename>.raw.

For those of you familiar with Aperture, I exported a test project using the “Export Originals…” command, selecting the “Create IPTC4XMP Sidecar File” option in the export dialog. I think that’s the best I can do on the Aperture side of things.

I’ve read (in the 3.8 manual) that (based on the filenames) darktable will read them, but won’t write to them.

Unfortunately darktable seems to be ignoring the file for some reason. I’m adding the exported folder to my library, and darktable is creating (as the docs say it will) <basename>.<extension>.xmp files.

Tags created in Aperture don’t show up in darktable.

I added some tags in darktable and then opened (in a text editor) Aperture’s XMP file and darktable’s XMP, to compare them. Both of them contain <rdf:Description /> tags, with a <dc:subject /> with <dc:Bag /> and <dc:li /> elements nested inside them. i.e. the Aperture keywords appear to be inside the correct tag hierarchy, from darktable’s point of view.

Are there any reasons why darktable might decide it doesn’t like the format of this XMP file? There are a few obvious differences:

  • darktable’s file starts with <?xml version= ... > while Aperture’s has <?xpacket begin='' id=''?> instead.
  • darktable’s <x:xmpmeta /> tag says it’s using “XMP Core 4.4.8-Exiv2” while Aperture is using “XMP toolkit 2.9-9, framework 1.6”.

There are other differences, but (speaking as a dev) they don’t look as likely to trip up a bit of code that’s trying to parse an XMP file, to me.

I can obviously upload them if necessary, but I’m fairly new here and wasn’t sure whether filling your screens with XML would be a good idea! And maybe something far simpler than the specifics of some XML tags is what’s actually tripping me up…

Any advice would be much appreciated. Cheers!

Open a bug report.

it might be that you have to rename all your XMP files to the pattern expected by darktable

which is originalfilename.ext.xmp

from the manual: “At present, darktable is able to load the following metadata from Lightroom-generated sidecar files”

so unless somebody implements something that can cope with Apple Apertures sidecar files, it’s quite obvious why dt doesnt import them

DId you have any other metadata that should be imported, like titles/descriptions/captions?
And were those imported correctly?

The <?xpacket begin='' id=''?> is supposed to be a valid xmp start, afaik.

I assume you are referring here to namespace declarations and references. I’m not sure those are even looked up (over the net), as some of the “http://…” links aren’t valid anymore… Most programs just use the tags they understand for each namespace (the declarations still need to be there before their use).

Also, what’s the delimiter used by Aperture betwee tag elements? We’ve seen some funny things happen with those as well.

And of course, your sidecars are in the same directory as the basefile they refer to.

Thanks all. It’s all really useful, making me more confident that it’s not just down to me missing something obvious, or a missing darktable setting.

I think @Tobias is probably right, I could have found a bug.

@darix The docs (link in my original message) explicitly talk about how dt will read sidecar files named <basename>.xmp, but won’t modify them. So while renaming them could fix it, that would still be a bug. I’ll test it while investigating.

@MStraeten I think we’re interpreting the manual differently. It’s not implicitly obvious from the statement you quoted what darktable will do with metadata from sidecar files that were generated by software other than Lightroom. If that is actually the case (that it only supports Lightroom’s xmp files) then we should either file a bug against the docs, or submit a pull request if we have access, to clarify that. I would agree the author may have intended it to read as though only Lightroom is supported, but if that’s the case we can improve on the way it’s worded.

@rvietor Good question, I was specifically testing tags so didn’t have any other metadata defined on this file. The xmpmeta tag I mentioned documents which underlying XMP library is used; I thought a dev might be able to infer something from it. It’s not an XML namespaces thing, more likely just a descriptive label for a human.

Regarding delimiters between tags, Aperture (and darktable) both put each tag in a separate <dc:li /> tag, nested inside a <dc:Bag /> tag. It’s one of the few parts of the file that’s consistent between the two files. And Aperture’s just using whitespace between its XML tags; it’s a valid doc.

And yes, the files are in the same directory. I think I’ll have a play with exiftool to see if I can rewrite Aperture’s files into something else that’s supported. And if that doesn’t get me anywhere I’ll probably write some code to convert Aperture’s files to darktable compatible ones. I’ve got things to try, at least!

If I end up filing a bug I’ll come back and link to it here.

I’m willing to be that this, along with perhaps the lack of a namespace for light room, is what is tripping you up. <? denotes a processing instruction, while the other denotation means you’re getting a valid XML file.

You can run darktable from the CLI with darktable -d all to see if there are any messages about the xmp file while importing.

Otherwise, if you provide some sample files and note what information you want transfered, we can probably help construct a script that will move it into a format darktable understands.