There are times when I have to remove an image from the library and then re-add to library (to change it’s and the corresponding sidecar’s name for example) and I’ve noticed that my tags are changing upon re-adding.
here is an example of the tag structure before I remove the image:
here is the same image’s tags and xmp file after removing from library, closing darktable (I have darktable look for updated xmp files on startup) and re adding to library:
any idea why this is happening? The tags upon re-adding are the old legacy keywords from when I was using Adobe Bridge and from when I first imported the files into darktable and darktable read the original xmp files. The Adobe created xmp files have long been deleted so all that is left in the folder are the raw files together with the darktable created xmp files (.NEF.xmp files in my case).
I know tag information is written to both the xmp file and the library but by removing from library, shouldn’t the tags on the existing xmp file be used to repopulate at the library level?
I move all of my files to new HDDs every few years or so so the thought of having this happen to every folder I have to re-add to library to re-map the files in darktable is quite concerning.
update: I made a mistake in my original post. Turns out that that folder did indeed have some of the old xmp files so the screengrab of the xmp after re-importing was incorrect. I went through the process of removing from library and re-adding and here is the .NEF.xmp after I re-added the photo so now the tags should match the second lighttable tagging window above.
I checked the time stamp and it seems the .NEF.xmp file is being updated upon adding to library even though there is a darktable format xmp file already there and I’ve done nothing to the photo other than remove and re-added.
Say I’m adding a photo for the first time to darktable, I would certainly expect for darktable to create a new .NEF.xmp file because that is how it is setup in settings by default (upon import).
Now that the photo is in darktable, I add/change tags and/or make some edits, those tags and edits are written to the .NEF.xmp file. So far, all is good and the .NEF.xmp file should represent my desired state for that photo in darktable.
Now say I have to rename that photo so I remove that photo by going actions on selection>remove. I rename the basename for both the raw file and the .NEF.xmp file. I then go to Import>add to library and select the folder that that photo is in. Now that the photo is back into the darktable library, the tags are only partially correct. I’ve also tested this by removing and re-adding without re-naming and the same thing happens.
I understood that one of the big benefits to sidecar xmp files is that your tagging and edits travel with the photo. But instead of reading the existing .NEF.xmp, darktable seems to be writing a new file, or at least updating it (the date modified changes when I view the xmp file in File Explorer.)
I did one more test by changing darktable settings>storage>XMP sidecar files>create xmp files to never. This time, the sidecar file was left alone but the tagging window in lighttable changed from what the sidecar file shows.
here is a visual summary: I’m using darktable 5.4.0
desired state of tags in lighttable tagging window
Since you’ve removed it, it is a new image, thus the XMP has to be regenerated.
What version of darktable was the original XMP file from? There have been changes to the tagging system and the changes you see in the XMP may simply be bringing the tags up to date with the current darktable version.
I think I can reproduce it. The root cause seems to be the comma in your subject tag. When re-importing, the tag gets split at the comma, so the remaining tag for the imported image is “animals”, and the rest after the comma is lost.
They may have been created with 5.2.1 and I’m now on 5.4.0. If that were the case though, wouldn’t that be resolved when I correct the tags in 5.4.0 and run the experiment all over?
What i don’t understand is why a new extension.xmp has to be generated if an extension.xmp file already exists? The order of operations should be if an existing extension.xmp file exists, read it, otherwise, create one. If darktable is going to create a new xmp everytime a photo has to be re-imported, what’s the point of the existing xmp?
ok, stupid beginner question but related to the above, there is a section here called play_raw where it looks like people are uploading their raw files and others have a go at it and post their version of edit along with the xmp file with their edits. The only way that’s useful is if anyone can take that xmp file, drop it into their folder and see what that person did with the edit. Now imagine if you did that and darktable on your side (mostly) ignores that xmp and writes a new one. I must be missing something, right? Maybe there is something off with my setup/options?
I’m just adding to library as the file are already in the folder. I only use copy & import for new photos from a card that don’t yet exist on my hard drive. Someone here suggested it might be how I have commas in my taggs. This explanation looks promising and I’m going through the process of updating my tags and re-testing. Thanks for the reply!
mate, thank you sooo much!! that was it! The only remaining issue I now have is that the copyright info drops off. I can see where the rights info is written to the xmp but not the copyright.
solution found! Someone suggested it could be the commas in my taggs. I replaced the commas with hyphens and issue resolved. Turns out that upon re-import, the subject tagg was split at the comma and ignored everything after that. Thanks you your help though. Much appreciated!
