the proposal will make complex tag<=>metadata management. This have a lots of side effect everywhere.

My viewpoint : WONTFIX

Andi, Marcel ?

Gilles Caulier

Hmm. Couldn't this be implemented by adding a flag to every tag in the database whether to write it to the image or not?

The flag could be inherited from parent tag on tag creation, so in daily use it would be quite simple to use:

Just add a tag(-category) like "marker", set the flag and then all sub-tags will have the flag set, too.


For READING tags from imported images the flag can be ignored - if the same tag is already in the image, just write it to database.

We can keep this bug for the future, if we should update the tags db schema at some time we can think about this again. I faintly remember a similar wish where certain tags were meant for publishing, others for private use.

It could be "fixed" by workaround: export plugin which will clear (or edit, or apply) metadata by choice.

Such feature could also be not special plugin but some widget(?) in many other plugins where pictures are exported from collection.

At the moment I'm tagging and sorting photos of my last holiday and I am remembered how useful this feature would be.

Tags are very useful to mark photos for a short time for further processing.

A concrete example: I'm geotagging all the photos, but have no track for some time (inside building, battery empty, gps tracker crashed), so I use the korrelator again, but with huge values for time gap.

To find the fotos, I first do a GPS search for the holiday area, tag all photos as "Geotagged", then switch back to my album, activate "Geotagged" tag filter, select all photos, deactivate the Geotagged filter, invert selection, tag all selection photos with non_geotagged, use the correlator again and then manually check all photos with "non_geotagged" tag if the location is correct.

Finally, I remove the geotagged and non_geotagged tags from the images.

Tagging and especially untagging the photos takes a lot of time, (for example untagging all 383 photos took more than 4 minutes for me), because of the write access to the jpg files.

I agree with original poster.  There are lots of ways to use tags that are not specific to a picture but are useful to collections of pictures.

One way to solve this would be to run two databases:  One is PICTURE meta data.
One is DIGIKAM meta-data.  

Digikam meta-data examples:
Tags can get out of hand if you use lots of them. Tag sets could be define for the collection level. So the tag-tree would have the option:  Show this branch only for this album.

Slideshow tags.  
If you work in PR or are a public speaker, you will have BUNCHES of slideshows for different purposes. And you are adding/subtracting stuff to them all the time.  If you can tag for "Church group speech" "Kiwanis" "Outdoor Ed"  Sure you can use regular tags for this, but those tags may not be best in a picture.


Workflow tags.
Several programs I've run into have tag sets that reflect the stage in the workflow.  E.g.
Pix come in and are assigned a tag unviewed.
The act of viewing it once changes it to viewed.
After going through the entire collection, and chucking the duds, the status
for every pic can be set to "culled"

Set tags.  We all do it.  We take 50 pix of something, chuck 30.  Of the remaining 20, there are 2 sets of 6 and one set of 8 that are essentially duplicates, but you don't want to chuck them, because they are all good.

So you mark them as a set.  Pick one as canonical for the set.  In thumbnail view this shows up as a stack of slides in one corner.  This is code for, "This slide has a bunch of almost identical siblings.

If possible sets should be nestable.

(This sort of thing is has great power for a commercial user.  A good way to
prove that you are the original owner of a picture is the ability to produce shots from the same session.  This would be very hard to fake.)

Marcel,

What's the status of this file with 2.x serie ?

Gilles Caulier

not implemented...
In principle, there is no problem to mark a tag as "dont write to the picture", it's easy to implement in the database
Another point is "deferred writing of metadata to pictures", discussed in 227814 and 268688

My view would be having "internal" tags which you could defined with following properties:
- never written to file (image meta or xmp)
- never exported (picasa, flickr & co)

As an example for me, I'm using the lock function of my Nikon D90 as a way to pre-rate pictures on camera and my import script transform the "lock" (just read-only fat32 attribute) in an exif rate of 1 with a tag d90lock, which I keep but obviously don't want when exporting albums & co.

The problem with deferred writing is: are you using internal/fast tags only temporarily or do you want to keep them. if the latter, at some point, you will enable meta writing and write them wether you wanted it or not.

I agree to Mikolay
"It could be "fixed" by workaround: export plugin which will clear (or edit, or apply) metadata by choice. Such feature could also be not special plugin but some widget(?) in many other plugins where pictures are exported from collection."

I won't call it workaround, because It wouldbe the smarter solution.
As a routine, which can be used by every export-plugin with it's own preset data.
So you can store all the metadata in the database; with the affect of increasing workflow speed.

If the digiKam-team solves this wish in this way, it would be great to make the preset data URL / mailaddress depending. So you will provide different presets for the same gallery provider (e,g, private / public) or receiving adress (e.g. customer / WordPress-workaround by Dimitri Popov).

Another aspect is that changes in meta data may cause changes in the pictures, so they will be backed up (is this correct english?) the next time. Having those fast tags would avoid this.

HP

The feature is present in Digikam 5.0.0 and it is called Lazy Syncronization, which can be enabled in Metadata Settings.