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 ...
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.
Similar story here... As Digikam is picking up in popularity, the DAM use case is probably weighing in more and more. Nowadays, even a small family album can be seen, in many ways, as a miniature DAM of some sorts... which boils down to.... Metadata. Luckily, the basics are already there : Date, Title, Caption, ... But there is a whole bunch other popular medata fields that are simply a pain to work with in Digikam at this point. - Take "source", for example. I am (sort of) able to do data entry on it (through templates)... But then I can't really meaningfully use it anywhere (search, table view, filters, ...) - Similar story with "author" / "creator"... which is luckily included in SEARCH, but not much of anywhere else.. - ... Imho, bringing all DC(Dublin Core) and IPTC fields into being "first class class citizens" would be a good starting point. However, being able to deal with ANY arbitraty metadata would be a game changer (though, I do realize that kind of generic support might be more challenging). Here's a short list of the kinds of things I would love to be able to do with ANY metadata field : - search queries - table views (as a custom column) - filters - thumbnail view (as a custom field by selecting it in preferences) - data entry (single image) - data entry (multiple images) - ... anywhere else ? For me, it starts out with SEARCH, that's why I have chosen to put this as a comment on this ticket. But obviously, it doesn't stop there. There are a bunch of other places (Table Views, Filters, ...) where being able to deal with ANY arbitrary metadata would be extremely useful. So, let me know if the maintainers prefer to track this (more general) request through another dedicated ticket, which I would be happy to open. BTW, when I say ANY arbitrary metadata field, I really mean it. This even includes the so called "composite tags" generated on the fly by ExifTool, which may even be user-defined ones. (Don't worry, those already show up in the Metadata View. So Digikam is already capable of fetching them.) Let's face it, one doesn't usually have full control over what metadata is written for an image, or where... This is true even for photos I take myself (as dictated by the camera) ... And it is more so for pictures that come from elsewhere... which may include those that were taken by a cousin (in a family setting)... or pictures sent by a photo agency (in a professional DAM setting). So, even if we try to settle for a small subset of Metadata fields ourselves, we still need to be able to deal with the reality of what flows into our collections... be it in a family setting, or a non-profit organisation, or professional collections.