Bug 460718 - Set date for analog photos with unknown or partial unknown date (and unknown time).
Summary: Set date for analog photos with unknown or partial unknown date (and unknown ...
Status: REPORTED
Alias: None
Product: digikam
Classification: Applications
Component: Plugin-Generic-TimeAdjust (show other bugs)
Version: 7.8.0
Platform: macOS (DMG) macOS
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-10-19 16:53 UTC by Henrik Hemrin
Modified: 2024-09-17 20:33 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Henrik Hemrin 2022-10-19 16:53:36 UTC
SUMMARY

Set date for analog photos with unknown or partial unknown date (and unknown time). 

In my collection, I have many analog photos I have digitized. 
Generally, I have no idea of correct time for when the photo was taken. 
In many cases I do not know the year.
In some cases I know the year.
In some cases I know the year and month.
In some cases I know the year, month and date. 

I have used Photoshop Element Organizer (PSE14). In PSE14 I could change the date to eg totally unknown - date is shown as ”?”. I could also change to only year etc. Photos placed accordingly in the time line. 

As far as I can find out I can only set a complete date (and time also included) in digiKam. 

My wish is a possibility to manage incomplete date information in digiKam, including photos shows up correctly in eg Date and Time line views and works in Search.

This wish is open to how it is best implemented but if it can be within standards it is an advantage. Info below under Additional information from standards is only for information.  


SOFTWARE/OS VERSIONS
Windows: 
macOS: 12.6
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION

I have done a bit of testing to find out how PSE14 handle, but so far I cannot conclude if PSE export this to file (it affect metadata but I have not concluded if details are transferred) or handled only in its database. If requested, I can do some more research how it is handled in PSE14.

I have done some reading of EXIF, IPTC and XMP standards and found some information that may be useful. Below are extracted text from some interesting paragraphs. I am not expert to understand them, but to me it indicates as something like I want maybe can be done within the standards. 

===

IPTC Photo Metadata Standard 2021.1

6.10 Date Created (page 22)
Designates the date and optionally the time the content of the image was created rather than the date of the creation of the digital representation.
Note 2: Software showing the metadata user interface should adopt a widget for this property that supports editing truncated dates, like year and month only, or year only. Software embedding truncated dates as IIM DataSet 2:55 should use the value "00" for undefined days or months (like "19180000" for an image taken "in the year 1918")

XMP Specs: photoshop:DateCreated [Date <External>]

Generic Implementation Notes (page 110)
13.2. Date value type
Applies to an XMP property if its value type is date: The XMP specification defines a quite flexible format for this value type, all these sets of year, month, day and time values are supported:
!"YYYY
!"YYYY-MM
!"YYYY-MM-DD !"YYYY-MM-DDThh:mmTZD !"YYYY-MM-DDThh:mm:ssTZD !"YYYY-MM-DDThh:mm:ss.sTZD
IPTC encourages makers of software to adopt a user interface widget for the Date value type properties which allows a user to enter all these variants of date and time.
Note the format of dates and times shown above is based on the ISO 8601 standard for date and time formats [ISO-8601]
===

Adobe XMP Specification Part 3 Jan 2020
Table 37 — IPTC data sets of use as XMP metadata (Continued) (page 70)
2:55
2:55 0x0237 Date Created 8 ASCII digits as CCYYMMDD, 00 for unknown parts
===

DC-101-2020_E Exif 2.32 metadata for XMP
A.2.2.2 Date (page 24)
Date is a date-time-value, which is represented using a subset of Date and Time Formats formatting: 
YYYY
YYYY-MM
YYYY-MM-DD
etc.
===
Digikam users mail:
https://mail.kde.org/pipermail/digikam-users/2022-October/034134.html
====
Comment 1 caulier.gilles 2022-10-19 17:02:17 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
Comment 2 Maik Qualmann 2022-10-19 17:09:33 UTC
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
Comment 3 Henrik Hemrin 2022-10-19 18:25:29 UTC
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.
Comment 4 Maik Qualmann 2022-10-19 19:00:21 UTC
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
Comment 5 Henrik Hemrin 2022-10-19 20:04:55 UTC
(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.
Comment 6 Maik Qualmann 2022-10-20 06:05:59 UTC
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
Comment 7 Henrik Hemrin 2022-10-20 18:31:41 UTC
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.
Comment 8 caulier.gilles 2024-09-17 20:26:14 UTC
Maik, 

This is a duplicate of bug #301357 ?

Gilles
Comment 9 Maik Qualmann 2024-09-17 20:33:39 UTC
Yes, and basically bug 140202 too.

Maik