Copying GPS data from one video file to another

[camner]

Lightroom Version Number

10.1.1

Operating System

1. macOS 10.15 Catalina

I'm trying to figure out from where LrC pulls GPS data. I often use iMovie to edit videos, and iMovie strips off lots of metadata, including location info, and also sets the date & time info to the time that the video is exported from iMovie (this actually makes sense, because often one is creating a new video from multiple clips and the date/time created is logically the export moment).

What I have been doing to solve the date/time problem is to run the following ExifTool command on edited video files:
exiftool -P -progress -overwrite_original_in_place -extractEmbedded -tagsFromFile source filename -all:all destination filename

This copies all writeable tags from the source file to the destination file.

But, although I can see with ExifTool that the destination file has GPS data in the same 2 locations as the source file (the Keys group and the Composite group), LrC doesn't pick up GPS data from the destination file when imported.

So, I'm wondering if there's someplace else that LrC is pulling the GPS data from.

 

[johnrellis]

The QuickTime format (used by .mov, .mp4, and other extensions) stores coordinates in QuickTime:GPSCoordinates. I just tried your ExifTool command line, and it successfully copied coordinates from .mp4 to another, and LR successfully read them. But if a camera or app stores coordinates in other metadata locations (e.g. in the XMP section), I haven't tested how LR gives priority to the two different locations.

The easiest way to make progress on what you're seeing is to upload sample source and destination files to Dropbox or similar and post the sharing links here.

 

[camner]

OK, I've had a chance to get back to this. Here's the link to a Dropbox folder containing the following:

1. Original video file (SOOC, an iPhone)
2. Output from ExifTool tag extraction on original video file
3. Video file created by iMovie
4. Output from ExifTool tag extraction on video file created by iMovie
5. Output from ExifTool tagsfromfile command
6. Video file after tagsfromfile command
7. Output from ExifTool tag extraction on video file after tagsfromfile command
8. Screenshots from LrC after original video file and Video file after tagsfromfile command are imported (showing no GPS data for final video file)

What you should see is that all the GPS data (and a whole lot more!) were stripped by iMovie. After running tagsfromfile, the subsequent video has the same GPS (and other) tags that the original iPhone video file had. BUT, upon import into LrC, there's no GPS data showing, even though the GPS info is in exactly the same tags in both the original file and the file processed through iMovie and then the tagsfromfile ExifTool command.

What stumps me is that as far as I can see, the GPS tags that are in the original video file are exactly the same as the GPS tags in the final video file (after running tagsfromfile). So, if LrC can read the location data from the original file, it should be able to do so from the final video file.

---------------------
As an aside, you may notice that LrC does NOT pick up the correct creation date from the video file processed through iMovie and then the tagsfromfile ExifTool command. iMovie changes the creation date to the date of the iMovie export (which makes sense, since iMovie is often used to combine clips from different dates, and the result is a new video). The tagsfromfile command doesn't seem to reset the track creation and modification (and other) date tags.

What I find DOES work on dates is to use GraphicConverter for handling the dates. Since GraphicConverter uses ExifTool to do its magic, ExifTool must be able to write out video track date tags and other video date tags, but I haven't dug deeply enough into this to understand why the tagsfromfile command isn't taking care of this.

Thanks for your willingness to take a look at this.

 

[johnrellis]

I'll dig into this on Monday -- thanks.

 

[johnrellis]

As an aside, you may notice that LrC does NOT pick up the correct creation date from the video file processed through iMovie and then the tagsfromfile ExifTool command. iMovie changes the creation date to the date of the iMovie export (which makes sense, since iMovie is often used to combine clips from different dates, and the result is a new video). The tagsfromfile command doesn't seem to reset the track creation and modification (and other) date tags.

Finally got to start looking at this. Haven't figured out the GPS issue yet, but I think I understand what's happening with Create Date, and it's ugly:

For unknown lame reasons, Apple defined the Quicktime "Create Date" [sic] field to contain the capture date in UTC, with no ability to specify a time zone. But most cameras don't know their time zone, so they record their clock in the Create Date field, and the clock is usually in local time. Knowing that, LR ignores the spec and interprets Create Date to be in local time.

Except that smart phones, including iPhones, do know their time zone, and they strictly obey the Quicktime spec and write Create Date in UTC. So for these videos, LR used to interpret that UTC date as local time, and the capture date in the Metadata panel would appear shifted by the time zone offset.

iOS started inserting a "proprietary" Apple-only "Creation Date" [sic] field that included the time zone. But Adobe wouldn't change LR to read it until Adobe got legal permission from Apple to read it. Apparently, Adobe has a legal policy that any field written by a camera that isn't an industry-standard field is "proprietary" and can't be read without the manufacturer's permission!

Finally, Adobe got such permission and LR 6.9 started reading Creation Date (with time zone) instead of Create Date.

Your Exiftool command copied both Create Date and Creation Date from the original .mov to the Imovie .mp4. So why is LR reading Create Date instead of Creation Date? I think it's because the .mov is in Quicktime format, while the .mp4 is in MP4 format. The two formats are nearly identical, with the former specified by Adobe and the latter specified by an ISO standard (that copied the Quicktime spec). It appears that LR will only read the Creation Date field for Quicktime files created by iOS, not for MP4 files!

I'm sure there is some Exiftool magic that will copy Creation Date from the Quicktime file and write it into the MP4's Create Date, adjusted by the time zone of the Creation Date. But it might be gross magic (i.e. involving a Perl expression supplied on the command line).

You asked...

 

[camner]

Finally got to start looking at this. Haven't figured out the GPS issue yet, but I think I understand what's happening with Create Date, and it's ugly:

For unknown lame reasons, Apple defined the Quicktime "Create Date" [sic] field to contain the capture date in UTC, with no ability to specify a time zone. But most cameras don't know their time zone, so they record their clock in the Create Date field, and the clock is usually in local time. Knowing that, LR ignores the spec and interprets Create Date to be in local time.

Except that smart phones, including iPhones, do know their time zone, and they strictly obey the Quicktime spec and write Create Date in UTC. So for these videos, LR used to interpret that UTC date as local time, and the capture date in the Metadata panel would appear shifted by the time zone offset.

iOS started inserting a "proprietary" Apple-only "Creation Date" [sic] field that included the time zone. But Adobe wouldn't change LR to read it until Adobe got legal permission from Apple to read it. Apparently, Adobe has a legal policy that any field written by a camera that isn't an industry-standard field is "proprietary" and can't be read without the manufacturer's permission!

Finally, Adobe got such permission and LR 6.9 started reading Creation Date (with time zone) instead of Create Date.

Your Exiftool command copied both Create Date and Creation Date from the original .mov to the Imovie .mp4. So why is LR reading Create Date instead of Creation Date? I think it's because the .mov is in Quicktime format, while the .mp4 is in MP4 format. The two formats are nearly identical, with the former specified by Adobe and the latter specified by an ISO standard (that copied the Quicktime spec). It appears that LR will only read the Creation Date field for Quicktime files created by iOS, not for MP4 files!

I'm sure there is some Exiftool magic that will copy Creation Date from the Quicktime file and write it into the MP4's Create Date, adjusted by the time zone of the Creation Date. But it might be gross magic (i.e. involving a Perl expression supplied on the command line).

You asked...

@johnrellis:

Thanks VERY much for the excellent explanation of what is going on here with how LrC is picking up (or not...) the capture date information from cameras (including the iPhone). I read the Adobe thread at LR 6.9 started reading Creation Date; what a mess it was!

Over the years I have puzzled out at least some of this behavior, but I certainly did not understand what was happening under the hood, so I appreciated learning some of that from your post.

 

[camner]

Just to complicate things further, I have discovered that iPhone videos that are shared with one via Shared Albums do NOT import into LrC with the correct Capture Date/time! As far as I can tell, the Capture Date/Time that LrC reports is the date & time that the person who shared the video via Shared Albums moved the video into the Shared Album from his/her iPhone Camera Roll. And then, to add insult to injury, LrC interprets that time in UTC! So, yesterday when I did an experiment with my daughter in Minneapolis ( UTC -6 vs UTC -8 for me), she dragged a video from her Camera Roll to a Shared Album (shared with me) at 1:24 PM CST. I immediately imported it into LrC as soon as I got it, and the Capture Date/Time was 9:24 PM (that is, ~8 hours later than the time of day when I imported the video into LrC!)

Digging into the video file in ExifTool....

• A video in a Shared Album is a .mp4 file, not a .mov file as was the original iPhone video as taken
• The QuickTime:CreationDate tag is NOT set
• The QuickTime: DateTimeOriginal tag IS set (with the correct -06:00 time zone offset) [this tag is not set by the iPhone when the video is taken, only when it is shared via Shared Albums]

So, LrC is NOT using the QuickTime: DateTimeOriginal tag to determine the Capture Date/Time. What I think may be happening is that LrC is using the QuickTime:CreateDate tag (interpreted in UTC) to incorrectly determine the Capture Date/Time.

I then looked a video file shot by my Canon G5X Mark ii camera. LrC DOES correctly pick up the correct Capture Date/Time. But, digging into the file with ExifTool...

• The video file from the Canon is an .mp4
• The QuickTime:CreationDate tag is NOT set
• The QuickTime: DateTimeOriginal tag is NOT set
• There is an EXIF: DateTimeOriginal tag set, but there is no timezone offset in that tag (grr....)!
• The EXIF:OffsetTimeOriginal and OffsetTime tags are set, with the correct -08:00 offset
• There are also some date/time tags set in the Composite Group (SubSecCreateDate, SubSecDateTimeOriginal, & SubSecModifyDate), all of which are full date/time tags that include the timezone offset

So, how does LrC pick up the correct Capture Date/Time? I'm not sure. Perhaps it uses the combination of EXIF: DateTimeOriginal with either EXIF:OffsetTimeOriginal or EXIF:OffsetTime to compute the correct Capture Date/Time.

I'm beginning to have some sympathy for Adobe with respect to setting the Capture Date/Time for videos. It seems that every situation (camera, shared album, etc.) can and does choose to set the video timestamp in its own idiosyncratic manner, making it much more difficult for Adobe to consistently determine accurately the Capture Date/Time.

 

[johnrellis]

Re GPS coordinates, I just filed a bug report -- LR imports QuickTime:GPSCoordinates from QuickTime (.mov) videos but not from MP4 (.mp4) videos:
https://feedback.photoshop.com/conv...ates-from-mp4-videos/60384c24129ce112e92ba36c
Please add your constructive opinion to the bug report, and be sure to click Like and Follow at the bottom of the first post. That will make it a little more likely that Adobe will prioritize a fix, and you'll be notified when the bug's status changes.