What is being/will be done about the tags management problem?

[Samuel Gilbert]

Hello,

  Is modifying tags in another software a common usage pattern?

  I can understand why someone would use an external photo editor such as
Gimp or Photoshop, but personally I think that trying to manage your
collection with 2 different "collection managers" is looking for trouble.  If
there is a valid use case, then investing efforts to try to make it work
smoothly might be worth it.  Otherwise, it's will require a lot of effort for
not a lot of gain.

Samuel

On 2013-02-19 16:00:16 Jean-François Rabasse wrote:

> On Tue, 19 Feb 2013, Marie-Noëlle Augendre wrote:
> > The tags synchronization issue has been poisoning the life (OK,
> > only the photography workflow ; -) ) of a number of Digikam users
> > for several months/years and frequently re-emerge as a subject in
> > this mailing-list. As for myself (and I think for some others,
> > too) I've gave up long ago to try to manage my tags, and I am
> > patiently (more or less) waiting for the situation getting better
> > before doing a huge organization of my whole photobase.
> >
> > Could the developers team tell us how soon the users can expect a
> > solution to this blocking problem.
>
> On Tue, 19 Feb 2013, Gilles Caulier wrote:
> > The light is here. I'm aware about this problem. As we entry in a
> > new students period, i will try to find people to investigate and
> > fix it.
>
> Hello,
>
> a few comments about this problem which is - as Marie-Noëlle said -
> reccurent on this list.
>
> From my humble opinion, it's not just a fix to software, it's a
> software design strategy. I've been concerned too, for a long time,
> with this issue and I had a look at the source code.
> The code seems corrects, some design choices may appear more
> questionnable.
>
> 1. Synchronization of tags between database and images :
> When Digikam writes metadata to images (or sidecar files),
> the written tagslist is the current database state,
> so « export » synchronization is done.
>
> When Digikam re-reads metadata, the tagslist is merged with the
> current tags associated to the image. (This is in source file
> metadatahub.cpp, in method MetadataHub::loadTags, it's an explicit
> merge, new tags are added to the current tags from DB, not a delete
> current and replace by new).
> And there, « import » synchronization is not effective, the database
> doesn't reflect what is into the images XMP sections.
>
> I don't see very well in which use cases this merging is useful,
> but why not, if it has been coded that way, it probably is.
> But what should be choosen, replace or merge ?
>
> At least, a simple fix could be an option in the metadata folder,
> « upon read concat new tags vs. replace all current by new ones ».
> And in the code, just a "tagList = loadedTagPaths" instead of merge.
> This would guarantee the database reflects correctly what is found
> from images and enforce reversible behaviour between « Write metadata »
> and « Reread Metadata » .
>
> 2. Metadata interchange with other applications : This is another
> tags related problems, due to the different tags storing formats.
> When Digikam writes metadata, tagslist are saved in several possible
> formats, the Digikam format, digiKam:TagsList, the Adobe LightRoom
> format, lr:hierarchicalSubject, the Microsoft Photo format,
> MicrosoftPhoto.LastKeywordXMP. So, the great thing is that other
> applications will get the tags.
>
> When Digikam re-reads metadata, reading is done with a priority
> order. Look for Digikam tags, if found keep that. If not found,
> look for Microsoft tags. If found keep that. If not found look for
> LightRooom tags, etc.
> (From source module dmetadata.cpp, method DMetadata::getImageTagsPath)
>
> But this means that if someone tags an image with Digikam, then uses
> later another application, e.g. LightRoom, and edit the tags,
> when back to Digikam the older tags in Digikam format will be
> reloaded, not the newer LightRoom tags.
>
> I just signal that, but it's very difficult to fix at software
> level. The only solution I can imagine would be to add into the
> digiKam namespace a kind of modification date. Upon read, comparing
> that date with the standard xmp:MetadataDate would allow to detect
> that another application has been used and that it could be better
> to load LightRoom tags first. But it's probably too rare a use case
> to be worth the work.
> Software can't be magic and letting users know what they do, and
> asuming what they do, is probably a simpler strategy.
>
>
> In conclusion : I really think that tags problem should probably
> require more accurate design definitions. What is expected, what do
> people do with tags, what should be the expected behaviour, do a
> majority of users work with different software and how should be the
> interoperability strategy, etc. But clearly, it's not a bug, not at
> all. It's design choice, and on the software planet, design changes
> should come from requirements changes. IMHO.
>
> Regards,
> Jean-François

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

[Elle Stone]

On 2/19/13, Brian Morrison <[hidden email]> wrote:

> On Tue, 19 Feb 2013 12:25:08 -0500
> Elle Stone wrote:
>
>> There is also the problem of keeping the database synchronized with
>> the sidecar metadata, if someone chooses to only write metadata to a
>> sidecar rather than risk writing to the image metadata:
>>
>> https://bugs.kde.org/show_bug.cgi?id=309058
>
> I don't mean to sink any ships here, but isn't this problem related to
> which programs support which metadata?

Well, there are all kinds of use cases and of course I am thinking
about my own use case. But I'm pretty sure I'm not the only person
using digiKam who doesn't let digiKam write to the image metadata but
instead uses sidecar files. So it seemed appropriate to bring up the
issue of keeping sidecars sychronized with the database.

FWIW, digiKam is the only program that writes XMP sidecar files for my
images. I don't use Lightroom. I do use Darktable on occasion, but
only as a raw processor, not for adding metadata.

>
> There are various types, metadata which is widely known about and
> supported for editing in multiple programs and there is private metadata
> which is only understood in one program (or maybe two). Unless there is
> a spec somewhere that defines the 'shared' metadata so that developers
> can implement support for it in their software then this circle can't be
> squared.

You are correct, of course. But I only want digiKam to square its own
circle. I want all metadata that digiKam writes to the XMP sidecar
file that digiKam creates (and that only digiKam writes to) to be kept
in synchronization with the metadata that digiKam writes to its own
database. I don't see how or why this should be substantially more
difficult than keeping the digiKam database in synchronization with
the metadata that digiKam writes to an image file. In either case, the
same problem of what to do with metadata written by other applications
(if the user chooses to allow this to happen) still remains.

> Isn't this exactly why sidecar files came about? A way of keeping data
> associated with a file in such a way that programs that don't know
> about it don't mess with it?

I was under the impression that sidecar files serve two purposes:
Provide a place to store metadata for file formats to which digiKam
can't write, or for which writing is still experimental. And provide a
place to store metadata if for whatever reason the user doesn't want
to write to the actual image file.

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

[Brian Morrison]

On Tue, 19 Feb 2013 13:30:07 -0500
Elle Stone wrote:

> But I only want digiKam to square its own
> circle. I want all metadata that digiKam writes to the XMP sidecar
> file that digiKam creates (and that only digiKam writes to) to be kept
> in synchronization with the metadata that digiKam writes to its own
> database. I don't see how or why this should be substantially more
> difficult than keeping the digiKam database in synchronization with
> the metadata that digiKam writes to an image file.

Ah, now that's something that I definitely can subscribe to, I can see
no point in not keeping these two sets of metadata in sync. Doing that
would be a good first step in curing this particular deficiency in
digiKam.

--

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

Le 19/02/2013 19:30, Elle Stone a écrit :

> I was under the impression that sidecar files serve two purposes:
> Provide a place to store metadata for file formats to which digiKam
> can't write, or for which writing is still experimental. And provide a
> place to store metadata if for whatever reason the user doesn't want
> to write to the actual image file.


it much easier to sync sidecar files than full images, for example if
you have an online gallery and change any local tag

jdd


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

[Andrew Goodbody]

On 19/02/13 18:01, jdd wrote:
> Le 19/02/2013 18:46, Gilles Caulier a écrit :
>
>> And definitively, this cannot be an introduce small project for
>> students, but a real GoSC 2013 project, because it's more complex that
>> i supposed in my previous mail.
>
> are there on this list people that needs merging of the tags in the
> database?

I'm not entirely sure but that merge may have been the result of a bug
fix involving adding a new tag to multiple images that did not share the
same set of initial tags.
https://bugs.kde.org/show_bug.cgi?id=264745

> if not it could be very easy to stop messing tags (the solution was
> given in the JFR mail).

Actually it does not address all the issues. When tags are renamed,
moved or deleted then only the database is updated. For the issues that
Jean-François mentioned to even matter in these cases there first of all
needs to be a process that identifies all affected images and updates
the tags for each image, be that in the image files or in the sidecar
files. AFAIK at the moment this simply does not happen at all. It is not
a case of merge vs replace and having to choose which one it should be.
To me this is absolutely a bug. It is vital infrastructure that has
never been implemented let alone been done wrong. It has nothing to do
with external programs altering image metadata, it is simply internal
house-keeping that must be done.

In implementing this process of updating the metadata for every affected
image then there must be a choice made of how to keep the changes to the
image metadata and the database metadata synchonised and then we need to
pay attention to Jean-François' ideas. Although in this case there is
another possibility. If it is possible to visit each image and use the
knowledge of the actual operation that is in progress then only that
operation could be applied both to the database and to the image file.
In this case if the image file and database were out of synchronisation
to start with they would still be out of synchronisation afterwards as
well. Only the tags being moved, renamed or deleted would be affected.
All other tags would not change.

However I am afraid that digikam has not been designed to be able to
apply update operations to image metadata. I think that update
operations are applied to the database and then all the database entries
for that image are either written out or not. So implementing my idea
above would not be simple.

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

[Jean-François Rabasse]

On Tue, 19 Feb 2013, Elle Stone wrote:

> On 2/19/13, Brian Morrison <[hidden email]> wrote:
>>
>> I don't mean to sink any ships here, but isn't this problem related to
>> which programs support which metadata?
>
> Well, there are all kinds of use cases and of course I am thinking
> about my own use case. But I'm pretty sure I'm not the only person
> using digiKam who doesn't let digiKam write to the image metadata
> but instead uses sidecar files.

You're not the only one :-)
(As discussed here recently, some naughty programs (The Gimp:-) tend
to corrupt metadata. Sidecar files is a safe alternative to embedded
data into images files.)

> So it seemed appropriate to bring up the issue of keeping sidecars
> sychronized with the database.

+1
As Gilles said a couple of hours ago, default behaviour and options
should cover the majority of users needs. And having consistency
between write/read operations seems a fair default.

>> Isn't this exactly why sidecar files came about? A way of keeping data
>> associated with a file in such a way that programs that don't know
>> about it don't mess with it?
>
> I was under the impression that sidecar files serve two purposes:
> Provide a place to store metadata for file formats to which digiKam
> can't write, or for which writing is still experimental. And provide a
> place to store metadata if for whatever reason the user doesn't want
> to write to the actual image file.

Brian, sidecar files are not exactly a way for an application to
« hide » its data to other programs. The internal sidecar files
structure is an Adobe standard (XMP/RDF) and any program equiped
with a XMP parser is able to read any conformant sidecar file, or
embedded data in images files, whichever program created it.
(It's the same structure, exactly, and it's possible to insert a
sidecar file content into the image and vice versa. Metadata handling
tools as exiftool or exiv2 do that.
As Elle said, sidecar files is only an alternative to writing into
the images files.

What is application specific is XMP schemas, aside from standard
schemas (XMP Base, Dublin Core, etc.)
And a metadata reader is just expected to read and use recognized
metadata schemas, and ignore specific ones.
That's what most software do. Interoperability is guaranteed for
standard schemas, it is optional regarding specific schemas.
(Feed an image tagged with Digikam to some Adobe software, it's
unliquely that the software with accept to deal with DK data.)

But, and that's probably why discussions about metadata often focus
around tags, structured tags and tags trees are special metadata
properties. Why special ? Two reasons :

1. It doesn't exist in standard schemas, it has been ignored or
forgotten. (I'd rather think forgotten).

2. It's a *very* useful feature. And the proof is that most software
environments offer this feature, use it, and implement it.
Because of point 1., each software does its personal implementation
(Digikam tagslist, Adobe Lightroom hierarchical subject, Microsoft
Photo, etc.)

The bad new is that this important data can't be easily shared.

The good new is that the XMP/RDF is a standard so, aside from such
or such application, it's always possible to perform applications
compatibility. So probably the simple strategy is to expect programs
to handle correctly their metadata, and rely on external tools when
conversions are needed.
E.g. reading digiKam:Tagslist "Location/Country/City" and converting
to lr:hierarchicalSubject "Location|Country|City" can be done even
without Digikam nor LightRoom.

The important thing is data content (and semantic), not formal
representation. I don't know which images manager I'll be using in
20 years, but I'm sure I want to keep my tags (and title, description
et al.) because it's part of the image memory.
For photo hobbyists, and we're are photo hobbyists, our images are
not just scanlines of coloured pixels.

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

[Simon Cropper-3]

Based on Jean-François sequencing this would be my expectation (see
inline comments...

On 20/02/13 02:00, Jean-François Rabasse wrote:

>
> On Tue, 19 Feb 2013, Marie-Noëlle Augendre wrote:
>
>> The tags synchronization issue has been poisoning the life (OK,
>> only the photography workflow ; -) ) of a number of Digikam users
>> for several months/years and frequently re-emerge as a subject in
>> this mailing-list. As for myself (and I think for some others,
>> too) I've gave up long ago to try to manage my tags, and I am
>> patiently (more or less) waiting for the situation getting better
>> before doing a huge organization of my whole photobase.
>>
>> Could the developers team tell us how soon the users can expect a
>> solution to this blocking problem.
>
> On Tue, 19 Feb 2013, Gilles Caulier wrote:
>
>> The light is here. I'm aware about this problem. As we entry in a
>> new students period, i will try to find people to investigate and
>> fix it.
>
> Hello,
>
> a few comments about this problem which is - as Marie-Noëlle said -
> reccurent on this list.
>
>  From my humble opinion, it's not just a fix to software, it's a
> software design strategy. I've been concerned too, for a long time,
> with this issue and I had a look at the source code.
> The code seems corrects, some design choices may appear more
> questionnable.
>
> 1. Synchronization of tags between database and images :
> When Digikam writes metadata to images (or sidecar files),
> the written tagslist is the current database state,
> so « export » synchronization is done.
>
> When Digikam re-reads metadata, the tagslist is merged with the
> current tags associated to the image. (This is in source file
> metadatahub.cpp, in method MetadataHub::loadTags, it's an explicit
> merge, new tags are added to the current tags from DB, not a delete
> current and replace by new).
> And there, « import » synchronization is not effective, the database
> doesn't reflect what is into the images XMP sections.
>
> I don't see very well in which use cases this merging is useful,
> but why not, if it has been coded that way, it probably is.
> But what should be choosen, replace or merge ?

The choice should be given to the user -- do you want to merge the
metadata or replace all the metadata?

> At least, a simple fix could be an option in the metadata folder,
> « upon read concat new tags vs. replace all current by new ones ».
> And in the code, just a "tagList = loadedTagPaths" instead of merge.
> This would guarantee the database reflects correctly what is found
> from images and enforce reversible behaviour between « Write metadata »
> and « Reread Metadata » .
>
> 2. Metadata interchange with other applications : This is another
> tags related problems, due to the different tags storing formats.
> When Digikam writes metadata, tagslist are saved in several possible
> formats, the Digikam format, digiKam:TagsList, the Adobe LightRoom
> format, lr:hierarchicalSubject, the Microsoft Photo format,
> MicrosoftPhoto.LastKeywordXMP. So, the great thing is that other
> applications will get the tags.
>
> When Digikam re-reads metadata, reading is done with a priority
> order. Look for Digikam tags, if found keep that. If not found,
> look for Microsoft tags. If found keep that. If not found look for
> LightRooom tags, etc.
> (From source module dmetadata.cpp, method DMetadata::getImageTagsPath)
>
> But this means that if someone tags an image with Digikam, then uses
> later another application, e.g. LightRoom, and edit the tags,
> when back to Digikam the older tags in Digikam format will be
> reloaded, not the newer LightRoom tags.
>
> I just signal that, but it's very difficult to fix at software
> level. The only solution I can imagine would be to add into the
> digiKam namespace a kind of modification date. Upon read, comparing
> that date with the standard xmp:MetadataDate would allow to detect
> that another application has been used and that it could be better
> to load LightRoom tags first. But it's probably too rare a use case
> to be worth the work. Software can't be magic and letting users know
> what they do, and
> asuming what they do, is probably a simpler strategy.

Personally, my expectation would be that if the software detects that
the metadata is different the user is provided an opportunity to chose
which metadata to keep.


> In conclusion : I really think that tags problem should probably
> require more accurate design definitions. What is expected, what do
> people do with tags, what should be the expected behaviour, do a
> majority of users work with different software and how should be the
> interoperability strategy, etc. But clearly, it's not a bug, not at
> all. It's design choice, and on the software planet, design changes
> should come from requirements changes. IMHO.

The most important thing is that no data is lost. Whenever metadata
change is detected the user should be provided an opportunity to review
the changes and decide what to keep and what to chuck away. Of course,
if the user prefers a straight up replace that is their prerogative and
the import metadata from file option should do just that!

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

--
Cheers Simon

    Simon Cropper - Open Content Creator

    Free and Open Source Software Workflow Guides
    ------------------------------------------------------------
    Introduction               http://www.fossworkflowguides.com
    GIS Packages           http://www.fossworkflowguides.com/gis
    bash / Python    http://www.fossworkflowguides.com/scripting
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[tosca]

2013/2/19 Simon Cropper <[hidden email]>

The most important thing is that no data is lost.

I didn't see anything lost up to now, as Digikam goes on keeping what I've been wanting to get rid of: I have several 'generation' of tags where I would like to have only the last one.

Marie-Noëlle

--


Mes dernières photos sont dans ma galerie.
Connaissez-vous Image Fixe, le photo-club de Saint Jean du Gard ?
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

[Simon Cropper-3]

On 20/02/13 05:30, Elle Stone wrote:

> On 2/19/13, Brian Morrison <[hidden email]> wrote:
>> On Tue, 19 Feb 2013 12:25:08 -0500
>> Elle Stone wrote:
>>
>>> There is also the problem of keeping the database synchronized with
>>> the sidecar metadata, if someone chooses to only write metadata to a
>>> sidecar rather than risk writing to the image metadata:
>>>
>>> https://bugs.kde.org/show_bug.cgi?id=309058
>>
>> I don't mean to sink any ships here, but isn't this problem related to
>> which programs support which metadata?
>
> Well, there are all kinds of use cases and of course I am thinking
> about my own use case. But I'm pretty sure I'm not the only person
> using digiKam who doesn't let digiKam write to the image metadata but
> instead uses sidecar files. So it seemed appropriate to bring up the
> issue of keeping sidecars sychronized with the database.
>
> FWIW, digiKam is the only program that writes XMP sidecar files for my
> images. I don't use Lightroom. I do use Darktable on occasion, but
> only as a raw processor, not for adding metadata.
>
>>
>> There are various types, metadata which is widely known about and
>> supported for editing in multiple programs and there is private metadata
>> which is only understood in one program (or maybe two). Unless there is
>> a spec somewhere that defines the 'shared' metadata so that developers
>> can implement support for it in their software then this circle can't be
>> squared.
>
> You are correct, of course. But I only want digiKam to square its own
> circle. I want all metadata that digiKam writes to the XMP sidecar
> file that digiKam creates (and that only digiKam writes to) to be kept
> in synchronization with the metadata that digiKam writes to its own
> database. I don't see how or why this should be substantially more
> difficult than keeping the digiKam database in synchronization with
> the metadata that digiKam writes to an image file. In either case, the
> same problem of what to do with metadata written by other applications
> (if the user chooses to allow this to happen) still remains.

You would think that it would not be difficult or time consuming for DK
to scan the albums and reconcile the various metadata repositories and
provide a opportunity for the user to see those images that are
out-of-sync (with subgroups showing why).

Out-of-sync files could then be inspected one-by-one using a tool that
shows the differences between the database, image and XMP file and
provides an opportunity for the user to select what data to keep. On
exiting this routine DK would then synchronize all the repositories.

>
>> Isn't this exactly why sidecar files came about? A way of keeping data
>> associated with a file in such a way that programs that don't know
>> about it don't mess with it?
>
> I was under the impression that sidecar files serve two purposes:
> Provide a place to store metadata for file formats to which digiKam
> can't write, or for which writing is still experimental. And provide a
> place to store metadata if for whatever reason the user doesn't want
> to write to the actual image file.
>
> Kind regards,
> Elle
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

--
Cheers Simon

    Simon Cropper - Open Content Creator

    Free and Open Source Software Workflow Guides
    ------------------------------------------------------------
    Introduction               http://www.fossworkflowguides.com
    GIS Packages           http://www.fossworkflowguides.com/gis
    bash / Python    http://www.fossworkflowguides.com/scripting
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Le 20/02/2013 00:02, Simon Cropper a écrit :

> Out-of-sync files could then be inspected one-by-one using a tool that
> shows the differences between the database, image and XMP file and
> provides an opportunity for the user to select what data to keep. On
> exiting this routine DK would then synchronize all the repositories.


on thousand of images?

jdd


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

[Simon Cropper-3]

On 20/02/13 10:05, jdd wrote:

> Le 20/02/2013 00:02, Simon Cropper a écrit :
>
>> Out-of-sync files could then be inspected one-by-one using a tool that
>> shows the differences between the database, image and XMP file and
>> provides an opportunity for the user to select what data to keep. On
>> exiting this routine DK would then synchronize all the repositories.
>
>
> on thousand of images?
>
> jdd
>
>

I have 10000 images I am moving around at the moment and DK is
rescanning the collection everytime I open it (The basic camera metadata
not tags at the moment because I am restructuring my library). This only
takes a minute or so.

I would think that to scan, extract and compare the metadata, a routine
would not take that long (~5 minutes). The problem is inspecting and
reconciling each file.

I suppose this is where preferences come in. If you only use lightroom
to change your metadata, you could automatically accept all the data in
the lightroom metadata section as a default whenever changes are detected.

--
Cheers Simon

    Simon Cropper - Open Content Creator

    Free and Open Source Software Workflow Guides
    ------------------------------------------------------------
    Introduction               http://www.fossworkflowguides.com
    GIS Packages           http://www.fossworkflowguides.com/gis
    bash / Python    http://www.fossworkflowguides.com/scripting
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Julien T]

After following this interesting thread for the last days, my 2 cents

2013/2/19 Jean-François Rabasse <[hidden email]>:
>
[...]
> But with XMP metadata, there's no such information. The XMP schema has
> a dedicated field, xmp:MetadataDate, that should be the last time
> metadata has been updated. Ideally, this field should be set automaticaly
> when writing metadata, but very few software do that.
> At least, the libexiv2 doesn't, too bad :-(

I agree strongly with a problem of spec but as It is probably
hard/long time before any improvements on this, digikam should provide
reasonable alternative.


> So, only the user can decide which is the reference and which is the
> outdated, and in which way to do the sync copy.

Like for a few other software, In case there is a conflict, software
should provide options: Keep either one side/newer or older/ignore/Log
and keep same option for next conflicts (what does every code
versioning stuff)

There is quiet a number of bugs for digikam+metadata
(https://bugs.kde.org/buglist.cgi?component=Metadata&product=digikam&list_id=528293).

As for me, I think "versioning of metadata" and MAC time should be one
of the solution (with the logging of any conflict and differences)
Bug 302924 - Versioning of Metadata
Bug 310067 - Optional finegrained metadata for Modified/Access/Changed
time and Digikam Last Read/Write
I don't see as a heavy thing, svn/cvs manage it pretty well. After,
need to decide if this stay in database, file, or a separate
db/svn/cvs/...
And as said before, this should stay optional/for advanced users, even
i wish the MAC time information to be standardized.

Other could-be "related" bugs
Bug 194777 - synchronize images with database does not update all
images if there are a lot of images in one album
Bug 198406 - xmp not synchronized, uncomplete
Bug 268688 - Write metadata to all images does not remove obsolete tags
Bug 220204 - digiKam could warn when writing metadata to pictures fails

And the big one when working on *lot* of pictures (>>100k) or slow
hardware but not about tags merging
Bug 227814 - "Write metadata immediately" option
Bug 222401 - Write only changed metadata to file using single button or on exit

Cheers,

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

[eldk]

Hello,

I think a look must be done here too :

http://ninedegreesbelow.com/photography/dam-software-metadata.html

and to those bugs :

https://bugs.kde.org/show_bug.cgi?id=283323

https://bugs.kde.org/show_bug.cgi?id=230602


Consistency of tags, tagging, and do it "easy"  is one of the most
important feature for all users I think.  

Greatings,

Eric


Le mardi 19 février 2013 à 11:16 +0100, Marie-Noëlle Augendre a écrit :

> The tags synchronization issue has been poisoning the life (OK, only
> the photography workflow ;-) ) of a number of Digikam users for
> several months/years and frequently re-emerge as a subject in this
> mailing-list.
> As for myself (and I think for some others, too) I've gave up long ago
> to try to manage my tags, and I am patiently (more or less) waiting
> for the situation getting better before doing a huge organization of
> my whole photobase.
>
> Could the developers team tell us how soon the users can expect a
> solution to this blocking problem.
>
> Thanks,
> Marie-Noëlle
>
>
> --
>
>
> Mes dernières photos sont dans ma galerie.
> Connaissez-vous Image Fixe, le photo-club de Saint Jean du Gard ?
> 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

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

[tosca]

Wrong move.
You have to go the web page (link in the bottom of each message) in order to unsubscribe.

Marie-Noëlle

2013/2/24 David Vincent-Jones <[hidden email]>

List-Unsubscribe

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

--


Mes dernières photos sont dans ma galerie.
Connaissez-vous Image Fixe, le photo-club de Saint Jean du Gard ?
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