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.
*** Bug 98340 has been marked as a duplicate of this bug. ***
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.
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
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.
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 ...
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]
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).
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 ...)
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
*** Bug 158520 has been marked as a duplicate of this bug. ***
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.
Just to add my "me too" this is most definitely something I would like to see in Digikam.
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.
Marcel, It's _the_ top rating entry from Bugzilla. I set it as relevant of future Model/View implementation. Gilles
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?
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
I want to change the order of sub-albums (what else can one call them) in an album, not indiviadual images.
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?
*** Bug 177355 has been marked as a duplicate of this bug. ***
Still valid and alive
*** Bug 230136 has been marked as a duplicate of this bug. ***
*** Bug 236249 has been marked as a duplicate of this bug. ***
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
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.
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).
(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?
*** Bug 191000 has been marked as a duplicate of this bug. ***
Marcel, Do you see comment #26 from Francesco ? Gilles Caulier
*** Bug 216802 has been marked as a duplicate of this bug. ***
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 ..
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.
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!
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).
*** Bug 323559 has been marked as a duplicate of this bug. ***
*** Bug 337002 has been marked as a duplicate of this bug. ***
Maybe someone will come up with a patch on 2014-10-18, to commemorate the 10th anniversary of this feature request? ;]
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 ???
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
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
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
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
thanks
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
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