Most phones offer the panorama function, some kind of top-and-bottom cropped 360 degree panorama.
Its advantage over traditional 360° panoramas is that it is much quicker to take (just slowly sweeping the phone in a circle), and also offers some VR/3D and audio features.
However, mapillary recognizes that it is a panorama but somehow wrongly interprets the cropped height (and possibly cropped width), leading to a weirdly stretched view:
Are there any plans to properly support this?
Cropped Area Left Pixels : 0
Cropped Area Top Pixels : 1355
Cropped Area Image Width Pixels : 8556
Cropped Area Image Height Pixels: 1638
Full Pano Width Pixels : 8556
Full Pano Height Pixels : 4278
Initial View Heading Degrees : 180
Initial View Pitch Degrees : 0
Initial View Roll Degrees : 0
Projection Type : equirectangular
Image Mime Type : image/jpeg
Audio Mime Type : audio/mp4a-latm
Image Width : 8556
Image Height : 1638
Encoding Process : Baseline DCT, Huffman coding
Bits Per Sample : 8
Color Components : 3
Y Cb Cr Sub Sampling : YCbCr4:2:0 (2 2)
Image Data : (Binary data 2280562 bytes, use -b option to extract)
Audio Data : (Binary data 242191 bytes, use -b option to extract)
Image Size : 8556x1638
Mapillary’s web app viewer used to have full GPano support. However, because OpenSfM on the backend does not this has been dropped in favor of full 360°×180° panoramas only (which is fine I guess). In other words, you need to fill the empty portion of your partial panorama with black for it to be displayed and processed properly.
Btw, just by looking at the resolution width and height numbers, your example above and the XMP printout do not seem to match anyway. So, I am not sure what you are comparing or looking at.
It’s just from a very similar example I had at hand.
I can write a script to fill the panorama, either with black, or with some interpolated filling. Should I do this? I fear it will uselessly degrade the original image quality, consume storage needlessly, and potentially confuse the SFM algorithms?
Should I do this?
You do not have to but you can always experiment.
I fear it will uselessly degrade the original image quality…
…consume storage needlessly,…
Yes, but this is negligible because it is going to be compressed very efficiently.
…potentially confuse the SFM algorithms?
You will not break anything. OpenSfM does not work on uniform color patches.