Metadata: Use creation time from Google Photos JSON sidecar file

[graciousgrey]

As a Google Photos user who has updated the capture time/date, I would like PhotoPrism to import the corrected date from the GPhotos JSON sidecar files instead of the (possibly incorrect) original exif date.

Implementation requires further investigation:

• GPhoto's JSON files contain only a UNIX timestamp field with no local time or time zone, possibly UTC unless Google doesn't know the location?
• Exif headers in images use local time for timestamps by default, while QuickTime/MPEG4 uses UTC by default
• Getting UTC time from GPhotos and local time from Exif can result in conflicting data that doesn't make much sense
• Using only the date from GPhotos can result in (helpful) information about the time zone or local time being lost
• To proceed, more GPhotos timestamp information is needed and practical tests should be performed/documented with different file sets

Acceptance Criteria:

• Provide a set of main media and sidecar test files covering cases with UTC time, local time, GPS info, and no/incomplete location data
• Find/write docs that specify which time zone(s) Google uses under what conditions (with/without GPS location, in JPEG, AVC, etc)
• The photoTakenTime from Google Photos JSON files MUST be prioritized over data found directly in Exif file headers
• Unit tests must be updated/added

[abheekda1]

Since it seems nobody has yet taken a look at this I'd be happy to give it a shot, how would I go about implementing this? I took a look at the metadata scripts and they seem pretty straightforward, just not sure how to make it so it prioritizes one over the other.

[lastzero]

Do we have an example file for testing? Our parser currently reads the time from photoTakenTime, not photoTakenAt.

[lastzero]

@ADawesomeguy You (and others) are welcome to do research and document the results so we can implement this! Changing the code is quite easy, just checked it - but we need to avoid creating a mess with inconsistent data for everyone. Testing in our users' production environments is not an option.

[lastzero]

See also:

• https://sethflowers.com/google/google%20photos/google%20photos%20takeout/exif/exiftool/2021/01/18/fixing-exif-dates-on-google-takeout-photos.html

[abheekda1]

Awesome, thanks for the info! I'll definitely take a look when I have time.

[jacobwhall]

this README has some info about Google Takeout exports that might be helpful

[abheekda1]

It's been a while but I'll give this a shot. If anyone else wants to step in and give it a look at some point that would be cool too.

[abheekda1]

Alright I've delved a bit deeper and was wondering where exactly the code is that I should change? In addition, would this be a frontend modification (changing the displayed date) or a backend modification (changing the metadata) or something else?

[jrstrunk]

I want to add a note of consideration here: please do not store the photo time in UTC as Google Photos provides it.

As a user, the original timezone of the photo is very important information because in most cases I just want to know the time of the photo in the local time it was taken. If I take a trip abroad and take photos, I do NOT want those photos' times to be stored in UTC. When I look at the photos, I want to see "Taken at 7:09pm" (the time in the abroad timezone the photo was taken in), NOT "Taken at 4:09am" (the time the photo was taken in, stored in UTC).

Since Google Photos stores photo times in UTC, we should first get the local offset of the photo time via the OffsetTimeOriginal EXIF tag, convert Google Photo's UTC time to be in the local timezone of the photo, and then store that localized time.

In the absence of a time offset in a photo that has datetime metadata, I think we should disregard Google Photo's UTC time because using it would mean no way of getting back to the local time the photo was taken it, which will result in a "wrong" photo time to the user who just cares about seeing the photo time in the timezone it was taken.

In the absence of any temporal photo data at all (if not in the metadata, maybe in the file name), I suppose the best we can do is just go ahead and use Google Photo's UTC time.

Edit: actually I think now I see that in the scope of this issue, we are not talking about ever writing to the file itself, but instead writing to wherever PhotoPrism stores metadata. I have updated the message body to reflect this realization.

[jrstrunk]

Here is some data that may help with testing:

• A large list of photo file names and their corresponding JSON metadata file names from a December 2022 Google Takeout: Github Gist. Notice: the JSON file name is not always the same as the photo's file name (for example on lines 133555 & 133556 or 126886 & 126887), "-edited" and other "-" postfixed files do not get their own JSON files (lines 129472, 129473, & 129474 or 107, 108, & 109), motion picture files do not get their own JSON files (lines 40006, 40007, & 40008), and motion picture files from 2017 have the .MP4 extension (line 40006) while newer, 2020+, motion picture files have the .MP extension (line 119905). There may be other oddities that I missed. If you are interested in seeing the contents of any of the files listed, let me know and I'll upload them.
• Example format of Google Photo's JSON metadata from Takeout without Geo data: Github Gist
• Example format of Google Photo's JSON metadata from Takeout with Geo data from a Google Pixel 4a: Github Gist
• Example format of Google Photo's JSON metadata from Takeout with the original photo time: Github Gist, and then once the same photo had its time modified via Google Photos: Github Gist (This is also an example of a photo taken long before I uploaded it to Google Photos).