I’m testing the Yi 4K since a few months, and I noticed a big problem with the exif’s timestamp:
Sometime, the datetimeoriginal tag is wrong. It seem’s this timestamp is computed at the writting time, not the capture time.
Here is an example with a 1s photo timelapse:
-17h57mn40s
-17h57mn41s
-17h57mn43s
-17h57mn45s
-17h57mn48s
-17h57mn48s
-17h57mn48s
-17h57mn48s
-17h57mn49s
Then, the gpx correlation is complely wrong. I had to manualy move a lot of images before sending them on the Mapillary servers.
I have this same camera. I like its 170-degree shooting angle but have noticed that my images seem a little off with them, and they’re not consistently off the same distance.
Becuase of this I recently decided to accept losses with the camera and try the Garmin Virb Ultra. This camera has integrated GNSS and a compass. I just got it in the mail, so have not tested it out.
My solution is very advanced, but the command-line application ExifTool (runs on Windows/Mac/Linux) allows setting the timestamp by file name sequence. You can use this as long as all photos have a sortable filename.
First set the timestamp for all photos to the start of the sequence: exiftool -datetimeoriginal="2018:08:09 17:57:40" *
In the next step, you’re going to increase the timestamp with 1 second more for each subsequent photo: exiftool "-datetimeoriginal+<0:0:${filesequence;$_*=1}" *
Of course, this assumes the whole sequence has an average of one photo per second (like in your example). The photos in your example would end up with the following timestamps:
17h57mn40s
17h57mn41s
17h57mn42s
17h57mn43s
17h57mn44s
17h57mn45s
17h57mn46s
17h57mn47s
17h57mn48s
Disclaimer: This is from my personal notes. It worked well last time I used it, which is several years ago. I don’t know if the current version uses the exact same syntax, or if I make a mistake when writing down my notes…
Thanks for the workaround, but as @Jaku103 explained, the offset isn’t regular.
Maybe I will write a python script to detect a group of images with the same timestamp, but my first goal was to alert the potential buyers that this action cam isn’t plug’n’capture.
For me, it’s close and in my opinion for mapping pupurses close enough. But, I capture by bike so the speed is slower. As a result, a little deviation is just that a little deviation. I’m sure if I was using a car that deviations would be huge. And, I can’t tell if they are off, because if they are it is a matter of seconds, that may be GNSS drift.
So, for people buying this camera keep in mind your capture speed, walking/biking you are probably fine. It was enough for me to bug me on it.
Does the camera store “subseconds”? As I understand it, these are not part of the standard datestamp, but stored in another metadata field. If the subseconds are different for the images with the same datestamp, you might still be able to geotag them to different locations on the GPX track.
Hooooo, the subsectimeoriginal exif tag! It’s my dream. It deserves separate topic.
I’ve already ask Yi technology to add this data since a long time (since the Yi 2K).
The problem is that no action cam manufacturer write it…except LG with the LG 360.
No subsectimeoriginal with Yi, GoPro, Gitup, Sony. Not even for the expensive Sony RX0. And I don’t understand the reason.
I suspect that it is not integrated in the Ambarella or Hisilicon SDK (action cam chipset manufacturers).
As it would help all the Mapillary contributors, and allow a better accuracy when you geolocalize the images, I’ve already asked the Mapillary staff to help me making some lobbying, with no luck.
I also use Yi 4k and I love it! In my experience with it, the times are really a bit off but only that I have to readjust one or two seconds maybe every 2 hours of taking pictures at 1 sec interval. I never had it as bad as StephaneP. Maybe it is a combination of a not-too-good implementation at Yi 4k and a slow SD card?
I now understand the reason Mapillary file names on my Samsung Note with a millisecond tag. Much better than the EXIF times that are not only in the wrong format for a date, rounded to the nearest second, but they vary by several seconds from the filename timestamps.