after several years of smoothly working with digikam and darktable I noticed (by chance) that darktable is not writing the edits to xmp sidecars generated in digikam anymore. When the sidecar was generated by darktable, everything works fine as before, even with multiple changes in both. The issue obvioulsy started in April 2025 and after a few hours of fiddling and downgrading I am relatively sure that the problem has to do with the xml structure. Darktable generated sidecars start with <?xml version="1.0" encoding="UTF-8"?> while digikam begins with <?xpacket begin="" id="" ?> (since April 25, before they started with <?xml> too).
My workaround is to import new images to darktable first, let it write the sidecars and open the images in digikam after. If there is no other solution, I could live with that workaround in the future too, but (as probably the most of you) I would prefer to check and tag images first before editing them.
Downgrading to older digikam versions (AppImages in my case) is somewhat strange: I tried it until back to 8.3.0 (March 24) and all older versions surprisingly start the sidecar with <?xpacket> too. As mentioned above, they didnât do so before April 25: I have thousands of files generated by digikam versions 8.3.0 to 8.5.0 before April 25 starting with <?xml>.
So at the moment Iâm quite overwhelmed with this issue and would appreciate any hints what to do next.
Addendum: Using âwrite sidedar filesâ in darktableâs history stack module is not working either, when the xmp starts with <xpacket>.- Since darktable does not try to write a new sidecar file, it obviously detects that there is one avalaible, but doesnât seem to accept it and so does nothing at all.
Addendum 2: Meanwhile i doubt my assumptions were correct. Starting the sidecar with <?xpacket> does not seem to be the core problem, as darktable overwrites it with <?xml> as long as the orginal sidecar was not generated by digikam. Opening a file edited in darktable with digikam changes the header back to <?xpacket> and darktabe changes it to <?xml> after. You can repeat that as often as you like, if just the original file was generated by darktable. So the problem is rather something with the initial creation of the sidecar by digikam, but not the xml structure. Sorry for the confusion!
There is a setting in Digikam about what extension to use for sidecar files
Thanks, but the settings are the same since years: I use basename.ext.xmp and leave âsidecar file names are compatible with commercial programsâ unchecked, as it would cause the file name to be basename.xmp instead and thus (as far as I remember) the sidecar would be ignored by darktable at all. So I tend to exclude a setttings issue.
the xpacket processing instruction is weird, and with the whole XMP data wrapped in a processing instruction, it is not surprising that dt doesnât read it, as processing instructions are not XML and the parser should just pass processing instruction along to the processor.
@Michmill do you know anything about this xpacket wrapper?
@paperdigits Just for the records: I tested AppImage versions 8.70, 8.6.0, 8.5.0, 8.4.0 and 8.3.0. All of them show the same behaviour. Strangely this definitely didnât happen when versions <= 8.5.0 were up to date. So maybe some other component is playing along.
Well, I also use both digikam and darktable, importing files first into digikam, adding keywords and descriptions, and then importing the files into darktable (through âadd to libraryâ). Not only does darktable read the digikam-generated sidecars, it also writes the edits back into the sidecars⊠And digikam is able to read back those sidecars. That is with digikam 8.7.0 and darktable 5.2.0.
To add to the confusion:
after digikam, and before import in dt, the sidecars start with <?xpacket begin="ï»ż" id="W5M0MpCehiHzreSzNTczkc9d"?>
after edits with darktable, the sidecars start with <?xml version="1.0" encoding="UTF-8"?>
Oh, and wikipedia, gives an example XML document for serialized XMP metadata in a JPEG photo, which starts with <?xpacket
Thanks. Another possibility, according to Microsoft, is that the offending sidecar file are, or have been caused to be ânot well-formedâ:
You may hear someone from your IT department mention âwell-formedâ XML. A well-formed XML file conforms to a set of very strict rules that govern XML. If a file doesnât conform to those rules, XML stops working. For example, in the previous code sample, every opening tag has a closing tag, so the sample adheres to one of the rules for being well-formed. If you remove a tag and try to open that file in one of the Office programs, you will see an error message, and the program will stop you from using the file.
You donât necessarily need to know the rules for creating well-formed XML (though they are easy to understand), but you do need to remember that you can share XML data among programs and systems only if that data is well-formed. If you canât open an XML file, chances are that file isnât well-formed.
@rvietor Exactly the same happened to me too, but unfortunately doesnât anymore. Do you use the apps on Linux or Mac/Win? And if on Linux: You use AppImages or other packages? Which distribution?
Iâm still trying to find where this long-functioning workflow broke off.