There is an older topic Edit sequence order that is similar but it seems like the platform has changed a lot since the time of that thread in 2017-18 so I’ll start a new one.
I’ve only recently started contributing seriously so apologies if this is a well known issue, but I’m noticing frequent of out of order images in the sequences I’ve uploaded. I’m using Android mobile app. Here is an example: this image should be first, and this image should be second. But their order has been swapped in the sequence. This is visible from the line between them jumping back and forth on the map:
When clicking through the sequence in the direction of travel you see the view make a large jump forward to point 2, then a smaller jump backward to point 1, then a larger jump forward to continue the sequence. It looks like the problem is that the timestamp of point 1 is 6:19:59.450 PM and for point 2 it is 6:19:59.222 PM. So point two is seen as first based on timestamps, even though from the GPS coordinates it should be second.
Is there any way to re-order these, or is it too late after they’ve been uploaded? If it’s not possible, does anyone know why the Android app would be setting the time stamps out of order like this? Any way to fix that behavior?
Thanks for the detailed reply, @GITNE. My phone is a Google Pixel and I’m not finding any settings where I can specify a certain time source. There is one called Automatic date and time which is enabled, though. Its description text says “Set [time] automatically using your network and wireless signals”. I’ll try toggling that off before my next capture and see if it makes any difference.
The Mapillary Android app doesn’t seem to offer any way to edit photo location, compass angle, or timestamp before upload, so I guess if I want to do any of this stuff I’ll have to transfer the photos off the phone and use the Desktop Uploader or mapillary_tools. Not as convenient, but perhaps will lead to better results. At some point I’d like to get a 360 camera so I’ll need to get used to this workflow anyway.
This feels like a potential bug with the Mapillary Android app. Thanks for reporting! I think we should be able to account for cases like this. There isn’t an easy way to fix after the upload, but we will take a look at fixing this in future versions of the Android app.
Glad it is helpful, @boris. Since my last post here I’ve switched my workflow to capturing images with the Android app but then then copying them off my phone and uploading them with the desktop uploader instead. So far I haven’t run into this issue with any of the sequences uploaded in that way. So that does seem to suggest a bug that happens when uploading from the Android app.
Hi @ezekielf, thanks for the report. I agree that this might be an issue (based on available info) on the app side. I tried to confirm it, but it seems that the shared links no longer point to images (were they deleted?). Do you happen to have any other examples? I’d be happy to confirm the root cause and fix the issue.
I have checked the Android code, and I can’t come up with any confident ideas about the cause for now. We always wait for the image to be saved before capturing a new one, and we always sort them by timestamp. There are a few operations here and there in between, but none of those should change the order of the images (at least based on the method documentation).
One nuance is that the mentioned images are 200 ms apart, which is incredibly dense capture—I can’t even achieve that on my phone (500–700 ms is the fastest). We were also using file creation time to sort images, so maybe there’s a hidden race condition. With the upcoming release (6.11), we’re switching to use EXIF timestamps everywhere, and that’s the best guess I have at the moment. If the issue persists in this app version, I will dedicate more time and dig deeper to find the root cause.
Oh shoot. I resurveyed that area because the original photos I took didn’t come out that well (low light). I deleted the first sequence, forgetting I had used them as examples in this thread. Sorry, I wish I hadn’t done that now.
Here is another example. If you start from this photo, and then advance through the next three in the sequence it should be fairly clear that two are out of order: https://www.mapillary.com/app/?pKey=1230239822463220&focus=photo
These were captured as the camera was panning from right to left as I made a 180 degree turn, so we would expect to see each photo advancing to the left by a small amount. Instead we see a large movement to the left, then a smaller movement back to the right, then another large movement to the left, then small movements to left continuing as expected.
Yes very dense. I noticed it usually would happen when the camera was panning side to side or turning, rather than moving straight ahead. It seems that the app triggers the shutter when the captured scene has changed a certain amount from the previous capture. This can happen very quickly when the camera is turning and new scenery rotates into view.
Church tour with artificial GPX sequence for the interior without GPS reception.
For time scaling, I count the elapsed video frames and calculate time anchors for significant points; further time points are added through simple time interpolation.
The lighting conditions in this example were very poor due to an overcast sky. Filming was permitted in this church, but only without a tripod or artificial light. Therefore, I apologize for the low image quality.
I use the OpenStreetMap editor JOSM here to draw and place GPX points. This tool also allows you to rearrange the order of GPX points.
To do this, import a GPX track. You can move and delete GPX points, and if you add a reasonable amount of time, you can also add new GPX points. After editing, the JOSM editor allows you to convert an OSM way into a GPX track. I’m using the JOSM editor here in the Mac and Linux versions.
Depending on the camera’s movement speed, Mapillary requires approximately one GPX anchor point every 5-40 meters (please correct me); Mapillary automatically fills in the gaps. If we assume that a recorded GPX track contains errors such as outliers, a good strategy is to first significantly simplify these tracks through post-processing. In the Insta 360 universe, I apply a reduction factor of 10, and with the Osmo, a reduction factor of 28!. The resulting simplified GPX track also loses many errors, and the final correction is much easier.
So that I can also explore the MAX universe, perhaps someone could lend me a Max2.
Hi @ezekielf, I check the images you’ve shared (thank you for this), and they are ordered in the order of the capture. Which means that the image which is logically first has timestamp as it was captured as a second image. This might back up my initial assumption and in this case this has to be resolved in our current release (see here).
Hopefully you will never see the issue after the app update Pls let me know if you ever see this again.
Pls let me know if you ever see this again.