You can capture using the Insta360 X3 as usual (be sure to pair the camera with phone to get GPS coordinates for your captures)
Stitch together the Insta360 X3 .insv captures to a 360 degree .mp4 file using Insta 360 Studio.
Save the exported 360 .mp4 file in the same directory as the _00_ “.insv” file with the same name. This is important because Mapillary will use the GPS information contained in the .insv file to put your capture on the map. Note: Insta 360 studio also includes the option to “Export GPX file,” however we don’t recommend using this because the fidelity of this GPX file is lower than what Mapillary can extract from the original .insv file.
Drag and drop the .mp4 file (or folder containing it) into the Mapillary desktop uploader. You’ll see a preview of the location on the map and can proceed to upload.
Let us know what you think and we hope this new process makes things a bit easier for you. Note that our recommended consumer 360 camera remains the GoPro MAX as it won’t require you to do stitching to upload to Mapillary, has built-in GPS, and is generally more affordable.
Thanks for the continue support on Insta360 X3! I’ve been following the development since last year, and it’s really impressive!
Using latest version (4.3.0) of the Uploader, I’m having some issues with GPX track: in the end, the images get a bit not-synchronized. This is my setup and workflow:
Connect phone with Insta360 X3 to get GPS (works fine)
Also collect GPX track with OsmAND in the background, with same phone (works fine)
Capture 360 video with camera (not time-lapse nor interval photos) (works fine)
Create MP4 video with Insta360 Studio (works fine)
Upload video with Desktop Uploader, either with GPX from OsmAND or with _00_.insv file (works fine)
However, since I’m driving, there are several moments that I have to stop at traffic lights etc. With that, the final result at mapillary.com have some offsets. For example, here after just 2 photos the resulted located photos are already very wrong.
I suppose there are some issues with interpolation and excluding photos at the same location, but then the final result seems very off from correct location.
Are you doing any trimming on the video file? If you are, that could explain it. The video file needs to be un-edited (unless you also edit the .GPX file to match).
If you’re not editing, could you share the .insv, .gpx, and .mp4 with us to take a look?
Hi @matheusgomesms - Thank you for providing these files! I took the .mp4 file you provided and uploaded it with the Mapillary desktop uploader. Note that you don’t need to extract .GPX from it yourself, and I didn’t use the .GPX files you provided, but rather let Mapillary handle it (from above " Save the exported 360 .mp4 file in the same directory as the _00_ “.insv” file with the same name. This is important because Mapillary will use the GPS information contained in the .insv file to put your capture on the map.")
Here is the end result, everything looks pretty well synced and I don’t seem to see a problem with this capture?
Note that the osmand .gpx file would likely cause a problem in this case because it doesn’t seem to exactly match the video. The video duration is 11:44 where as the osmand .gpx duration is 12:47 (screenshot below)
Good to know, thanks! That’s a bit weird (but good!) that it worked. I ran several tests and in all occasions there was some unsync between photos/location.
I also capture the GPX track because Insta360 app is a bit unreliable, and UL2GSV tools can trim the GPX track to match the video duration.
Anyway, I’ll run some more tests today (just using MP4 and .insv file) and I’ll let you know!
Sorry for taking a long time to answer, but I was checking properly all my data.
I saw another error (this time not Mapillary’s fault): sometimes (apparently when you stop for a bit), Insta360 X3 stop recording GPS. So, the resulting INSV files are wrong (GPS-wise), and Mapillary also becomes wrong, because is retrieving the GPX track from wrong INSV files.
I’ll try to contact them to see what could be the issue, but that was one of the reasons I recorded a separated GPX track.
(If you also wish I can send some files you could test as well).
Hi Boris,
This message just to share my experience with Insta X3
It is true that the gpx file exported via Insta 360 studio has a low coordinate density. You say that in the insv file things improve but I have the doubt that this is not the most precise way to synchronize the mp4 file. This is because there is still the need to transfer the position data from the smartphone to the camera and this process can generate delays in the position log in the insv file. For this reason I tried to record the gpx file via the orux maps app setting it to the maximum sampling frequency (1 second) then I proceed in this way (I state that I record the tracks by bicycle with insta X3 mounted on the helmet):
1- before reaching the starting point of the track to be mapped on mapillary I start recording the gpx track on orux and the video on the insta X3.
2-I reach the starting point of the mapping already at the speed that I will maintain during the recording. This is to prevent orux from starting from recording pause mode due to too low movement speed (I guess this auto pausing feature is a default set also in Osmand app and many other apps)
3-I keep the phone in view with the time shown on the screen (seconds included)
4-in post processing and with Insta 360 studio I cut the video between the start point and the end point taking note of the start time recorded directly from the video by looking at the phone.
5-in the gpx file I delete all the points before the video start time that I detected by looking at the phone at the first frame of mp4. To do this I use notepad++ because I found that if I use the compegps program the gpx file cleaned in this way is not accepted by mapillary desktop uploader.
6-I put the mp4 file and the gpx file in the same folder giving them the same name and I proceed with the upload via mapillary desktop uploader (rev.4.6.0)
From the preview of the first upload this procedure seems to have been successful. The advantage is that you don’t need great programming skills or various scripts, just Insta360 studio and a text file editor.
A question: I saw that using this system mapillary samples about one image per second or even more and this seems like a waste to me. Is this a fixed feature or by varying the speed of the bicycle or the sampling frequency of the gps points can I reduce the number of samples displayed on mapillary?
Thank you for sharing your workflow! Glad it is working for you.
In terms of sampling, mapillary samples uploaded video at 1 image very 3 meters - which is done so that there are enough frames to read store signs, house numbers, etc. It is probably too much for some use cases, but as a general purpose solution it tends to work well.
a question: but when in mapillary you load video streams associated with GPX files captured with external tools (for example oruxmap or osmand) the duration of the GPX must be exactly the same as that of the MP4? Could there be at least a few seconds of difference? Because usually the operator has a single cell phone available, first he gives the command to start video recording, then he gives the command to start GPX track. It is obvious that between one start and the other a few seconds could pass. Thanks, I was trying to understand if it is possible to upload an mp4 file, whose GPX counterpart has a few seconds of difference
@protezionecivilefvgr - with the latest version of the Mapillary Desktop Uploader (4.7) there should be an automatic sync between the timestamps in the mp4 file and the .gpx. However, for insta360 specifically, once you stitch the 360 video file, the timestamps in the video file are removed. So specifically for Insta360 the timestamps need to match exactly. Ideally you would need to start recording at the exact same time (for example by using the hardware record button on the camera, or by relying on the gps data that the insta360 app automatically generates). You can also edit the .gpx data manually later if needed.
The synchronization between orux gpx file and insta 360 video Is a bit complicated due to random delays in both systems (insta camera and the device that record the track). I found an other way to synchronize them: if no clear marks on the map like street crosses I simply do a turn or circle before the begin of Road to map. Then I cut video and gpx file in order to match by using the visual marks in the video (end of turn or Road crossing). Mandi.
I’m currently testing the use of OsmAnd GPX recordings in parallel with INSTA Remote GPX recordings. To do this, I overlay the OsmAnd GPX recording of the day with the Insta Remote GPX recording in the OpenStreetMap editor JOSM. The Insta Remote GPX sequence only serves to find the appropriate sequence in the OsmAnd daily recording. Initial tests are promising. Unfortunately, OsmAnd interrupts its recording in tunnels. At least I can connect OsmAnd to an ODB2 Bluetooth adapter via Bluetooth Low Energy. In theory, this should allow me to get vehicle telemetry data into the Mapillary recording. In OsmAnd, you can adjust the desired GPX interval; in any case, this way I can see more Insta360 X3 images in Mapillary, and the orientation of the image sequences is smoother and more stable.
It would be perfect if, in the future, you could upload a single OsmAnd GPX track recording of the day to your account as a separate Mapillary upload. Then, Mapillary could assign the matching image sequences to the corresponding image sequences based on the timestamp. Currently, recording the GPX track is one of the biggest challenges for cameras.
I generally only record videos with my Insta360 X3 and upload them to Mapillary in ProRes 422 format using the desktop uploader for the best image quality. Insta 360 allows a recording sequence duration of 30 minutes, followed by a technical interruption of around 6 seconds. I cut the resulting .inf recordings into 5.45-minute sections. With ProRes 422, this creates file sizes of around (5.45 minutes =) 50 GB each. A half-hour trip therefore means I upload around 600 GB of video data to Mapillary. Mapillary obviously only copies the parts for which there is a GXP point. This means that the Mapillary user ultimately only sees a fraction of the video data I uploaded to Mapillary. If Mapillary were to interpolate GPX points, Mapillary could also use additional images. I’m achieving a very poor target leveling factor of 0.152 in CompleteTheMap Europe However, I’m actually still uploading 25 video frames per second to Mapillary.
