[digikam] [Bug 375703] New: Moving grouped images into another album removes groups

[bugzilla_noreply]

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

--- Comment #18 from Wolfgang Scheffner <[hidden email]> ---
But then I can throw all my wonderful doc about grouping into the bin :-((
No, but seriously: It's for sure worth a second thought! You are right: the
differences are minim. But right now I don't have the time for the second
thought. And the devs have to say anyway whether it is worth it from the
technical point of view.
I did use the function up to now only to get familiar with it for wrting the
doc. Will do a bit more soon (if I don't get washed away by the ongoing
discussion anyway).
Just one thing comes to mind: if we cancel grouping we need to provide some
kind of conversion for those users who used it already. We cannot just kill
their existing groups ...

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

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

--- Comment #19 from Jens <[hidden email]> ---
True - removing features must always be well thought out and there must be a
migration path (= database migration). I thought about this some more. The
concepts are indeed very similar, only little change would need to be done to
enable "pseudo grouping" using subfolders:

+ Albums would get a new property setting whether
  - the album should be treated as a folder as it is now, with
    - a entry in the albums tree view
    - a separate section in the main view)
  or
  - as an image group inside the main thumbnails view, not in the albums
sidebar
    - using the album's folder thumbnail image as thumbnail
    - and the thumbnail image's metadata to sort this thumbnail

+ Such "group" albums would also allow metadata changes to the main thumbnail
image and optionally apply them to all images inside the group.

+ There must be a migration function which converts grouped images to "group
folders"
  for all future Digikam versions (since we don't know what versions people
will use)
  which automatically activates on startup so future Digikam versions don't
modify old databases.

Advantages:
- We can get rid of a huge ton of complexity regarding grouped images
  (moving, copying, external manipulation, reimport, etc.)
- Image groups are represented in the file system and not just in the database
  (better for external image manipulation)
- Import grouped images into Digikam is much easier since (almost) all you need
to do is create the appropriate subfolders. Maybe it would even be possible to
create ".xmp" files inside folders with appropriate folder properties for
Digikam, this would make data transfer even easier.

Disadvantages:
- There will be two types of "albums" for the future.
  This might require modification of existing code regarding albums.
-

I think it would be worth it. Image groups are a really great feature but right
now the feature is somewhat unstable and so I am still a bit hesitant to use it
intensively.

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

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

Ricardo Sanz <[hidden email]> changed:

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

--- Comment #20 from Ricardo Sanz <[hidden email]> ---
*** Bug 377782 has been marked as a duplicate of this bug. ***

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

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

--- Comment #21 from Ricardo Sanz <[hidden email]> ---
IMHO I don't think grouping images is so similar to subalbums. One typical use
of groups is group the RAW and the JPG file of the same image. This way you
only see one picture (the JPG probably) of your images instead of having the
RAW image, the camera JPG and your own developed JPG.

Also, about mentioned advantages, it's said: "Image groups are represented in
the file system and not just in the database (better for external image
manipulation)". This may be true, but is it really an advantage? Using groups
for each picture and its derivatives (RAW, JPGs, etc) means each 'real' album,
in the filesystem, would be a bunch of directories, with all versions of the
same picture on each. Is this better than having all in the same directory?
IMHO is not.

Using directories for each group probably will end in a cluttered album view
with thousand of tiny albums. Also, it makes necessary to select the main
picture of each subalbum to be shown in the parent album: this needs a
convenient GUI to do it. And, are all subalbums going to be shown in the parent
album alongside the parent's picture? This will be a change in current
Digikam's behavior, potentially affecting many users.

Also, grouping is a feature present in other image software like Darktable or
Adobe Lightroom.


I just wanted to add my point of view, of course I don't know the problems that
grouping brings to the Digikam base code, I'm a talking only as a user :)

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

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

--- Comment #22 from Jens <[hidden email]> ---
Ricardo, I wasn't intending to (much) change the *visual* appearance of grouped
images. Just the technical way of storing them.

Right now, there are a huge heap of difficulties involved in managing grouped
images and it is hard (if not impossible) to get at groups from without
Digikam. Using folders (=albums) for groups, with a special tag, will keep
files grouped if files are moved outside Digikam and not require a huge amount
of database management when copying, moving or renaming albums with groups.

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

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

Vincent Tassy <[hidden email]> changed:

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

--- Comment #23 from Vincent Tassy <[hidden email]> ---
Hi Team,
I was hoping this would be fixed in 5.6 but the problem still occurs and it's a
pain :-( losing alot of time re-doing the grouping of images ...

FWIW, On my system (Fedora25), the issue occurs only when moving albums from
one collection to another one (like local SSD to NFS based NAS)
Moving albums inside the same collection preserves images groups ...

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

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

[hidden email] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Moving grouped images into  |Moving local grouped images
                   |another album removes       |into another remote album
                   |groups                      |removes groups

--
You are receiving this mail because:
You are the assignee for the bug.