Bug 326501 - New search classifications
Summary: New search classifications
Status: REPORTED
Alias: None
Product: digikam
Classification: Applications
Component: Searches-Advanced (show other bugs)
Version: 3.5.0
Platform: openSUSE Linux
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-23 13:01 UTC by bugs bunny
Modified: 2017-08-18 09:50 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description bugs bunny 2013-10-23 13:01:21 UTC
Description:
Currently, search groups support "single queries per property" (e.g. width between 400px and 800px). Consequently, there is only a single (local) search result. On the other hand, calendar and time line support the global classification of all images according certain criteria.

Request:
A generic classification schema (comparable to the search schema) for different aspects should be implemented as follows:

Proposal:
"Advanced classify" could be implemented in parallel to "advanced search" as follows:
parallel to e.g., "find pictures with a width between 100px and 1600px", there is a
- "classify pictures with a width between 100px and 1600px by 100 px", leading to 15 different classes which could be shown, e.g. in a kind of "calendar view" with corresponding thumbnails or, alternatively, in a type of "album view" (consisting of classes as albums) supporting all views.
Comment 1 caulier.gilles 2013-10-23 14:11:12 UTC
Do you know that all search criteria can be saved in Advanced Search view as a virtual album and replayed later as well. This include all date, time, and pictures properties criteria...

Gilles Caulier
Comment 2 bugs bunny 2013-10-24 09:32:49 UTC
(In reply to comment #1)
> Do you know that all search criteria can be saved in Advanced Search view as
> a virtual album

To be more precise:
Let's use the term "album" for a structure which can be substructered in hierarchies. Using this terminology, the result of an advanced search is a set of "search groups" (digiKam terminology). Currently, the results of "advanced search" can only be stored as a single list, not as a hierarchy.

The request / proposal is as follows:
1. "width between 100px and 200px" leads to an advanced search result (which can be displayed in a album)
2. "height between 200px and 400px" delivers a different image set

now, using the 2nd search result as sub-album of the 1st result would lead to the following image sets:
a) AND: sub-album contains all images fulfilling both search criteria
b) OR: sub-album contains all images fulfilling any criteria
c) XOR: subalbum contaings all images with width between 100px and 200 px and height not in range 200px until 400 px)

with the current approach (as far as I understand):
1. the two searches have to be formulated as a single advanced search, combining the different search criteria
2. three different searches have to be defined in order to formulate the different logical operators between the (elementary) advanced searches
3. there is no visualization of the different search groups as separate entities
4. moreover, it is not possible to change the logical operator between the search results without editing the search result again

the proposed concept separates search criteria and logical operators. Moreover, different logical operators could be displayed by different icons (like "^", "v", "x" (similar to the tag filter (right pane), where "+" and "-" show the inclusion/exclusion of a tag)
Comment 3 bugs bunny 2013-10-24 09:45:04 UTC
(In reply to comment #1)
> Do you know that all search criteria can be saved in Advanced Search view as
> a virtual album and replayed later as well. This include all date, time, and
> pictures properties criteria...
> 
> Gilles Caulier

This describes the properties of search criteria, however, it does not solve the "classification" issue.
"search" is filtering/selection, whereby "classification" is clustering/ordering: "classification" will deliver all input values, but combined in different (mutually exclusive?) clusters, while filtering delivers a subset, fulfilling the filter criteria. Filtering is covered in digiKam, clustering is not.
Comment 4 bugs bunny 2013-10-24 15:52:10 UTC
hierarchical search vs filtering:

another way of describing the concept is the simulation by tag filters as in the following example:
1. tag all images with width < 500 with the tag "width"
2. tag all images with height > 600 with the tag "height"
3. define the height-tag as a sub-tag of the  width-tag

then:
a) activating the width-tag only filters all images with width < 500 (independent of the height)
b) activating the height-tag filters all images with height > 600 (independent of the width)
c) activating both filters (must have) in "OR"-mode filters all images with width < 500 OR height > 600 (same with: activating width-tag and toggle=children or activating height-tag and toggle=parents
d) activating both filters (must have) in "AND" mode filters all images with width < 500 AND height > 600
e) activating both filters and setting the height-filter to "must not have" filters all images with width < 500 and height <= 600
and so on…

the proposed "hierarchical search" follows the same approach, but uses "(named) search results" instead of "tags" as filters