Fall back on DateTimeDigitized or DateTime when DateTimeOriginal not present
Submitted by Jim Nelson
Assigned to Eric Gregory
Link to original bug (#715820)
Description
---- Reported by jim@yorba.org 2009-12-17 16:10:00 -0800 ----
Original Redmine bug id: 1184
Original URL: http://redmine.yorba.org/issues/1184
Searchable id: yorba-bug-1184
Original author: Jim Nelson
Original description:
Some digital photos may be generated from a scanner rather than a camera. A scanner won't fill in the DateTimeOriginal EXIF tag but DateTimeDigitized. Some cameras fill in both (with the same date/time), some only use DateTimeOriginal.
We may want to fall back on DateTimeDigitized if DateTimeOriginal is not present. It technically is not the time of exposure, so it may be that we only want to use it for Basic Information and sorting, but not when creating events.
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:41:00 -0700 ----
History
Comment 1
Updated by Adam Dingle over 3 years ago
- Subject changed from DateTimeDigitized and DateTime to fall back on DateTimeDigitized when DateTimeOriginal not present
Comment 2
Updated by Jim Nelson about 3 years ago
An upstream report that may be related to this: [https://bugs.launchpad.net/ub untu/source/shotwell/bug/644125](http://trac.yorba.org/search?q=this%3Ahttps%3 A%2F%2Fbugs.launchpad.net%2Fubuntu%2F%2Bsource%2Fshotwell%2F%2Bbug%2F644125)
There's actually a third EXIF date/time field we might consider: plain DateTime. This is usually present along with DateTimeOriginal and DateTimeDigitized. It's possible that the latter two are not present but this one is; we should use it rather than consider the photo undated.
Comment 3
Updated by Jim Nelson about 3 years ago
- Subject changed from fall back on DateTimeDigitized when DateTimeOriginal not present to Fall back on DateTimeDigitized or DateTime when DateTimeOriginal not present
Comment 4
Updated by Jim Nelson about 3 years ago
- Priority set to High
Comment 5
Updated by Jim Nelson about 3 years ago
In the summary I suggested we not use DateTimeDigitized when generating events. I now think we should (or use DateTime) in the absence of DateTimeOriginal. The EXIF spec has been interpreted so widely, we now have a user reporting that his Nikon scanner is only adding DateTime. Using any of these three for events is far better than treating the photo as undated, or worse, using its file modification time.
Comment 6
Updated by Jim Nelson about 3 years ago
Additionally, we should provide an upgrade scheme when we do this. We should note all photos in PhotoTable that have an exposure time set to zero (which indicates that there was no DateTimeOriginal in its metadata and the time was not later set by the user) and attempt to re-fetch the date/time, this time using the fallback scheme described. If found, this value should be set in the database.
This work could be done by the startup scan. Of course, it should only be done once, and only for existing databases.
We should discuss if this upgrade scheme will also create events for these photos.
Comment 7
Updated by Adam Dingle about 3 years ago
-
Priority deleted (
<strike>
_High_</strike>
)
Comment 8
Updated by Adam Dingle about 3 years ago
- Priority set to High
It turns out that photos from the Palm Pre are affected by this bug, since they contain only a DateTime tag and not!DateTimeOriginal. See#2862. Upping to high; would be great if we could fix this for 0.8.
Comment 9
Updated by Adam Dingle almost 3 years ago
- Status changed from Open to Review
- Assignee changed from Anonymous to Eric Gregory
Comment 10
Updated by Adam Dingle almost 3 years ago
We've decided to implement this for 0.8, but we won't implement the extra upgrade scheme proposed by Jim in comment 7 above at this time since it's late in the release cycle and we have lots else to do.
Comment 11
Updated by Adam Dingle almost 3 years ago
-
Priority deleted (
<strike>
_High_</strike>
)
Comment 12
Updated by Eric Gregory almost 3 years ago
Note that the issue mentioned in comment:7 has been placed in ticket #2910 (closed). This bug now only covers scanning new photos for DateTimeDigitized and DateTime.
Comment 13
Updated by Eric Gregory almost 3 years ago
- Status changed from Review to 5
- Resolution set to fixed
- % Done changed from 0 to 100
We now look in the following additional exiv2 paths for timestamps:
Exif.Photo.DateTimeDigitized
Xmp.exif.DateTimeDigitized
Exif.Image.DateTime
Fixed in r2410
Comment 14
Updated by Charles Lindsay 7 months ago
- Status changed from 5 to Fixed
--- Bug imported by chaz@yorba.org 2013-11-25 21:43 UTC ---
This bug was previously known as bug 1184 at http://redmine.yorba.org/show_bug.cgi?id=1184
Unknown Component Using default product and component set in Parameters Unknown version " in product shotwell. Setting version to "!unspecified". Unknown milestone "unknown in product shotwell. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
Resolution: RESOLVED FIXED