GoPro videos importing with UTC for created date, not the date of the camera - ideas?

[ross101]

Lightroom Version Number

14.4

Operating System

1. macOS 14 Sonoma

I am exporting files from a GoPro 13 by way of downloading directly from microSDXC plugged into an iMac, copying to a destination with finder, then importing to Lightroom Classic.

The dates for videos come across as GoPro videos importing with UTC for capture date/time, not the date/time the camera was actually set to (UTC -4). I have examples when the camera was set to Eastern time, as well as Mountain Time (where I'm importing the photos). The .jpg photos come across with the correct date/time..

Anyone know why this is happening and how to import to lightroom with the correct dates?

The below video should have imported with a time of 9:50AM (was shot in Eastern time, imported in Mountain time zone). Instead, it shows the UTC time.

 

[John R Ellis]

It's a result of Apple's poorly written Quicktime spec from decades ago, lack of industry interest to improve the MP4 standard based on Quicktime, and Adobe deprioritizing video support in Lightroom:
https://community.adobe.com/t5/ligh...ing-the-quicktime-mp4-standard/idi-p/14007948

The workaround is straightforward: Select all the videos, do Metadata > Edit Capture Time, and select Shift By Set Number Of Hours.

 

[ross101]

John, many thanks for your note! I also saw your excellent thread on dates/times and read through your referenced post.

If I'm understanding correctly, older digital cameras wrote local time, whereas newer connected/gps cameras may be writing UTC as they more tightly adhere to the poorly written spec. I guess the reason I haven't seen this previously is that most of my cameras (aside from iPhone) are now a bit dated.

It does seem the root of the issue is Lightroom, given what you've shown, and also that other software (FCP, for example) leverage a correct date (though I don't see created date shown). Regardless of standards, I don't know possibly how it cannot be considered a 'bug', based on user function. Pictures and videos imported from a single camera and sorted by capture time do not show in sequential order.

In my case, the timestamp is an issue that has to be addressed before importing to lightroom, as for the last 20 years, I've imported all images from a given date (multiple cameras) at the same time, and rename the file with a dated sequence number (e.g. I_20220403_047.dng) that mirrors capture time. The original intent was to always be able to sort by image name, and see the images in-order (whether in LR , OS, or any software). With more people in my family who are shooting pics, I now think about moving away from this sequence number standard, but it has been both handy and a PITA.

I did some brief tests on editing capture time. In LR, it appears to only update the database, as it seems I can't write the metadata back to video files. If you know a way to update the metadata of the file, I'm all ears.

I also made the change in Bridge (which also reflects the UTC created time). In that instance, it did seem to update the actual file, such that when subsequently imported to LR, the creation date is accurate. I get nervous about such changes, though, because I don't know that may mess up other software (or re-import to LR after/if they address the issue). I think I have to do some additional validation using some sort of exif data viewing tool. If you have any recommendations on such a tool for MacOS, I'd love to hear about it.

I will submit a bug report to adobe to further articulate the user pain. Users paying for a subscription really shouldn't have to jump through the hoops, when other software does handle it correctly. Too bad Adobe is aware but chosen to not make this a priority!

FWIW, I enjoyed your work since I was a kid!

 

[John R Ellis]

Regardless of standards, I don't know possibly how it cannot be considered a 'bug', based on user function.

Adobe's definition of "bug" is very narrow -- it isn't a "bug" if LR is operating "as designed". LR wasn't designed to handle camera-specific interpretations of the Quicktime capture date, so when it does different things with video from different cameras, that's not a "bug". That's why the post I linked to is in the Ideas section of the Adobe forum rather than Bugs.

it appears to only update the database, as it seems I can't write the metadata back to video files. If you know a way to update the metadata of the file, I'm all ears.

Right. When video support appeared in LR 3 and enhanced a little in LR 4, Adobe never finished the implementation, including the ability to write back metadata to the video files.

If you're a glutton for mind-numbing detail, you could use the Run Any Command plugin to run the free Exiftool utility, passing it the name of the file and the capture date stored in the LR catalog. If you're not familiar with either Friedl's plugins or Exiftool, expect to take at least a couple hours figuring everything out.

You could also write a script that uses Exiftool to shift the capture time of videos before you import. There are examples on the Exiftool man page of the necessary magic.

Exiftool is by far the most authoritative and robust tool for reading and writing metadata to photos and videos.

 

[ross101]

First off, I'm thankful for your guidance, John.

Adobe's definition of "bug" is very narrow -- it isn't a "bug" if LR is operating "as designed". LR wasn't designed to handle camera-specific interpretations of the Quicktime capture date, so when it does different things with video from different cameras, that's not a "bug". That's why the post I linked to is in the Ideas section of the Adobe forum rather than Bugs.

I'm sure we could go through quite a few beers with friendly debate about that Have worked a few decades with large technical systems... I get that bad design or missing requirements don't constitute a bug. However, for more than a decade, videos produced on cameras sorted correctly (with an expected behavior) within the application, whereby the still images and videos sequenced in the correct order. The historic proper functioning of this field, coupled with the application be labeled sort by 'capture time' makes it virtually impossible for me, and likely just about every other user, to see this as anything other than a defect. I hear what Adobe has gotten your buy-in about their definitions of a bug, but at the end of the day it's not functioning with the precedent they set. Regardless of who they point their finger at, they have to be the one to fix it. If they can manage lens correction profiles for about every lens out there, it seems they could make it function as it has historically. Especially given the number of new cameras annually has shrunk dramatically over the last decade. One might say sorting by capture time correctly might be considered a 'universal requirement' for all photo management software, unless, of course, it's 2nd rate software.

Or... perhaps they could change the sort option title from 'capture time' to 'exif metadata capture time raw data value, even if it's UTC' and all the people importing from recent cameras will be satisfied viewing their images out of order?

Right. When video support appeared in LR 3 and enhanced a little in LR 4, Adobe never finished the implementation, including the ability to write back metadata to the video files.

If you're a glutton for mind-numbing detail, you could use the Run Any Command plugin to run the free Exiftool utility, passing it the name of the file and the capture date stored in the LR catalog. If you're not familiar with either Friedl's plugins or Exiftool, expect to take at least a couple hours figuring everything out.

You could also write a script that uses Exiftool to shift the capture time of videos before you import. There are examples on the Exiftool man page of the necessary magic.

Exiftool is by far the most authoritative and robust tool for reading and writing metadata to photos and videos.

Alright, I'll setup exiftool on my machine. I guess my concern/decision point is that I change the actual exif data, then Adobe decides to make the software work as expected... then what? And, I'll have to test with other software where I may import, such as apple photos for family, to see if that messes with it. So, some investigation needed.

I've used Friedl's plugins before, but not that one. I'll check it out.

Thanks for all your support, and have a great weekend.

 

[John R Ellis]

I'm just trying to accurately describe Adobe's definitions and processes, not express agreement with them -- they're not the processes I used when I managed software teams :-<

my concern/decision point is that I change the actual exif data, then Adobe decides to make the software work as expected

I think it's unlikely that will happen before the next ice age. Video is LR's stepchild, receiving almost no support since LR 4 (2012). You still can't export video or slideshows in resolutions greater than 1080p (without a plugin).

 

[Gnits]

Just a thought….

It is possible to place an xmp side car file beside an image which if correctly formatted / structured will result in the metadata for that specific image within LrC been updated with the xmp file metadata contents.

I have my own Ingest app which copies images from card to their final project folder destination and which renames the images to match my preferred naming schema. When ingesting multiple cards… I always felt that it would be useful at the point where the cards are transferred to disk to apply specific title, caption, location, copyright info, specific to the cards been transferred.

I spotted years ago that PhotoMechanic transferred ratings and other metadata via xmp sidecar files to allow this data to be absorbed via the LrC import module.

A few weeks ago I upgraded my Ingest App to allow the option of entry of Title, Caption, Location per card ingested. It creates the appropriate side car files per image. It works perfectly.

I have only created these side car files to cater for the specific fields of interest to me… but I see no reason any metadata field could be updated via side card xmp files.

So, you could write a mini app or script, incorporating Exiftool.exe.. which could create these xmp side car files with a capture date timestamp calculated as you wish. You could use the same script to rename the filename transferred to disk so that it would guarantee what ever sort sequence you would like to use when capturing video files from multiple camera sources.

Some caveats…
1. I have only used this technique for still images.. I do not capture video so had no incentive to explore that space. It may not work for video files.
2. I used this approach for fairly static fields such as Title, Caption, Location. Perhaps different rules might apply to fundamental fields such as Capture TimeStamps… which are key elements within the LrC database structure.

 

[ross101]

I'm just trying to accurately describe Adobe's definitions and processes, not express agreement with them -- they're not the processes I used when I managed software teams :-<

Fair enough. I feel like Adobe's corporate culture and relationship with customers hasn't changed, almost ever.

I think it's unlikely that will happen before the next ice age. Video is LR's stepchild, receiving almost no support since LR 4 (2012). You still can't export video or slideshows in resolutions greater than 1080p (without a plugin).

I believe you. I do little activity with video in lightroom, aside from cataloging. However, I can recall way back when (v2 or 3) that it was atrocious and at some point it seemed to function a lot more. I don't even recall when they introduced video capabilities or if they were there in 2.

 

[ross101]

Just a thought….

Matt, thanks for the thoughts - I appreciate you sharing, and the thoughts on the xmp.

I have to look closer when I get exif tool installed and back from travel next week, but think I am seeing ratings and labels carry over from bridge without an xmp file. I've been testing out a new workflow to rate and cull, as well as label videos associated with live view photos using bridge. At least, I don't think there were any xmps present in any of the exports. And I did verify that changes to the creation date, as made in bridge, did also carry forward. I need to look closer and see specifically which fields it is updating. So, adding the step to change the date there may end up being straight forward.

But if not, then the app or script option using exiftool with the sidecar file will be a good option. There may even be some additional benefits or shortcuts from handling it this way.

Ultimately, before I make any changes, I have to dig in more to see if changing that data has other adverse effects to other downstream applications (apple photos, FCP, social sites, etc). The last thing I want to do is make everything outside of lightroom wonky!

 

[Gnits]

Bridge may give you what you need. Bridge might have been there before xmp was invented and Adobe would have the ability to create a direct pipe to their other products. I am not sure how this stuff works in Bridge, but I expect Bridge might respect and use xmp side car files if present.


Learning how to use Exiftool is always useful.

If you go down the Xmp route let me know. I will send you a worked example and how I have made it a simple painless process (for me).

BTW.
I often end up copying high volume cards for others (wildlife, 120 frames per second stuff, stills and video). I hear people complaining frequently that they lost or do not know how to find their video files. I added a routine to my ingest app.. that copies all video files in an Sd card to a subfolder of the target project folder and saves all the video related folders and their content…. so at least the video files do not get lost, thumbnails and metadata files are preserved, etc. when the cards are formatted.

 

[Gnits]

The last thing I want to do is make everything outside of lightroom wonky!

Agreed… my workflow, file and folder naming schema is designed to cater for projects outside of Lightroom that may incorporate Cad systems and their files, project management tools and their files, etc…For some (probably a lot) the Lightroom / Photoshop / Bridge ecosystem caters for their needs, but often I needed to cater for major commercial projects where cad drawings were more important than images.

 

[ross101]

You might be right about Bridge before xmp was their accepted sidecar format.

Thanks for offering to share the xmp example and info. I may well take you up on that.

Is this ingest app a personal app you created through some framework (possibly AI), or is it a product you've put out there for others? Yeah, it can definitely get tricky to keep all the pieces together, and of course the different formats over the years.

Hopefully I get this all sorted out when I'm back next week, as I have about 150GB of random snorkel video/pics from this GoPro and a TG-5 to cull and import. It's the first real use I've had of the GoPro, and what a pleasant surprise to find all this out about lightroom!

 

[ross101]

...for projects outside of Lightroom that may incorporate Cad systems and their files, project management tools and their files, etc…

Now that is a whole different layer of complexity!

 

[John R Ellis]

It is possible to place an xmp side car file beside an image which if correctly formatted / structured will result in the metadata for that specific image within LrC been updated with the xmp file metadata contents.

I just verified that LR doesn't read metadata from a .xmp sidecar when you import a video.

However, your comment reminded me that it will read metadata from a .jpg "sidecar" (a JPEG with the same base file name in the same folder):
https://community.adobe.com/t5/ligh...here-is-a-mov-with-the-same-name/m-p/14279023

Years ago, some cameras (Sonys?) used JPEG sidecars, perhaps because the firmware engineers found it more expedient to use the JPEG code they already had for still photos, rather than figure out a different standard. I don't know of any cameras that still write JPEG sidecards.

 

[ross101]

I just verified that LR doesn't read metadata from a .xmp sidecar when you import a video.

However, your comment reminded me that it will read metadata from a .jpg "sidecar" (a JPEG with the same base file name in the same folder):
https://community.adobe.com/t5/ligh...here-is-a-mov-with-the-same-name/m-p/14279023

Years ago, some cameras (Sonys?) used JPEG sidecars, perhaps because the firmware engineers found it more expedient to use the JPEG code they already had for still photos, rather than figure out a different standard. I don't know of any cameras that still write JPEG sidecards.

Interesting... I was just wondering about this a few days ago, when I saw an old .mov with +JPEG. Now, maybe that was an actual still taken at the start as some sort of thumbnail or even a standalone pic, but I don't seem to be able to access it (haven't tried very hard). This was on a Panasonic FZ-35.

Edit: I see your post in the other thread... I'll have to go back to the original files to see if it is a standard JPEG or possibly intended as a sidecar.

 

[Gnits]

I just verified that LR doesn't read metadata from a .xmp sidecar when you import a video.

Thanks for that.. I was going to do a test.. so you have saved me that effort.

I am successfully placing Title, Caption, Location metadata content into xmp side car files which LrC then uses to populate correctly the related metadata fields in the catalog for the specific image. So, I have no need to work with Jpg side car files. Also…. I want to protect the option to use raw or jpgs for any specific project scenario… Currently all raw… but in the past I did charity work for sports events and working directly with jpgs was optimal.


As I have no idea what validation may be happening, I restrict / validate the metadata to numbers and letters and a few punctuation chars… and excluding all special chars. It has crossed my mind to cater for ( or explore) multiline content… was a need in the past when I was auto updating blog posts … but not a need now and have not tested that scenario.

Again.. thanks for testing the video sidecar combo.

 

[John R Ellis]

when I saw an old .mov with +JPEG. Now, maybe that was an actual still taken at the start as some sort of thumbnail or even a standalone pic, but I don't seem to be able to access it (haven't tried very hard). This was on a Panasonic FZ-35.

When you import a video with a corresponding .jpg, if the option Preferences > Treat JPEG Files Next To Raw Files As Separate Photos is unchecked (the default), then the .jpg is treated as a sidecar. (As with some other options in Preferences and Catalog Settings, its actual meaning doesn't correspond precisely with its name.) Like JPEGs in raw + JPEG pairs, you can't access the video'sJPEG from within LR -- you have to go to File Explorer / Finder.

 

[Gnits]

With Sony cameras, jpg files are saved close to the video file for use as thumbnails. There is also video related metadata saved in other files… My assumption is that increasingly, video editing software will make use of this, especially where log files and colour grading tools are used by modern video cameras (and maybe in camera editing of footage).

Now that is a whole different layer of complexity!

I am amazed that there are not increasingly good apps available to help manage the workflow for videographers. Maybe they exist and I am just not aware of them. 20 years ago I had demands to manage (at data centre level) video and stills footage related to large construction sites. Videos and stills were used for security monitoring, but also to prove that construction specifications have been complied with as much cheaper to review video footage compared to stripping down structures to verify compliance to spec at a later date. In those days the concept of network connectivity to these locations was the stuff of dreams and managing stills and video assets was laborious and expensive.

 

[John R Ellis]

This was on a Panasonic FZ-35

Well, that's a 16-year-old camera, so it's conceivable it recorded video metadata in .jpg sidecars.