------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=140202 Summary: Allow fuzzy dates for photos and albums Product: digikam Version: unspecified Platform: Gentoo Packages OS/Version: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: general AssignedTo: digikam-devel kde org ReportedBy: mail bradenm com 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-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=140202 ------- Additional Comments From mikmach wp pl 2007-01-17 21:52 ------- 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. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Braden MacDonald-2
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=140202 ------- Additional Comments From mail bradenm com 2007-01-17 22:52 ------- 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. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Braden MacDonald-2
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=140202 ------- Additional Comments From arnd.baecker web de 2007-01-18 08:02 ------- 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") _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Braden MacDonald-2
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=140202 ------- Additional Comments From ach mpe mpg de 2007-01-18 23:58 ------- 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 _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Braden MacDonald-2
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=140202 ------- Additional Comments From page74010-ldsgen yahoo fr 2007-07-03 19:35 ------- 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. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Braden MacDonald-2
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=140202 ------- Additional Comments From brianremedios gmail com 2007-07-04 19:17 ------- 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. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Braden MacDonald-2
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=140202 caulier.gilles gmail com changed: What |Removed |Added ---------------------------------------------------------------------------- Component|general |Metadata _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Braden MacDonald-2
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=140202 kde-2 dotancohen com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW everconfirmed|0 |1 ------- Additional Comments From kde-2 dotancohen com 2007-12-26 16:56 ------- 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. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Free forum by Nabble | Edit this page |