The template metadata feature set all photo information at the same time, not one by one, to be faster.

If you want to edit one by one these information, go to Image/Metadata/Edit All Metadata. This will lauch a dialog to change Exif,Iptc, or XMP metadata.

Gilles Caulier

Thanks for your answer.

I want to edit for example the copyright for a bunch of fotos but not using a template.
A template is fine for copyright, but not for all the metadata. 

Maybe I missed the point but if the input fields would be editable it would be perfect.

Created attachment 72141 [details]
edit copyright tool

Yes, it's possible to do it through Metadata Editor from kipi-plugins.

Gilles Caulier

Yes, it is possible but it is not a nice way to do it at all. It would be a lot more intuitive to use the template to pre-fill the entries, if wanted, and let the user simply edit those fields from the main digikam window. After all those fields are there and visible so it is quite frustrating not to be able to edit them.

So, we are up to 2014 and this "bug" still exists. Templates are nice, but some of the information on that panel (particularly the location data) SHOULD be directly editable. Or maybe, more appropriately, it should be on the "Descrption" tabe since that is what it actually is. It should be something the user can edit directly without having to navigate to a modal dialog box and manually go to those fields. That is incredibly slow and tedious for a large collection of images.

*** Bug 333845 has been marked as a duplicate of this bug. ***

*** Bug 333359 has been marked as a duplicate of this bug. ***

*** Bug 256849 has been marked as a duplicate of this bug. ***

Firstly, I see that there have been people other than myself complaining about this as far back as January of 2012 if not earlier ( http://mail.kde.org/pipermail/digikam-users/2012-January/015725.html ). The complaints are consistent and do not vary by platform / distribution. That makes this a confirmed bug in a KDE member project and not the distribution maintainers' problem. I for one have been annoyed by this on Slackware (which doesn't mess with anything) as well as Fedora and Ubuntu (distributions that are more opinionated).

Secondly, all of the proposed "fixes" and "work-arounds" I have seen don't actually address the core problem: the template system is functioning on some false assumptions. We should not be telling end-users that if they only do some command-line voodoo then their problems will be solved. They'd not be using Digikam if CLI voodoo was the most reasonable solution.

So, let's clear some things up about how users are clearly expressing that they expect templates and Metadata Editing to behave.

(1) If there's not a value there in the template, but the original contains a value in that field then users expect the two to be _MERGED_ and not that the template set original fields to empty if not set in the template. Unfortunately, this isn't always what happens—and when it is actually happening sometimes it is hard to tell because of the way the UI is set up (it doesn't warn the user when EXIF/IPTC/XMP fields contain different values, for instance).
Ideally, fields in the template would be "multi-state" in nature—empty + overwrite, filled-in + overwrite, filled-in + append (when supportable), filled-in + "use as default if not set already", and empty + ignore / don't clear. That can be boiled down to a few fairly simple epi-metadata properties ideally in the form of an "always overwrite / merge (when possible) / don't change existing value / use as default" selector per metadata field (presuming that "use as default" only overwrites empty fields).

(2) Templates should act like templates. They are starting points, not the end result. This is related to my first point and is the crux of the original complaint in this bug report. In fact, both (while potentially separate work items) should be fixed at the same time. If the "Caption / Tags" panel is going to be read / write for some fields then it should be for all of them, even if a template has already been applied. Conversely, perhaps the panel _should_ be read-only and double-clicking on a field opens it in the "Edit All Metadata" modal dialog.

Affected Versions: everything from the 0.x vintage through 3.5.0
Affected Distributions: All tested (including, but not limited to Debian, Fedora, RHEL, Slackware, and Ubuntu)

(In reply to Drew N from comment #9)

> If the "Caption /
> Tags" panel is going to be read / write for some fields then it should be
> for all of them, even if a template has already been applied. Conversely,
> perhaps the panel _should_ be read-only and double-clicking on a field opens
> it in the "Edit All Metadata" modal dialog.

I just tried editing the "Title" and "Comment" properties of an image using the "Caption / Tags" panel and not only did it not show the location information I had set (and then synced with the file), which was clearly visible in the "Metadata" viewer panel, it cleared the location metadata that I had just set when applying the title and comment changes. When I find the right bug, if it already exists, I'll tack that on there too. This indicates a larger potential problem.

Thank you Drew! 

I love digikam, but this design flaw is the #1 frustration for me managing my archive. Photos need individual locations, captions and descriptions and to efficiently manage photos (like a professional with power of open source), that meta-data should be editable directly on the panel just like the tags and other meta-data.

Templates are NOT a workable solution since every photo can (an usually does) have a distinct set of location and description data. The "edit all metadata" dialog is a DISASTER for managing more than a trivial small set of photos. Returning from a shoot, I might add 100 to 1000 photos and in many cases there are 10 to 100 locations that are needed. 

I use digikam on 3 different operating systems: Linux (Ubuntu), Windows and OSX. This is not a platform specific bug, but a design flaw in Digikam.

(In reply to Andrew from comment #11)
> Templates are NOT a workable solution since every photo can (an usually
> does) have a distinct set of location and description data. The "edit all
> metadata" dialog is a DISASTER for managing more than a trivial small set of
> photos. Returning from a shoot, I might add 100 to 1000 photos and in many
> cases there are 10 to 100 locations that are needed. 

I think what was originally intended (having done some UI/UX work) was that the user would duplicate or modify an existing template for each new variation and then apply that new variation to the set of photos in that group. Unfortunately that is unworkable in the long run for anything more complicated than "vacation" photos from a single event / location.

All I want from templates is to be able to apply copyright, attribution, contact information, and use instructions (such as tagging everything with the CC BY-NC-SA license) without messing up other fields and without making it difficult to edit other fields ad-hoc. Alas, Darktable cannot do that properly by itself yet, so I am using Digikam to do it.

Correct! Even for something as simple as a vacation, the location information is ussually distinct for each photo if I'm filling it out properly (saying "Puerto Rico" isn't helpful, I want to know it was the Fort of San Jaun, Puerto Rico, but obviously ever photo in that album isn't from there). 

The catch phase for Digikam is "Manage your photos like a pro with the power of open source." Even if regular uses routinly want to set uniform location information, that isn't helpful for power users. 

Can templates have a checkbox next to each seciton to enable/disable that section. That way you can set up a template to change whatever sub-set of the information you want, from everything to just one field (or one set of fields). Turn them on by default, but then let those of us that need the flexibility disable parts of the template and edit the location information in the side panel.

The current design is clearly a "it is good enough for this trivial test case" solution. It doesn't work for real users.

*** Bug 358238 has been marked as a duplicate of this bug. ***

I really like digikam and use it for quite some time now, but this is the one big flaw of digikam that ever since annoys me. I find it very unintuitive that the fields of the "Information" tab are not directly editable. Having templates is nice as an additional tool but it is not a replacement for being able to edit fields directly.
Further, according to this old mail from the malinglist, it indeed was once possible to do it (https://mail.kde.org/pipermail/digikam-users/2012-January/015668.html).

As this bugreport is really old now, I would like to know: are there intentions to eventually fix this?

*** Bug 381463 has been marked as a duplicate of this bug. ***

Version 5.6. Still same issue. A pain.

I'm putting in my 2 cents on this report. I agree with Andrew and Drew. Opening a modal window to edit image specific IPTC fields is neither intuitive nor does it encourage good data management habits. These location fields (sub-location, city, state/province, country) should be editable in the same area as the Title and Caption fields of the right sidebar in the main window.

And templates should not used for data that changes image to image. Best use of templates is for info that does not change often, but should be applied to every image that is imported. Things like creator info, copyright and usage info, etc.

I also wish I could edit my comment... But, I should add, I have been experimenting with Digikam since 5.6. I am now using 5.9.

The bug is still here.

Git commit d672e63c7174e09935b27bcdd55e3d5fb1627791 by Maik Qualmann.
Committed on 06/12/2022 at 18:11.
Pushed by mqualmann into branch 'master'.

change template behavior to merge the metadata
- empty template fields no longer overwrite metadata
- fix removing template when using sidebar
- no empty metadata is written.
Related: bug 449754

M  +2    -2    NEWS
M  +4    -7    core/dplugins/bqm/metadata/assigntemplate/assigntemplate.cpp
M  +2    -14   core/libs/fileactionmanager/metadatahub.cpp
M  +71   -0    core/libs/metadataengine/containers/metadatainfo.cpp
M  +2    -0    core/libs/metadataengine/containers/metadatainfo.h
M  +48   -0    core/libs/metadataengine/containers/template.cpp
M  +5    -0    core/libs/metadataengine/containers/template.h
M  +90   -36   core/libs/metadataengine/dmetadata/dmetadata_iptc.cpp
M  +102  -57   core/libs/metadataengine/dmetadata/dmetadata_template.cpp
M  +3    -8    core/libs/properties/captions/disjointmetadata.cpp
M  +19   -2    core/libs/properties/captions/itemdescedittab_infoview.cpp
M  +8    -8    core/utilities/import/backend/cameracontroller.cpp

https://invent.kde.org/graphics/digikam/commit/d672e63c7174e09935b27bcdd55e3d5fb1627791

*** Bug 465854 has been marked as a duplicate of this bug. ***

*** Bug 392978 has been marked as a duplicate of this bug. ***