Version: (using KDE KDE 3.5.5) Installed from: Gentoo Packages Often, users import photos from e-mail, sites like flickr, flatbed scanners, or from digital cameras that have the wrong date set. For photos like these, a user might know that the photo is from "January 2004", but be unsure of the exact date in January 2004 that the photo was taken on. However, Digikam requires not only a complete date but also always has a field for the exact time the photo was taken as well. It should be possible for the user to specify the date of a photo only as accurately as he knows it. For example, the user should be able to say any of the following as the date/time of the photo: 2002 August 2006 15 May 1998, time unknown 14 January 2006, 03:17 pm As it is, I believe, Digikam assumes that it knows the exact date and time for each photo, even if this information is completely incorrect. Users who only know the year of a photo are essentially forced to set a date such as January 1st at 12:00pm, rather than not specifying a date/time at all. Further, albums have a similar problem. Users most often create albums containing photos that span multiple days. An album for a trip to Paris might include 5 days of photos. Yet, Digikam only allows specifying a single day as the date of the album. Digikam provides an easy way to make this date the mean date of the photos, but this is of limited practicality. Does the album date represent the date of the earliest photo in the album? The mean date? The latest date? The date when the photos were uploaded? Different users prefer each of these, but none of the approaches really make sense. The obvious, intuitive approach is to allow a range of dates for each album. For example, any of the following should be allowed as album dates: 2006 May-July 2004 13-19 July 2005 16 December 12:05 p.m. - 18 December 01:42 a.m. 29 September 1969 This would allow the user to specify dates to exactly the accuracy he knows the dates, and would make the search by date and browse by date features actually useful and practical for more users.
Digikam takes date from Exif headers. There is no support for fuzzy dates. As I understand desire for such solution I don't think introducing additional level for description of date in photo would be good thing. Completely different issue with albums. There is no problem of coordination with photo matadata.
I realize EXIF doesn't support fuzzy dates. I thought Digikam could set the EXIF date tag to the earliest possible date (e.g. "Jan. 1, 2006" for the fuzzy date "2006") and use a second tag (does ITPC support custom tags?) to indicate the fuzziness. This would allow backwards compatibility, and allow for fuzzy dates. Ideally, some modern, shared standard such as http://freedesktop.org/wiki/Standards_2fshared_2dfilemetadata_2dspec would allow standardization of a fuzzy date spec for all file types and metadata storage formats, which would prevent this from becoming useful only within Digikam.
Note that albums part of #0 is also related to http://bugs.kde.org/show_bug.cgi?id=89364 ("Change date of album to exif date of first image")
I ponder if setting a date for an album is needed at all. We have the dates in the database. Wouldn't it make more sense to compute it dynamicly when needed? Instead of setting the a date (range would be better) only have a global or per album (is that really needed?) config setting what to display. E.g: the first, average, last or maybe even custom ( like first+1Week+12hour date) Default IMHO should be the range first-last. Do we need the others? Use case where something less than first last makes sense? Mhmm,... Achim
I am using DigiKam to sort and manage a very old collection of family pictures (dates run from 1874 to 1930s). They have been scanned and, of course, have no EXIF records. I want to label them with a date as accurate as I can guess, which implies some fuzzyness. Using EXIF date and time for pictures which possess such headers is alright, but we really need a way to time-sort pictures with manually provided fuzzy data. Although in a totally different domain, GRAMPS (genealogical software) has solved the issue. Maybe, DigiKam could use a secondary date and time source in case EXIF data is missing.
I'm doing the same archiving of family photos and the dating issue plagues me as well. Rather than specify start/end dates I would suggest that we follow the scientific community's approach by specifying an uncertainty factor. I.e. for a number this might be like 10 +/- 0.5. For date values we would have June 4, 1974 +/- 2 months. Of course this would mean that the specified date would have to be the median date so that the fuzzy date boundary can exist before & after it. If we add two new integer fields to albums, uncertaintyCount (1-n) and uncertaintyUnit (enum of day/month/yr/decade/etc) we can generate hidden begin/end dates in the DB that can be used for SQL queries. I'm not familiar enough with the current DB schema to know if we can associate these new values with individual photos but it would be a good addition if we could. They wouldn't be stored as EXIF values, just held by digikam alone.
I like Brian's suggestion from the DB perspective, but if implemented it will require a UI that hides the uncertainty factor from the user. I can't see my mother in law understanding the uncertainty factor. Heisenberg, maybe, but not my mother in law. That said, I think that it is the perfect solution to actually having usable EXIF info, and having fuzzy dates. I'm also confirming the bug and voting for it.
Fuzzy date is really a strange concept (KPhotoAlbum)... It can be difficult to understand this stuff for end users. Also, it can be a lots of jobs to make a suitable interface... Marcel, Andi, what do you think about ? Gilles Caulier
*** Bug 158735 has been marked as a duplicate of this bug. ***
No feedback about (see my comment #8)... ??? Gilles Caulier
I don't think the implementation UI would be a difficult concept at all. You'd start at the top with a pair of radio buttons: [ ] date: [dateField] [ ] date range Users selecting the top option just enter the date as usual. Selecting the bottom one would reveal two additional date endpoint controls: (short explanatory text here) Earliest [datefield] Latest [datefield] ( show effective date span here) Once the user sets the date boundaries, under the covers Digikam computes the median date and the appropriate uncertaintyUnit & uncertaintyCount values to fit the specified date span. Brian Remedios
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.
The issue is still relevant, it would be great to support fuzzy dates.