What's wrong with my subsecond sequences?

Contributing and equipment
1

I have been working on processing photos with less than a second between them. The camera says it’s 0.5 seconds between photos, but it’s really more like 0.67… Anyway, I found this topic (Page not found) and the github issue topic referenced therein (https://github.com/mapillary/mapillary_issues/issues/1319#issuecomment-139901432), and tried both of the scripts to interpolate subseconds (by blaueente and @StephaneP).

Everything looks good after processing, and when I load the photos into JOSM, they seem to be in the correct order. However, after I upload them, Mapillary does something in the backend that breaks the order. See this sequence: Mapillary. Each group of three photos in a row jump from 1 to 3 to 2 in sequence.

This issue was referenced in the github thread, but the resolutions are now three years old, and don’t seem to apply to the mapillary_tools I’m using (which are a version behind current).

Any ideas if I can fix this without too much revamping of my workflow?

2

Hi!
Download exiftool and try to run this command:

exiftool -DateTimeOriginal path_to_some_jpg_file

If some of your files include a subsecond value in the datetimeoriginal exif metadata, I know what happened, it’s a bug in the mapillary_tool scripts:

If you still have some images to process, you can try my fork:

pip install --upgrade git+https://github.com/Stefal/mapillary_tools.git@patch-6

But I don’t know any way to fix this bug on already uploaded images.

3

None of my processed photos have any subseconds in DateTimeOriginal. All subseconds that were added are in SubSecTimeOriginal. I tried a couple of things, one where only the photos with 0.5 subseconds had the tag (SubSecTimeOriginal = 500000), and a couple different ways of adding 000000 to all the other photos too. The correct photos are given the subsecond (so e.g. the first 12:55:12 gets nothing or 000000, the second 12:55:12 gets 500000), but Mapillary puts the order as :12, :13, :12.5, which seems really weird.

4

Could you share a group of processed (with mapillary_tools) images with this problem ? I’d like to download them and look at the exif data.

5

Here’s a link to a .zip of a few photos: Dropbox - File Deleted

6

Hi!
Am I right that these images were not processed with the mapillary_tools python script at all ?
If I’m right, there is a problem with the script you used, because the timestamps are wrong:

G0080110_12_48_12 → 16:48:05.0
G0080111_12_48_12 → 16:48:06.5
G0080112_12_48_13 → 16:48:06.0

And the script overwritten all the datetime values (original, capture, digitized, modified), so you can’t retrieve the original ones with these exif metadata.

But, there is something very interesting: The GPS Timestamp

G0080110_12_48_12 → 16:48:05.5
G0080111_12_48_12 → 16:48:06.0
G0080112_12_48_13 → 16:48:06.5

So it’s possible to copy the GPS TImestamp to the DateTImeOriginal + SebSecTimeOriginal values. I don’t know how to do this with exiftool. I could do it in python, but I don’t have enough free time right now.

By the way:Are these GPS timestamps with subsecond values written by the gopro, or by the script you used ?

7

Thanks for the catch! I think that is what’s causing the issue, and running through my scripts one at a time may have caught the problem.

First off, I use a mixture of mapillary tools and some other tools, because I had some weird issues with some cameras, and I’m not a great coder…

So the problem comes when I geotagged. For this sequence, I was geotagging with a -6.5 second offset from the photo timestamp. So that applied a 0.5 subsecond to the photos in the GPS Timestamp, as you saw.

However, awhile back I started overwriting -AllDates<GPSDateTime with exiftool, because I was having issues with Mapillary not understanding that the GPS time was UTC, and DateTimeOriginal was my time zone. Thus, in Mapillary, the timestamp in the corner was 4-5 hours off. I’m not sure if this is different now (whether Mapillary reads GPSDateTime first?), but that’s how I’ve done it for awhile.

The upshot is that with that .5 second offset, the time copied into DateTimeOriginal etc. cuts off that necessary half second, shifting all the timestamps. That, I assume, is why Mapillary reads
G0080112_12_48_13 → 16:48:06.5
before
G0080111_12_48_12 → 16:48:06.0
because they are both 16:48:06 in the timestamp.

I’m trying a slightly different offset (-6.45) to see if that fixes the issue. If it does, great. I might also see what it does without overwriting those tags.

8

I don’t remember the correct command line, but with exiftool, you can retrieve the DateTimeOriginal from the filename. So this what I would do:

  • Delete all the datetime, gps datetime exif metadata
  • copy the time from the filename to the exif datetimeoriginal
  • Start from scratch with “clean” images.
9

I seem to have gotten it to work. Thanks for the help. It’s annoying that it was something like that, but sometimes it just takes more eyes looking at the problem.

10

Всем, привет! Прошу прощения если пишу не в подходящую тему.Стали теряться(не опубликовываться) загружаемые последовательности. Я загружал несколько своих видео на legacy.mapillary.com.- в последний раз не была ни одна опубликована.

11

Translation

Hello! I apologize if I am not writing in a suitable topic. We began to lose (not publish) downloadable sequences. I uploaded some of my videos to legacy.mapillary.com.- the last time none was published.
Also uploaded 4 photos via Mapillary Uploader for Desktop - only 2 were published.