New Xiaomi Mi Panoramic 360 Camera


@tryl I was thinking the same but do not know how to extract this info from the jpeg’s. I’ve made a zip file containing 2 images. The original from the Mi Sphere and the same images but stitched. The stitched one also has this curved horizon. Do you have ways to find out whether this theory is correct? Thanks in advance


The exif standard is easy to find.


@peewee32 Thanks for posting that sample. I managed to combine the original images into a single one for Mapillary using Hugin, which means I can script it on Linux.

Basically using circular fisheye as the source projection, 180 degree FOV, a circular crop to use only what you see through the lens, and 0/180 degrees for the yaw values (forward and backwards).


I don’t se the human readable tags that Ricoh uses. But there is some binary stuff in the user comment field. That could contain the data. If that is correct they have chosen a pretty voulnable way to store the info. It only takes the tiniest error between camera and the software that reads it, to get a huge error. Because the image is pretty level from the beginning, you could (if possible) disable correction or use the method @andrewharvey used: Would you post a more detailed explanation? I run Linux too, and even Windows users might get a much better workflow from this method.


@tyrl Sorry I haven’t put together a detailed process as I don’t have this camera so don’t have a need just yet, but I was interested in first finding out if it can be used without running Windows. Based on my tests you can use Hugin to stitch the two fisheye images together into an equirectangular single image panorama for upload to Mapillary, just like their Windows software does. It’s much easier to do it first in Hugin, then export the scriptable version so it can be run in batch on a sequence of photos.

In Hugin you can set the roll & pitch which might account for a tilted camera but I’m not sure. Either way you need the orientation of the camera.


Thanks Andrew and Tryl. The scripting with Hugin seems very interesting. Not only because the desktop software is not able to handle many photos in one instance but also because I need to correct the roll & pitch which are wrong on most images. I use python scripts for adding location and GPSImgdirection so one more script for stitching does not seem so bad. Hopefully the scripts can handle large numbers. If any body has gotten any further with a Hugin script for this camera I would appreciate some info on this.

On the Xiaomi facebook group some people have posted Hugin templates. Here’s one. Not sure if this is any use to someone. I myself am not familiar with Hugin.

Today I also found out I was not using the latest desktop software. I found this out because of this site with Mi Sphere resources. The latest version does not crash so fast but it still crashed. I was able to stitch 617 out of the 2144 total before it crashed. The version does not have any settings to control/overrule the pitch/role so still not much of use for photos taken from the camera fixed to my velomobile.


That’s very helpful! Saves everyone else from tying to find the correct Hugin parameters for this camera. I had to split the source image into a left (D1) and right (D2) but apart from that, the Hugin template worked perfectly!


Ruben Frosali posted on facebook and supplied a link for a template on github. This template should be able to work on just 1 image and there is no need for cutting. I can not get it to work in the Hugin desktop version.

I loaded 1 image and applied the template but all I see is just 2 circles in the image. Just like the original.
Can you try and see if this works?

Next step would be batch processing images.


I used the template and uploaded the result in Mapillary
It’s pretty good. I used Geosetter for set GPS location with the trace gpx of my Garmin.

With Hugin the assembly is very slow, but it works.
It takes about 14 seconds to process an image with my GPU (GTX770) or 15 seconds with my CPU (i5-4670K).

My batch file:

DIR /B /A-D *.jpg >fichiers.txt
for /f "delims=" %%i in ('type fichiers.txt') do (
ren %%i image.jpg
hugin_executor --stitching .\template-XiaomiMijiaMi.pto --prefix image-finish.jpg
ren image-finish.jpg %%i
del image.jpg
del fichiers.txt


@nfrery Thanks for posting. The images look good.

With a little luck I do not need to go the Hugin way because I’ve come a little further. The PC app has a setting that checks/unchecks the gyro option. I’ve tried this several times but his did not seem to solve the strange stitching. In the latest version of the software however it does work. When I uncheck this the horizon is level. Not only that but the app was also capable of processing more than 2000 images without crashing. Now all I had to do was add GPS info to the images and upload to Mapillary. Unfortunately the Mapillary python scripts do not work on these images. I don’t know why they work on images of the xiaomy yi and don’t on the Mi Sphere. So I did this step with fotogeotag tool by javawa. Then I tried uploading with python script as usual. This seemed to work (although I get a lot of messages saying “HTTP ERROR 400: bad request in images xxxxxxx.jpg” ). mapillaryscript

Finally al photos are uploaded but the scripts ends with “Success : 0 , Failed: 0”. So this also does not seem to work with images from this camera. I then uploaded via the website. No problem there but this is not very handy for large numbers. I hope the Mapillary team will put some effort in enhancing the processing script for photos taken with action- and 360 cams. A flawless GUI for Windows users is more than welcome.

Here is an example sequence.

When a photo is shown the first time it is a low resolution one. You have to wait a few seconds (probably depending on speed of internet connection) before the high resolution one is shown and it looks like you have to pan or zoom for this to happen. It looks like it takes longer with these Mi Sphere photos before the high resolution one is shown. Although I have a high speed internet connection it sometimes takes 5 seconds before high resolution is shown. So don’t judge the quality of these images on first glance.


In the facebook group of the Mi Sphere Jason Wang wrote : " Dear all, the in-camera stitching will be an optional feature in the next APP release. It is ready in the this FW version but the adapted APP is coming later."

The latests firmware of the camera (not available in google play yet) still has the timelapse error that the interval is a few seconds longer than indicated.


After reading this thread I decided to buy this camera. Image quality compared to theta m15 is awesome.
Had some problems with stopping interval shooting. After pressing, camera stops shooting after … longer time. Didn’t have time to watch during drive.
And I hope they fix interval shooting. As stated before, 2 sec is ±3.8 sec. As if timer start counting after image saved, not after image taken.

To compare “same” spot.
theta m15:

Stitched in hugin with script from
Official app had problem with the gyro setting, but I didn’t try now latest version with fixed gyro setting.

With this image quality and price it is a very good camera.


Great there’s more of us with this camera. This will help overcome problems. I’ve just made a brief video on how you can contribute to mapillary with this cam. I know there are more ways but this might be the easiest for some.
The python scripts are causing problems for me so I decided to upload via web interface. I’ve had uploads with over 1000 images without problems.


you can upload more than 1000 photos per upload. however theres an issue, where ever you preview a photo in the sequence, it will always go to the first image in the sequence.
nice video, keep them coming. sounds like the cheapest 360 solution around


OK I have finally got around to testing this camera out, see (excuse the thumb smudge on the lens).

It’s pretty easy to use and like everyone else it took a photo every 4 seconds even though I set it to 2 second interval.

I was using the app to add location to each image, but this is not working very well, as the location is only updating every 12 seconds or so which bunches the images up together on the map, so I have had to manually correct these, I guess I will need to run a separate GPS tracker app and then add to the images afterwards, any recommendations?

Also I used the Xiaomi PC app to batch stitch the images and it seemed to work OK! :slight_smile:

I am really happy with the image quality and if Xiaomi can sort out the location data then it will be almost perfect!


Thanks for posting! Quality looks similar to the LG360

On Android:
On Linux:


I also own the LG360 but this Mi Sphere image quality is really a lot better

I correlate my images to a recorded GPX file with fotogeotag.
Very intuitive. If you have your camera 90 degrees rotated (for better aerodynamics and less visibility) you can change this in the program setting. You can also have it set the image direction based on GPX. This is needed for Mapillary.

I’ve also noticed that the GPS recording is wrong. I’ve reported this to Jason Wang of Xiaomi who is active on facebook in the mi Sphere group.
He did a little customer satisfaction survey. This is what I reported.

  1. The photo interval time is incorrect. 2 seconds is like 4 and 5 is like 7 seconds.
  2. If I select 2 second interval mode I expect the camera to store this setting but when I restart my camera it is not in interval mode. I have to use my smartphone again to set it to interval mode. So please have the camera remember all settings when it shuts down. (like the xiaomi Yi action camera)
  3. When the camera is placed on a moving vehicle and it is in photo interval mode the gyro registration is wrong. I guess the sensor is very sensitive to little shocks of the vehicle. I did not experience this problem with my LG360 camera. See this example and try to pan. You will see what I mean. If this can not be corrected I would like to see the PC app have the option to overwrite pitch , roll and yaw when stitching.
  4. Location registration is wrong sometimes. See the bug I reported on Facebook. “I have a GPS bug but have not reported it yet because I thought it might be caused by the interval bug. Here is a sequence I shot in 2 second interval (which is more like 4) using GPS function of the app. You can jump from one image to the next with the little arrows in the picture. The issue is that it seems like 2 photos are located on the same spot. If you jump to the next it does and the next time you jump it stays on the same spot. So every 2 consecutive photos are on the same spot. So instead of the more or less expected 4 seconds between the dots there is now 8 seconds. That is odd but as said it might have to do with the interval bug.”
    I have used the interval mode without GPS on. In post processing I add location from my garmin GPS to all photos based on timestamp. That worked just fine so the time registration seems OK. It is just the GPS location that is sometimes wrong.


Thanks @andrewharvey and @peewee32 this is really useful.

I think the image quality is better, but you might need to zoom in on the image and wait a few seconds to see it. It certainly should be better as the resolution is higher than the LG360 :slight_smile:


Small test in forest. Cloudy, no direct sunlight. Tested fixed ISO and/or fixed shutter speed.
Light conditions were not optimal, so some images don’t look good.

And I tried turning the camera (lens to side, not forward).
No rain, but was quite misty. Car’s windscreen was wet in seconds. Camera lens without a drop of water for longer time.
(After this sequence, first drop appeared.)

Now I am waiting when they fix time interval error (+2sec)
And if somebody didn’t know, camera now saves images as JPG or DNG (RAW).


So it saves in RAW! Now, that is a killer feature, because it makes it possible to fine tune the images much better. I had decided to not upgrade my Theta S this time, but this might just chance my mind.

@kaylesk will you post a raw file so I can try to play with it and see how much extra information it contains?