First of all exiftool is amazing and can do almost everything.
I have to rename image files which have darktable sidecar file ant try to do it with exiftool.
The typical file names are _IMG0001.CR2 and _IMG0001.CR2.xmp
Renaming the image file itself is easy and even renaming the sidecar file is not too complicated :
exiftool -tagsfromfile %f '-FileName<CreateDate' -d %Y%m%d_%H%M%S%%-c.CR2.%%e -ext xmp [i]DIR[/i]
(by the way, I woul'd like not to use "CR2" in the command in case Canon invent "CR3" some time but I couldn't)
The last issue is that the sidecar file keeps the name of the original image file name this way :
xmpMM:DerivedFrom="_MG_0001.CR2"
(sample darktable xmp file attached)
exiftool can read it like this :
exiftool -DerivedFrom _MG_0001.CR2.xmp
Derived From : _MG_0001.CR2
exiftool cannot set it :
exiftool -DerivedFrom=whatever _MG_0001.CR2.xmp
Warning: Improperly formed structure for XMP-xmpMM:DerivedFrom
Nothing to do.
Is there some workaround or have I to go back to awk/sed/perl... ?
Rgds
Chrisaga
It looks like Darktable is using the DerivedFrom name as a simple string tag when it's supposed to be a structured tag, containing a variety of metadata (http://www.exiftool.org/TagNames/XMP.html#ResourceRef).
StarGeek posted while I was composing my response. :)
Here is what I had written:
Hi Chrisaga,
You should report this bug to Darktable. xmpMM:DerivedFrom is a ResourceRef structure, not a simple string.
You can force ExifTool to overwrite the incorrectly written XMP using -m, but you need to first decide what you want to write. If you want to write an element of the ResourceRef structure, perhaps DerivedFromFilePath or something like that. See the XMP specification and the ExifTool xmpMM tags documentation (https://exiftool.org/TagNames/XMP.html#xmpMM) for more information.
- Phil
Quote from: Phil Harvey on April 08, 2017, 12:30:54 PM
StarGeek posted while I was composing my response. :)
And I almost waited to post until after I took out the trash. :D
If you report this as a bug, you can refer them to page 28 of XMPSpecificationPart2.pdf, table 29 (http://www.adobe.com/content/dam/Adobe/en/devnet/xmp/pdfs/XMPSpecificationPart2.pdf#page=28).
Edit: It looks like this (https://redmine.darktable.org/issues/9064) is the feature request that ended up adding (https://redmine.darktable.org/projects/darktable/repository/revisions/664cf7cbaef9b83fbc58eb0d87069d9e716edaf1) it to Darktable.
Thank-you both StarGeek and Phil.
It was already clear for me that ExifTool expect DerivedFrom to be a structure but exiv2 aparently don't and DarkTable relies on exiv2. Or maybe it's only a DarkTable thing ...
I will try Phil's workaround and use DeriveFrom as a simgle string because this sidecar file is where DarkTable keeps all the development parameters for the corresponding image file.
Therefore, I want to keep it the same, even if it's wrong.
Well I tried using -m but it won't do the trick.
Checked ExifTool man page and found that it probably cant override this warning since it is not reported as [minor] nor [Minor].
:-\
I meant to use -m with DerivedFromFilePath. ExifTool won't write DerivedFrom improperly as a string unless you override the standard definition with a user-defined tag. See the sample config file (https://exiftool.org/config.html) for examples if this is what you want to do.
- Phil
I tried to report the issue here (https://redmine.darktable.org/projects/darktable/issues/new), but since I'm on windows and they don't have a windows build that I can test, I can't really completely fill out the issue properly and don't want to just fill it with fake data.
Thank you Phil
I managed to redefine XMP-xmpMM:DerivedFrom in a config file to set it as a string and not a structure and it worked.
Content of the test.cfg file :
%Image::ExifTool::UserDefined = (
'Image::ExifTool::XMP::xmpMM' => {
# Redefine XMP-xmpMM:DerivedFrom as a string (not a structure) for use on DarkTable sidecar files
DerivedFrom => { },
},
);
The following command finally works :
exiftool -config test.cfg -DerivedFrom=whatever _MG_0001.CR2.xmp
ExifTool is really a great tool ! So versatile ! :)
Quote from: StarGeek on April 08, 2017, 04:06:17 PM
I tried to report the issue here (https://redmine.darktable.org/projects/darktable/issues/new), but since I'm on windows and they don't have a windows build that I can test, I can't really completely fill out the issue properly and don't want to just fill it with fake data.
Thank you StarGeek.
I'll try to report the issue but it will probably be low priority since those sidecar files are only supposed to be used by DarkTable itself
A few more data on this topic.
The original file looked like this :
<?xml version="1.0" encoding="UTF-8"?>
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="XMP Core 4.4.0-Exiv2">
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about=""
xmlns:xmp="http://ns.adobe.com/xap/1.0/"
xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:darktable="http://darktable.sf.net/"
xmp:Rating="1"
xmpMM:DerivedFrom="_MG_0001.CR2"
darktable:xmp_version="2"
darktable:raw_params="0"
darktable:auto_presets_applied="0"
darktable:history_end="0">
<dc:creator>
<rdf:Seq>
<rdf:li>Christophe Agathon</rdf:li>
</rdf:Seq>
</dc:creator>
<dc:rights>
<rdf:Alt>
<rdf:li xml:lang="x-default">© Christophe Agathon</rdf:li>
</rdf:Alt>
</dc:rights>
[...]
</rdf:Description>
</rdf:RDF>
</x:xmpmeta>
([...] is the location of a bunch of empty sequences)
After changind what DarkTable think is xmpMM:DerivedFrom, the file looked very different :
<?xml version='1.0' encoding='UTF-8'?>
<x:xmpmeta xmlns:x='adobe:ns:meta/' x:xmptk='Image::ExifTool 10.23'>
<rdf:RDF xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
<rdf:Description rdf:about=''
xmlns:darktable='http://darktable.sf.net/'>
<darktable:auto_presets_applied>0</darktable:auto_presets_applied>
<darktable:history_end>0</darktable:history_end>
<darktable:raw_params>0</darktable:raw_params>
<darktable:xmp_version>2</darktable:xmp_version>
</rdf:Description>
<rdf:Description rdf:about=''
xmlns:dc='http://purl.org/dc/elements/1.1/'>
<dc:creator>
<rdf:Seq>
<rdf:li>Christophe Agathon</rdf:li>
</rdf:Seq>
</dc:creator>
<dc:rights>
<rdf:Alt>
<rdf:li xml:lang='x-default'>© Christophe Agathon</rdf:li>
</rdf:Alt>
</dc:rights>
</rdf:Description>
<rdf:Description rdf:about=''
xmlns:xmp='http://ns.adobe.com/xap/1.0/'>
<xmp:Rating>1</xmp:Rating>
</rdf:Description>
<rdf:Description rdf:about=''
xmlns:xmpMM='http://ns.adobe.com/xap/1.0/mm/'>
<xmpMM:DerivedFrom>20170215_204340.CR2</xmpMM:DerivedFrom>
</rdf:Description>
</rdf:RDF>
</x:xmpmeta>
It's completely different (multiple rdf:Description blocks, variables replaced by <...> </ ...> blocks) but I did some tests and DarkTable accepts to import it along with the image. It immediately rewrites the file the way it likes.
Today's lesson : xml is kind of voodoo and ExifTool is a good gris-gris
;)
Yes, XMP (RDF/XML) is difficult from the programming point of view (https://exiftool.org/commentary.html#XMP) because it can take so many forms.
- Phil