All of this segment Mapillary
But this concerns only this segment, all the other ones are fine. Maybe it would need to be recomputed or something ?
It seems OK to me? Or what is the problem you’re seeing exactly?
Look at this. Here’s the sort of compass and the edge of the photo for the bad segment:
And here they are for a good segment:
You can see that on the good segment, the FOV wedge is wide, as it should be given that I’m shooting in Max SuperView and the image is properly projected on the screen, but on the bad segment, the FOV wedge is tiny, and the image is projected like it was a regular field of view, and this issue will probably make the Mapillary model that assigns positions for objects found in photos confused, because it will think that this object that’s at the border right of the image is at let’s say 30°, but in reality it’s at 80° (yeah my bad maybe I’m not explaining it clearly actually)
I see - do you happen to have the original video/image files for those segments you could share?
Well actually I archive my videos and delete them when they’ve been uploaded, so I only have an encoded one that’s thus not the original, but here it is anyway : GX031484_encoded_CRF60_PRESET4.mkv - Google Drive
It’s encoded in AV1, so you may have to use VLC to play it
I was a bit wrong btw, this doesn’t affect all the segment, and it’s not the only group of images that are affected
There’s this image Mapillary who is affected and some others before it, but you can see that the image right after is not affected
And it’s probably linked, there’s some images like this
who are projected very weirdly in the corners ( Mapillary )
Maybe this is only affecting the GoPro Max with the Max Superview setting ? Idk cause that’s what I shot in
Interesting - strange that the projection changed mid-way through a sequence. @tao for any thoughts on how this works?
This can happen because the projection parameters for the web app viewer (MapillaryJS) are actually computed by OpenSfM during reconstruction rather than read and applied from Exif data. For OpenSfM to successfully compute projection parameters it has to
- find matching features in one or more other images
- reconstruct the camera position relative to all images in the equation (feature matching images).
Only then, after step 1 and 2 are complete OpenSfM can successfully compute projection parameters. Sometimes, OpenSfM is unable to find enough matching features in any other image in the sequence. Hence, it is also unable to compute projection parameters. In this case, OpenSfM outputs default linear projection parameters, which manifest as a plane projection surface in the web app viewer.
The wired corners can happen because sometimes the camera position or projection parameters cannot be reconstructed faithfully (the equation has no good solution) or slight error values go into the equation. By design, the equation solver is not fully deterministic because it depends on a tiny amount of randomness which can lead to slightly off results (OpenSfM chooses randomly some of the feature positions that go into the equation as values).
Having said that, @TheWonderfulTartifle you do not have to worry about your imagery get screwed up on Mapillary. Your imagery is safe, it is just that the projection parameters are off. There is a great chance that with the next OpenSfM update or sequence recomputing things will turn out better or just perfect for your sequence.
1 Like