[digiKam-users] Odd problem with tags, a sort of 'ghost' tag

[Chris Green]

I have been sorting out the tags on a lot of my images.

In particular I have been merging some 'place' tags which managed to
get under different headings, for example I had places/UK/wales/anglesey and
places/wales/anglesey.

So now I have some images which show lots of different tag settings
according to how I view them:-

    Hovering over the thumbnail shows 'Anglesey'.

    Selecting 'UK' under tags in the left sidebar shows the image.

    Selecting 'UK' in the tags filter on the RHS (with all albums
    selected on the left) shows nothing.

    Viewing the tags with exiv2 or exiftool shows
    'Xmp.digiKam.TagsList [seq Text] = ['Places/Wales/North Wales/Anglesey']
    which is what I'd expect.


Is it simply that the Digikam database is out of step with the image
metadata?  How can I re-copy *all* metadata from images to the database?

--
Chris Green
·

[woenx]

It's possibly what you say, Digikam's database is not up to date with the
metadata. For reading the metadata and saving it to the database, just click
on Item -> Re-read Metadata from File. You can do that for a whole
selection.



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Chris Green]

woenx <[hidden email]> wrote:
> It's possibly what you say, Digikam's database is not up to date with the
> metadata. For reading the metadata and saving it to the database, just click
> on Item -> Re-read Metadata from File. You can do that for a whole
> selection.
>
OK, thanks, I'll try that and see what happens.

--
Chris Green
·

[meku]

That the image shows up when using the left sidebar but not the tags filter suggests to me that your Tags tree is in an inconsistent state.

Depending on your Digikam version and database backend this can happen when creating or deleting Tags. I haven't confirmed if the Digikam maintenance tool will correct this inconsistency, personally I use a script that will rebuild the Tree when this happens.

On Thu, 27 Sep 2018 at 06:33, Chris Green <[hidden email]> wrote:

I have been sorting out the tags on a lot of my images.

In particular I have been merging some 'place' tags which managed to
get under different headings, for example I had places/UK/wales/anglesey and
places/wales/anglesey.

So now I have some images which show lots of different tag settings
according to how I view them:-

    Hovering over the thumbnail shows 'Anglesey'.

    Selecting 'UK' under tags in the left sidebar shows the image.

    Selecting 'UK' in the tags filter on the RHS (with all albums
    selected on the left) shows nothing.

    Viewing the tags with exiv2 or exiftool shows
    'Xmp.digiKam.TagsList [seq Text] = ['Places/Wales/North Wales/Anglesey']
    which is what I'd expect.


Is it simply that the Digikam database is out of step with the image
metadata?  How can I re-copy *all* metadata from images to the database?

--
Chris Green
·

[Chris Green]

meku <[hidden email]> wrote:

> [-- text/plain, encoding quoted-printable, charset: UTF-8, 42 lines --]
>
> That the image shows up when using the left sidebar but not the tags filter
> suggests to me that your Tags tree is in an inconsistent state.
>
> Depending on your Digikam version and database backend this can happen when
> creating or deleting Tags. I haven't confirmed if the Digikam maintenance
> tool will correct this inconsistency, personally I use a script that will
> rebuild the Tree when this happens.
>

Yes, I suspect that tag handling is not as robust as it might be.
What does your "script that will rebuild the Tree" actually do?

Going on from that can anyone tell me which Tag modification actions
write to the database and which write to the image metadata?  ... and
why doesn't Digikam always write to both?

--
Chris Green
·

[woenx]

In theory, if you have checked the corresponding checkboxes in the Settings,
Configure digikam, Metadata menu, everything should be written to the
metadata.

However, in digikam 5.8 or 5.9, old metadata was not deleted from the
database when new metadata was found in a picture, so mismatches happened
frequently. In digikam 6.0b that problem was solved and I've had no problems
so far.



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Gilles Caulier-4]

2018-09-27 18:10 GMT+02:00 Chris Green <[hidden email]>:

meku <[hidden email]> wrote:
> [-- text/plain, encoding quoted-printable, charset: UTF-8, 42 lines --]
>
> That the image shows up when using the left sidebar but not the tags filter
> suggests to me that your Tags tree is in an inconsistent state.
>
> Depending on your Digikam version and database backend this can happen when
> creating or deleting Tags. I haven't confirmed if the Digikam maintenance
> tool will correct this inconsistency, personally I use a script that will
> rebuild the Tree when this happens.
>

Yes, I suspect that tag handling is not as robust as it might be.
What does your "script that will rebuild the Tree" actually do?

Going on from that can anyone tell me which Tag modification actions
write to the database and which write to the image metadata?  ... and
why doesn't Digikam always write to both?

This is the legacy of the project (started in 2001, don't forget).

Some people want store in both, some other just in database (and never touch original image).

The last one is the default workflow.

 

The complexity of the metadata hub (it's called like this in source code) is to be able to handle all case with tags, written from DK, outside, from another application (welcome interroperabilty), manage all kind of file formats, handle XMP side car, must support multi-threading.

All low level operations are delegate to Exiv2 library.

For tags, and multiple selection of items with different tags already assigned, we need to process a good merging, without lost anything, depending of tags list changes.

The maintenance is also tedious, especially to synchronize DB to image and vis-versa.

So, if you think that "tag handling is not as robust as it might be", well you welcome to take the train in source code and to improve it. The game is not so simple to manage, if you list all input conditions and all output states from the box.

Gilles Caulier

--
Chris Green
·

[Chris Green]

woenx <[hidden email]> wrote:
> In theory, if you have checked the corresponding checkboxes in the Settings,
> Configure digikam, Metadata menu, everything should be written to the
> metadata.

But *which* metadata, in the image or in Digikam's database?

>
> However, in digikam 5.8 or 5.9, old metadata was not deleted from the
> database when new metadata was found in a picture, so mismatches happened
> frequently. In digikam 6.0b that problem was solved and I've had no problems
> so far.
>
It sounds more and more like I need to move to 6.0 beta!

--
Chris Green
·

[Chris Green]

Gilles Caulier <[hidden email]> wrote:

> [-- text/plain, encoding quoted-printable, charset: UTF-8, 61 lines --]
>
> 2018-09-27 18:10 GMT+02:00 Chris Green <[hidden email]>:
>
> > meku <[hidden email]> wrote:
> > > [-- text/plain, encoding quoted-printable, charset: UTF-8, 42 lines --]
> > >
> > > That the image shows up when using the left sidebar but not the tags
> > filter
> > > suggests to me that your Tags tree is in an inconsistent state.
> > >
> > > Depending on your Digikam version and database backend this can happen
> > when
> > > creating or deleting Tags. I haven't confirmed if the Digikam maintenance
> > > tool will correct this inconsistency, personally I use a script that will
> > > rebuild the Tree when this happens.
> > >
> >
> > Yes, I suspect that tag handling is not as robust as it might be.
> > What does your "script that will rebuild the Tree" actually do?
> >
> > Going on from that can anyone tell me which Tag modification actions
> > write to the database and which write to the image metadata?  ... and
> > why doesn't Digikam always write to both?
> >
>
> This is the legacy of the project (started in 2001, don't forget).
>
> Some people want store in both, some other just in database (and never
> touch original image).
>
> The last one is the default workflow.
>
> The complexity of the metadata hub (it's called like this in source code)
> is to be able to handle all case with tags, written from DK, outside, from
> another application (welcome interroperabilty), manage all kind of file
> formats, handle XMP side car, must support multi-threading.
>
> All low level operations are delegate to Exiv2 library.
>
> For tags, and multiple selection of items with different tags already
> assigned, we need to process a good merging, without lost anything,
> depending of tags list changes.
>
> The maintenance is also tedious, especially to synchronize DB to image and
> vis-versa.
>
> So, if you think that "tag handling is not as robust as it might be", well
> you welcome to take the train in source code and to improve it. The game is
> not so simple to manage, if you list all input conditions and all output
> states from the box.
>

Yes, sorry, I realise it's (very) complex.  Apart from anything else
the lack of standards etc. mean that everything is much more difficult
than it might be.

However it would be really nice to have a simple on/off for where
metadata is written.  E.g. a set of radio buttons in the Digikam
settings as follows:-

    X - Write metadata to database
    X - Write metadata to images
    X - Write metadata to database and images

The complexity of where to write (as in which exif/iptc/xmp fields) a
particular item doesn't really affect the above three possible settings.

--
Chris Green
·

[woenx]

Chris Green wrote
> woenx &lt;

> marcpalaus@

> &gt; wrote:
>> In theory, if you have checked the corresponding checkboxes in the
>> Settings,
>> Configure digikam, Metadata menu, everything should be written to the
>> metadata.
>
> But *which* metadata, in the image or in Digikam's database?

Oh, I meant the metadata in the image.

If you upgrade, I would do a full re-scan and cleanup of the library in
order to sync the image metadata with the database (digikam won't re-scan
for itself unless a picture has been modified).

I think it works just fine in the last versions, I haven't had any problems.



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[meku]

I have used a MySQL procedure to rebuild the entire tree in database so it is runs in seconds, whereas re-importing metadata from files takes several hours. The tags tree is a standard nested set model so there is much information on the internet about this type of tree structure.

This solution is probably only applicable if you are using the external database option in Digikam, and always backup your database. The source is made available here: https://github.com/mcdamo/digikam-scripts/blob/master/digikam-tags-check.sql

On Fri, 28 Sep 2018 at 02:16, Chris Green <[hidden email]> wrote:

meku <[hidden email]> wrote:
> [-- text/plain, encoding quoted-printable, charset: UTF-8, 42 lines --]
>
> That the image shows up when using the left sidebar but not the tags filter
> suggests to me that your Tags tree is in an inconsistent state.
>
> Depending on your Digikam version and database backend this can happen when
> creating or deleting Tags. I haven't confirmed if the Digikam maintenance
> tool will correct this inconsistency, personally I use a script that will
> rebuild the Tree when this happens.
>

Yes, I suspect that tag handling is not as robust as it might be.
What does your "script that will rebuild the Tree" actually do?

Going on from that can anyone tell me which Tag modification actions
write to the database and which write to the image metadata?  ... and
why doesn't Digikam always write to both?

--
Chris Green
·

[Chris Green]

woenx <[hidden email]> wrote:

> Chris Green wrote
> > woenx &lt;
>
> > marcpalaus@
>
> > &gt; wrote:
> >> In theory, if you have checked the corresponding checkboxes in the
> >> Settings,
> >> Configure digikam, Metadata menu, everything should be written to the
> >> metadata.
> >
> > But *which* metadata, in the image or in Digikam's database?
>
> Oh, I meant the metadata in the image.
>
> If you upgrade, I would do a full re-scan and cleanup of the library in
> order to sync the image metadata with the database (digikam won't re-scan
> for itself unless a picture has been modified).
>
> I think it works just fine in the last versions, I haven't had any problems.
>

OK, thank you, I will try the 6.0 beta now I'm back home with a
reliable and fast internet connnection.

--
Chris Green
·

[Sveinn í Felli-2]

Þann mið 26.sep 2018 20:21, skrifaði Chris Green:

> I have been sorting out the tags on a lot of my images.
>
> In particular I have been merging some 'place' tags which managed to
> get under different headings, for example I had places/UK/wales/anglesey and
> places/wales/anglesey.
>
> So now I have some images which show lots of different tag settings
> according to how I view them:-
>
>      Hovering over the thumbnail shows 'Anglesey'.
>
>      Selecting 'UK' under tags in the left sidebar shows the image.
>
>      Selecting 'UK' in the tags filter on the RHS (with all albums
>      selected on the left) shows nothing.
>
>      Viewing the tags with exiv2 or exiftool shows
>      'Xmp.digiKam.TagsList [seq Text] = ['Places/Wales/North Wales/Anglesey']
>      which is what I'd expect.
>

One question; has the database been accessed from different systems/OS
or moved between disks ?
Has the tag "North Wales" maybe split up to two tags?
I once (long time ago) had problems with tags with spaces in their name.
At the time it could have been different character encodings teasing me.

Just wondering,

Sveinn í Felli

[Chris Green]

woenx <[hidden email]> wrote:

> Chris Green wrote
> > woenx &lt;
>
> > marcpalaus@
>
> > &gt; wrote:
> >> In theory, if you have checked the corresponding checkboxes in the
> >> Settings,
> >> Configure digikam, Metadata menu, everything should be written to the
> >> metadata.
> >
> > But *which* metadata, in the image or in Digikam's database?
>
> Oh, I meant the metadata in the image.
>
> If you upgrade, I would do a full re-scan and cleanup of the library in
> order to sync the image metadata with the database (digikam won't re-scan
> for itself unless a picture has been modified).
>

Hmm, I've just downloaded the Digikam 6.0 beta Appimage.  It appears
to be rescanning all my images without any help from me!  Should I do
anything more to ensure everything is in sync?

--
Chris Green
·