optionally keep image extension in XMP sidecar file names
Needs ReviewPublic
Actions

Authored by jakobmalm on Jan 3 2018, 8:22 PM.

Details

Reviewers

None

Group Reviewers

Summary

Many programs (Capture One Pro, Lightroom (I believe), and others) construct the XMP sidecar file name without the image file name extension, replacing it with 'xmp'. digiKam (and several others, like darktable) instead append '.xmp' to the full image file name, including the original extension.

There are pros and cons to both approaches.

The changes in this commit make it configurable to keep the image extension or not in the file name when constructing an XMP sidecar file name.
A checkbox (defaults to checked) "Keep Image Extension in XMP Sidecar Name" was added to Settings > Configure digiKam > Metadata > Sidecars.

Some references:
https://bugs.kde.org/show_bug.cgi?id=264007
https://photo.stackexchange.com/questions/86830/digikam-metadata-in-xmp-sidecarfiles-using-myphoto-xmp-instead-of-myphoto-jpg-xm
https://mail.kde.org/pipermail/digikam-users/2012-June/016381.html
https://mail.kde.org/pipermail/digikam-devel/2013-January/065996.html
https://discuss.pixls.us/t/linux-applications-and-their-non-standard-xmp-sidecar-naming-convention/2688

Note:
Because the member functions involved in MetaEngine are static, I access the setting using the MetadataSettings singleton. This is not the current behaviour in MetaEngine with other settings, but I think this is a good way to accomplish the goal. An alternative would be to make the functions non-static, but my guess is that it would involve quite a bit of refactoring. (And I'm not sure why the settings are currently being copied into MetaEngine, when they could just be accessed using the MetadataSettings singleton...)

Diff Detail

Repository

R482 digiKam

Lint

Lint Skipped

Unit

Unit Tests Skipped

jakobmalm requested review of this revision.Jan 3 2018, 8:22 PM

jakobmalm created this revision.

As far as I see this does not handle/prevent/... the case where there is two different files with the same name but different extensions (e.g. name.dng and name.tif) - am I missing something?

Do we have to handle/prevent/... that case? As a user, I'm totally fine with having to handle that myself, if that means I get a pretty straightforward way to interact with the programs that I use.

Will this break something, or lead to problems in the execution of the program?

You can have a situation where name.tif has tag A and name.dng tag B. With name.xmp scheme the information in the database will then be inconsistent with the information in the file. It is essentially a race which is written to xmp first, i.e. when writing information from db to file metadata, whether name.xmp ends up with tag A or B is random. I don't know whether it will create problems with the execution, but I wouldn't be surprised.
A simple way to minimize this risk would be to only allow "name.xmp" scheme when the option to write to xmp for raw formats only is checked. Unless someone converts from native raw to dng it is rather unlikely, that there will be a naming conflict.

Revision Contents
Changeset List

			Path	Packages
M			libs/dmetadata/metadatasettingscontainer.h (1 line)
M			libs/dmetadata/metadatasettingscontainer.cpp (3 lines)
M			libs/dmetadata/metaengine.cpp (15 lines)
M			utilities/setup/metadata/setupmetadata.cpp (11 lines)