Bug 303239 - GROUP : grouped images are found, but do not show in searches
Summary: GROUP : grouped images are found, but do not show in searches
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Albums-ItemGroup (show other bugs)
Version: 2.7.0
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-09 16:20 UTC by Kyle Altendorf
Modified: 2019-11-10 20:40 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 7.0.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kyle Altendorf 2012-07-09 16:20:55 UTC
I use CHDK to shoot DNG along side JPG.  I used a couple cards and had some conflicts downloading (I use rsync, so my own issue, not digiKam's).  I recovered a bunch of images from the cards using photorec and used the fuzzy search to find the duplicates to delete.  Let's take image 4225.  The copies are:

IMG_4225.JPG
IMG_4225.DNG
f4095744.dng
<something>.jpg (already deleted)

I also normally group my DNG as sub-images of the JPG, so IMG_4225.DNG is grouped with IMG_4225.JPG as the primary.  f4095744.dng was never grouped.  When I fuzzy search, JPG are found and shown and I deleted all the recovered duplicates already.  DNG are also shown and say that their are two in the group, but when selected the grouped DNG are not shown unless I go back to a normal view and expand the group from the JPG.  The result is that despite showing that a found duplicate group has two entries, only one image is shown in the central gallery view.

Reproducible: Always

Steps to Reproduce:
1. Have .DNG and .JPG
2. Group .DNG to .JPG with .JPG as primary
3. 'Collapse' group
4. Copy .DNG to another name
5. Fuzzy search for duplicates
6. Select .DNG duplicate entry
Actual Results:  
Duplicate entry lists two items but only one shown

Expected Results:  
Duplicate entry lists two items and both are shown with some indication that the appropriate .DNG is part of a group.

This was also present in 2.6.0 this morning.  Both versions were installed from the philip5 PPA and are being run under Kubuntu.
Comment 1 Marcel Wiesweg 2012-07-22 15:14:22 UTC
On 1 July I have committed code which, as I believe, should fix this issue. I guess it is in 2.7.0.
Grouped images will not be shown, but if the master is shown, all grouped images should be loaded if not yet present.
Comment 2 caulier.gilles 2014-08-31 10:13:03 UTC
*** Bug 330905 has been marked as a duplicate of this bug. ***
Comment 3 caulier.gilles 2014-08-31 10:14:41 UTC
Kyle,

This file still valid using last digiKam 4.2.0 ?

Gilles Caulier
Comment 4 caulier.gilles 2016-07-06 19:46:22 UTC
This file still valid using last digiKam 5.0.0 ?

Gilles Caulier
Comment 5 Maik Qualmann 2018-03-14 06:04:40 UTC
*** Bug 391839 has been marked as a duplicate of this bug. ***
Comment 6 MarcP 2018-09-01 11:33:32 UTC
If I am not mistaken, this thread in Digikam's mail list refers to this bug. It provides an example and some screenshots showing the behavior.
http://digikam.1695700.n4.nabble.com/digiKam-users-Show-grouped-images-in-a-folder-td4706510.html
Comment 7 Maik Qualmann 2019-11-10 11:41:55 UTC
Marc,

I'm currently working on fixing inconsistent grouping behavior. What do you think, should we only show grouping in the Physical Album view and disable it in the Tag, Date and Search view? Or should an option "menu-> view-> [x]Show all groups as open" exist?

Maik
Comment 8 MarcP 2019-11-10 12:09:58 UTC
I am not sure. I mostly used grouping to group duplicated, very similar, or edited version of the same picture, often in different directories. The problem with that is that pictures not on the top of the stack (the "master") are hidden in their respective directories. But the same problem occurs in the Tag panel (among others). Ideally, all pictures in a stack should be displayed in all directories, regardless of which one is the master (or maybe any grouped picture in a given directory should be the master of his own stack?). I'm not sure if any of that makes sense because I don't know how it works internally.

Between the two options you propose, I'd lean towards the latter. It's in the album view where grouping is more useful, and also where it can cause more inconvenience when pictures are hidden.
Comment 9 Maik Qualmann 2019-11-10 20:40:50 UTC
Git commit cfcbed2adb646e21066c8615199586ab3cb49169 by Maik Qualmann.
Committed on 10/11/2019 at 20:38.
Pushed by mqualmann into branch 'master'.

add option in the view menu to show all groups as open
Related: bug 321339, bug 382311, bug 396337, bug 413704
FIXED-IN: 7.0.0

M  +3    -1    NEWS
M  +11   -4    core/app/items/views/digikamitemview.cpp
M  +1    -0    core/app/items/views/digikamitemview.h
M  +5    -0    core/app/main/digikamapp.cpp
M  +2    -0    core/app/main/digikamapp.h
M  +2    -0    core/app/main/digikamapp_p.h
M  +8    -1    core/app/main/digikamapp_setup.cpp
M  +3    -1    core/app/main/digikamui5.rc
M  +10   -0    core/app/views/stack/itemiconview.cpp
M  +1    -0    core/app/views/stack/itemiconview.h
M  +4    -3    core/app/views/tableview/tableview_model.cpp
M  +10   -13   core/libs/database/models/itemfiltermodel.cpp
M  +2    -0    core/libs/settings/applicationsettings.cpp
M  +3    -0    core/libs/settings/applicationsettings.h
M  +10   -0    core/libs/settings/applicationsettings_albums.cpp
M  +3    -0    core/libs/settings/applicationsettings_p.cpp
M  +2    -0    core/libs/settings/applicationsettings_p.h

https://invent.kde.org/kde/digikam/commit/cfcbed2adb646e21066c8615199586ab3cb49169