Summary: | Set date for analog photos with unknown or partial unknown date (and unknown time). | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | Henrik Hemrin <hehemrin> |
Component: | Plugin-Generic-TimeAdjust | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | REPORTED --- | ||
Severity: | wishlist | CC: | caulier.gilles, metzpinguin |
Priority: | NOR | ||
Version: | 7.8.0 | ||
Target Milestone: | --- | ||
Platform: | macOS (DMG) | ||
OS: | macOS | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Henrik Hemrin
2022-10-19 16:53:36 UTC
Try the Generic Time Adjust plugin from 7.9.0 pre-release DMG installer available here : https://files.kde.org/digikam/ screenshot : https://i.imgur.com/QRlAKLH.png Best Gilles Caulier We have bug 140202, for me it's a duplicate. digiKam saves the date in the database, they need a complete date. So the database would have to be expanded for a fuzzy date - presumably to a text date. It would first have to be tested whether Exiv2 and ExifTool already support the shortened XMP standard. Internally in digiKam it would probably require significant changes. Maik 1. I tested quickly Generic Time Adjust plugin from 7.9.0 pre-release but Appimage on Linux Mint 21 instead of DMG. It does not allow incomplete date, seems to be in this respect same as 7.8.0. 2. Yes, bug/wish 140202 is almost same. Differences: I add requirement for totally unknown date (and time). I exclude the album wish. In addition, maybe my bug/wish add some info. But basically, my bug/wish can be seen as duplicate. I am sorry I did not find 140202 before I filed my report. Another technical problem is that we use QDateTime internally for all date operations (and there really are a lot of them). QDateTime always needs a valid date. Just one question, they write, they don't even know the year of some images, where should such a image be placed in a timeline? Maik (In reply to Maik Qualmann from comment #4) > Another technical problem is that we use QDateTime internally for all date > operations (and there really are a lot of them). QDateTime always needs a > valid date. Just one question, they write, they don't even know the year of > some images, where should such a image be placed in a timeline? > > Maik If I compare PSE14, they place unknown date as oldest in time line. For user it is represented as a "?". But when I look at time line, it shows I have photos starting from Jan 1400, so I guess they use 1 Jan 1400 as date for unknown... My current Wow for unknown is I set to 1 Jan 1800 (when I later may know better, I update). And for other I set a fictive as close as I know. In addition for all those, I add a tag with the details I know, eg "unknown date", "1956", "Feb 1976". So I manage without this wish, but the wish would be an improvement. But that of course said without considering how difficult it is to implement or any drawback. PSE will also set a date internally, the oldest in the collection if it is completely unknown and otherwise always the 1st day or month, etc. A mask will certainly be saved for this, which part of the date is known. In this way it can also be integrated into digiKam. The effort is still considerable to implement it. Maik As I understand where we are now: The bug (wish) use case is understood. The use case is reasonable. The use case is relevant for many more users but likely far from being useful for most users on a very frequent basis. Work arounds are possible to manage the use case in an acceptable but less attractive way. Another bug, 140202, is close enough to consider this bug as a duplicate. Potential solutions have briefly been brought to the table incl issues to investigate. Implementation of any solution is at this stage considered as complex needing considerable effort. For me as Reported by, the other bug report 140202 is good enough to change my (this 460718) bug report as duplicate. To be decided by digiKam Developers if this one should be changed to duplicate or not. Maik, This is a duplicate of bug #301357 ? Gilles Yes, and basically bug 140202 too. Maik |