Bug 367700

Summary: It should be possible to search for more, if not all metadata fields.
Product: [Applications] digikam Reporter: Barbara Scheffner <laurakittyinka>
Component: Searches-AdvancedAssignee: Digikam Developers <digikam-bugs-null>
Status: REPORTED ---    
Severity: wishlist CC: caulier.gilles, development, kde.bugs, metzpinguin, till.niermann
Priority: NOR    
Version: 5.2.0   
Target Milestone: ---   
Platform: Ubuntu   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: Test image as requested by Maik Qualmann
MediaPro details view of IMG_3798.JPG
MediaPro location view of IMG_3798.JPG
digiKam IPTC details of IMG_3798.JPG
digiKam XMP details of IMG_3798.JPG
digiKam icon tooltip of IMG_3798.JPG
Photo with FujiFilm EXIF metadata

Description Barbara Scheffner 2016-08-23 06:40:00 UTC
From the above list of Possible Duplicates only 180268 has some relvance from my point of view. Unfortunately Ingomar has restricted his description to the artist or byline field.
In my opinion it should be possible to search for much more, best all metadata fields. In the handbook there is a good chapter explaining the advantages of Digital Asset Management which has to do a lot with metadata. There is also something said about workflow.
Very often my first step in a workflow to edit metadata is to find all the pics I want to edit. For example I made a mistake in the last few years using ES as country code for Spain. digiKam now offers ESP in it's dropdown list for the country field. To tidy up the mess I need to find all the pics with ES as country code. Similar problems exist in my collection with other fields like sublocation, city, ...
And generally spoken: when you set up a database you never know what you might want to search for later. So it makes no sense to limit the search to certain fields.

Next step in the above example would be to change the country field of all the pics in the search result from ES to ESP with one mouse click. But that will be a new entry to the the wishlist ...
Comment 1 Glenn Washburn 2017-03-13 19:45:23 UTC
I'm running into an issue on 5.4 that this feature request would resolve as well.  I'd like to search all images that have the GPano XMP namespace, but there is currently no predefined search area for this (nor do I think there should be).

bug 180268

I think a first iteration of this should create a new search section called "Metadata".  In that section there should initially be one horizontal line of a select box and a text input box.  The select box would contain a selectable list of all metadata fields contained in every image known to the database.  The text input box would be the corresponding value being search for.  Further iterations can add search operators and value type selection.

Just below the metadata search fields should be a button labeled "Add search field" or something like that.  Pressing the button would add another metadata search field as an AND clause in the query.  Further iterations may choose to add the ability to modify the AND to an OR or add other boolean logic operations.

As I understand it the search currently can only search over data in the database.  Not all (actually most) of the image metadata is not stored in the database.  So this issue depends on a as of yet non-existant bug to change the schema and import all image metadata.  I don't think the importing should be too difficult since DK already gets and displays the metadata info in the metadata tabs.  As a side note, the maintenance mode which syncs image metadata to database should be taken into account as well.
Comment 2 Till Niermann 2018-09-22 08:55:37 UTC
I have been a MediaPro user for a long time, now I'm forced to migrate to a different DAM tool because Phase One decided to discontinue this product. So in a first step I had MediaPro write the catalog's metadata to each image file.
Now, if I want to use digiKam, I'm having serious trouble getting some of the data out of the files, and into digiKam. The main reason is that in digiKam it is not possible to search in specific metadata fields, e.g. the ones that were added (and filled) by MediaPro. So even though after a long evaluation of alternatives digiKam seems to be the best option for me, I'm losing valuable information, specifically:

* Hierarchically organized location information (country - state - city - location)
* Names of persons (in my case, hundreds of them).

That information had its dedicated fields in MediaPro, so converting all that to tags wouldn't be helpful.

Of course, I could think of a better solution than just an enhanced metadata search. The best solution for me would be a more generic support for location information that is not geocoded, and for persons.
Comment 3 Maik Qualmann 2018-09-22 20:33:51 UTC
Can you provide a test image with metadata to get an idea of which tags are not processed. DigiKam already supports "Xmp.mediapro.CatalogSets".

Maik
Comment 4 Till Niermann 2018-09-23 13:04:15 UTC
Created attachment 115182 [details]
Test image as requested by Maik Qualmann

Test image (MediaPro catalog entry) as requested by Maik Qualmann. The image itself was scaled down so as to make the file smaller.
Comment 5 Till Niermann 2018-09-23 13:06:02 UTC
Created attachment 115183 [details]
MediaPro details view of IMG_3798.JPG
Comment 6 Till Niermann 2018-09-23 13:06:47 UTC
Created attachment 115184 [details]
MediaPro location view of IMG_3798.JPG
Comment 7 Till Niermann 2018-09-23 13:08:18 UTC
Created attachment 115185 [details]
digiKam IPTC details of IMG_3798.JPG
Comment 8 Till Niermann 2018-09-23 13:08:53 UTC
Created attachment 115186 [details]
digiKam XMP details of IMG_3798.JPG
Comment 9 Till Niermann 2018-09-23 13:35:09 UTC
Created attachment 115188 [details]
digiKam icon tooltip of IMG_3798.JPG
Comment 10 Maik Qualmann 2018-09-23 19:53:09 UTC
Thanks for the sample. Much has already been read by digiKam. The "People" tag not yet. The location "Zeche Zollverein" is problematic. The tree: "Deutschland-> Nordrhein-Westfalen-> Essen" could be formed from IPTC-> Country Name-> Province State-> Sub Location, but is this a common standard for a tag tree?

Maik
Comment 11 Till Niermann 2018-09-23 20:18:56 UTC
(In reply to Maik Qualmann from comment #10)
> Thanks for the sample. Much has already been read by digiKam. The "People"
> tag not yet. The location "Zeche Zollverein" is problematic. The tree:
> "Deutschland-> Nordrhein-Westfalen-> Essen" could be formed from IPTC->
> Country Name-> Province State-> Sub Location, but is this a common standard
> for a tag tree?
> 
> Maik
"Zeche Zollverein" is rather a "Sub Location", whereas "Essen" is the city. So the levels would be Country Name -> Province State -> City -> Sub Location. This seems to me like a logical hierarchy, and I made use of it on a regular basis, but I can't say if it is a standard. On the other hand, I wouldn't know a different place to specify a sublocation, e.g. a street address, a point of interest, or the name of a neighborhood within a big city.

Till
(In reply to Maik Qualmann from comment #10)
> Thanks for the sample. Much has already been read by digiKam. The "People"
> tag not yet. The location "Zeche Zollverein" is problematic. The tree:
> "Deutschland-> Nordrhein-Westfalen-> Essen" could be formed from IPTC->
> Country Name-> Province State-> Sub Location, but is this a common standard
> for a tag tree?
> 
> Maik
Comment 12 meku 2022-10-20 23:16:41 UTC
Created attachment 153069 [details]
Photo with FujiFilm EXIF metadata

I would like to amplify this feature request. There are various metadata fields that I find would be very useful to search or filter on, for example (names from exiftool):
- ExifIFD.CompositeImage (sometimes used to determine if image is an in-camera HDR)
- ExifIFD.LensMake (only the LensModel is currently searchable)

Also various maker-specific fields, for example:
- FujiFilm.FilmMode
- FujiFilm.PictureMode (more reliable than CompositeImage field for determining if image is an in-camera HDR)
- FujiFilm.WhiteBalance (more detailed than EXIF WhiteBalance)
- FujiFilm.ShutterType (mechanical or electronic)

To achieve this will require the bulk image metadata to be indexed to a new DB schema/table to make it searchable.