Cameras and time zones

Contributing and equipment
1

I just made a little research, while trying to get some geotagging to be correct. I use 3 cameras: A Garmin Virb Elite, from which I make a gpx track to geotag the others. 2 Xiaomi Yi (no GPS) and a Sony as100v (that also has GPS). I found that my phone (Sony Xperia X2) made too many errors when I use that to create a GPX track.

So, I have to correlate times in order to geotag. But time zones and daylight savings time is something that should not exist. Wait, if UTC was just used for anything not meant to be human readable, the problem would be solved. Of cause camera manufacturers and/or standard creators have not always figured that out.

Story: At 19:22 DK local time with DST / 18:22 UTC I took an image with each camera and named the images after the camera. Only showing exif-tags with the string ā€œDateā€ in them, gave this:

sony.JPG
File Modification Date/Time : 2015:11:05 19:31:54+01:00
File Access Date/Time : 2015:11:05 19:28:55+01:00
File Inode Change Date/Time : 2015:11:05 19:31:54+01:00
Modify Date : 2015:11:05 19:22:16
Date/Time Original : 2015:11:05 19:22:16
Create Date : 2015:11:05 19:22:16
Sony Date Time : 2015:11:05 19:22:16
GPS Date Stamp : 2015:11:05
GPS Date/Time : 2015:11:05 18:22:17Z

yi.jpg
File Modification Date/Time : 2015:11:05 19:22:30+01:00
File Access Date/Time : 2015:11:05 19:28:55+01:00
File Inode Change Date/Time : 2015:11:05 19:27:42+01:00
Modify Date : 2015:11:05 19:22:29
Date/Time Original : 2015:11:05 19:22:29
Create Date : 2015:11:05 19:22:29

garmin.JPG
File Modification Date/Time : 2015:11:05 19:22:08+01:00
File Access Date/Time : 2015:11:05 19:28:56+01:00
File Inode Change Date/Time : 2015:11:05 19:27:47+01:00
Modify Date : 2015:11:05 19:22:08
Date/Time Original : 2015:11:05 19:22:08
Create Date : 2015:11:05 19:22:08

What can we learn?

Most importantly, all the dates that are not related to the file, are given in local time without any indication of time zone or DST! I will have to look at File Modification Date/Time to get a time zone (but note at both the Sony and GArmin, that they does not correspond to the Create Date). And why on earth would anyone write a local time without specifying time zone or DST?

Second, the Garmin is wird. It has a GPS - actually a good one - but does not write the ā€˜GPS Date/Timeā€™ tag. But anyway, all it images are tagged with ISO 0 and 1/11 for shutter speed.

What have I learned (for the nā€™th time):
Never ever trust a computer. Always observe and understand.

Ahh, now I got that out :smile:

1 Like
2

I am trying to figure out what happened with your pictures, correct me if I am wrong :wink:
Tou took the picture at 18.22.16 (sony), 19.22.30 (yi) and 19.22.08 (garmin) none off the devices writes down the timezone at all.
Att 19.27.42 (yi), 19.27.47 (garmin) you uploaded images to your computer, which created the file modification and file access timestamps with timezone. The sony picture you modified after you uploaded it to your computer. Therefore the modification time is after the access time.

So you could learn, that your cameras donā€™t use timezones and your computer does.

But why do you need to know the timezone in your scripts?

3

The ā€œmodificationā€ I made to the sony picture, was moving it from one folder to another. The camera actually took 3 photos and I downloaded all of them to the computer.

  1. Without time zones I donā€™t know the actual time the images was taken. If I know the approximate location I can figure out the time zone, but that is a difficult operation compared to putting the time zone or UTC time into the exif-spec.
  2. When I create a gpx track from the garmin images, the gpx format requires UTC format. That is the way it should be, because that places the images on an exact time. If I for some reason want to use that gpx track later, it is bound to give problems if I have to remember that it does not comply with the spec.
  3. I currently use exiftool for reverse and normal geotagging. It is a nice tool, but when doing geotagging it looks like it assumes the images are taken in the computers local time zone and converts the times. When doing reverse geotagging (create gpx from images) it just copies the time, because its reverse geotagging features is a bit hacky. So in this way the times does not end up matching.

I could just ignore the time zones and use Mapillarys geotagging script, but as I state: It is plane wrong to ignore them. It will just create problems another time. As a software developer it would be like cutting myself to do that.

4

I see tour problem, but since youā€™re basically only map in Danmark, it is a theoratical problem. It should be relative easy to change the local times to UTC in your script (but watch out for daylight saving time)

I guess you are using all cameras to make 360 views and than you should be able to use info from the garmin to figure out which timezone you are in. Your phone probably also has a decent GPS, and there are many APPS to save your tracks. So maybe you should use your phone to make a GPX file

5

My solutions is actually to correct the time when I do reverse geotagging. exiftool fixes it in the other places. But still, it is a hack and when we changed to winter time I got it wrong and ended up uploading a couple of sequences that are located in the wrong place.

It is a solution that works, but it should not be a problem and I have to correct the time 2 times a year and make sure I do not create gpx traces on the wrong side of DST dates. It shuld not be a problem if the dear people who made the exif spec had put a time zone into it. It is just frustrating. But hey, in my daily work as a software developer, I some times have to deal with even worse standards and systems that are approved to be standard compliant but are not. We must remember that standards are made by humans and that species makes mistakes.

I have formerly used my phone, but from time to time it creates a point that just jumps several hundred meters into a random direction, then the next one is perfect again. The worst result of this can be seen on http://www.mapillary.com/map/im/s_JGETokTFhhe7Fy2vT_dg/map - I would like to correct it, but as long as change sets can only be max 100 pictures it would take too long time. The same result can also be seen around the area, but in lesser scale.

My garmin is also much more precise than my phone in general. The phone is a Sony Xperia Z2, which was a top model a couple of years ago and still updated. A nice phone and I think it should perform better.

6

isnā€™t there another exif tag, you could use to put the UTC in?

7

I just had a look at my cameras time stamps in exif-data and realized that I had overlooked a very important Z in the last line of my output from the Sony:

sony.JPG
File Modification Date/Time : 2015:11:05 19:31:54+01:00
File Access Date/Time : 2015:11:05 19:28:55+01:00
File Inode Change Date/Time : 2015:11:05 19:31:54+01:00
Modify Date : 2015:11:05 19:22:16
Date/Time Original : 2015:11:05 19:22:16
Create Date : 2015:11:05 19:22:16
Sony Date Time : 2015:11:05 19:22:16
GPS Date Stamp : 2015:11:05
GPS Date/Time : 2015:11:05 18:22:17Z <---------------

Yes, it is there in my original paste. The Z means the time is in UTC. It is not there in the Xiaomi YI output (which has no GPS so that is OK) but the Garmin does not have it either.

Well, lets just say, that camera data messy and you cannot always trust it (anyone working at Mapillary must have learned this a 1000 times by now).

E.g. my Garmin camera will tag all pictures as having been taken with 1/15s of shutter speed. This is definitely not true. I have updated to the newest version with no change.

1 Like
8

I will add that the output of the sequences is a multiple of the minute of the first photo, but the time zone is different from the local one.
This feature can make the next day.

9

Still your times are to the nearest second. If we want precise location as we drive then a second will be 13 meters out. I have found the exif times are variable and up to 5 seconds difference compared to the file name time. Which one should we use? Why does it vary? The next problem is that the gpx times are not synchronized with the photos. Just rounding to the nearest second seems a bit approximate. I have developed a script using linear referencing to account for sub seconds but it is complex.

10

The file modification time is set by the cameras operating system when the file is written. If it is pushed it may very well have built up a queue of files to write. For that reason I would definately go for the exif time. For a specific camera you could take a series of images of an accurate data source. That will show teh acuracy.

My favorite tool, exiftool, also does linear interpolation using all the data it has. But of cause both the camera and gpx file may be rounded by up to 0.5 seconds each.

With consumer grade equitment we can only do a best efford with regard to precision. Most cameras will not record milliseconds, so we have to live with what we got. The GPS is not entirely accurate either. It is always possible to better, and we should try, with the resources we got.

11

Might also be worth mentioning that FAT filesystems store time/date without a UTC reference. ie be careful using create/modified dates.

1 Like
12

I did not use the file system modified date, I used the datetime stamp in the file name which uses a UTC format and records milliseconds. But since tryl points out it the file saving time is probably in a queue it will be irrelevant. The only real way is to take a photo of an atomic clock (a gps will do!) and calibrate each run.

13

I guess that a file name with a time stamp would usually be created from the actual time the image is taken. It is only the file system modification time that might be off.

But if the camera does not have GPS I strongly suggest taking a picture of a GPS time, as they can easily drift several seconds over just a month. Preferably an app that shows UTC time, so you are never in doubt about the actual time.