[digikam] [Bug 367700] New: It should be possible to search for more, if not all metadata fields.

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[digikam] [Bug 367700] New: It should be possible to search for more, if not all metadata fields.

bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=367700

            Bug ID: 367700
           Summary: It should be possible to search for more, if not all
                    metadata fields.
           Product: digikam
           Version: 5.2.0
          Platform: Ubuntu Packages
                OS: Linux
            Status: UNCONFIRMED
          Severity: wishlist
          Priority: NOR
         Component: Searches
          Assignee: [hidden email]
          Reporter: [hidden email]

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 ...

--
You are receiving this mail because:
You are the assignee for the bug.
Reply | Threaded
Open this post in threaded view
|

[digikam] [Bug 367700] It should be possible to search for more, if not all metadata fields.

bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=367700

Glenn Washburn <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #1 from Glenn Washburn <[hidden email]> ---
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 the assignee for the bug.