Bug 91562 - Change order of pictures in the virtual album manually
Summary: Change order of pictures in the virtual album manually
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Albums-MainView (show other bugs)
Version: 1.3.0
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-10-18 00:23 UTC by Tom Albers
Modified: 2018-08-20 07:16 UTC (History)
22 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Albers 2004-10-18 00:23:59 UTC
Version:           0.7.0-cvs (using KDE 3.3.0,  (3.1))
Compiler:          gcc version 3.3.4 (Debian 1:3.3.4-12)
OS:                Linux (i686) release 2.6.5-1-k7

For example: I made some pictures of my new house a while ago and want to order them so it makes sense for my parents. 

It would be nice if I could reorder the pictures manually.
Comment 1 Renchi Raju 2005-03-06 18:54:56 UTC
*** Bug 98340 has been marked as a duplicate of this bug. ***
Comment 2 DEnnis Meulensteen 2005-11-03 11:05:15 UTC
This is a great feature which I also miss since switching from iMatch under Win...

In Imatch it is called 'light box' sort mode and is implemented as a custom sort mode, where the sort order is maintained even when switching between sort by date, name, or whatever other sort mode.

This allows a person to sort like pictures and makes it a lot easier to detect keepers and trash junk pictures.
Comment 3 Torsten Crass 2007-05-08 17:19:23 UTC
Hi there,

on the digiKam homepage, a light box implementation has been announced, which is certainly a useful feature - though quite different from Tom's original feature request. I hope Dennis mentioning IMatch's light box feature in his posting doesn't prevent the DnD custom image sort order feature from being implemented for plain albums...? (Would be really cool if such a custom sort order could be retained when expporting an album as, say, HTML gallery...)

Regards --

Torsten
Comment 4 Simon van der Sluis 2007-11-13 08:55:46 UTC
I think being able to reorder images, preferably by dragging them to a new position in the album would be a great feature.

For example, I recently had 10 films developed into digital format by a camera shop.  However they did not developer the films in order, so the images as imported into digikam are in the order of development, not the order in which I took them.  A right pain.

I've not looked at the schema of the database, but assume it would be as simple as adding an order by column, and all queries could use this column in the order by clase.  The column could be initially populated by the order in which the images are added to an album, which in most cases should be file name or file creation date.

Apart from that, I'm lov'n digikam, keep up the good work.

Comment 5 Arnd Baecker 2007-11-13 09:14:02 UTC
Hi Simnon, in your case you could try to use the time-adjust to
bring the images into the right order.

Concerning your proposed solution, which sounds
perfectly fine on the level of ordering within one album:
There is maybe one issue, which makes things more complicated than just
an ordering within one album:
For a slide show I mark all relevant images using a tag.
Then I go into the tags view, only displaying the images 
for the slideshow, which may be scattered over various albums.
Now I would like to re-order some images. 
As this is not album based, how should this be implemented?
Even worse, if I have two slide-shows, but they re-use
the some of the images, but need a different ordering, how could this be done?

Maybe it would work to have additional orderings for each album and tag?
(What is, if new images get added to a tag, where do these end?
Its not obvious to me if this is the right solution ... 



Comment 6 Simon van der Sluis 2007-11-13 09:48:13 UTC
Hi Arnd

I hadn't thought of the case where you wish to order within a tag.
After giving it 5 minutes thought, ordering within a tag would probably 
be a great feature, the only sensible default ordering within a tag that 
I can think of is the order they are added to a tag, and where multiple 
images are added simultaneously, add them to the tag in the order 
specified by the album.  However I guess you'll never please everyone no 
matter how you implement this. 

I've tried the change date idea it does work, but it's a big job when 
you're trying to order over 500 pictures.

Simon

Arnd Baecker wrote:
[bugs.kde.org quoted mail]
Comment 7 Mikolaj Machowski 2007-11-13 11:44:36 UTC
Arnd, maybe not make it too difficult. Just say it is impossible to make
your own order in a Tag (and don't forget about Search).  Just add
feature: create Album from a Tag/Search (as is wish somewhere in BKO)
and make order there.

But nice addition would be possibility to make renaming work in such
ordered albums to make sure this order will stay in other programs (eg
I copy images from this album to Konqueror or burn on CD/DVD).
Comment 8 Arnd Baecker 2007-11-13 12:03:17 UTC
Hi Mikolaj, creating an Album from a Tag/Search would copy
all images, right? This I would not like...

(I think that ordering searches is not possible in an easy way,
but ordering images corresponding to a tag could work, 
in particular the way Simon suggested
seems doable, and not overly complicated ...)
Comment 9 Torsten Crass 2007-11-13 12:47:12 UTC
Hi all digiKam fans,

> I think being able to reorder images, preferably by dragging them to
> a new position in the album would be a great feature.

definitely! I've desperately been wating for years for this feature to be introduced! It's really such a pain that currently the only way to re-order images within an album (e.g. for HTML export) is to manually mess around with filenames, dates, and the like.

> I've not looked at the schema of the database, but assume it would be
> as simple as adding an order by column, and all queries could use
> this column in the order by clase.  The column could be initially
> populated by the order in which the images are added to an album,
> which in most cases should be file name or file creation date.

If I recall correctly, a patch implementing a sorting feature exactly the way your propose had been submitted years ago, but has initially been rejected since it would require a change in the database schema (though I don't believe adding a column should pose a big problem...). It was planned to introduce this patch in (I think) the 0.8 series of digiKam, but this hasn't happened yet -- in spite of the fact that we have 0.9.2 already... Considering that this is among the three highest rated digiKam feature request, I wonder when it will be implemented?

> Apart from that, I'm lov'n digikam, keep up the good work.

Agreed!

Regards --

    Torsten
Comment 10 Arnd Baecker 2008-02-28 07:36:01 UTC
*** Bug 158520 has been marked as a duplicate of this bug. ***
Comment 11 Marcus 2008-06-15 10:19:12 UTC
Just to add my wish to the wishlist:
Would really be nice to have a function for free order of pictures, for example in virtual folders like search, lighbox or a new slideshow. To show slides in a good order it would be great to have something like a layout table with numbered fields of slides, you can freely move slides within like exchange to slides, put one in-between... Well, this would need a database, to stay virtual. But file renaming - even if used with copies of the original files - is no option. Some export funktion incl. renaming to save the order for other programs would extend the possibilities.
Comment 12 Chris Green 2008-09-02 12:50:06 UTC
Just to add my "me too" this is most definitely something I would like to see in Digikam.
Comment 13 Stefan Haag 2008-09-02 22:59:25 UTC
As also mentioned on the ML: Using a playlist concept is another possible approach, at least for using in slideshows. This would also allow to show one
picture more than one time.
Comment 14 caulier.gilles 2008-12-23 07:57:56 UTC
Marcel,

It's _the_ top rating entry from Bugzilla. I set it as relevant of future Model/View implementation.

Gilles
Comment 15 paull 2009-06-14 08:05:50 UTC
Hi all
IMO, custom ordering of photos is a must-have for anyone preparing a serious slide show.(f-spot doesnt have it either..). Personally, I most prefer the concept of playlists: I would like to be able browse through various albums and tags, place slideshow-relevant photos on the lighttable, compare them, arrange their order, and save it as a slideshow/playlist.
Alternatively I could imagine that there is a custom-order-view for every tag. In the regular album/tag view, you can drag and drop photos in any order you like, and, switch back and forth between your custom order and the regular order-by-date view. In this case you would have to tag all slide-show-relevant pictures with a common tag first. This seems a bit artificial to me, the lighttable approach I find more natural.

Any chance of seing such a feature near future?
Comment 16 sergio.guibert 2009-07-30 18:22:51 UTC
Hi all,
I would definitely enjoy an "drag-and-drop" feature to manually change order of pictures within an album. 
Kphotoalbum and Picasa have such a feature, but I would prefer to use Digikam that I think more powerful.
Regards
Comment 17 Chris Green 2009-07-30 23:01:32 UTC
I want to change the order of sub-albums (what else can one call them)
in an album, not indiviadual images.
Comment 18 Kjetil Kjernsmo 2009-11-07 00:17:27 UTC
This is a feature of the Advanced Slideshow now, isn't it? So, what seems to be lacking is to save the slideshow as an album?
Comment 19 Dirk Langner 2009-11-08 23:11:15 UTC
*** Bug 177355 has been marked as a duplicate of this bug. ***
Comment 20 Marcel Wiesweg 2010-03-10 15:46:59 UTC
Still valid and alive
Comment 21 Marcel Wiesweg 2010-03-10 15:47:12 UTC
*** Bug 230136 has been marked as a duplicate of this bug. ***
Comment 22 caulier.gilles 2010-05-06 09:34:24 UTC
*** Bug 236249 has been marked as a duplicate of this bug. ***
Comment 23 JB 2011-08-24 15:46:20 UTC
This is indeed a must-have feature for any photo management software in my opinion. I would really like to use digiKam for my day to day photo management needs, but this is a show stopper. It can't be that hard to implement? If it's possible to sort images by rating (meta data) then it should also possible to add a meta data category for custom order? The only difficulty would be implementing an easy to use drag & drop interface. But considering how advanced digiKam already is in other aspects, that shouldn't stop such an important feature from being added to an otherwise great program.

JB
Comment 24 Francesco Riosa 2011-08-25 10:57:32 UTC
Note to self:

Adding a field in "imageInformation" would be better but imageProperty could do.
Order by granularity should became selectable.

For example datetime could be casted to date, then you apply manual order.

Also some album implementation around have spatial positioning of images, the changes should not forbid to switch to this implementation but possibly complement it.
Comment 25 Marcel Wiesweg 2011-08-25 17:41:14 UTC
I'm a bit skeptical to regard the order as a single property of a picture. Isnt rather the order of a group of pictures the property of a presentation, allowing a picture to be member of multiple presentations with different neighbors?

If we store an order like a z-level per picture, it works in one view (album) with a defined group of neighboring images, but can be completely off in the next view (tag, date).
Comment 26 Francesco Riosa 2011-08-25 18:23:12 UTC
(In reply to comment #25)
> I'm a bit skeptical to regard the order as a single property of a picture. Isnt
> rather the order of a group of pictures the property of a presentation,
> allowing a picture to be member of multiple presentations with different
> neighbors?
> 
> If we store an order like a z-level per picture, it works in one view (album)
> with a defined group of neighboring images, but can be completely off in the
> next view (tag, date).

Assuming:
1) the order should be unique in the whole collection, cross all the albums.
2) Only user marked images have an order, the other are neutral.

This way we can hope the order make sense also if the views are different, if this is too far fetched then we can keeping the previous assumptions:

create a table for sorting the images with the following properties:
image id,
view kind,
z index (or x,y,z for a spatial conscious album ;)

image id and z index are obvious, view kind could be of two types, "default" or a specific view descriptor {"album", "date", "tag"} this way we can:

a) chose to give or not a default order for the image
b) use the view order and fallback to a default one

Speaking of sql the only way I can think of it is a subquery which could look like this (mysql dialect):

(
SELECT 
  o.`z index`,
  o.`view kind`
FROM imageSorting AS o
WHERE o.`imageid` = ?id
  AND o.`view kind` IN ("default", ?view_kind)
ORDER BY (o.`view kind` = ?view_kind) DESC
LIMIT 1
)
result may be NULL

Be warned this is both complex and slow.

what do you think?
Comment 27 caulier.gilles 2011-12-14 10:16:50 UTC
*** Bug 191000 has been marked as a duplicate of this bug. ***
Comment 28 caulier.gilles 2011-12-14 10:17:43 UTC
Marcel, Do you see comment #26 from Francesco ?

Gilles Caulier
Comment 29 caulier.gilles 2011-12-14 10:28:43 UTC
*** Bug 216802 has been marked as a duplicate of this bug. ***
Comment 30 Arnd Baecker 2011-12-22 17:43:37 UTC
I think that the assumption "1) the order should be unique in the whole collection, cross all the albums." would
restrict the possible usage scenarios.
For example, if one wants to create different galleries for
a year (i.e by defining tags gallery_year and gallery_summer),
then both could use a subset of common pictures.
However these common pictures could be arranged in a different
ordering in each gallery. Thus the ordering would not be unique
in the whole collection.
Anyway, this would be a really cool feature ..
Comment 31 b3nmore 2012-07-04 18:46:51 UTC
I would really like to see this feature implemented in the near future. So I'm throwing in some comments to keep at least the discussion alive.

In my opinion, a manual sort order makes only sense, if it's linked to a reference set of pictures. This may be defined by an album or by tags (or by a time interval, but I'm not sure about this yet).
Why? Because
0) it meets the most frequent usage case: people choose a certain set of pictures and then start arranging them
1) it allows different subsets with common pictures to have their own order without influencing each other
2) all other views and search results can be mapped into an album or tag and than arranged
3) it probably makes implementing it much easier

Another question is what happens when items are added to the reference set? We need a way to incorporate them into our manual order. Probably the most natural way would be to follow the original order of the set (date, filename,size ...). That means use the pictures which weren't moved as a frame and place the new ones accordingly.

This gives us three attributes for our order identifier: reference set, original sort order and the picture position. A possible identifier could be constructed as follows (although their may be more SQLish ways to organize it): As soon as a picture is moved manually it gets an order identifier like
<ref set type><ref set id>_(orig sort key(+1)-orig sort key (-1))/2

I guess this needs some explanations. For example, we start with an album (album id=17) which is sorted by date. We move a picture between two pictures with dates "15.09.11 15:00" and "15.09.11 16:00" then the identifier would be a17_"15.09.11 15:30". Manually sorting goes then by date or the pseudo date of the identifier if the prefix matches the current view.

This approach has following advantages: Moving an images requires only to adapt the identifier of this particular image. When we add pictures to our reference set they get automatically incorporated in a natural order like discussed above. We can store the order identifier in the meta data of the image and restore the manual sort order by parsing the meta data (in the case we lose the db or we just copy a picture folder).

Some further thoughts: What happens when the reference set doesn't exist anymore (e.g. a deleted tag)? The order identifier to this reference set would become obsolete and should be deleted.

Hopefully it contains some useful thoughts, feel free to take it apart.
Comment 32 Teo 2013-06-20 10:57:47 UTC
Today we are at 3.3.0 Beta2, and this feature has not been inserted yet.
I have read the discussion and I second that it would be great its implementation DB-wide. 
I am also aware that it wouldn't be an easy task to accomplish.

But, what about to start implementing it only in album view? I do really thing this is a must-have feature for any decent photo management program... and Digikam is light-years far better than decent.
It seems to me that we don't build the wheel because we are not able to built a F1 car :-)

Please! please! please! Fix this!

Many thanks for your great effort on Digikam!
Comment 33 gorn 2013-06-20 11:21:40 UTC
Many thanks for great Digikam, but please, please, fix this.

To help a little I just add the idea how to approach this. I won't reapeat previous arguments from other comments and I think that for the first step we only need manual sorting for albums and tags. 
Here is what i suggest: Add the order column to the relation table which joins the tag/album and the photo. 
This way the same photo can be sorted differently in different albums/tags. Althought I think that for first iteration it is enough is newly added picutres have order column empty which would put them (for eaxample) at the end of the set. In fact this concept is quite natural, at this is the waydragging and dropping files a in from/to directories work in many Windowind systems (KDE, WIndows, Mac at least).
Comment 34 caulier.gilles 2013-11-28 12:23:59 UTC
*** Bug 323559 has been marked as a duplicate of this bug. ***
Comment 35 caulier.gilles 2014-08-23 21:26:27 UTC
*** Bug 337002 has been marked as a duplicate of this bug. ***
Comment 36 DrSlony 2014-08-23 23:19:24 UTC
Maybe someone will come up with a patch on 2014-10-18, to commemorate the 10th anniversary of this feature request? ;]
Comment 37 felix.reuning 2018-01-02 00:01:37 UTC
Unfortunately the feature is yet not available and I had to use FSViewer.exe (with wine) from http://faststone.org as workaround. Especially if you have pictures from different sources (smart phone, camera) and/or from a scanner - with no or wrong time stamp - it would be very helpful.

I think the FSViewer implementation could be used proposal. The custom sort is done with following steps:
1.) Sort Step: Sort pictures by drag & drop (This sort is only available within FSViewer because it is stored in a custom FSViewer file "fssort.ini")
2.) Fixation step: Automatic rename by pattern e.g. imageXXX (XXX is a counter)

Due to the fixation step re-sort result is available within other programs like digikam.
Could the team also implement this feature directly within digikam ???
Comment 38 Maik Qualmann 2018-07-29 18:01:22 UTC
Git commit 7b390cd8cdc8982b5cdd4489fbda36de59c73850 by Maik Qualmann.
Committed on 29/07/2018 at 17:59.
Pushed by mqualmann into branch 'master'.

Merge branch 'gsoc18-iconview-sort' into master

M  +24   -0    core/app/dragdrop/imagedragdrop.cpp
M  +1    -0    core/app/dragdrop/imagedragdrop.h
M  +71   -0    core/app/items/digikamimageview.cpp
M  +3    -0    core/app/items/digikamimageview.h
M  +3    -0    core/app/main/digikamapp_setup.cpp
M  +8    -0    core/app/views/digikamview.cpp
M  +1    -0    core/app/views/digikamview.h
M  +21   -0    core/libs/database/coredb/coredb.cpp
M  +9    -0    core/libs/database/coredb/coredb.h
M  +3    -1    core/libs/database/coredb/coredbfields.h
M  +28   -0    core/libs/database/item/imageinfo.cpp
M  +10   -0    core/libs/database/item/imageinfo.h
M  +2    -0    core/libs/database/item/imageinfodata.h
M  +10   -0    core/libs/database/models/imagesortsettings.cpp
M  +2    -1    core/libs/database/models/imagesortsettings.h

https://commits.kde.org/digikam/7b390cd8cdc8982b5cdd4489fbda36de59c73850
Comment 39 Maik Qualmann 2018-07-31 10:41:23 UTC
Git commit bf4ec4ab6b8e52454a3f5285c1a679df2ea39fb7 by Maik Qualmann.
Committed on 31/07/2018 at 10:39.
Pushed by mqualmann into branch 'master'.

factoring manual sorting

M  +2    -2    core/app/dragdrop/imagedragdrop.cpp
M  +18   -46   core/app/items/digikamimageview.cpp
M  +3    -3    core/app/main/digikamapp_setup.cpp
M  +2    -3    core/libs/database/coredb/coredb.cpp

https://commits.kde.org/digikam/bf4ec4ab6b8e52454a3f5285c1a679df2ea39fb7
Comment 40 Maik Qualmann 2018-07-31 19:48:07 UTC
Git commit c6e92a02cfeebc86b60faad9442e780a7342abbf by Maik Qualmann.
Committed on 31/07/2018 at 19:46.
Pushed by mqualmann into branch 'master'.

fix and optimize manual sorting

M  +21   -13   core/app/items/digikamimageview.cpp
M  +0    -2    core/libs/database/coredb/coredb.cpp
M  +14   -2    core/libs/database/item/imageinfo.cpp
M  +1    -1    core/libs/database/item/imageinfo.h
M  +1    -1    core/libs/database/item/imageinfodata.h

https://commits.kde.org/digikam/c6e92a02cfeebc86b60faad9442e780a7342abbf
Comment 41 Maik Qualmann 2018-07-31 20:12:27 UTC
Git commit ff2415c06095c98a439f886002bb6df824c12db9 by Maik Qualmann.
Committed on 31/07/2018 at 20:11.
Pushed by mqualmann into branch 'master'.

use CoreDbOperationGroup
FIXED-IN: 6.0.0

M  +2    -1    NEWS
M  +7    -1    core/app/items/digikamimageview.cpp

https://commits.kde.org/digikam/ff2415c06095c98a439f886002bb6df824c12db9
Comment 42 Philippe ROUBACH 2018-08-01 07:11:29 UTC
thanks
Comment 43 caulier.gilles 2018-08-01 09:21:07 UTC
Philipe,

This new feature to order icon view contents manually is not yet included in AppImage bundle. You cannot yet test this functionality. 

If you follow the commit in this file, you will see that a student work on this project in July in a separated branch, and Maik finalize the code for 6.0.0. The code is in git/master branch.

I'm not at home for 2 weeks. I cannot rebuild the AppImage bundle as my Internet connection is just limited by my cellular. I'm back on 13 August and i will provide a new 6.0.0 beta AppImage quickly. Please be patient.

Gilles Caulier
Comment 44 caulier.gilles 2018-08-20 07:16:05 UTC
Philippe,

This feature is now available in 6.0.0-beta1 bundles and ready to test. Files are here :

https://files.kde.org/digikam/

Gilles Caulier