Version: 0.10.0 (using 4.2.90 (KDE 4.2.90 (KDE 4.3 Beta2)) "release 138", KDE:KDE4:Factory:Desktop / openSUSE_11.0) Compiler: gcc OS: Linux (i686) release 2.6.25.20-0.4-default This might be better considered as a wish than a bug, but I feel that it has buggy consequences... see background. First some background: --------------------- I had some photos in three different albums, which I'll label A, B, and C, where the photos in A were created before those in B, which were before those in C. All three of these albums were imported into digikam together, but despite having "View -> Sort images -> By date" selected, search results sorted the albums in the order C, A, B. Hmmm, confusing... I spent a long time trying to work out how my image dates were so messed up, despite looking OK. Turned out that this corresponded to the modification dates on the corresponding folders, and these dates were used to set the "Album dates" which appear to have a higher priority than the individual image dates in the sorting algorithm. Changing the "Sort albums" option did not fix this. None of this is what I'd expected. A suggestion for fixing this problem (with a bit of speculation on my part about the internals of digikam): --------------------------------------------------- Album dates seem to be initialised to the modification date of their directory (correct?). Then one must manually set the date to something otherwise (oldest, average, newest, etc...). I think it would be much simpler (and less onerous) on the user if there could be a global preference for deriving the default album date (e.g. oldest, newest, average, or folder date); especially for importing large back-catalogues of photos into digikam. Moreover, rather than simply being able to initialise album dates in a preferred way, it would be nice if an albums date could be set to "static" _or_ "dynamic" (maybe requiring a default option also). A static date would be set and never change on its own. You could still include oldest, newest, etc... shortcuts for picking these one-off dates. A dynamic date would change as changes to the folder's contents are noticed, based on whether oldest, newest, etc... is set in the albums properties. Finally I should note that I only propose the keeping of static dates at all because that seems to be the existing bahaviour. I could well imagine doing away with it completely however, and just using dynamic.
Any news on this after 8 years? I'd be happy with a very simple solution: Add one global option whether to determine the album date automatically or manually. That is, somewhere in settings, there'd be "Determine album date from" with options: - oldest image date - average image date - newest image date - manually specified date (this is the current solution) If the album dates are stored in the database, then changing this option to oldest/avg/newest could update all the album dates in the database (thus, one loses any manually set album dates). Also, the date choosing in album properties and album creation would be disabled/removed when not in "manually specified date" mode.
Archeology going on :D I support this idea, with slight modifications: Provide all options in the album creation/modification dialog and remember the one that was last chosen. There can still be a setting for automatically added albums (i.e. picked up by scanning), but I think there should be a direct choice in the dialog. No need to set it again if you don't want to, as it remembers the previous choice. Otherwise one has to know about some option hidden in the configuration, that's not good user experience. Changing the dates retrospectively could be a maintenance option, but certainly can't happen automatically. This violates the "least surprising and invasive behaviour" principle (which I just made up). Changing the users data automatically due to a new feature is never an option in my opinion.
One point of the "dynamic" date is that the album shouldn't have any date as such, only the images have dates. And then, the date of the album is just computed from the images (oldest, newest or average). If I add/remove images, the date of the album should change accordingly. This is what Shotwell does and I think it's intuitive. For me, it is very confusing that an album has a date and it can (and by default is) something very different from the photo dates. In my thinking, the images have dates and the "album date" just reflects that somehow. I understand that for efficiency reasons the album date is stored in the database and thus it needs to be updated automatically whenever the image collection changes in the album. Thus, the album date in the database isn't "user data" but rather just cached date. Therefore, I don't see any violation of the principle. :) And of course, this wouldn't have to be a default option. Also, I understand that sometimes people might want to put dates on albums so that it has nothing to do with the dates of the images, but I think that is not a typical case. At least I have never had any use for such a feature.
Simon, The idea some good too from my viewpoint... Gilles Caulier
@Jaakko I didn't consider the totally dynamic case and that's not what it is today. It is an actual property, not just caching of something derived from the album content. I do see your point, such completely dynamic behaviour would actually be fine by me. However it is a much more intrusive change, and I made bad experiences with assuming a "normal" workflow - people do all kinds of things. You could also call adding images with a completely different date later on "not typical" (at least I never do that). Well I guess it is moot to discuss this in more detail until someone picks this up and does it - I added it to my list of things to do when time permits, but that can mean anything.
This is the complexity of this kind of task : introduce changes which do not have side effect with all workflow already used by DK users. Typically the album date must be estimated, depending of the album contents. Automatized date computation can fail in some cases. For ex : - image has no date => we use file time stamp instead image metadata. - album has video => currently Exiv2 video metadata do not work has expected. We will return always the FS time stamp in this case. - album has XMP sidecar => date can be extracted from this container and if option is turned on from DK config pannel. - ... and i forget certainly some other cases here... So to compute the date album average can be complicated and can give a false value. Batch processing this kind of task can introduce wrong date in album properties from database. To resume : it's not simple task. This is why this entry exist since a very long time in bugzilla. Gilles Caulier
I don't see the complexity of determining image dates as a part of this issue. If we assume that digikam assigns dates to images somehow, determining album date automatically from that info is trivial. And because determining image dates is something that digikam has to do (and does) anyway regardless of this feature, I think it can be assumed. For instance, when the images are sorted by date, there is already some mechanism to figure out what date to use for each image. Just use the same mechanism here. How are missing timestamps handled when sorting images by date? Use the same result here. If an album is empty or none of its images has a date, then the album has no date and that's ok.
I just came up with a very simple solution that would be sufficient for me. Instead of needing to modify anything about album date framework, just add a few options to View -> Sort Albums: -> By Oldest Image Date -> By Average Image Date -> By Newest Image Date in addition to the existing options: -> By Folder -> By Category -> By (Album) Date And if the choice is persistent between sessions, that would be just the sufficient and perfect solution for me. Thus, this would still keep album date system as it is now, but still allows users to "ignore" that value and sort based on the album contents. What do you think?
There is now an option when importing whether to use the oldest, newest or average album date. With Bug 461069, the album date is now updated depending on the setting when copying, moving or deleting images. Maik