Summary: | Images sorted incorrectly | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | DrSlony <bugs> |
Component: | Import-Sort | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | bugs, caulier.gilles, wazery |
Priority: | NOR | ||
Version: | 2.9.0 | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 3.0.0 | |
Sentry Crash Report: |
Description
DrSlony
2012-09-19 15:06:29 UTC
By default, this time come from FS, not metadata. Why ? To collect quickly items information from camera device. I already solved this issue, through bug #246401 Solution : force digiKam to collect items info from image metadata. warning : this can take a while. Go to Camera setup, and turn on right option (disabled by default) Gilles Caulier Caulier thank you for looking into this, but unfortunately metadata time won't help, because it's identical for shots that were shot quickly in series. That's why I provided those exiftool/exiv2 results, unless you get the time from some other place? The only way to keep the correct order that I know of is to have that photo import window sort by filename, not by FS time or metadata time. No. there is no better way to extract date and time from metadata. After all it's stamp from camera device... By default, Date and Time granularity is limited to 1 second in Exif. There is perhaps a solution, if Markernotes as a better time resolution information to use. But, of course, it's not standardized... The Filename items filter mst be implemented in 3.0.0 beta1. Islam ? Gilles Caulier If the (new, 3.0) model/view implementation is similar to the main view, the filename will be used as second criterion if the primary one, the time, is identical. It should, at least. DrSlony: In the digikam main view, are the photos sorted correctly? @Marcel comment 4 The photos are not ordered correctly in the import from camera window. If I import the photos without renaming them and sort them by filename then they show up correctly in the digiKam main view. I have not tried to import the photos without renaming them and sort them by date in the digiKam main view. If I import the photos and rename them #### on the fly and sort by file name then they will also show incorrectly in the digiKam main view. Perhaps you can give us two photos which sort "B A" but should sort "A B" for testing. ad. comment 5: If I import the photos without renaming them and sort them by date then they show up correctly in the digiKam main view. If I import the photos and rename them #### on the fly and sort by file name then they will show incorrectly in the digiKam main view. If I import the photos and rename them #### on the fly and sort by date then they will show incorrectly in the digiKam main view. So this is a more human explanation of what's happening: 1- Some photos have an identical date when shot quickly in succession. 2- They are stored in the correct order on the memory card because the number in their filename is incremented in the correct order. 3- digiKam's Import window lists them in the incorrect order, which means it does not sort them by filename. 4- When imported without renaming, and the album is sorted by name or date, they are shown in the correct order. This means that when they are sorted by date and the date of two or more photos is identical, then digiKam falls back on the filename (which is good). 5- When imported with renaming to ###, they are numbered in the same incorrect order that they appear in in the Import window. When I sort by date, the order does not change. This is weird. Why would sorting by date show them in the correct order in point 4, but not here? Here are 6 sample photos for your enjoyment [54MB]: http://filebin.net/zkfwzmu5cb/file/bug_307053_photo_sort_order.tar.bz In the 3.0 import window, your six sample images in a short test are sorted as the file name sequence number suggests, regardless if I sort by date or by filename. Your comment 7 refers to 3.0 as well? Marcel: no, it referred to 2.9.0. Thank you for the fix :) If this is fixed in 3.0.0, please close it. |