This functionality is powered by SfM and is useful for correcting captures that were done at an angle. For example, this capture shown in the gif would normally be askew and facing the ground, and is now aligned to the horizon. The functionality will work for all images in the catalog that have been correctly processed with SfM (most images). It is on mapillary.com only at the moment, and will be coming to the mobile clients soon.
Let us know if you run into any issues, or have comments/thoughts.
I am happy that you are on the job. A few key points:
The example image appears to be slightly rolled to the right after horizon leveling. Perhaps this is due to SfM alignment threshold?
No horizon leveling seems to be applied to the panning coordinate system, which makes for a bit of a weird experience.
Maybe horizon leveling should not be applied on planar and fish-eye images? Looking at some other examples this latest MapillaryJS automatic horizon leveling feature on severely tilted planar and fish-eye images gives mixed results, probably depending on SfM’s ability to reconstruct a camera pose.
AHL breaks here, probably due to lack of sufficient SfM data:
However, when SfM was able to do its job the result is impressive:
Drop the AHL animation because it adds no value to the user but just makes seasick. It also makes playback wobble.
Please add toggles for AHL and AFVR (auto forward view rotation) because users have different needs and preferences.
How long has this been out? I noticed the other day my captures done with my GoPro Max2 in single lens mode were bouncing around a lot when watching the capture. The camera was put slightly at an upward angle, because if it was flat it would capture the mount and inside of my vehicle.
@AmericanMapper - this should now be applied to all captures, so take a look at the ones you’ve uploaded on Mapillary.com and let me know if you see any issues!
It was wobbling a bit, but I think that might have been a glitch with my camera, as it evened out way better than it had been just a little bit later in the capture.
I think, I have figured out what is going on here. Your example image works correctly because SfM was able to reconstruct a camera pose for this particular image. Go to the last image in the sequence. Note that the panning coordinate system is congruent with the image’s coordinate system, not with the horizon. Compare to the second last image in the sequence.
This one is easy. Note that the image in the viewer looks slanted or rolled to the right. However, compare it to the original image through “Download image”. The original camera pose was almost perfectly aligned with the tangent plane. My guess is that SfM was able to produce a camera pose here but it did not find a sufficiently correct solution, may it be due to not triggering, insufficient runtime, no good solution, or etc.
So, I think we can make out a pattern here: SfM might need some alignment threshold adjustment or other fine tuning, including re-triggering for some images.
Initially, I did not care much for AHL in the viewer (because tilted images usually do not bother me much) but after experiencing perfectly horizon level planar, fish-eye, and 360° examples, I am really happy about it. So, kudos to the implementer! However, SfM definitely needs some more tweaking to make the experience more consistent across all images.
I am going to try to make a video but it may turn out difficult. Though, I am pretty sure it is the same effect @AmericanMapper has observed.
Great to see this! It’s a big improvement for imagery taken while walking or biking where it’s hard to keep the camera level. Or just when driving up and down hills.
Great, I was wondering if there is a way to correct my early takes with 360 camera
I have 3 sequences with extremely bad orientation due to some bad settings in Ricoh Theta:
But not everything is ideal. Play this one:
I wonder if algorithm its checking the giro sensor data and using them badly (as the camera is wobbling alot on bad pavement). Since then I started using backpack and MAX2 (thanks Mapillary!) to mount camera and its more cussioned now nad I guess the data is better.
Thank you for the positive feedback folks! I’m glad to hear the feature is working well for you
@masterofnoroad - we were able to ship some algorithm improvements, so if you play this example you provided now, things will look better (still not perfect, but a lot better than it used to be I think).
Unfortunately the other 3 examples we can’t do much with due to the quality of the source data.
Yes, that is true @une_abeille - we are testing the feature on mapillary.com first and then we will put out a new release of the MJS library which will need to be incorporated on other surfaces that display Mapillary (like the Mapillary mobile apps, iD editor, OsmAnd, etc)
I think we’re getting to close to having things stable here, so should be able to do that soon!
With my photos, the horizon levelling has been very satisfactory so far thanks to Insta360 Studio’s “Automatic horizon leveling” and ‘Stabilisation Type: Motion’ export function. Now, however, this is no longer the case at all. Here’s an example of how an exported photo looks in Insta360 Studio and after processing by Mapillary, where it is totally askew now:
@Hol_Ger - Mapillary only does a very tiny adjustment for this example, you look at the photo without the x & y values in the url (which are added when you manually rotate it) the difference is very small when you toggle off horizon alignment in settings.
You can toggle off the feature if its not working well for you (click on your avatar, go to settings). MJS and Insta360 seem to align slightly differently in this case, but I think the difference for most users will be very small.
I can’t reproduce the effect as clearly today as I could yesterday. But the middle screenshot in my comment shows that this is what it looked like. Could this be because the sequence (the photo) was still being processed?
When I switch the feature off, it looks acceptable again.
Yes, SfM processing often continues even after sequences become gray in the feed, hence there is a good chance camera poses will eventually align correctly. Sometimes, it may take a few hours, sometimes weeks. So, patience is key here.
Having said that, I have noticed that SfM often leaves out the last image in the sequence from processing. There may be some kind of loop range bug or something. Please, take a look at this.
@caglarpmeta - for when you are back, could take a look at SfM often leaving out the last image? (@GITNE if you have an example link that would be amazing)
“Leaves out” may be a bit strong or imprecise. The AHL effect seems to suggest that SfM handles the last image in a sequence differently. Try to compare to the second last or third last image in the sequence. I am unsure whether all image types or only 360° images are affected. It is just that the effect appears to be most visible on 360° images.
There is indeed something strange going on with the roll axis in MapillaryJS or SfM. Try these examples again:
This one is incorrectly rolled to the left when viewed initially (AHL does not work), despite having been captured almost perfectly level. Now, click “3D” then “Street + Spatial”. Notice how the view is rolled back to align with the image’s original roll.
This one is correctly roll and pitch level with the horizon when viewed initially (AHL works correctly), although it had been rolled when captured. After clicking “3D” then “Street + Spatial”, the image’s original roll is restored.
To quickly restore the initial view (for easier debugging), traverse to the next or previous image in the sequence and then back.
A few key points:
image appears to be slightly rolled to the right after horizon leveling. Perhaps this is due to SfM alignment threshold?
playback wobble.
So, kudos to the implementer! 
