Hi! I am using my camera to provide best quality imagery. It features the interval function, so it takes one image per five seconds. Sometimes, I have to abort it because people or cars are crossing (and begin a new interval recording). When I used my phone, I experienced that when I upload (via Desktop uploader) one batch, it split it into several Mapillary sequences, although they belong together. Is there a way to force one upload to become one Mapillary sequence? Thanks in advance
They must be very close to each other I think
Sequences will always be split into 1000 images, that’s the maximum sequence size.
Using the command line tools. I would suspect the desktop uploader can also configure these;
There are various parameters invoking the tools that will “split” a sequence and “force” creating duplication errors that drop those that are too close in time or distance. The command line help for “process” for example;
–cutoff_distance CUTOFF_DISTANCE
Cut a sequence from where the distance between
adjacent images exceeds CUTOFF_DISTANCE. [default:
100.0]
–cutoff_time CUTOFF_TIME
Cut a sequence from where the capture time difference
between adjacent images exceeds CUTOFF_TIME. [default:
60.0]
–duplicate_distance DUPLICATE_DISTANCE
The maximum distance that can be considered “too
close” between two images. If both images also point
in the same direction (see --duplicate_angle), the
later image will be marked as duplicate and will not
be upload. [default: 0.1]
–duplicate_angle DUPLICATE_ANGLE
The maximum camera angle difference between two images
to be considered as heading in the same direction. If
both images are also close to each other (see
–duplicate_distance), the later image will be marked
as duplicate and will not be upload. [default: 5.0]
I would suggest in your case of the photos in a date/time ascending file name set, use some numbers like;
–cutoff_distance 100 (100m maximum between photos)
–cutoff_time 3600 (1 hr max between photos. Check such a large number works though)
–interpolate_directions (You probably manually set the image direction so make sure this is not included)
–duplicate_distance 0.01 (10mm minimum movement between each frame. Check such a small number works though)
–duplicate_angle 90 (so it wont drop frames if you rotate the camera around close to the same point with a direction change of <90deg)
Hope this helps.
1 Like
Thank you, this sounds reasonable! The position alone is probably not the problem, as I was next at the sequence when I aborted it. I also saw image sequences containing more than 1000, or they used command lines. Anyway, I was not near that limit
It’s also worth knowing that if (before Mapillary process) the photos have the GPS position (and probably direction) already saved in EXIF the actual date is not so important and a GPX etc isn’t needed. AFAIK the tools won’t care about anything but the lat/lon and date/time order. ie it’s possible to merge a specific route from a number of source dates/times and fabricate a date/time from (say) the filename. eg;
20260321_010101_555.jpg might represent March 21 2026, 1:01:01.555
Then use exiftool to change the date/time fields;
exiftool -P -overwrite_original ‘-alldates<filename’ ‘-SubSecTime*<${Basename;m/(\d+$)/;$=$1}’ ./
One would have to be careful with vastly different light conditions (that might affect object recognition) and use a date and time that is reasonably close, but it is then possible to create a series of images as if it was just one pass, from more than one.
Not sure if this may help for your workflow method, but thought worth a mention.
I use Interval Mode for the same reason and use it to record my hikes. To get the whole hike as a single continuous sequence, I use the Mapillary tools and set the following environment variables before running ‘process’:
export MAPILLARY_TOOLS_MAX_SEQUENCE_LENGTH=10000
export MAPILLARY_TOOLS_DUPLICATE_DISTANCE=-0.1
export MAPILLARY_TOOLS_CUTOFF_TIME=7200
export MAPILLARY_TOOLS_CUTOFF_DISTANCE=2000
export MAPILLARY_TOOLS_MAX_SEQUENCE_PIXELS=500G
However, from around 2,500 images per sequence, the process does not complete properly and the sequence remains yellow. There were discussions about this some time ago. See, for example,https://forum.mapillary.com/t/how-many-images-per-sequence/9466. Here you can view an affected sequence: https://www.mapillary.com/app/?lat=50.9284313&lng=14.3144506&z=17&panos=true&pKey=1995777131011990&focus=photo&x=0.41119060984194594&y=0.5484816383211263&zoom=0.1.
Just fyi: You can use the inf Python artifact to disable limits that grow. You can use 0 to disable limits that converge toward zero. It should have been documented but it has been omitted for no apparent reason. 
Actually, there is no image count that makes a sequence get stuck or fully processed. In fact, there are sequences with over 15k images that have been processed just fine. On the other hand, I have had sequences with as few as 137 and 287 images stuck in “Map Data Processing”. This is a systemic issue. Sadly, the issue has been consistently sidelined and down played for years by Mapillary. 
At least, this is my impression. The official policy animates you to upload as many images per sequence as you like, which makes sense. Technically, it is generally possible to upload as many images per sequence as you like, no image gets lost, and you can view every image after upload but in practice there is no guarantee that any of your sequences, no matter how many or few images they may have, are going to get fully processed.
1 Like
2,500 is an empirical figure based on my uploads. The discussion I linked to shows that it can actually be significantly lower. In that discussion, you mention the “137 and 287” threshold.
Anyway, even if the sequences remain yellow for all eternity – that’s enough for me. All the images are there, navigable and rotatable. Perhaps some information (traffic signs?) wasn’t extracted correctly, but those occur very, very rarely in my routes 
Thanks for the tip.
I had a second batch with this command which had elapsed images in it, and it worked :). The first test batch failed, but already during the command process, maybe non-related files were disturbing :).