When uploading .360 video with Mapillary uploader, it uploads at 1 frame per second. This doesn’t cause much trouble up to speeds of 20-30 km/h, but on large streets where minimum speeds are higher, the distance between photos becomes much greater.
With my GoPro Max 2, I can get 10 frames per second. This significantly reduces the distance difference at high speeds, but at lower speeds, the photos are very close together. Is it possible to adjust the upload sequence to filter out photos like in Panoramax if the distance between two photos is less than ‘x’?
Or do I need to apply manual filtering before uploading?
Sub B_BatchReduceGPX_XML() ' === Default-Einstellungen / Parameter Insta 360 === Const REDUCE_FACTOR As Long = 10
I’ve found the following reduction factors:
Insta360 requires a reduction by a factor of 10
OSMO360 requires a reduction by a factor of 28
I currently lack experience with the Max 2.
Thank you. I can manually reduce the GPS track points, but I wanted to know if it’s possible to perform a bulk cropping during upload without additional filtering.
Hello, burakonder based on my experience, reducing the GPX density before uploading significantly simplifies the prior correction of GPX outliers and errors. Once a GPX track is uploaded, further corrections are hardly possible.
@GITNE You’re right, when uploading .360 video directly, you don’t need external GPX data, but uploading this way outputs 1 frame per second. Since GoPro GPS data records at 10Hz, we can successfully match it to 10 frames per second by extracting the GPX data from the video.
Of course, drive at 100 km/h on the highway won’t do any good, but unfortunately, you can’t drive on a trunk highway at 20-30 km/h either.
Last year I drove thousands of kilometers on the German Autobahn, and driving behind trucks is unacceptable for an amateur cartographer. Driving in the passing lane there is dangerous at anything under 110 km/h. A good mix in Germany is 120 to 160 km/h, and you make good progress. I’m aware that you have to accept gaps in traffic sign recognition in the passing lane. The solution is simply to trust that you’re not the only one creating Street View images there. It would be particularly helpful to get more truck drivers to participate in Mapillary.
@osmplus_org My intention may have been misunderstood. From a driving safety perspective, I find 360° shots risky at speeds above 100 km/h due to the potential for adverse situations with vehicle-mounted suction cups. Therefore, in Turkey, I only take 360° shots on streets and trunk roads where the maximum speed limit does not exceed 100-110 km/h.If I’m driving on a motorway, it only records footage from inside the vehicle.
@GITNE Of course, I shoot at minimum speeds and in the slower lane, as far as the road allows. However, sometimes, for various reasons, it’s necessary to exceed the legally mandated minimum speed limits to avoid compromising traffic safety.
In such cases, to compensate for the long distances between photos, instead of using timelapse photos, I shoot in 25fps video mode and then split it into frames. The timelapse photo limit is insufficient because it only allows one photo every two seconds.
@burakonder - you do not need to “split it into frames” - Mapillary will do that for you on the backend (and will automatically sample at 1 frame every 3 meters). So if you just upload the .360 video file directly, everything should “just work”
You can use my program for changing the sampling rate (standard 3.0 meters like boris mentioned). Sometimes it’s better to go lower (on foot/bike/slow speed car), other times you want bigger distances (high speed, rural area without any markers/traffic signs).
It’s especially made for the GoPro Max 1 and 2 for easy processing (only setup the maps, username and the other settings) and click process. It’s also possible to make StreetviewStudio ready files and nadir support is also present.
@burakonder - thank you for reporting this. This behavior is not expected, we’re going to look into it to see why this is happening. Thanks @Yaro for taking a look.
It is the same effect I have already reported earlier; some EAC projection faces exhibit high compression ratio artifacts when converted by the backend to equirectangular projection. @yaro The mystery is solved. The effect does not come with the video stream but is caused by Mapillary’s conversion/re-projection step.
Hi @burakonder, thanks for the example. It looks like the quality drops specifically here and then in the area with bad quality, and we’re back on track from this point. If I am not mistaken, the problem is with in the back camera stream only. First noticed by @GITNE long time ago I will check there’s nothing else hidden.
In any case, I will let you know when it is gone for good.
I will check there’s nothing else hidden.
The effect is visible on the top, back, and bottom EAC faces.