Should mapillary_tools process the GPSDateStamp & GPSTimeStamp only then in this example the MAPCaptureTime value should end in _000. Either way, something is off.
@tao A closer look reveals that mapillary_tools does not read SubSecTime* at all and just assumes all files with identical DateTime* values (within 1 second) to basically have identical timestamps. So, it just appends _100, _200, _300, and so on for every next file with the sameDateTime* value.
When both GPSTimeStamp and DateTimeOriginal are found in an image, mapillary_tools will prefer GPSTimeStamp. This is by design.
SubSecTime* are not designed to be applied for GPS timestamps (see EXIF Tags). Also it will cause some offset issue, here is an illustration of the potential issue:
# Assume the capture order is as follows:
Image 1:
DateTimeOriginal: 2025:02:10 12:56:23
SubSecTimeOriginal: 900000
GPSTimeStamp: 11/1 56/1 23/1
Image 2: # captured after 0.2 seconds
DateTimeOriginal: 2025:02:10 12:56:24
SubSecTimeOriginal: 100000
GPSTimeStamp: 11/1 56/1 23/1 (remained unchanged here because only 0.2 difference)
@GITNE Proposal workaround is to add your subseconds to GPSTimeStamp directly, e.g. 11/1 56/1 23.626625
I see, good catch @tao. So, mapillary_tools reads GPSTimeStamps with top precedence and compares these (only), which is generally the right thing to do. However, I think we could add a special case here. If DateTimeOriginal+OffsetTimeOriginal is equal in value to GPSDateStamp+GPSTimeStamp then mapillary_tools should read DateTimeOriginal+SubSecTimeOriginal+OffsetTimeOriginal for processing. Note that in this case you must not assume SubSecTimeOriginal == 0 should SubSecTimeOriginal be lacking. Whenever GPSTimeStamp has fraction seconds it will never be equal to DateTimeOriginal+OffsetTimeOriginal due to DateTimeOriginalās 1 second limited resolution or granularity. Hence, GPSTimeStamp with subāseconds should be assumed safer or closer to the truth for processing. I hope this makes sense?
I am not sure that sorting by both, GPSDateStamp+GPSTimeStamp and DateTimeOriginal+SubSecTimeOriginal+OffsetTimeOriginal, instead of by precedence only is a good strategy because GPS and DateTimeOriginal(+SubSecTimeOriginal+OffsetTimeOriginal) timestamps can deviate greatly. Maybe there is something I am unable to foresee here or I do not fully understand what you mean by āto sort images by bothā.
Alternatively, you could add an option that would enable hinting to mapillary_tools the timestamp source to use. Or, make the precedence configurable with a file (but this would be a lot of work). Anyhow, I think that for the ease of use mapillary_tools needs a sane default timestamp source precedence with proper subāsecond support, which admittedly may be more complex than one would think at first glace. So, letās call it more fashionably āSmart Timestamp Source Selectionā (since, you know, everything has to be smart today to sell).
@GITNE Proposal workaround is to add your subseconds to GPSTimeStamp directly, e.g. 11/1 56/1 23.626625
It should be OK to do if GPSDateStamp+GPSTimeStamp and DateTimeOriginal+OffsetTimeOriginal are of equal value.
However, I think we could add a special case here. If DateTimeOriginal +OffsetTimeOriginal is equal in value to GPSDateStamp +GPSTimeStamp then mapillary_tools should read DateTimeOriginal +SubSecTimeOriginal +OffsetTimeOriginal for processing.
This is a great suggestion. We will take it into consideration. Thank you.
I am not sure that sorting by both
Sorting by both is just a better estimate for the order for the images. Ordering is more important than timestamp absolute accuracy because it affects both processing and visualization.
Anyhow, I think that for the ease of use mapillary_tools needs a sane default timestamp source precedence with proper subāsecond support
Yeah I agree, we need this āSmart Timestamp Source Seletionā by considering all possible clock sources. We can make it better. Before we get there, try exiftool to make sure the preferred tags are correctly updated.
look reveals that 
