[digikam] [Bug 367700] It should be possible to search for more, if not all metadata fields.
https://bugs.kde.org/show_bug.cgi?id=367700 meku changed: What|Removed |Added CC||kde.b...@meku.org --- Comment #12 from meku --- Created attachment 153069 --> https://bugs.kde.org/attachment.cgi?id=153069&action=edit 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. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 367700] It should be possible to search for more, if not all metadata fields.
https://bugs.kde.org/show_bug.cgi?id=367700 --- Comment #11 from Till Niermann --- (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 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 367700] It should be possible to search for more, if not all metadata fields.
https://bugs.kde.org/show_bug.cgi?id=367700 --- Comment #10 from Maik Qualmann --- 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 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 367700] It should be possible to search for more, if not all metadata fields.
https://bugs.kde.org/show_bug.cgi?id=367700 --- Comment #9 from Till Niermann --- Created attachment 115188 --> https://bugs.kde.org/attachment.cgi?id=115188&action=edit digiKam icon tooltip of IMG_3798.JPG -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 367700] It should be possible to search for more, if not all metadata fields.
https://bugs.kde.org/show_bug.cgi?id=367700 --- Comment #8 from Till Niermann --- Created attachment 115186 --> https://bugs.kde.org/attachment.cgi?id=115186&action=edit digiKam XMP details of IMG_3798.JPG -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 367700] It should be possible to search for more, if not all metadata fields.
https://bugs.kde.org/show_bug.cgi?id=367700 --- Comment #7 from Till Niermann --- Created attachment 115185 --> https://bugs.kde.org/attachment.cgi?id=115185&action=edit digiKam IPTC details of IMG_3798.JPG -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 367700] It should be possible to search for more, if not all metadata fields.
https://bugs.kde.org/show_bug.cgi?id=367700 --- Comment #6 from Till Niermann --- Created attachment 115184 --> https://bugs.kde.org/attachment.cgi?id=115184&action=edit MediaPro location view of IMG_3798.JPG -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 367700] It should be possible to search for more, if not all metadata fields.
https://bugs.kde.org/show_bug.cgi?id=367700 --- Comment #5 from Till Niermann --- Created attachment 115183 --> https://bugs.kde.org/attachment.cgi?id=115183&action=edit MediaPro details view of IMG_3798.JPG -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 367700] It should be possible to search for more, if not all metadata fields.
https://bugs.kde.org/show_bug.cgi?id=367700 --- Comment #4 from Till Niermann --- Created attachment 115182 --> https://bugs.kde.org/attachment.cgi?id=115182&action=edit 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. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 367700] It should be possible to search for more, if not all metadata fields.
https://bugs.kde.org/show_bug.cgi?id=367700 Maik Qualmann changed: What|Removed |Added CC||metzping...@gmail.com --- Comment #3 from Maik Qualmann --- 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 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 367700] It should be possible to search for more, if not all metadata fields.
https://bugs.kde.org/show_bug.cgi?id=367700 Till Niermann changed: What|Removed |Added CC||till.nierm...@netcologne.de --- Comment #2 from Till Niermann --- 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. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 367700] It should be possible to search for more, if not all metadata fields.
https://bugs.kde.org/show_bug.cgi?id=367700 caulier.gil...@gmail.com changed: What|Removed |Added Component|Searches|Searches-Advanced CC||caulier.gil...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 367700] It should be possible to search for more, if not all metadata fields.
https://bugs.kde.org/show_bug.cgi?id=367700 Glenn Washburn changed: What|Removed |Added CC||developm...@efficientek.com --- Comment #1 from Glenn Washburn --- 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. -- You are receiving this mail because: You are watching all bug changes.
