PhotoStructure ignored the date metadata of some photos, marked them as taken in 2002

While I was browsing my library by date, I found a group of 62 assets, all tagged by the exact same date: Dec 8, 2002, 12:00 PM
These files have the correct date information inside the metadata and on the name, yet PhotoStructure still tagged them incorrectly.

Looking through the files, there doesn’t seem to be a pattern to them.
The dates vary between 2014, 2015 and 2016.
All were taken with my old Motorola XT1022 and uploaded to Google Photos using Picasa, but I have loads of other photos that fulfill these conditions that were tagged properly.

I am using PhotoStructure for Desktops 0.9.1 on Arch Linux.
Any logs I could provide to help debug this issue? I’ll be mailing a sample of the affected pictures to support@photostructure.com shortly.

Edit: The photos have been emailed.

Thanks for reporting this!

You can run the info tool to see what’s going on: https://photostructure.com/server/tools/#file-information

(add --verbose or even --debug for extra details), and look for the CapturedAt log messages.

You can also run exiftool -j -struct $path/to/file

I’m happy to take a look at a sample image you email to me, too.

PhotoStructure takes the earliest valid time it finds in the metadata. In these files’ case, CreateDate is set to 2002:12:08 12:00:00:

$ exiftool -CreateDate /home/mrm/Desktop/live/*.jpg
======== /home/mrm/Desktop/live/IMG_20141217_233300220-edited.jpg
Create Date                     : 2002:12:08 12:00:00
======== /home/mrm/Desktop/live/IMG_20141221_104133723-edited.jpg
Create Date                     : 2002:12:08 12:00:00
======== /home/mrm/Desktop/live/IMG_20150106_160343264-edited.jpg
Create Date                     : 2002:12:08 12:00:00
======== /home/mrm/Desktop/live/IMG_20150107_133241272-edited.jpg
Create Date                     : 2002:12:08 12:00:00
======== /home/mrm/Desktop/live/IMG_20150113_225416155-edited.jpg
Create Date                     : 2002:12:08 12:00:00
======== /home/mrm/Desktop/live/IMG_20150126_191717032-edited.jpg
Create Date                     : 2002:12:08 12:00:00
======== /home/mrm/Desktop/live/IMG_20150207_155319222-edited.jpg
Create Date                     : 2002:12:08 12:00:00
======== /home/mrm/Desktop/live/IMG_20160614_113451615.jpg
Create Date                     : 2002:12:08 12:00:00
======== /home/mrm/Desktop/live/IMG_20160614_114354045.jpg
Create Date                     : 2002:12:08 12:00:00
======== /home/mrm/Desktop/live/IMG_20160614_115211068.jpg
Create Date                     : 2002:12:08 12:00:00

You can remove the CreateDate tag from these files with exiftool: just run

exiftool -CreateDate= $path/to/file.jpg.

The next time PhotoStructure synchronizes those files, it should show the other date. Here’s what info says after I had ExifTool remove CreateDate:

[
  {
    _PhotoStructureVersion: '1.0.0-alpha.0',
    capturedAt: {
      date: ExifDateTime {
        year: 2014,
        month: 12,
        day: 17,
        hour: 23,
        minute: 32,
        second: 59,
        millisecond: 0,
        tzoffsetMinutes: undefined,
        rawValue: '2014:12:17 23:32:59',
        zoneName: undefined
      },
      localCentiseconds: 2014121723325900,
      offset: undefined,
      src: 'tags:DateTimeOriginal'
    },

If this is a common issue in your library, would it be helpful to have the CapturedAtTags be a setting (so you could, say, remove CreateDate if you knew it was always going to be wrong)?

(How did it get set in the first place, I wonder?)

The current list is:

const CapturedAtTags = [
  // By the specification, DateTimeOriginal should be the time of the
  // shutter actuation, and CreateDate should be the time that the file
  // was written to the memory card (but not all mfrs follow the spec)
  // http://u88.n24.queensu.ca/exiftool/forum/index.php?topic=2568.0

  // <https://exiftool.org/TagNames/EXIF.html>

  // First "*original*"
  "SubSecDateTimeOriginal", // (fractional seconds for DateTimeOriginal)
  "SubSecCreateDate",
  "SubSecTimeDigitized", // (fractional seconds for CreateDate)
  "SubSecMediaCreateDate",

  "DateTimeOriginal", // (date/time when original image was taken)

  // Then "*create*"
  "OriginalCreateDateTime",

  "CreateDate", // (called DateTimeDigitized by the EXIF spec)
  "DateTimeCreated",
  "DateCreated", // XMP tag
  "DateTimeDigitized",
  "MediaCreateDate",

  "DateTime",

  // Then *modify*
  "SubSecTime", // (fractional seconds for ModifyDate)
  "ModifyDate", // (called DateTime by the EXIF spec)

  // Lightroom:
  // "HistoryWhen", // This is when history records happen, NOT when the file was captured!

  // Google Takeout (not really reliable, though)
  "photoTakenTime"

  // This is the Google Photos upload time. That's not something we want, so
  // it's commented out. DON'T ADD IT BACK, FUTURE ME!
  // "creationTime"
]

More details here:

Thanks for the fast replies, they’re highly appreciated!

:eyes: :eyes: :eyes:

That would be very helpful, yes.
When PhotoStructure gains the ability to edit tags, it would be great if we could remove tags using the UI, bonus points if we could do it in bulk!

Quick question: Is the ‘Create Date’ tag a frequently utilized in people’s libraries?
Maybe it should be weighted less than the ‘Image Date/Time’ tag by default?

I wonder too. I have no idea of what could have caused this, other than a obscure bug inside Picasa (RIP!) or my old phone’s firmware.

Given that @Lars_Noschinski saw this issue too, and in both cases, there were other tags that had good contents, I think it’s safe to just remove CreateDate from the list of tags that PhotoStructure looks at by default. (see below)

For extra credit, the list of tags will be configurable via the new capturedAtTags library setting:

# +------------------+
# |  capturedAtTags  |
# +------------------+
#
# The following tags are examined to parse a file's captured-at time. The
# earliest valid tag is returned. See
# <https://photostructure.com/faq/captured-at/> for details.
#
# PS_CAPTURED_AT_TAGS="[\"SubSecDateTimeOriginal\",\"SubSecCreateDate\",\"SubSecTimeDigitized\",\"SubSecMediaCreateDate\",\"DateTimeOriginal\",\"OriginalCreateDateTime\",\"DateTimeCreated\",\"DateCreated\",\"DateTimeDigitized\",\"MediaCreateDate\",\"DateTime\",\"SubSecTime\",\"ModifyDate\",\"photoTakenTime\"]"

This change will be in -alpha.3, which is a couple days out (I need to finish search).

1 Like

Would it be better to just include CreateDate at the end of the list? It would appear earlier it was midway in the list, but if it was “last” then it’s kind of an “if all else fails”.

Flip side, I can add it back if I want it, no biggie, just thought I would toss it out there.

2 Likes

I agree, it turns out that I had some examples that only had CreateDate, so removing that tag completely is a bit too blunt of a fix.

I added a special filter that discards CreateDate only if it’s this specific raw value.

1 Like

@LiveLM here’s the parsing results for your files without this fix:

$ node dist/library/info --captured-at /home/mrm/Desktop/live2/* | grep Centiseconds
      localCentiseconds: 2002120812000000,
      localCentiseconds: 2002120812000000,
      localCentiseconds: 2002120812000000,
      localCentiseconds: 2002120812000000,
      localCentiseconds: 2002120812000000,
      localCentiseconds: 2002120812000000,
      localCentiseconds: 2002120812000000,
      localCentiseconds: 2002120812000000,
      localCentiseconds: 2002120812000000,
      localCentiseconds: 2002120812000000,

And with the fix:

$ node dist/library/info --captured-at /home/mrm/Desktop/live2/* | grep Centiseconds
      localCentiseconds: 2014121723325900,
      localCentiseconds: 2014122110413300,
      localCentiseconds: 2015010616034300,
      localCentiseconds: 2015010713324100,
      localCentiseconds: 2015011322541600,
      localCentiseconds: 2015012619171700,
      localCentiseconds: 2015020715531900,
      localCentiseconds: 2016061411345200,
      localCentiseconds: 2016061411435400,
      localCentiseconds: 2016061411521100,
1 Like

Dates look correct and they match the file names. Looks good to me!
When this fix makes it’s way into a release, I’ll try making a new library containing the affected files to make sure they get tagged correctly.

1 Like