# Feature request: Full support for Google Photospheres and "Panoramas" **URL:** \ **Category:** Smartphones\ **Created:** [October 2, 2023, 1:39pm UTC](https://forum.mapillary.com/t/feature-request-full-support-for-google-photospheres-and-panoramas/7453 "2023-10-02T13:39:44Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![enteq](https://avatars.discourse-cdn.com/v4/letter/e/dec6dc/32.png) [@enteq](https://forum.mapillary.com/u/enteq)\ **Post date:** [October 2, 2023, 1:39pm UTC](https://forum.mapillary.com/t/feature-request-full-support-for-google-photospheres-and-panoramas/7453/1 "2023-10-02T13:39:44Z")
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: > **[Mapillary](https://www.mapillary.com/app/?pKey=135770112300168)** > > Street-level imagery, powered by collaboration and computer vision. Are there any plans to properly support this? ```auto 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 ``` [https://exiftool.org/TagNames/XMP.html#GPano](https://exiftool.org/TagNames/XMP.html#GPano) ---
**Author:** ![GITNE](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/gitne/32/70659_2.png) [@GITNE](https://forum.mapillary.com/u/GITNE)\ **Post date:** [October 2, 2023, 2:38pm UTC](https://forum.mapillary.com/t/feature-request-full-support-for-google-photospheres-and-panoramas/7453/2 "2023-10-02T14:38:15Z")
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. ---
**Author:** ![enteq](https://avatars.discourse-cdn.com/v4/letter/e/dec6dc/32.png) [@enteq](https://forum.mapillary.com/u/enteq)\ **Post date:** [October 2, 2023, 3:25pm UTC](https://forum.mapillary.com/t/feature-request-full-support-for-google-photospheres-and-panoramas/7453/3 "2023-10-02T15:25:26Z")
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? ---
**Author:** ![GITNE](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/gitne/32/70659_2.png) [@GITNE](https://forum.mapillary.com/u/GITNE)\ **Post date:** [October 2, 2023, 3:47pm UTC](https://forum.mapillary.com/t/feature-request-full-support-for-google-photospheres-and-panoramas/7453/4 "2023-10-02T15:47:51Z")
> Should I do this? You do not have to but you can always experiment. 😉 > I fear it will uselessly degrade the original image quality… No. > …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. ---
**Author:** ![enteq](https://avatars.discourse-cdn.com/v4/letter/e/dec6dc/32.png) [@enteq](https://forum.mapillary.com/u/enteq)\ **Post date:** [December 18, 2023, 5:15pm UTC](https://forum.mapillary.com/t/feature-request-full-support-for-google-photospheres-and-panoramas/7453/5 "2023-12-18T17:15:39Z")
> [@GITNE](#): > > 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). This was called “cropped” panorama. I found where it was removed: > > > \## Motivation > > Remove unused functionality. > > \## Contribution > > \### Remove > …\* Spatial configuration > \* Connected components property > \* Positions visible property > \* Mouse component > \* Double click zoom handler > \* Components > \* Background > \* Debug > \* Route > \* Cropped panorama support > \* GPano functionality > \* Node > \* Full pano property > \* Pano property > \* GPano property > > \## Test Plan > > \`\`\` > yarn prepare > yarn test > yarn start > \`\`\` > 1. Manual interaction with viewer. Very unfortunate 🙁 ---
**Author:** ![GITNE](https://sea1.discourse-cdn.com/flex015/user_avatar/forum.mapillary.com/gitne/32/70659_2.png) [@GITNE](https://forum.mapillary.com/u/GITNE)\ **Post date:** [December 18, 2023, 6:09pm UTC](https://forum.mapillary.com/t/feature-request-full-support-for-google-photospheres-and-panoramas/7453/6 "2023-12-18T18:09:47Z")
Yeah, I would have also loved to see OpenSfM improved (project cropped panos on full spheres) in this regard rather than having good existing functionality removed from mapillary-js.