| Summary: | SCHEMA : add fuzzy dates support for photos and albums | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Braden MacDonald <mail> |
| Component: | Database-Schema | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | wishlist | CC: | bcr, caulier.gilles, james |
| Priority: | NOR | ||
| Version: | 0.9.2 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Braden MacDonald
2007-01-17 18:24:41 UTC
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. I'd like to add my support for this wishlist item. Since the main use case is for scans of historical photos, it could be worth looking at how Gramps does it: https://www.gramps-project.org/wiki/index.php/Dates |