How does PhotoStructure capture captured-at?

How does PhotoStructure capture captured-at?

One of the most important pieces of metadata about a photo or video is when it was captured.

PhotoStructure has advanced heuristics to determine this “Captured-At” time.

📅 What’s a “valid date,” according to PhotoStructure?

Any date between 1826 (the first year a photograph was captured) and 2 days from now is considered a “valid date.”

If you have paintings or other imagery from before 1826, change the minValidYear library setting.

1️⃣ Step 1: Look at EXIF metadata

PhotoStructure first looks at IPTC, EXIF, and other metadata tags, stored both in the original file, and in sidecars, with these tag names:

  1. SubSecDateTimeOriginal (fractional seconds for DateTimeOriginal)
  2. DateTimeOriginal (date/time when original image was taken)
  3. SubSecCreateDate
  4. OriginalCreateDateTime
  5. CreateDate (called DateTimeDigitized by the EXIF spec)
  6. SubSecTimeDigitized (fractional seconds for CreateDate)
  7. DateTimeCreated
  8. CreateDate
  9. SubSecMediaCreateDate
  10. MediaCreateDate
  11. DateTimeDigitized
  12. DateTime
  13. SubSecTime (fractional seconds for ModifyDate)
  14. ModifyDate

The oldest “valid date” wins.

2️⃣ Step 2: Look for an ISO-compliant filename and path

If we reach this step, no EXIF, IPTC, or other metadata tags encoded the captured-at time, so we resort to fuzzier heuristics.

Several cameras and smartphones encode the date and time as the filename of the photo or video. If this is ISO compliant, fully-specified, and “valid date,” PhotoStructure will use this as the captured-at time.

3️⃣ Step 3: Look for a date-like filename and path

If the filename encodes something that can be decoded as a datestamp, and that datestamp matches either the file’s “birthdate,” PhotoStructure will return that datestamp.

4️⃣ Step 4: Infer a date interval from siblings

We look at “sibling” files in the same directory, with similar names and similar filestamps, that have captured-at times that were extracted via Step 1 or Step 2.

If we can find both an upper and lower bounding sibling, we set the capture-at time to be a date interval between these two files.

PhotoStructure has this heuristic for two reasons:

  1. Video formats regularly omit EXIF or IPTC timestamps, and we don’t want to revert to filesystem times.

  2. If you’ve used applications that strip metadata (say, jpegtran without the -copy option), you may have inadvertently removed metadata. This “sibling inference” at least puts the image into the correct ballpark.

5️⃣ Step 5: Fuzzy date parsing

At this point we are scraping the bottom of the heuristics barrel.

If any containing directory of the file has a name that is, ideally, a valid YYYY-MM-DD, we’ll return that as the captured-at day.

You can disable this step with the usePathsToInferDates library setting, and fuzzyDateParsing and fuzzyYearParsing configure strictness of this step.

6️⃣ Step 6: Use filesystem times

PhotoStructure really tries to avoid using filesystem times, as it’s frequently incorrect.

Many backup and file synchronization applications don’t retain the source file’s filesystem times. The filesystem time frequently reflects when the file was first copied to that volume, rather than when the file was originally captured.

If you don’t want to import photos or videos that require this step, set the useStatToInferDates library setting to false.

📸 What should I do with scanned photos?

If your scanning software adds metadata with the incorrect datestamp (so PhotoStructure is using “Step 1”), you can clear the times with ExifTool, and then put these scanned images into a directories with the roughly-correct date (formatted as YYYY-MM-DD, or “August 1983” or “1983 AUG”). PhotoStructure will then resort to using Step 5 for the captured-at time.

The forum has some additional tips for handling scanned images.