Bug 121310 - GROUP : allow to have grouped pictures while importing
Summary: GROUP : allow to have grouped pictures while importing
Status: RESOLVED DUPLICATE of bug 318357
Alias: None
Product: digikam
Classification: Unclassified
Component: Import-PostProcessing (show other bugs)
Version: 0.8.2
Platform: Compiled Sources Linux
: NOR wishlist with 270 votes (vote)
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-02-03 19:46 UTC by Julien Narboux
Modified: 2022-01-21 03:31 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In:
caulier.gilles: Junior_Jobs+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Julien Narboux 2006-02-03 19:46:01 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources

Allow to group photos as a pile. Some photos could be grouped 
automatically when downloading from the camera. For instance
- photos which have been shot at a small time interval (less than 30 
seconds),
- photos which have been shot using bracketing
- photos which have been shot in panoramic mode and which need to be 
stitched (the files are named sta_ , stb_, stc_ ...  for some Canon 
cameras)

This idea is from Aperture.
Comment 1 michael papet 2006-07-17 23:52:59 UTC
These are very useful features for regular users. 
Comment 2 Arnd Baecker 2006-09-07 13:58:17 UTC
Grouping pictures might also be useful for images derived
from one image
(See http://bugs.kde.org/show_bug.cgi?id=125387)

When combining several pictures into a group, one could
select which of them is visible.

Grouping could also be useful when shooting a sequence of pictures
where maybe one or two are really good, while
the others are ok, and still nice to keep.

Visually line like |----------------| in the thumbs display
could indicate pictures belonging to a group. Clicking on such a line
would display all of them, and not just those which are marked
as visible.
Comment 3 Matt Rosewarne 2006-11-06 22:39:27 UTC
Comment #25 in bug 125387 would be a possible solution to this wish.
Comment 4 Arnd Baecker 2007-12-04 10:12:06 UTC
In http://bugs.kde.org/show_bug.cgi?id=151228 Christian Meyer wrote:
> But grouping offers a new problem: in a slide show or for generating tumbnails 
> only one picture of the group should be taken, as I want to see only the JPG 
> and not the RAW (for duplication and performance reasons).
> But in a general group (e.g. for pictures taken during a short period of time, 
> multiple JPGs that were processed differently from one RAW, source pictures 
> for panorama stiching, etc.) I problably want to see all pictures of that 
> group? during screening or a slide show.
> So the generalisation brakes here :(

I don't see that this breaks, if the following is implemented:
a) allow several images within a group to be visable, even if the
   group is collapsed
b) allow for "uncollapsing" a group of images/all groups of images

After uncollapsing one could easily select the images in the usual way.

The rules, by which images are (initially) collected in a group should
be flexible and be specified by the user. Adding/removing
further images to a group should be easily possible, 
as well as the selection of those images which are visible when
the group is collapsed.

In addition to the necessary changes in the database, 
this will require substantial modifications to the way albums
are displayed currently.

Comment 5 Steinar Skagemo 2007-12-19 07:06:35 UTC
*** This bug has been confirmed by popular vote. ***
Comment 6 Valery Novikov 2008-01-27 18:50:50 UTC
It a very very usefull and wanted feature. Many processed copyes of one photo should be grouped, to be visible as one logical image.
Comment 7 Gerhard Hoogterp 2008-02-05 22:43:37 UTC
I asked about something a lot alike in the newsgroup/mailinglist and was pointed to this bug. So here's my take on the idea:

-->8--
Anyhow, the idea is that images with the same basename would present
themselfs as a single image stack. They can share keywords, tags etc. as
they are versions of the same image. 

An example:
I download an image from my minolta as pict0001.mrw which I then load into
my raw file converter and convert int pict0001.jpg. As I want to upload the
image to photosig, usefilm etc. I create a version which has the right size
and a frame which I name pict0001.online.jpg. As I would like to print it
or to use it as a wallpaper I could also end up with a pict0001.20x30.jpg
and a pict0001.wallpaper.jpg

While this is just my way of naming things (and they are in a folder
structure with some added logic) it shows at least my wish to handle all
those versions as a single entity.
As in this case it could be automated (images with the same basename are
stacked) doing something alike manual could be beneficial for those with
other naming scheme's.

-->8--
Comment 8 caulier.gilles 2008-12-06 11:13:56 UTC
Andi,

And another candidate for Qt4 Model/View of AlbumIconView

Gilles Caulier
Comment 9 caulier.gilles 2008-12-06 13:43:01 UTC
Marcel, Andi,

To identify easily all file relevant of QT4 Model/View port for later 0.10.0, a new bugzilla tag have been created.

Please use it at necessary.

Gilles

Comment 10 Dotan Cohen 2008-12-08 11:48:34 UTC
At the risk of creating a lot of noise on bugzilla, I would like to add a usage scenario for this feature. Many users of digital cameras do not take a single photo of a person or place, but rather multiple shots in the hope that one will turn out nice. However, even the not nice photos are not usually erased! This feature will bring the way people view photos in Digikam in line with the way people shoot photos with their camera: shoot in series, but only aim for one good photo.
Comment 11 DGardner 2009-05-12 19:16:26 UTC
I would kill (metaphorically) for this kind of feature. I'm mostly just
repeating what is above, but I hope it shows that groups would be a big
benefit for a typical workflow and provides some use cases for designing
a solution.

I usually shoot RAW+JPEG because most of the time the JPEG is good enough
and I don't have to spend time doing a separate raw conversion. However,
I end up with twice the number of photos (one "x.cr2" for every "x.jpg")
and have to tag them all separately (I don't believe in "albums", I use
saved searches for that kind of thing, so I tag everything in detail and
have one album folder per month).

I rename all the files and have a naming convention for edits. For example,
"IMG_1234.cr2" might become "20090512-dg40d-1234-00.cr2" (where "00" is the
revision number of the original file). The JPEG will have the same name.
I might then do some editing and have "...-01.jpg" or "...-02-7x5.jpg" or
the like. These are all just alternative versions of the same image and
will be derived from the original CR2 or JPEG file. Sometimes there could
be half a dozen versions cropped for different aspect ratios for printing
or display as wallpaper, etc. However, all will have the same base name
"20090512-dg40d-1234". That would be the name I'd use for the group if
I could have a group. I'd probably pick the best edit for viewing on the
screen as the default image for the group.

As well as having lots of edits of one image, I often have lots of
alternative shots of the same subject. More than 50 is not unusual for
portraits (close-ups, head and shoulders, full body, etc.) and I usually
only want to see a few of these when browsing the thumbnails. At present,
I try to do this with filters based on star ratings, but I haven't got
around to rating everything yet, so it doesn't work very well and I can't
always decide which of the bunch I like the best and which one I'd prefer
on screen versus in print. I would not put them all in the same group. I
would have different groups, splitting up close-ups, full-body, etc. The
default image for the group might change over time as I decide which
images I prefer.

So, I have lots of copies of the same image and lots of similar images
and would like to group them. I'd really like two levels of groups. I
could see the default image for a group on the main thumbnail view and
then "explode" this to show the images in that group, but where images
are edits of the same image, they would still be grouped together. I
could then "explode" these and view them individually.

This would have a massive benefit to the usability of digiKam. I have
so many similar images that browsing the thumbnail view can be very
slow. If I could reduce the number of images shown in a way that does
not require a few rounds of tagging and filtering, it would speed up
my workflow a lot. It would also make it easier to show others parts
of the collection without having to say, "Let's skip those 97 images
of a bumble bee."

One level of grouping could be based on automatically matching base
file names. A nominated tag could be used to pick the "default" image
for any such grouping; I might pick "Technical/Default Revision" and
then apply that to one of the images whenever I'm creating revisions
of the same image. That would allow me to search for the images I want
to show on the screen without requiring any new search functionality
for some new kind of image relationship. Until I have added such a
tag (and I might never do so for some images), the system can just
pick one image for me. So, by defining a naming pattern, all my CR2
and JPEG images are grouped automatically on import and the base name
from the naming pattern would become the thumbnail name.

Grouping related images would probably need to be more manual. I could
lasso a few of these "same image groups" together and then allow them
to be collapsed to a single thumbnail. I don't particularly want to
give them a special name. My file names are sequential, so just giving
the base name of the first and last images in the group and the number
of images would suit me on the main thumbnail view. The default image
for the group could be defined by associating a tag or a star-rating
with this purpose. Star rating might suit some people, but I'd probably
have images with the same star rating in the group and only want to
pick the one that looks best on my screen, not the one that was cropped
for printing, so I'd associate a "Technical/Pick of Bunch" tag with
this purpose and assign it to one image in each group (if I had any
preference).

As others have mentioned, panoramic sequences would be much easier if
this grouping feature was available. The stitched image could then
become the default image for the group. (Who wants to browse through
all of the individual images for a panorama all of the time? It just
slows down the thumbnail view.)

That description is a bit rough and ready, but I hope you get an idea
of how much of a killer feature this could be.

Best of luck with the new QT4 Model/View changes. I hope it makes things
like this possible.
Comment 12 Mathias Lindner 2009-12-29 14:13:16 UTC
Is this a duplicate of this:
https://bugs.kde.org/show_bug.cgi?id=126149
??
Comment 13 Marcel Wiesweg 2009-12-29 14:59:19 UTC
Strictly, the bug later filed is a special case and thus a duplicate of this here which is the general case. But there are some interesting pieces of information in the 126.. bug thought the discussion is too long. Let's keep them both.
Comment 14 kde 2014-01-27 23:46:07 UTC
We just finished implementing a somewhat similar feature called "Group Selected Images By Regex" and added it to bug 318357
Comment 15 caulier.gilles 2015-10-25 08:45:08 UTC
*** Bug 354324 has been marked as a duplicate of this bug. ***
Comment 16 caulier.gilles 2022-01-21 03:31:06 UTC

*** This bug has been marked as a duplicate of bug 318357 ***