Time of capture metadata bug in iPhone 4 movie clips

Updated 9/12/10: I’m not sure any more if this is an iPhone 4 glitch or an Adobe Lightroom 3.2 bug. A thread has been opened in the Adobe Lightroom Forum, if you’d like to chime in there.

After upgrading the iPhone with iOS 4.1, I recorded a new video clip, imported it and some new photos into Lightroom, and the same wrong date and time appear for it.

According to a comment on my thread in the Apple Support Forums, the correct time of capture is displayed for iPhone 4 video clips elsewhere but Lightroom. And I also noticed that Lightroom displays the very same incorrect date and time of capture for video clips taken with the Nokia N95.

Updated 9/27/10: I’ve been in touch with Adobe, and it turns out this is a “designed” behavior. That is, because movie clips do not have EXIF data (there is no standard for EXIF data when it comes to them), they are assigned a random date and time as they’re imported into Lightroom. HDSLR video files are accompanied by a .THM file which stores the necessary EXIF data, and that’s why they show up properly.

Quoting from Davide M.’s (Adobe) response:

So I then had a look at our bug database and it turns our this is a known issue with mobile phones although somewhat out-with our control. Movie files do not technically have EXIF data or at least the standard has not yet been established. Since the import process can assign a timestamp to a movie file, we ignore this time stamp since it can be inaccurate, as shown by the example of your video file being changed by the simple process of email. Other applications while appearing to work fine, in fact are simply showing you the files creation date. If you were to duplicate the file, you will see that the timestamp in these other applications will change to the time the file duplication took place.

The reason why most DSLRs work is because they create a sidecar file containing that information. Files with no timestamp, such as the ones from the iPhone and the Nokia N95 do not create this and hence default to 1/1/04 when looking at the Loupe information overlay.

In the example you used, the Canon 7D creates a .THM sidecar file with the same name as the video file it generates. This contains all the data associated with the video file.

Still, this is problematic behavior, as it introduces erroneous times of capture in these movie files. So I asked Davide if it would be possible for Lightroom to be updated so that it writes a more accurate time of capture for these movie files. Thankfully, he agreed to log it as a feature request. Time will tell if this will make it into a future LR update. Quoting him below:

That’s certainly something I can log in our feature request list. Because this has been deemed ‘as designed’ by our engineering team (due to the lack of EXIF data in movie files) it is not technically a bug. None the less, I can see that this would be a useful addition to our application. Thanks for bringing this to our attention.

Thank you, Davide!

After downloading a few movie clips taken with an iPhone 4 (running iOS 4.0.1) onto my computer, I saw right away that their time of capture was incorrect, even though the iPhone’s time had been set up correctly. I took a few screenshots of the movie clips in Lightroom, which you can see below. Click on each to view them large.

This time metadata error happens when using either the main (back-facing) HD video camera, as shown above, or the front-facing VGA camera, as you can see from the screenshot below.

It looks like iPhone 4 records the same time for all video clips recorded with it, set at 1/1/04 1:44:24 AM.

It goes without saying that any digital video camera worth its salt will record the time of capture properly. The question, naturally, is when Apple will fix this glaring bug?

For comparison purposes, here is a screenshot of a Canon 7D movie clip, also shown in Lightroom. The time of capture was recorded properly, as was to be expected.


9 Thoughts

  1. Just curious if this post is still active.

    I havent tested specifically for the iPhone, but I do know that in Lightroom 4 it still isnt managing video capture times correctly. I can take videos on 7 different cameras at the same time and have them each be given different times by Lightroom.

    Windows Explorer, for free, does a much better job.

    Like

  2. Are iPhone 4 Video clips geotagged? I read here and elsewhere online that they are, though a number of users seem to have difficulty displaying the data:

    http://www.nytimes.com/2010/08/12/technology/personaltech/12basics.html (..ubiquity of geotagged photos and videos…”

    If they are tagged with GPS coordinates, how can I display the metadata under Windows XP or 7 with a free viewer if possible? (And then how can I delete it for privacy concerns?)

    I’m completely familiar with EXIF and understand this does not apply. Perhaps the metadata is particular to the .MOV filetype and Quicktime which the iPhone uses?

    I looked under the Extra Metadata tab in VLC (under Media Information), but nothing appeared there.

    Perhaps http://en.wikipedia.org/wiki/ExifTool would display the geotag, though it seems if it does it only has read capability for the .MOV filetype. I haven’t tried this tool, have you?

    Thank you.

    Like

  3. tell those clowns at adobe to utilize the “modified date” as this date usually coincides with the “picture taken date”

    Like

  4. While unfortunate, I’m not surprised by the timecode issue as Lightroom isn’t doing much with video–which is OK because it is so good with still images! However, there is a place to read this metadata correctly, at least with iPhone: while there is no EXIF’ the quicktime format does contain standard fields for creation date and even LOCATION data for videos recorded as .mov. I’ve discovered that Aperture, iPhoto, iMovie for iPhone, and Quicktime X show location and date on clips from my iPhone 3G3. It would be nice if other programs would read this metadata, too (others are starting, but there is not much awareness).

    Claude

    Like

Comments are closed.