Hi. I think sidecar files should allow to basic modes of usage: 1) Write all known metadata to the sidecar files This seems to be what we have now, although not really everything seems to be written, e.g. all the MarkerNote data is NOT in the sidecar files. I must admit that I do not see any real use case where one wants to do this in contrast to (2) below. 2) Write only changed data to the sidecar files. IMHO this is actually the main way how things should be used... sidecar file in principle suck for many reasons but they have two big usage scenarios: a) when you don't want to modify the meta-data of the image themselves (i.e. one just want's to override something, like a description or geodata) b) when one can't change the meta-data easily for technical reasons (e.g. would corrupt the image, confuse other software, or one wants to add so much data that simply can't be encoded in the binary meta-data chunks (a) is IMHO the main reason here. What I tried was taking an image, and overriding it's camera model field, what I got is however the big attached xmp file. But IMHO: <?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="" tiff:Model="foobarcamera "> </rdf:Description> </rdf:RDF> </x:xmpmeta> should have been enough (well perhaps some xmlns are missing). btw: Why tiff:Model? Shouldn't this be some exif:foo property? The "same" happens (right now) when I go to the maintenance mode and rebuild the meta-data... all files get XMP sidecar files, even nothing at all has changed on them. I personally think mode (2) would be enough, i.e. only storing changed data to the sidecar files, but at least there should be an option which makes it doing only this... there's not much reason for this meta-data duplication. Cheers, Chris. Reproducible: Always
Created attachment 78997 [details] full sidecar file
btw: Of course this idea also includes to always write only minimised files, i.e. if I haven't set any of: <rdf:Alt> <rdf:li xml:lang="x-default"/> </rdf:Alt> don't write them. Or if nothing digikam specific is used... don't include the digikam xmlns ... same for Dublin Core, etc.
How is your proposed usage of sidecars covered by the XMP specification? Does it work with Adobe products? How is "removal" of a field implemented? (file shall not be touched, contains a comment, comment shall be removed from metadata)
Admittedly, I'm not that expert of XMP (or MWG)... just have had some glances over them when they came out.... so I may be wrong. AFAIK, the sidecar files are "specified" in Part 3, but little ist given about them, especially no information about whether or how any merging is done when metadata is found in multiple places - or at least I couldn't find anything: While it says "Write the external file as a complete, well-formed XML document, including the leading XML declaration."... this doesn't necessarily mean that any Exif or what ever needed to be complete, does it? I wouldn't read it like that. Perhaps one should talk about this to them?! You're right that there would be probably no way to denote the removal of a field. It's probable though, that my proposed usage is not standardised... nevertheless... wouldn't it be the better way? If you agree, one could possibly try to contact the standard editors on that issue. Chris.
You are right, sidecars are very much underspecified. In particular, the important MWG guidelines which talk about reconciliation between the different formats dont care about sidecars at the moment. In the absence of a written standard, one source is to look at other software supporting sidecars, and to think about what is possible and what not. Removal is really an important point, please see bug 309058 and our implementation in KExiv2::Private::loadSidecarData. In fact, if there is a sidecar which does not contain a comment, then we will not use the comment from the file, as it is removed from the XMP sidecar which "dominates".
Anything new here? I just stumbled again over this... I mean apparently we won't likely get any "standard" here soon,... i.e.. a specified behaviour on what happens with the meta-data in sidecar files: 1) do they completely replace the image-metadata? 2) do they get merged per property (probably in the sense of "overriding") image-metadata? 3) is there a more complex merging i.e. that some properties are only merged as group like if the image contains GPS-Lon, GPS-Lat and GPS-Alt ... but the sidecar file contains only GPS-Lon, GPS-Lat then these two will be taken but GPS-Alt will be "cleared" So could digikam simply offer at least (1) and (2)? They don't seem to be too difficult to implement... I guess on would need a configuration option for how sidecar files are read and one for how they are written. Right now I just tried to change the orientation of an image... and I got that: <?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:digiKam="http://www.digikam.org/ns/1.0/" xmlns:exif="http://ns.adobe.com/exif/1.0/" xmlns:photoshop="http://ns.adobe.com/photoshop/1.0/" xmlns:tiff="http://ns.adobe.com/tiff/1.0/" xmp:CreatorTool="digiKam-3.5.0" xmp:CreateDate="2014-04-01T17:49:22" xmp:MetadataDate="2014-04-01T17:49:22" xmp:ModifyDate="2014-04-01T17:49:22" digiKam:PickLabel="0" digiKam:ColorLabel="0" exif:DateTimeOriginal="2014-04-01T17:49:22" exif:PixelXDimension="1429" exif:PixelYDimension="1056" photoshop:DateCreated="2014-04-01" photoshop:Urgency="0" tiff:DateTime="2014-04-01T17:49:22" tiff:ImageWidth="1429" tiff:ImageLength="1056" tiff:Compression="1" tiff:PhotometricInterpretation="2" tiff:Orientation="8" tiff:SamplesPerPixel="3" tiff:PlanarConfiguration="1" tiff:XResolution="419430400/2097152" tiff:YResolution="419430400/2097152" tiff:ResolutionUnit="2" tiff:Make="EPSON" tiff:Model="Perfection V700/V750" tiff:Software="SilverFast 8.0.1 r42 (Mar 14 2014) 9978c52 14.03. "> <tiff:BitsPerSample> <rdf:Seq> <rdf:li>8 8 8</rdf:li> </rdf:Seq> </tiff:BitsPerSample> </rdf:Description> </rdf:RDF> </x:xmpmeta> I what I'd prefer however is rather something like. <?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:tiff="http://ns.adobe.com/tiff/1.0/" xmp:CreatorTool="digiKam-3.5.0" xmp:CreateDate="2014-04-01T17:49:22" xmp:MetadataDate="2014-04-01T17:49:22" xmp:ModifyDate="2014-04-01T17:49:22" tiff:Orientation="8" </x:xmpmeta> - I don't need the photoshop crap,... so there should be some checkbox somewhere, whether these fields are written per default. - Since that was a TIFF file, and the orientation is apparently stored in some TIFF properties,... I don't need any Exif either (I haven't changed it) - All the other TIFF properties weren't changed, so they shouldn't appear either. - Neither have I changed the digikam Labels... so I guess those should be dropped, too, and as a consequence the namespace as well. Cheers, Chris.
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.
Well it would still be nice to see such feature... so yes.