How to remove "left behind" tag tree

[Elle Stone]

When moving a tag with sub-tags to below another tag, so the original
tag is now part of a different tag tree, the tag-with-sub-tags still
is in the original location, too, in the xmp sidecar file, but it's
also in the new location. So it's now in the xmp sidecar file in two
locations.

How do I delete the original tag tree? It isn't showing up in the
digiKam tag tree, only in the xmp sidecar file.

Using exiftool to examine the xmp sidecar tagslist:
test-tag, test-tag/sub-test-tag, Intake/test-tag/sub-test-tag, Intake/test-tag

But in digiKam, in the tags sidepanes, only the tags under "Intake"
are shown. There is no tag-tree consisting of just
"test-tag/sub-test-tag". Rereading the metadata from the image (which
ought to reread the metadata from the sidecar file), isn't having any
affect, meaning it's not showing that the sidecar file really still
has the original tag tree in place. So there doesn't seem to be any
way to "redelete" the original tag tree.

I had this same problem when I was writing directly to the image file.
Except when writing to the actual images, eventually I was able to get
rid of the second copy, by some magic combination of selecting and
writing to all tags.

Kind regards, and hoping for some insight,
Elle Stone
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[tosca]

Hum... I begin to understand why I encountered such weird results when trying to reorganize my tags tree. Though I didn't investigate, I found the same tags in different places or the tree, depending on different parent.

Marie-Noëlle

2012/10/24 Elle Stone <[hidden email]>

When moving a tag with sub-tags to below another tag, so the original
tag is now part of a different tag tree, the tag-with-sub-tags still
is in the original location, too, in the xmp sidecar file, but it's
also in the new location. So it's now in the xmp sidecar file in two
locations.

 

--


Mes dernières photos sont dans ma galerie.
Retrouvez-moi aussi sur mon blog.
Et parcourez les Cévennes à ma façon avec Cévennes Plurielles,


_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Marcel Wiesweg]

> When moving a tag with sub-tags to below another tag, so the original
> tag is now part of a different tag tree, the tag-with-sub-tags still
> is in the original location, too, in the xmp sidecar file, but it's
> also in the new location. So it's now in the xmp sidecar file in two
> locations.

See bug 268688 and some similar reports.
Lot of work for a proper solution.



_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Andrew Goodbody]

On 24/10/12 19:21, Marcel Wiesweg wrote:
> See bug 268688 and some similar reports.
> Lot of work for a proper solution.

Yes, it's a long standing issue. It means that digikam currently behaves
in a non-intuitive way. I suspect that many people are editing their
tags hierarchy without realising that any already tagged photos are not
being updated resulting in inconsistencies.

It is the single biggest thing that I would like to be fixed in digikam.

Andrew
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Elle Stone]

On 10/23/12, Marie-Noëlle Augendre <[hidden email]> wrote:
> Hum... I begin to understand why I encountered such weird results when
> trying to reorganize my tags tree. Though I didn't investigate, I found the
> same tags in different places or the tree, depending on different parent.
>
> Marie-Noëlle

Hi Marie-Noëlle,

If you let digiKam write to your image files, you *can* get rid of the
duplicate tags. The trick is to follow the steps below, but please
check very carefully to make sure that these steps work for you before
deploying over all your images!

1.Use "Image/reread metadata from image" to reread all the tags. The
"left-over" tags will be pulled into the digiKam database and appear
on the tag tree. If you use exiftool to check, at this point you can
see the unwanted, duplicate tag embedded in your image file:

exiftool -a -s -G1 -tagslist 041126_141312.jpg
[XMP-digiKam]   TagsList: test/test1, Intake/test/test1

2. Go to the right pane, Filters, and select ALL tags (sounds odd, but
this seems to be necessary).

3. Go to the left pane, Album, and select the root album (or at least
the album that contains all the images with the leftover/duplicate tag
you are trying to remove).

4. Go to the left pane, Tags, and select the root tag of the tag tree
you want to remove, so only images with the unwanted tag will be
displayed in the center pane. Select (highlight) all of these images.

5. Go to the right pane, Captions/Tags, uncheck the unwanted tag, and
apply. The previously selected images will disappear from the center
pane. If you use exiftool to check, you will see that now the
unwanted, duplicate tag is no longer embedded in your image file:

exiftool -a -s -G1 -tagslist 041126_141312.jpg
[XMP-digiKam]   TagsList: Intake/test/test1

6. On right pane, Tags (or any other pane that shows all the tags),
delete the unwanted duplicate tag (but only if it isn't assigned to
any other images, or else you'll have to reread the image metadata to
pull the tag back in).

7. If you reread the metadata from the image, you'll see that the
unwanted tags really are gone. If you are using this procedure on a
whole lot of images, you may need to reselect them and write the
metadata to the images, and then reread to see if the unwanted tags
were deleted from all the images. I ended up having to repeat the
procedure several times to get rid of unwanted duplicate tags written
to around 3000 images.

Unfortunately, the above steps don't work if digiKam only writes to
the xmp sidecar files instead of directly to the image. It seems that
digiKam only *adds* tags to the xmp sidecar file but never takes tags
away. So the XMP sidecar files can't be kept in synch with the digikam
database. Which for me, given my workflow, makes the sidecar files not
useable. If there is a magic procedure for synchronizing the digiKam
database and the sidecar files, hopefully someone will share.

Kind regards,
Elle
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Elle Stone]

On 10/24/12, Marcel Wiesweg <[hidden email]> wrote:
> See bug 268688 and some similar reports.
> Lot of work for a proper solution.

That is the most depressing bug report I've ever read.

Writing *only* to the database has the advantage that writing to the
database is very fast and the disadvantage that if the database fails,
you lose all your metadata.

Writing to the database AND the images has the advantage that if the
database fails, you still have your metadata. It has the disadvantage
that writing to the images is slow: fixing leftover tags on 4000
images took hours on my not-so-new computer. Writing to the images has
the further disadvantage that if digiKam makes a mistake or has a bug
(it happens), you can lose your metadata or otherwise corrupt your
image.

Writing to the database and to an XMP sidecar file seems to be the
best of both worlds. Writing to the XMP text file is faster than
writing to image files. And I can check the contents of the XMP files
and if everything looks right, periodically use exiftool to transfer
the XMP file metadata over to the image file, thus keeping the
metadata in the image file in case the database fails (I've had bad
experiences with digiKam writing to the image files).

Unfortunately, writing to the XMP sidecar files doesn't work because I
can't keep the XMP sidecar files in synch with the database.

On 10/24/12, Andrew Goodbody <[hidden email]> wrote:
> On 24/10/12 19:21, Marcel Wiesweg wrote:
> Yes, it's a long standing issue. It means that digikam currently behaves
> in a non-intuitive way. I suspect that many people are editing their
> tags hierarchy without realising that any already tagged photos are not
> being updated resulting in inconsistencies.
>
> It is the single biggest thing that I would like to be fixed in digikam.
>
> Andrew

Agreed. I have around 10,000 scans and raw files that I haven't yet
added to the digiKam database, because I never quite felt like I had a
"workflow that works". So I am at a loss as to how to procede. Even if
writing metadata to the image files weren't so slow, I don't want to
risk writing to these additional image files. And using XMP sidecar
files seems not possible at present.

Elle


--
http://ninedegreesbelow.com
Articles and tutorials on open source digital imaging and photography
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Remco Viëtor]

On Wednesday 24 October 2012 20:36:30 Andrew Goodbody wrote:

> On 24/10/12 19:21, Marcel Wiesweg wrote:

> > See bug 268688 and some similar reports.

> > Lot of work for a proper solution.

>

> Yes, it's a long standing issue. It means that digikam currently behaves

> in a non-intuitive way. I suspect that many people are editing their

> tags hierarchy without realising that any already tagged photos are not

> being updated resulting in inconsistencies.

>

> It is the single biggest thing that I would like to be fixed in digikam.

>

> Andrew

> _______________________________________________

> Digikam-users mailing list

> [hidden email]

> https://mail.kde.org/mailman/listinfo/digikam-users

 

One of the problems you face in correcting this behaviour is that when you make any change in the tag tree, potentially ALL your images (or sidecars) will have to be rewritten. If you are doing some extensive re-organisation of the tree, this can happen multiple times. So simply synchronising the changes with the file metadata can get very, very slow (not to mention risk of write errors, but for that we have backups, in theory...). It will also feel very slow: you have a number of changes in mind, but after every chance you'll have to wait while Digikam updates the affected files

 

I think something like this asks for a kind of 'maintenance mode', where changes are put in a queue, and when you exit the maintenance mode, all changes are made in batch (to both database and images). If you cancel maintenance, no changes will happen.

That would allow each image to be touched only once at most, speeding up the whole process (*): checking what has to be done for an image only requires database access. In addition, if modifications of the tag tree outside maintenance mode are forbidden(**), it'll remind you that changing your tag organisation is something you should be doing rarely (IMO).

 

(*) There's still a lot of images to be rewritten, but that happens at a moment where the user has finished changing stuff, so it won't interfere as much.

 

(**) addition of tags can still be allowed, as it only affects selected images, and only adds to the metadata, nothing has to be removed.

 

Remco

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Elle Stone]

Remco, you are absolutely correct. Rewriting all the images is very,
very slow. A maintenance mode would be nice.

The slowness of writing to all the image files is one reason I've been
investigating using XMP sidecar files, as writing to a text file is
much faster than writing to an image file.  Unfortunately, apparently
digiKam doesn't reread the XMP files, so the XMP sidecar files can't
be kept in synch with the database.

I agree that changing your tag organization *ideally* should be done
rarely or never. However, in reality, figuring out how to organize
tags is an iterative learning process. No-one knows when they start
tagging images how they really want the tags to be structured. So tag
reorganization is essential for beginners and also for peope who've
been tagging for a while.

The last time I reorganized my tag tree was because digiKam doesn't
make it very easy to search on "not any tag in this entire tag tree".
So I broke the tag tree - which kept track of location by country,
stateprovince, city and sublocation - into separate trees, one for
country, one for stateprovince, etc.

Ideally all that location information belongs in the xmp metadata
fields (iptc-extended uses xmp rather than iptc):
xmp-iptcExt:LocationShownCountryName
xmp-iptcExt:LocationShownProvinceState
xmp-iptcExt:LocationShownCity
xmp-iptcExt:LocationShownSublocation

But I don't see how to get the location information where it belongs
using digiKam, as digiKam still wants to write location information to
iptc fields. And I don't know if digiKam can search on the
iptc-extended location fields, even if I used exiftool to enter the
information properly. So I'm using tags instead. Hence the tag
reorganization: I want to be able to easily locate images that don't
have complete location information.

Kind regards,
Elle

On 10/25/12, Remco Viëtor <[hidden email]> wrote:

> On Wednesday 24 October 2012 20:36:30 Andrew Goodbody wrote:
>> On 24/10/12 19:21, Marcel Wiesweg wrote:
>> > See bug 268688 and some similar reports.
>> > Lot of work for a proper solution.
>>
>> Yes, it's a long standing issue. It means that digikam currently behaves
>> in a non-intuitive way. I suspect that many people are editing their
>> tags hierarchy without realising that any already tagged photos are not
>> being updated resulting in inconsistencies.
>>
>> It is the single biggest thing that I would like to be fixed in digikam.
>>
>> Andrew
>> _______________________________________________
>> Digikam-users mailing list
>> [hidden email]
>> https://mail.kde.org/mailman/listinfo/digikam-users
>
> One of the problems you face in correcting this behaviour is that when you
> make any change in the tag tree, potentially ALL your images (or sidecars)
> will have to be rewritten. If you are doing some extensive re-organisation
> of the tree, this can happen multiple times. So simply synchronising the
> changes with the file metadata can get very, very slow (not to mention risk
>
> of write errors, but for that we have backups, in theory...). It will also
> feel very slow: you have a number of changes in mind, but after every
> chance you'll have to wait while Digikam updates the affected files
>
> I think something like this asks for a kind of 'maintenance mode', where
> changes are put in a queue, and when you exit the maintenance mode, all
> changes are made in batch (to both database and images). If you cancel
> maintenance, no changes will happen.
> That would allow each image to be touched only once at most, speeding up
> the whole process (*): checking what has to be done for an image only
> requires database access. In addition, if modifications of the tag tree
> outside maintenance mode are forbidden(**), it'll remind you that changing
> your tag organisation is something you should be doing rarely (IMO).
>
> (*) There's still a lot of images to be rewritten, but that happens at a
> moment where the user has finished changing stuff, so it won't interfere as
>
> much.
>
> (**) addition of tags can still be allowed, as it only affects selected
> images, and only adds to the metadata, nothing has to be removed.
>
> Remco

--
http://ninedegreesbelow.com
Articles and tutorials on open source digital imaging and photography
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Le 25/10/2012 15:22, Remco Viëtor a écrit :

> I think something like this asks for a kind of 'maintenance mode',
> where changes are put in a queue, and when you exit the maintenance
> mode, all changes are made in batch (to both database and images). If
> you cancel maintenance, no changes will happen.

or simply a "write only database for this session" mode. Writing to
the database is very fast (relative to writing to files)

jdd


--
http://www.dodin.org
http://jddtube.dodin.org/20120616-52-highway_v1115
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Jean-François Rabasse]

On Thu, 25 Oct 2012, Remco Viëtor wrote:

> One of the problems you face in correcting this behaviour is that when you
> make any change in the tag tree, potentially ALL your images (or sidecars)
> will have to be rewritten. If you are doing some extensive re-organisation
> of the tree, this can happen multiple times. So simply synchronising the
> changes with the file metadata can get very, very slow (not to mention risk
> of write errors, but for that we have backups, in theory...). It will also
> feel very slow: you have a number of changes in mind, but after every chance
> you'll have to wait while Digikam updates the affected files

I agree. And more, aside from « extensive re-organisation » of tags, even
the simple task of documenting new images leads to multiple metadata
updates. E.g. on a single image :
  - geolocating then clicking Apply --> write to image or sidecar
  - setting a title or caption, then Apply --> write
  - rating, --> write

etc.

Even if update time for a single image isn't that great (today, but
probably Nikon users remember the time where a buggy libexiv2 took about
10 seconds per file to rewrite Makernotes :-), it's not really optimal.


> I think something like this asks for a kind of 'maintenance mode', where
> changes are put in a queue, and when you exit the maintenance mode, all
> changes are made in batch (to both database and images). If you cancel
> maintenance, no changes will happen.

Indeed. A pseudo workaround is to disable all writing (the Metadata settings
folder, uncheck all options « Save Image tags to...», « Save caption and
title...», etc.) before working.
Then images edition, documentation, tagging can occur in database only mode.
When done, recheck on the desired write options, then run albums level
commands, « Write metadata to images... »
(Then go for a coffee:-)

But, instead of checking off (and on later) several write options, a kind
of maintenance mode could be a simple flag, or checkbox, « Delay metadata
writing ». AKO global write option.
Or another entry in the Metadata writing mode menu, « Write nothing »,
thant could be selected before extesive works, and set again later.
Perhaps, this could go on a Wishlist ?

BTW: geolocation seems to always write (to image or sidecar, depending of
the metadata writing mode) upon Apply. I don't see exactly the interest
of writing a picture location in a sidecar file only. As it's standard
Exif data, GPSsubIFD, this will prevent any coordinates aware application
(e.g. web services as GPS Visualizer) to work with the image :-(

But it could be really bothering for those of users that don't like DK to
write into images files, to select « Write to image file », before
geolocating, then switch back to « Write to sidecar file only » before
editing a title, etc. Plus the potential risk for mistakes.
I'd really be interested in reading users experience.

Regards,
Jean-François

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Jean-François Rabasse]

On Thu, 25 Oct 2012, Elle Stone wrote:

> The slowness of writing to all the image files is one reason I've been
> investigating using XMP sidecar files, as writing to a text file is
> much faster than writing to an image file.  Unfortunately, apparently
> digiKam doesn't reread the XMP files, so the XMP sidecar files can't
> be kept in synch with the database.

FYI :
Slowness problem comes from the metadata handling library, libexiv2,
used by Digikam, and DK isn't to be blamed. I have personal experience
with this library because I use it for some personal programs.
The API provides two major calls, readmetadata(), then writemetadata()
after edition. But what seems to me a design weakness is that the
readmetadata is actually a read-and-decode, instead of a read and wait
for decoding upon first need.

So, if a program wants to edit a XMP property, e.g. the Image title,
the read will also trigger a reading of the whole Exif section and full
decoding, including Makernotes parsing, and decoding all the stuff.
A really useless and high CPU consumming task !

But Digikam is only client of that library. Seems to be another good
reason to try to feature all things that could limit the needs for writing
to files, maintenance mode or such.


> I agree that changing your tag organization *ideally* should be done
> rarely or never. However, in reality, figuring out how to organize
> tags is an iterative learning process. No-one knows when they start
> tagging images how they really want the tags to be structured. So tag
> reorganization is essential for beginners and also for peope who've
> been tagging for a while.

And also for people that happen to import images sets that have been
tagged with another application. Digikam reads the hierarchicalSuject
fields when scanning for new images, and creates on the fly the tags
structure. But in 95% of cases, the structure set by another individual
isn't your personal structure, and you often need to reorganize, to fit
the original tags tree into yours.


> The last time I reorganized my tag tree was because digiKam doesn't
> make it very easy to search on "not any tag in this entire tag tree".
> So I broke the tag tree - which kept track of location by country,
> stateprovince, city and sublocation - into separate trees, one for
> country, one for stateprovince, etc.

A dirty trick to process missing tags :
Mark all your images with dummy tags, /Nocountry, /Nocity, etc.
Then select all images with the /Location/Country tag set, and drop the
Nocountry tag on these images. Etc.
At end, select all your images with /Nocountry, it's the « remaining »
not yet localized stuff.
A bit weird, but...


Regards,
Jean-François
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Remco Viëtor]

On Thursday 25 October 2012 17:23:31 Jean-François Rabasse wrote:

>

...

> I agree. And more, aside from « extensive re-organisation » of tags, even

> the simple task of documenting new images leads to multiple metadata

> updates. E.g. on a single image :

> - geolocating then clicking Apply --> write to image or sidecar

> - setting a title or caption, then Apply --> write

> - rating, --> write

>

Well, if the geolocation tab could be fused with the Caption/Tags tab, you'd only need one Apply command: at the moment, you can set title, caption, tags and ratings in one go, then click Apply only once to apply all those changes (currently, Geolocation is separate though).

 

Personally, I try and get the metadata complete for the RAW files, and then they are carried over to teh processed images (unless I use batch tools, but that's a different subject).

 

I'll have to think a bit about your proposed work-around, esp. in relation to OP's problem: keeping external tags in place, while removing outdated Digikam tags. My gut feeling is that that's going to cause difficulties.

 

Remco

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Elle Stone]

I'm not sure what you mean by "keeping external tags in place, while
removing outdated Digikam tags".

What I would like is that the tags in the XMP sidecar file exactly
synchronized with what is in the database: move a tag on the tag tree,
it should be moved in the XMP sidecar file; delete a tag on the tag
tree, it should be deleted in the XMP sidecar file. Etc.

I realize other people's workflow might require a different behavior.
But it seems like keeping the XMP sidecar and the database
synchronized should be an option, even if it isn't the default
behavior. Right now, writing to the images behaves very differently
differently than writing to the XMP sidecar files.

Apparently a lot of people have not succeeded in getting their
database synchronized with their image metadata after they move tags
around the tag tree. I posted the way to do just that earlier in this
thread. It isn't intuitive. But it works IF you allow digiKam to write
to your image files instead of only writing to XMP sidecar files.

The problem is I don't want digiKam writing to my image files any
more. Last week I discovered that IPTC information written before I
started using digiKam is mysteriously missing. It was there a month
ago. So I am faced with retrieving lost IPTC information for around
2500 images. Fortunately I have backups. A while back I spent hours
rotating all my jpegs that had the wrong rotation flag, and then found
out the rotation algorithm wasn't lossless. Fortunately I had backups.
Etc.

I also don't want to trust just having the metadata in the database.
So I decided to try using XMP sidecar files.

digiKam can create XMP sidecar files. It can add tags to XMP sidecar
files. But apparently it can't remove tags from XMP sidecar files.
Possibly it can't even read the XMP sidecar files that it created in
the first place. Therefore XMP sidecar files can't be kept in synch
with the database. Which makes the XMP sidecar files essentially
useless - might as well not waste the time and CPU cycles writing tags
at all if the tags can't be kept in synch with the database. Or so it
seems to me.

My apologies for whining and complaining so much - digiKam is a great
image manager, but I'm having a bit of trouble getting it to work like
it seems it ought to.

Elle


On 10/25/12, Remco Viëtor <[hidden email]> wrote:

> On Thursday 25 October 2012 17:23:31 Jean-François Rabasse wrote:
>>
> ...
>> I agree. And more, aside from « extensive re-organisation » of tags, even
>> the simple task of documenting new images leads to multiple metadata
>> updates. E.g. on a single image :
>>   - geolocating then clicking Apply --> write to image or sidecar
>>   - setting a title or caption, then Apply --> write
>>   - rating, --> write
>>
> Well, if the geolocation tab could be fused with the Caption/Tags tab,
> you'd only need one Apply command: at the moment, you can set title,
> caption, tags and ratings in one go, then click Apply only once to apply
> all those changes (currently, Geolocation is separate though).
>
> Personally, I try and get the metadata complete for the RAW files, and then
>
> they are carried over to teh processed images (unless I use batch tools,
> but that's a different subject).
>
> I'll have to think a bit about your proposed work-around, esp. in relation
> to OP's problem: keeping external tags in place, while removing outdated
> Digikam tags. My gut feeling is that that's going to cause difficulties.
>
> Remco

--
http://ninedegreesbelow.com
Articles and tutorials on open source digital imaging and photography
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Jan Köster]

Am Donnerstag, den 25.10.2012, 16:19 -0400 schrieb Elle Stone:
>
> digiKam can create XMP sidecar files. It can add tags to XMP sidecar
> files. But apparently it can't remove tags from XMP sidecar files.
> Possibly it can't even read the XMP sidecar files that it created in
> the first place. Therefore XMP sidecar files can't be kept in synch
> with the database. Which makes the XMP sidecar files essentially
> useless - might as well not waste the time and CPU cycles writing tags
> at all if the tags can't be kept in synch with the database. Or so it
> seems to me.

I've had similiar experiences when trying to use the same tag structure
in different programs. I had thought that if the tags are stored in the
xmp sidecar files it would be easy to have tag trees synchronized over
different porgramms, computers or even OS.  So I intuitively also
believed that data stored in sidecar files are synchronized to data
stored in tha database and vice versa. Be it automatically or on demand.
However this does not work (for me at least, might be I'm doing
something wrong). Not even with between two installations of digikam.

DK is one of the mightiest image management tool. And I really like it a
lot. But this issue is really a blocker for me.

It would be great to know if this is a problem of philosophy or of
technology. IE is the behaviour intended to be like this (and will not
change) or are there technical limitations, problems, etc keeping DK
from synchronizing metadata between sidecar files and database?

Jan

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Elle Stone]

I submitted a bug report on the problem of not being able to
synchronize the sidecar files with the database:
https://bugs.kde.org/show_bug.cgi?id=309058

I'm hoping there is a quick, easy solution, because it's a blocker for me, also.

Elle

On 10/25/12, Jan Köster <[hidden email]> wrote:

> Am Donnerstag, den 25.10.2012, 16:19 -0400 schrieb Elle Stone:
>>
>> digiKam can create XMP sidecar files. It can add tags to XMP sidecar
>> files. But apparently it can't remove tags from XMP sidecar files.
>> Possibly it can't even read the XMP sidecar files that it created in
>> the first place. Therefore XMP sidecar files can't be kept in synch
>> with the database. Which makes the XMP sidecar files essentially
>> useless - might as well not waste the time and CPU cycles writing tags
>> at all if the tags can't be kept in synch with the database. Or so it
>> seems to me.
>
> I've had similiar experiences when trying to use the same tag structure
> in different programs. I had thought that if the tags are stored in the
> xmp sidecar files it would be easy to have tag trees synchronized over
> different porgramms, computers or even OS.  So I intuitively also
> believed that data stored in sidecar files are synchronized to data
> stored in tha database and vice versa. Be it automatically or on demand.
> However this does not work (for me at least, might be I'm doing
> something wrong). Not even with between two installations of digikam.
>
> DK is one of the mightiest image management tool. And I really like it a
> lot. But this issue is really a blocker for me.
>
> It would be great to know if this is a problem of philosophy or of
> technology. IE is the behaviour intended to be like this (and will not
> change) or are there technical limitations, problems, etc keeping DK
> from synchronizing metadata between sidecar files and database?
>
> Jan
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

--
http://ninedegreesbelow.com
Articles and tutorials on open source digital imaging and photography
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Marcel Wiesweg]

>
> I've had similiar experiences when trying to use the same tag structure
> in different programs. I had thought that if the tags are stored in the
> xmp sidecar files it would be easy to have tag trees synchronized over
> different porgramms, computers or even OS.  So I intuitively also
> believed that data stored in sidecar files are synchronized to data
> stored in tha database and vice versa. Be it automatically or on demand.
> However this does not work (for me at least, might be I'm doing
> something wrong). Not even with between two installations of digikam.
>
> DK is one of the mightiest image management tool. And I really like it a
> lot. But this issue is really a blocker for me.
>
> It would be great to know if this is a problem of philosophy or of
> technology. IE is the behaviour intended to be like this (and will not
> change) or are there technical limitations, problems, etc keeping DK
> from synchronizing metadata between sidecar files and database?

In 309058 we are trying to find out if there is a testcase where reading or
writing to sidecars behaves differently to reading or writing to the image
file's XMP. It should not; the only difference is that in an image file there
is additionally IPTC keywords which may somehow interfere.

The problem that a reorganization of the tag tree is not transported to the
files having assigned these tags is discussed in extenso.
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[tosca]

The more I have tried to organize my tags since I began to use Digikam a couple of years ago, the more I've added to the mess!
Most tags seem to appear several times in different places all over the arborescence.

I'm willing to reset my whole tagging system and start afresh to tag my 25000 and more pictures, but I need to clean up everything beforehand.
Any idea/recommandation how to do that? it'll have to erase all the tags (and only them) from all the metadata wherever they are registered.

Thanks for helping,
Marie-Noëlle

2012/10/27 Marcel Wiesweg <[hidden email]>

>
> I've had similiar experiences when trying to use the same tag structure
> in different programs. I had thought that if the tags are stored in the
> xmp sidecar files it would be easy to have tag trees synchronized over
> different porgramms, computers or even OS.  So I intuitively also
> believed that data stored in sidecar files are synchronized to data
> stored in tha database and vice versa. Be it automatically or on demand.
> However this does not work (for me at least, might be I'm doing
> something wrong). Not even with between two installations of digikam.
>
> DK is one of the mightiest image management tool. And I really like it a
> lot. But this issue is really a blocker for me.
>
> It would be great to know if this is a problem of philosophy or of
> technology. IE is the behaviour intended to be like this (and will not
> change) or are there technical limitations, problems, etc keeping DK
> from synchronizing metadata between sidecar files and database?

In 309058 we are trying to find out if there is a testcase where reading or
writing to sidecars behaves differently to reading or writing to the image
file's XMP. It should not; the only difference is that in an image file there
is additionally IPTC keywords which may somehow interfere.

The problem that a reorganization of the tag tree is not transported to the
files having assigned these tags is discussed in extenso.

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

--


Mes dernières photos sont dans ma galerie.
Retrouvez-moi aussi sur mon blog.
Et parcourez les Cévennes à ma façon avec Cévennes Plurielles,


_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Elle Stone]

Hi Marie-Noëlle,

Here's one possible approach. To be on the safe side, first create
backup copies of all the images and put them somewhere digiKam isn't
looking. Also make a backup copy of the digiKam database.

Then use exiftool to locate and delete all the tagging metadata from
the images themselves (from the images digiKam is managing, not from
the backup copies). Also delete any digiKam XMP sidecar files.

Temporarily set digiKam up to not write any metadata to images or to
digiKam xmp sidecar files (just write to the database) and clean up
the tag tree in the digiKam database. It goes a lot faster if digiKam
is writing only to the database, and you can delete and rearrange tags
without fear of creating a new set of unwanted tags.

When you are finished deleting and rearranging all the tags in the
database, there won't be any remnant unwanted tags in the image
metadata (having removed them with exiftool) or in any existing XMP
sidecars (because they were already deleted). So when everything is
exactly like you want, you can write out the desired tag trees to XMP
sidecars or back to the image files, whichever you want. And this time
digiKam won't get confused when it "synchronizes" while writing out
the tags.

Send me a private email and I can help with the exiftool commands.
digiKam writes tags, captions, rating, and etc to a number of
different locations (eg digiKam xmp tags, lightroom xmp tags,
microsoft xmp tags), and exiftool can remove whatever needs to be
removed.

I just went through this procedure with all of my own images and I
took notes along the way. I ended up finding and removing a ton of
old, unwanted metadata left behind by various DAM softwares that I've
used at one time or another.

Kind regards,
Elle



On 11/7/12, Marie-Noëlle Augendre <[hidden email]> wrote:

> The more I have tried to organize my tags since I began to use Digikam a
> couple of years ago, the more I've added to the mess!
> Most tags seem to appear several times in different places all over the
> arborescence.
>
> I'm willing to reset my whole tagging system and start afresh to tag my
> 25000 and more pictures, but I need to clean up everything beforehand.
> Any idea/recommandation how to do that? it'll have to erase all the tags
> (and only them) from all the metadata wherever they are registered.
>
> Thanks for helping,
> Marie-Noëlle
>
> 2012/10/27 Marcel Wiesweg <[hidden email]>
>
>>
>> >
>> > I've had similiar experiences when trying to use the same tag structure
>> > in different programs. I had thought that if the tags are stored in the
>> > xmp sidecar files it would be easy to have tag trees synchronized over
>> > different porgramms, computers or even OS.  So I intuitively also
>> > believed that data stored in sidecar files are synchronized to data
>> > stored in tha database and vice versa. Be it automatically or on
>> > demand.
>> > However this does not work (for me at least, might be I'm doing
>> > something wrong). Not even with between two installations of digikam.
>> >
>> > DK is one of the mightiest image management tool. And I really like it
>> > a
>> > lot. But this issue is really a blocker for me.
>> >
>> > It would be great to know if this is a problem of philosophy or of
>> > technology. IE is the behaviour intended to be like this (and will not
>> > change) or are there technical limitations, problems, etc keeping DK
>> > from synchronizing metadata between sidecar files and database?
>>
>> In 309058 we are trying to find out if there is a testcase where reading
>> or
>> writing to sidecars behaves differently to reading or writing to the
>> image
>> file's XMP. It should not; the only difference is that in an image file
>> there
>> is additionally IPTC keywords which may somehow interfere.
>>
>> The problem that a reorganization of the tag tree is not transported to
>> the
>> files having assigned these tags is discussed in extenso.
>> _______________________________________________
>> Digikam-users mailing list
>> [hidden email]
>> https://mail.kde.org/mailman/listinfo/digikam-users
>>
>
>
>
> --
> <http://www.marie-noelle-augendre.com/photos/>
>
> Mes dernières photos sont dans ma
> galerie<http://www.marie-noelle-augendre.com/photos/>
> .
> Retrouvez-moi aussi sur mon blog <http://www.mnaugendre.com/>.
> Et parcourez les Cévennes à ma façon avec Cévennes
> Plurielles<http://www.cevennes-plurielles.com/>,
>

--
http://ninedegreesbelow.com
Articles and tutorials on open source digital imaging and photography
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[tosca]

Thanks for your answer, and sorry to have been a bit long to answer ... days seem to be way too short at the moment!

2012/11/8 Elle Stone <[hidden email]>

Hi Marie-Noëlle,

Here's one possible approach. To be on the safe side, first create
backup copies of all the images and put them somewhere digiKam isn't
looking. Also make a backup copy of the digiKam database.

Then use exiftool to locate and delete all the tagging metadata from
the images themselves (from the images digiKam is managing, not from
the backup copies). Also delete any digiKam XMP sidecar files.

That's the easy and quick thing to be done.
 

Temporarily set digiKam up to not write any metadata to images or to
digiKam xmp sidecar files (just write to the database) and clean up
the tag tree in the digiKam database. It goes a lot faster if digiKam
is writing only to the database, and you can delete and rearrange tags
without fear of creating a new set of unwanted tags.

When you are finished deleting and rearranging all the tags in the
database, there won't be any remnant unwanted tags in the image
metadata (having removed them with exiftool) or in any existing XMP
sidecars (because they were already deleted). So when everything is
exactly like you want, you can write out the desired tag trees to XMP
sidecars or back to the image files, whichever you want. And this time
digiKam won't get confused when it "synchronizes" while writing out
the tags.

Thing is the whole procedure will take quite some time, and I don't know when I'll be able to do that as I need my Digikam to add new pictures several times a week.
I can keep separated picture files on different removable hard disc; but I understand Digikam can handle only one DB per installation ... unless I create a special user (having his own Digikam DB in his /home) for doing the job on the old pictures, while I use a new DK installation in my own /home to handle the pictures that keep coming week after week.

Once the job is done, I could reimport the "old" pictures in the new installation.
Would it be feasible like that?
 

Send me a private email and I can help with the exiftool commands.
digiKam writes tags, captions, rating, and etc to a number of
different locations (eg digiKam xmp tags, lightroom xmp tags,
microsoft xmp tags), and exiftool can remove whatever needs to be
removed.

Couldn't you send them to the mailing-list? I guess I'm not the only one to have mess to clean up ....
 

I just went through this procedure with all of my own images and I
took notes along the way. I ended up finding and removing a ton of
old, unwanted metadata left behind by various DAM softwares that I've
used at one time or another.

Kind regards,
Elle

Thanks a lot,
Marie-Noëlle

 

On 11/7/12, Marie-Noëlle Augendre <[hidden email]> wrote:
> The more I have tried to organize my tags since I began to use Digikam a
> couple of years ago, the more I've added to the mess!
> Most tags seem to appear several times in different places all over the
> arborescence.
>
> I'm willing to reset my whole tagging system and start afresh to tag my
> 25000 and more pictures, but I need to clean up everything beforehand.
> Any idea/recommandation how to do that? it'll have to erase all the tags
> (and only them) from all the metadata wherever they are registered.
>
> Thanks for helping,
> Marie-Noëlle
>

--


Mes dernières photos sont dans ma galerie.
Retrouvez-moi aussi sur mon blog.
Et parcourez les Cévennes à ma façon avec Cévennes Plurielles,


_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[davidvj]

CONTENTS DELETED

The author has deleted this message.