[digikam] [Bug 326501] New: classification: a new way of global search

[drch]

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

            Bug ID: 326501
           Summary: classification: a new way of global search
    Classification: Unclassified
           Product: digikam
           Version: 3.5.0
          Platform: openSUSE RPMs
                OS: Linux
            Status: UNCONFIRMED
          Severity: wishlist
          Priority: NOR
         Component: general
          Assignee: [hidden email]
          Reporter: [hidden email]

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.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

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

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |[hidden email]
         Resolution|---                         |INVALID

--- Comment #1 from Gilles Caulier <[hidden email]> ---
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

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[drch]

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

--- Comment #2 from bugs bunny <[hidden email]> ---
(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)

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[drch]

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

--- Comment #3 from bugs bunny <[hidden email]> ---
(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.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[drch]

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

bugs bunny <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |---

--- Comment #4 from bugs bunny <[hidden email]> ---
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

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

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

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|general                     |Searches

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

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

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|classification: a new way   |New search classifications
                   |of global search            |

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel