360 imagery on Mapillary is growing! This is great news - we love being able to look in all directions, however, you may have noticed that sometimes the default view for 360 images is a bit confusing (looking to the side or behind).
We’ve released an update to automatically re-orient the 360 image view to the “front” (direction of travel). For example, when you view a 360 image like this, you’ll see a little animation turning the image to look straight ahead.
This update has been made on mapillary.com only for now and will be coming to the mobile apps and 3P users as well as an update to the mapillary-js library.
This means when you shoot 360 imagery you no longer need to point the camera lens to the front in order for your imagery to appear “front facing” on Mapillary. In fact, we generally recommend pointing cameras like GoPro MAX2 to the side to reduce wind resistance and increase clarity on the businesses and addresses to the left and right of streets.
I think you mean “reorient the view” because you do not actually reorient images. Words matter in this case specifically.
This feature looks interesting, though I am not sure what it actually solves. The current version is a bit buggy. When playing a 360° sequence the view sometimes randomly jumps around, especially when you set like a sideways view to the direction of travel. There also seems to be no UI or key-combo to disable it.
While at it, you can also add a horizon leveling toggle like requested in Nice new 360 Camera for Mapillary: PANOX V2 - #27 by salvopro because reconstruction already gives you all the horizon offset camera pose parameters. All you have to do is just update the viewing angle on the image.
By the way, high voltage pylons on the beach (on sand) in a seismic zone? Who authorizes such engineering madness? It is like begging for disaster.
Yes, correct, I meant re-orienting the view (updated in the text).
Do you have any examples you can link to where you’re seeing unexpected behavior? It should maintain your sideways perspective if you explicitly rotate the view there. Generally this is based on the direction of travel so there are some heuristics to account for imperfect GPS making this imperfect as well (but should be significantly better in the overall).
The main problem this is solving is helping users have a clearer understanding of what they’re looking at more expected behavior when using the navigation arrows as well. Generally I think for most users the most intuitive thing is for image views to start pointing in the direction of capture rather than off to the side or behind the capture direction, etc.
Got it, I think I now understand a little bit better what it is supposed to do. So, the viewing angle should only be reoriented on accessing a 360° sequence for the first time and potentially also when playing a sequence, right? However, there is something weird happening when you set a non‑forward viewing angle and then jump to some other image in the sequence using the media bar. The viewing angle is neither preserved nor reoriented to image direction (or normalized at the next image) but it looks like the initial (or maybe previews) offset is applied. It is very confusing. I think you want to have a “Reorient View to Image Direction” or “Reorient View Relative to Image Direction” toggle for this function, or something along these lines. Furthermore, you have to be clear about what you want precisely. Do you want reorienting to either image direction or normalizing on the next image?
As a general rule of thumb, I agree that when you come from no image or a planar image the viewer should display 360° images in image direction initially, unless the URL has viewing angle and zoom parameters, of course. However, should this also happen when you come from a 360° image and/or when you have set a custom viewing angle?
This also means that you should drive directly to your POI.
I regret that no osm wikipedian nor osm developer has ever done any serious work around the mapillary key. The OSMers have only been vandalising my work.
@GITNE - yes, reorientations can happen on both (when you initially load an image, and also later when the road turns for example). If as the user you manually rotate the view, that offset is preserved for the sequence (and also captured in the url).
I can’t seem to replicate what you mean by “there is something weird happening when you set a non‑forward viewing angle and then jump to some other image in the sequence using the media bar.” - do you mind maybe recording a small video?
@Lowiekse - the orange cone in the map rotates as you rotate the view, and the map is positioned to be north up, so in your screenshot you are looking north-east. Good idea that this could be made more explicit though!
The confusion comes from the animated delay when the viewing angle offset relative to the image direction is applied and sometimes that it is applied at all. Having said that, I would rather have a toggle to switch between preserving the viewing angle (old style) between images and applying viewing angle offset relative to image direction (new style). Furthermore, if you can, I would rather rid of the animation that applies the viewing angle offset relative to image direction because there is really no reason for it. The animation would only make sense to indicate that the viewing mode has changed, like when you would toggle viewing angle modes from old style to new style or when you had a toggle to rotate the viewing angle always towards image direction at playback.
In other words, some users intuitively favor a local point of reference (mainly women, new style) others favor a global point of reference (mainly men, old style).
As i like to shoot lenses left/right i was using “Equirectangular_rotate” before upload and rotated all images by 90°. Some discipline to always mount the camera the same way is needed though
@GITNE - thanks for the feedback - the animation helps give the user context that this is a 360 image view that is being rotated. Without it, its a hard jump which feels like jank and as a user you might get confused about what just happened to what you were looking at.
That being said, I’d also love to see a video screencapture of any issues you or others encounter. Thank you also for the suggestion on disabling, its something we could likely add in a future release (particularly if we see issues for some captures or users).
@flohoff - thank you for sharing. Yes, the new functionality I’m describing basically does the same thing for videos/images that were not previously rotated. Those that were already rotated should remain (correctly) as they are.
Try to go here from one side of the street to the other.
or here
To me, this feels unnatural now because a) you always have to press and b) you can no longer alternate between street sides to look down the street in the same direction (by pressing and ).
Furthermore, the navigation graph sometimes switches street sides when you press or (although it should not) and thus rotates the view in the opposite direction just because the other side of the street has naturally been captured in the opposite direction. This also means that you can no longer naturally navigate down a street or road in the same direction through continuously pressing (on whichever side of the street and regardless of whichever direction a street has been captured). Again, just because the other side of the street has been captured in the opposite direction, which is totally arbitrary.
Keep pressing here. Bonkers loop! Note also that GPS positions are perfectly aligned here, which makes it an ideal special case that should work flawlessly but it does not. Imagine a case where GPS positions are not perfectly aligned (like it is for most sequences) or the image capture direction is to the side (like you recommend to capture shop signs). Users will be even more confused. Hence, local or image direction relative view reorientation only makes sense for sequence playback or as an option.
Perfect, yes, thank you for these examples @GITNE ! Looks like we need some better handling of these types of transitions. We will get this resolved in an upcoming release. I am heading on a bit of an extended summer holiday - and will be back in the second half of August to resolve.
Thank you for your patience and thank you again for these examples!
Words matter in this case specifically.
I am not sure what it actually solves. The current version is a bit buggy. When playing a 360° sequence the view sometimes randomly jumps around, especially when you set like a sideways view to the direction of travel. There also seems to be no UI or key-combo to disable it.
Who authorizes such engineering madness? 
It is like begging for disaster.
and b) you can no longer alternate between street sides to look down the street in the same direction (by pressing 
).
or 
(although it should not) and thus rotates the view in the opposite direction just because the other side of the street has naturally been captured in the opposite direction. This also means that you can no longer naturally navigate down a street or road in the same direction through continuously pressing