*** This bug has been confirmed by popular vote. ***

This wish is partially implemented and will be available in digiKam 0.8. The search functions will allow you to search on exif dates and comments. I'll leave this wish open until searching on all exif data is implemented.

Tom, 

In trunk svn branch, new Digikam::DMetatada class can be used for that. Just need to add new method to use with Exiv2 library. Let's me hear what you need exactly to perform metadata search.

Gilles Caulier

SVN commit 528157 by cgilles:

digikam from trunk : improving image properties restoration in database using image metadata:

- Fix DMetadata method to get image Exif/Iptc tags properlly. (With the old implementation, Comments from Exif and Iptc, Rating from Iptc and are never checked duing a wrong validity test - stupid bug)
- Now at startup, these informations are backported to database :

  ==> Comments from JFIF section, or Exif UserComments tag, or Iptc Caption tag.
  ==> Date & time stamp from Exif dateTime tag or Iptc date & time tags.
  ==> Rating from Iptc Urgency tag !!! If you add new files in your Album library, witch are rated using Mapivi for example, digiKam items rating will be appear in main interface.

Nota : these updates in database are only performed to new files :

  ==> when all albums are parsed during statup (or manually from Tool menu).
  ==> when new items are downloaded using camera interface.
  ==> when a folder is imported from main interface.

TODO :

- Performed a database update at startup when files are already in database and when metadata have been changed outside digiKam (using ExifTools for example)
- Do something with digiKam Tags, since they are stored in IPTC Keywords tags. This is most complicated to do because there is no hierarchy between IPTC Keywords like with digiKam tags. We store only Tags name in IPTC keywords. I propose : 

  ==> to check if a digiKam tags name already exist in database and taging automaticly item using it. 
  ==> do nothing if Tags name do not exist (no new digiKam Tags will be created in database).
  ==> If dupplicate Tags name exist in digiKam database (for ex. Travel/City and Travel/France/City), use only the first Tag name found in database.

digiKam Tags <==> IPTC Keywords rules is a complex problem. Please give me your viewpoints into B.K.O. Thanks in advance

CCMAIL: digikam-devel@kde.org
CCBUGS: 91811

 M  +9 -4      digikam/albumdb.cpp  
 M  +4 -1      digikam/albumdb.h  
 M  +7 -5      digikam/scanlib.cpp  
 M  +16 -3     kioslave/digikamalbums.cpp  
 M  +4 -4      libs/dmetadata/dmetadata.cpp  
 M  +14 -8     libs/jpegutils/jpegmetadata.cpp  
 M  +9 -5      libs/jpegutils/jpegmetadata.h  

My viewpoint :
- Perhaps the database update should be optionnal at startup (enabled by default for newcommers) and availlable from the tool menu. This database update can be time consuming with big databases and experimented users will know when they have changed the IPTC informations on their pictures (and they can go and take a coffee if they trigger the update themselves).

- If the Tag name does not exists, digikam should ask if it should be created or not and where. Of course, there should be a choice to apply the answer only on the actual picture or to all the following (on that session or everytime ?).

- Perhaps the same for duplicate tags : choice between taking the first tag, all tags or ask which one. If first or all is chosen, the following images will be handled automagically else the question will be asked on each duplicate.

Appart from that, "toutes mes félicitations" for all the big work done on that application. IPTC handling was the missing feature that was taking me away from digikam and now, everything is comming in good shape.

Loïc from France near Geneva

#1 : 

==> database update is already an option in Misc Setup dialog page.

==> About startup time, this will no take any more time that we have actually, because i'm use an instance of a new class named DMetadata using Exiv2. No image dedoder have been used to extract metadata. Exiv2 use a pure file parser (like it does with KFileMetaInfo).

An instance of DMetadata is created for each file parsed. This class extract Exif and IPTC metadata at once. After i just parse in memory the right tags. It's very fast.

Actually only JPEG file are parsed. In the future, We will parse more file types, like TIFF/EP, DNG, NEF, CR2, CRW, etc... Current Exiv2 implementation can support these file formats. Only in this case, startup will be decreased...

#2 #3 : 

==> this can be very wierd to end user if we have importated 100 new image files with differents IPTC keywords (:=)))...

==> perhaps a setup to perform automaticly theses operations can be better.

Gilles From France near Aix en Provence (:=))

SVN commit 533353 by cgilles:

digikam from trunk : improving image properties restoration in database using image metadata:

- Fix DMetadata method to get image Exif/Iptc tags properlly. (With the old implementation, Comments from Exif and Iptc, Rating from Iptc and are never checked duing a wrong validity test - stupid bug)
- Now at startup, these informations are backported to database :

  ==> Comments from JFIF section, or Exif UserComments tag, or Iptc Caption tag.
  ==> Date & time stamp from Exif dateTime tag or Iptc date & time tags.
  ==> Rating from Iptc Urgency tag !!! If you add new files in your Album library, witch are rated using Mapivi for example, digiKam items rating will be appear in main interface.

Nota : these updates in database are only performed to new files :

  ==> when all albums are parsed during statup (or manually from Tool menu).
  ==> when new items are downloaded using camera interface.
  ==> when a folder is imported from main interface.

TODO :

- Performed a database update at startup when files are already in database and when metadata have been changed outside digiKam (using ExifTools for example)
- Do something with digiKam Tags, since they are stored in IPTC Keywords tags. This is most complicated to do because there is no hierarchy between IPTC Keywords like with digiKam tags. We store only Tags name in IPTC keywords. I propose : 

  ==> to check if a digiKam tags name already exist in database and taging automaticly item using it. 
  ==> do nothing if Tags name do not exist (no new digiKam Tags will be created in database).
  ==> If dupplicate Tags name exist in digiKam database (for ex. Travel/City and Travel/France/City), use only the first Tag name found in database.

digiKam Tags <==> IPTC Keywords rules is a complex problem. Please give me your viewpoints into B.K.O. Thanks in advance

CCMAIL: digikam-devel@kde.org
CCBUGS: 91811

 M  +1 -1      imagedescedittab.cpp  


--- trunk/extragear/graphics/digikam/libs/imageproperties/imagedescedittab.cpp #533352:533353
@@ -417,7 +417,7 @@
         if (AlbumSettings::instance()->getSaveIptcTags())
         {
             // Store Image Tags like Iptc keywords tag.
-            metadata.setImageKeywords(oldKeywords, d->currInfo->tagNames());
+            metadata.setImageKeywords(oldKeywords, d->currInfo->tagPaths());
         }
 
         if (AlbumSettings::instance()->getSaveIptcPhotographerId())

Hi all,

Just to please users to be patient (:=)))

digiKam for KDE4 will improve the seach tool to includes all major photo informations. The Database structure will be changed to include a lots of new metadata. The new Database schema is avaialble on svn from this openoffice file:

http://websvn.kde.org/*checkout*/trunk/extragear/graphics/digikam/DBSCHEMA.ODS?revision=708848

Marcel currently work to enable this schema. A new Database front end have be written with a lots of new features as support of multiple root album for ex.

Database management is a tiedous stuff and we won't to test indeep before to give a public version to test. 

Thanks in advance for your patience and your support.

Gilles Caulier

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

This is actually implemented with latest commits about search bar. Gilles, is it ready for closing?

Mikolaj, I don't think so, this wish is about many more fields.
I think this can be implemented only for digikam >=0.10,
when all the fields are available in the database.

Mik,

No. Please, do not close this file. Search is to perform query on DB around whole albums collection. Filter only query DB about current selected Album. It's different...

Gilles

I move this file to Filter component. This is the last feature to do to solve this entry. It will be done with KDE4 port

Note : Metadata based search have been fully implemented by Marcel in KDE4 port of digiKam

Gilles Caulier

Regarding #13 I am closing this as done.