https://bugs.kde.org/show_bug.cgi?id=372217 Bug ID: 372217
Summary: The results of the Duplicates are currently sorted by
the image id and sortable by name and count if
similars. But it should be sortable by the similarity
of the duplicates, too. [patch]
Product: digikam
Version: 5.3.0
Platform: Compiled Sources
OS: Linux
Status: UNCONFIRMED
Severity: wishlist
Priority: NOR
Component: Searches-Fuzzy
Assignee:
[hidden email]
Reporter:
[hidden email]
Target Milestone: ---
Created attachment 102120
-->
https://bugs.kde.org/attachment.cgi?id=102120&action=editThe first patch.
When searching for duplicates, the result set is a table with the thumbnail and
the count of similar pictures (including the original one). It is possible to
sort the rows by either the reference picture (either name or id, I'm not sure
here) or the count of entries in this virtual album. Sadly, it is not possible
to sort the result by similarity. This patch introduces this functionality. For
each reference image, the average similarity (in percent) is calculated for the
potential duplicates, excluding the reference image. This way, it is possible
to sort the virtual albums by the average similarities of the duplicates in
both ascending and descending order. There is still one glitch in the sorting.
Since the sorting of the items is done by lexicographic order, the ordering of
was not correct if the length of the average similarity string differs. This
problem was fixed with another patch that introduces arithmetic ordering for
this column explicitly. The second patch will be submitted as comment.
The complete commit messages:
"
[PATCH] Extended the duplicates search list view. Now, the average
similarity of the found duplicates (excluding the original image) is shown as
table column. Sorting the result set by the average similarity is thus
possible. To implement this feature, the haariface had to be modified. It
returns a map of average similarities to a map of image ids to the set of
similar images instead of the map of image ids to the set of similar images.
Communicating the average similarity to the search list view was not possible
via slots and signals and this would have lead to sending a map of image ids
to average similarities and then distributing the appropriate average
similarity to the correct FindDuplicateAlbumItem. Instead, the average
similarity is communicated via the SearchXml-query as a field of the group.
This way, the correct item gets the correct similarity automatically. The
evaluation of the new field by an SQL query is surpressed by the introduction
of noEffect fields which need to have a prefix "noeffect_". So, the log is
not polluted by unnecessary debug information.
"
and
"
[PATCH] The items in the FindDuplicatesAlbum were sorted by
lexicographic order which does not make sense for the average similarity
column (e.g. 100.00 is not correctly sorted). Thus, the less than operator
was adopted such that for the average similarity column, arithmetic order is
used. To make the code more stable against regressions due to reordering the
columns, an enum was introduced.
"
--
You are receiving this mail because:
You are the assignee for the bug.
Locked
