Bug 136260

SVN commit 598955 by cgilles:

digikam from trunk : KipiInterface : if a kipi-plugin change pictures metadata, use libkipi::Interface::refreshImages() to update sidebar Metadata contents.

Important: Marcel, this way do not yet update database contents accordinly with metadata contents (Tags/Rating/date/comments <==> EXIF/IPTC) from an existing item in picture collections. This requires more indeep changes in Digikam::Scanlib and digikam::AlbumDB class. We need to discut about these changes together.

CCMAIL: marcel.wiesweg@gmx.de
CCBUGS: 136260, 136258, 136256

 M  +8 -2      kipiinterface.cpp  


--- trunk/extragear/graphics/digikam/digikam/kipiinterface.cpp #598954:598955
@@ -62,6 +62,7 @@
 #include "dmetadata.h"
 #include "imageattributeswatch.h"
 #include "kipiinterface.h"
+#include "kipiinterface.moc"
 
 namespace Digikam
 {
@@ -597,6 +598,13 @@
 
 void DigikamKipiInterface::refreshImages( const KURL::List& urls )
 {
+    KURL::List ulist = urls;
+
+    // Re-scan metadata from pictures. This way will update Metadata sidebar and database.
+    for ( KURL::List::Iterator it = ulist.begin() ; it != ulist.end() ; ++it )
+        ImageAttributesWatch::instance()->fileMetadataChanged(*it);
+    
+    // Refresh preview.
     albumManager_->refreshItemHandler(urls);
 }
 
@@ -685,5 +693,3 @@
 
 }  // namespace Digikam
 
-#include "kipiinterface.moc"
-

Accordinly with commit #601479 and report #136257, the interface of MetadataEdit kipi-plugin have been completly re-written.

I close this file now.

Gilles Caulier

> I close this file now.


Gilles, I think you misunderstood scope of this wish. Interface is more
clear now (with separate entries in submenus) but I think author was
thinking about something like "meta-editor". For example if user would
fill Comment field, this field would be updated for all possible meta
data systems: Exif, IPTC, Digikam and in future XMP. In that way all
meta-comments would be in sync, without need to multiple editions of
similar dialogs.

If you don't want to do this kind of thing you should reclassify that
for WONTFIX or reopen it for future use.

m.

Op zondag 5 november 2006 13:53, schreef Mikolaj Machowski:
  > author was thinking about something like "meta-editor". For example
  > if user would fill Comment field, this field would be updated for
  > all possible meta data systems: Exif, IPTC, Digikam and in future
  > XMP. In that way all meta-comments would be in sync, without need
  > to multiple editions of similar dialogs.

This indeed is more like I ment to say. I would like to add that the way 
the program "easytag" (an ID3-tag editor for tagging musicfiles; 
http://sourceforge.net/project/showfiles.php?group_id=5216 ) is 
handling things in a sidebar is perhaps a nice example for digikam. 
Since the concept of sidebars is one of the pillars of digikam, this 
would be a nicer implememtation of tag-editing than the way it is done 
now via a three-levels-deep nested menuoption.

Caspar.

See comments #3 and #4. I reopened the report.

Caspar.

I am still not sure if I understand the wish.
If I change the comment of a picture in the Comments & Tags sidebar, and the relevant setup option is enabled, the comment is changed in digikam's database, written to Exif and IPTC.
What we don't have currently is: "Write comment,tags etc. from the metadata of these pictures to DB" (currently only at first import) and "Write comments, tags etc. from DB to the metadata of these images" (currently only when changed using sidebar)

Op zondag 5 november 2006 16:13, schreef Marcel Wiesweg:
  > If I change the comment of a picture in the Comments & Tags
  > sidebar, and the relevant setup option is enabled, the comment is
  > changed in digikam's database, written to Exif and IPTC. What we
  > don't have currently is: "Write comment,tags etc. from the metadata
  > of these pictures to DB" (currently only at first import) and
  > "Write comments, tags etc. from DB to the metadata of these images"
  > (currently only when changed using sidebar)

You're quite right. And therefore I like to refer to what Mikolaj 
Machowski wrote:
For example
  > if user would fill Comment field, this field would be updated for
  > all possible meta data systems: Exif, IPTC, Digikam and in future
  > XMP. In that way all meta-comments would be in sync, _without_need_
  > _to_multiple_editions_of_similar_dialogs.
But it is not only about the Comment, Keywords and Creation-date. I 
would like to be able to edit ALL the relevant EXIF- and IPTC-tags from 
within one integrated dialog, instantly available and not only via a 
menu-option. As I suggested a sidebar-solution would be great.

Caspar.

True Marcel. But it works (incompletely as you wrote) only for Comment,
Tags.  There are more fields common for all meta-systems. Eg.: Date,
time, copyright.

Well, the solution is simple : add Checkbox options at the right place on both dialog to sync common tags (Exif Comments <=> IPTC Caption <=> JPEC section <=> host app. comments for example)

I have seen some Win32 app. running like this.

Gilles

Op maandag 6 november 2006 20:30, schreef Gilles Caulier:
  > Checkbox options at the right place on both dialog to sync common
  > tags (Exif Comments <=> IPTC Caption <=> JPEC section <=> host app.
  > comments for example)

This is exactly what I meant to poit you at, mentioning easytag to you 
as an example of how this can be done. I'll add a screenshot of the 
program to the list.

Caspar.

Created attachment 18445 [details]
easytag mainwindow screenshot

SVN commit 720609 by cgilles:

digiKam from trunk (KDE4) : XMP metadata management with database.

This is the first stage to control XMP metadata contents with Database contents and vis versa. This code handle XMP with current Database schema witch still the same than 0.9.x.

Marcel work currently on the new databse schema describe on the OpenOffice document available at this url :

http://websvn.kde.org/trunk/extragear/graphics/digikam/DBSCHEMA.ODS?view=log

The code will be adapted later by Marcel to handle more XMP tags according with this new schema.

This is the list of current changes :

- Preparing code to handle strings hosted in different languages (comments for example, dixit B.K.O #98462).
- Handle all Xmp.exif and Xmp.tiff tags has Exif metadata content to get photo informations set by camera.
- Do not set Iptc.Urgency tag with Rating value, but use standard Xmp.Rating tags instead. Import of Iptc.Urgency 
as Rating still running if Xmp metadata are not available. (B.K.O: 134206).
- Preparing code to handle Xmp strings set different authors(comments for example, dixit B.K.O #134476).
- Set the Tags name as Xmp.subject (keywords).
- Set the Copyright/Authors information in Xmp tags (schema inspired from Adobe Photoshop 7.0).
- Store Tags Path List into a dedicaced digiKam.org Xmp namespace as a sequence of strings. Do not use Iptc.Keywords for that. Import from Iptc still running if Xmp metadata is not available. This way is very important to restore properlly in database all tags assigned to an imported picture. There is not strings size limitation with Xmp and char encoding is always UTF-8. Nothing will be lost now.
- Xmp is always stored in pictures format witch support this metadata format : jpeg, png, and tiff.

All these changes require to update libkexiv2 and Exiv2 from trunk to compile and run digiKam properlly.

CCMAIL: digikam-devel@kde.org
CCMAIL: marcel.wiesweg@gmx.de

BUG: 134206
BUG: 149966

CCBUGS: 98462
CCBUGS: 132362
CCBUGS: 91811
CCBUGS: 134476
CCBUGS: 136260
CCBUGS: 146714




 M  +59 -44    digikam/metadatahub.cpp  
 M  +1 -1      libs/database/collectionscanner.cpp  
 M  +127 -71   libs/dmetadata/dmetadata.cpp  
 M  +5 -4      libs/dmetadata/dmetadata.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=720609

Caspar,

Please try digiKam 1.0.0-beta3 from svn trunk. There is:

- Metadata Template support.

http://www.flickr.com/photos/digikam/3706246469/

- a new Batch Queue Manager with...
- a Batch Template metadata tool.

http://www.flickr.com/photos/digikam/3680885801

This is enough for you ?

Gilles Caulier

I am not on KDE4 yet, and probably will not for some time. So I am not able to judge what you implemented. The screenshots look promising.

The metadata templates don't really work as I, personally, would expect.  I had assumed that I could apply a template and it would only update the fields contained in the template.  Instead when I apply a template it removes entries already set in on the file if the template doesn't have a value for the field.  I expected it to leave those tags untouched.

How about using the existing Image / Metadata / Edit XMP window for this functionality? I'd guess that sidebar would be too much cluttered (especially on smaller displays).

The edit XMP window already includes majority of needed keys (ITPC Core, IPTC Ext), many of which can usually be synced directly with other standards (IPTC/IIM, Exif, Dublin Core, ...).

Additionally, it would be nice to allow smart editing of the keys in case of multiple images selected (overwrite, update, add). Keys, which have different contents in selected images, could be greyed out to warn user that if changed, information may be lost in some images.

This would probably also solve the bug https://bugs.kde.org/show_bug.cgi?id=144858 asking for a batch metadata editing.

Templates are of limited use: they are useful only for data shared by almost all images, not for step-by-step adding of metadata (e.g. select all images and add origin:country; select less images: add origin:city; select even less images and add origin:sublocation, etc.).

Caspar,

There are few work on this entry. It still valid using digiKam 2.x serie ?

Gilles Caulier

Thank you for the bug report.

As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.

digiKam takes care about syncing the metadata accross various data structures (XMP Core/Adobe/whatever, IPTC, Exif), so direct editing of a particular subset does not seem a way to go anyway as it would break the sync.

Batch application through standard UI (side bar: tags, caption; GPS location via menu Item / Geo) seems to work quite well - only the "changed metadata" are applied to selected images (replacing existing values, if any), other metadata are preserved.

A more fine grained mass editing is better to be done in a script with exiftool/exiv2.

IMHO, this bug report could be closed as Fixed (I am not the "reporter", though).