Though this worth a mention. Perhaps someone would like to check/replicate.
I had been “stuck” on version 0.10.3a1 for a while. I was using an older distro that only had Python 3.7. Now have bookworm and the latest tools 0.11.1
I have a side facing mobile phone camera that I control remotely with wget’s that I only trigger at low road speeds. Up until the mapillary version change the following process script worked faultlessly.
mapillary_tools --verbose process “/mybook/mupload/$CURRDATEWS/process”
–offset_angle 270
–overwrite_all_EXIF_tags
–device_make Samsung
–device_model GTI9305T
–duplicate_angle 90
–duplicate_distance 0.25
–cutoff_distance 50
–cutoff_time 180
–interpolation_offset_time -39600
–geotag_source nmea
–geotag_source_path /mybook/upload/$CURRDATEWS.nmea
The phone creates the EXIF data with a local time stamp, so I have to use an offset for writing the separate GPS values. It’s own GPS is far too variable. I actually write the GPS data (exiftool) into EXIF, but then strip it before process/upload. The unstripped files I use for my own local OSM work.
The offset (-39600) has to be varied as I travel from east to west and through daylight saving variations (Australia)
After the recent tools upgrade I am getting quite odd time/date stamp behaviour. For example yesterdays run at 8AM local wrote GPS date/time as previous day 1000z. (It should have been 2100z) I was thinking it was an integer vs float problem, but didn’t pursue. As it turns out changing the processing to use my already geoencoded images works fine. (–geotag_source exif) I vaguely remember that the tools may have got the view direction wrong or I didn’t have a local means to position interpolate in the past, but the photos/view/position are correct within maybe 0.5 secs, so good enough.
Someone may wish to try/check large time offsets.