Summary: | It should be possible to search for more, if not all metadata fields. | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | Barbara Scheffner <laurakittyinka> |
Component: | Searches-Advanced | Assignee: | 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
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. 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. 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 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.
Created attachment 115183 [details]
MediaPro details view of IMG_3798.JPG
Created attachment 115184 [details]
MediaPro location view of IMG_3798.JPG
Created attachment 115185 [details]
digiKam IPTC details of IMG_3798.JPG
Created attachment 115186 [details]
digiKam XMP details of IMG_3798.JPG
Created attachment 115188 [details]
digiKam icon tooltip of IMG_3798.JPG
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 (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 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.
|