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.
These are very useful features for regular users.
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 #25 in bug 125387 would be a possible solution to this wish.
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.
*** This bug has been confirmed by popular vote. ***
It a very very usefull and wanted feature. Many processed copyes of one photo should be grouped, to be visible as one logical image.
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--
Andi, And another candidate for Qt4 Model/View of AlbumIconView Gilles Caulier
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
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.
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.
Is this a duplicate of this: https://bugs.kde.org/show_bug.cgi?id=126149 ??
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.
We just finished implementing a somewhat similar feature called "Group Selected Images By Regex" and added it to bug 318357
*** Bug 354324 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 318357 ***