Litchi - Testing Panoramas
For the first time, early this morning, I tried using Litchi for taking Panoramas.
What one should appreciate with panoramas is that the automated taking of the necessary images for a panorama was available in Litchi long before it was released in Go4 with DJI Firmware. DJI held off introducing until they also added the image stitching (in app and medium res initially, and on-board and hi-res with the M2P and M2Z).
Remember: Litchi only takes the images. You will need to stitch them yourself. But, pre M2P/M2Z, you needed to do this anyway to get a hi-res panorama, and even with those two models you can get an even higher res panorama if you stitch the source images … but one way too large to be hosted anywhere, so perhaps only relevant if someone wanted to process the RAW images before stitching..
The first difference - Speed.
Having Litchi take these image groups in order to create a panorama (via the drone’s API … rather than being done by the on-board DJI Firmware) is an interesting comparison…
DJI’s firmware just chugs through the 34 direction/tilt combinations (for a full 360 pano) quite quickly … barely pausing in each position - probably because it knows it’s own position/heading/tilt precisely at all times, and can just get on with it.
Litchi, on the other hand, seems to wait much longer for the drone to get into the next heading/tilt position … possibly/perhaps/probably because
- it has to wait for the drone to feed back this data and check it before taking the next photo
- adding in a long enough pause to ensure movement has ceased
- waiting for writes to the SD card to complete before moving on.
(See notes on defining your panorama below in regard to Delay settings.)
So I’d imagine that, where things in view are moving (@callum’s wind turbines, yesterday, for instance), would probably have far more “fly away props” created in the stitching than using the faster Go4 and on-board firmware.
I should have compared jpeg only … I was (and always do) taking jpeg+RAW … to see if this also impacted the speed … particularly if it was waiting for any writing to SD Card to complete before moving on.
The second difference - The interface.
There are two buttons on Android, (three on iOS - see at the end of the post.).
The top button does a default 360 pano of 21 images - but the tilt never goes above +0°, the horizontal. (Go4/firmware 360s also uses the higher tilt angle of +30°.)
The second button lets you “define” your panorama.
Now, to be honest, it was only +3°C … and I didn’t hang about long enough to investigate all these settings far beyond the obvious ones, let alone try them all.
Settings 1 - You can scroll these settings continuously [next 3 images], they are not in pages. (I wish they were in pages, less likely to accidentally change a setting as you scroll.)
Width = angle between ends of the panorama - 360° for completing a full panorama in the horizontal plane. (Needs clarification for <360° … just drone rotation or “left of left image to right of right image”. I believe the amount of drone rotation - so there will probably still be an overlap even at 345°, for instance.)
Columns = How many images at the horizontal (+0°) tilt. (8, in the screenshot, means one every 45° of rotation.) Also see Grid Pattern, below.
Height = This is a tricky one to fully grasp. Yes - it’s the height of the panorama in °, but where this measurement is from is less simple.
If you are taking a more normal panorama (say, 3 wide and two high), without the straight down shot, this height is centred on the gimbals tilt as the panorama is initiated. So - if your camera is set to -25° as you initiate a pano with height set to 80°, it will take pics that cover from -65° to +15°.
If you are including a straight down shot, it’s measured upward from the straight down. 120° is max range (straight down to +30° above the horizontal. So - 90° would be up to the horizon, etc.
START - nn PHOTOS = nn changes as you change the various parameters. Clicking it initiates the taking of the panorama images.
This is fixed in position, Only what is above it scrolls.
Rows = Number of image rows - (not including the “straight down” shot @ -90°).
(4 in the screenshot means ones at -60°, -30°, +0° and +30°.)
Nadirs = Straight down shots at -90°. (Sets to zero for width < 360° or Columns = 1)
Grid Pattern = Spherical or Linear.
Linear - you get as many images on each Row as the number of Columns
Spherical - you get as many images on the +0°/horizontal row as the number of Columns, but in the rows below (and the one above if in use) will have increasingly fewer on each row that ensures the same amount of overlap … but reduces the number of images needed.
Capture Strategy - Row by Row or Column by Column … just personal preference, really … although, if one wanted to minimise ghosting (Callum’s unattached blade, above) this could be used … depending on which way any objects are moving. I’ll leave you to work that one out.
(One thing I have discovered, as a result of the images not being grouped by panorama, if the images are row-by-row, it’s far easier to detect the starting image of each panorama sequence, that being 8 sky images … and ending with the straight down.)
Delay Before / After each Photo - This could be useful … and I can think of one instance where I could have used this to good effect. I’ll need to re-do that one.
And, finally, yes - the number of photos does change with settings …
The Pros and Cons
Pro - How many images / layout/ percentage of a full sphere / image overlap / timing / sequence - all definable.
Con - In the default 360, the camera only goes up to the horizon.
Con - It’s something else to buy, and it’s not why I (or most people) would buy it - that’s for Waypoint Missions. (But that is a massive Pro for Litchi!)
Con - Exhuming a few hundred images from your SD Card and sorting them into groups that relate to each panorama.
Third button on iOS
On iOS there’s a third Folder icon button between the Default Pano button the Pano Settings button - which I believe gives you a history (of some sort) of the panoramas that you’ve taken.
The Panoramas? The results??
Well - I was out early for Sunrise photos … DSLR and Drone … but the sky was white and overcast, and the low sun through the mist meant half the sky was really bright and the rest just featureless.
Whatever the shortcomings (mainly res) of the DJI panorama function on pre M2P/M2Z drones, stitching is not one of them.
Along with the images it saves are a load of .xml files that record the camera’s precise orientation at the time each image was taken, and it uses this information to do a damned good initial image alignment exercise, and then normal alignment by image analysis for the best possible stitch.
This actually means you can take a 360 pano in fog, and it will stitch all the images in the correct relative position and orientation - and it will look perfect! (Hell - there won’t be any detail to know it’s not! ).
But - when it comes to using other software to stitch, and depending on which one used, the first pass is by image analysis and then, depending on the software, human tweaking.
This morning’s images were never going to be interesting, that wasn’t the point of the exercise - but I had hoped to get something from them. The ground is all OK … anything above (and slightly below) the horizon just wasn’t working (in ICE) though. So - another excursion needed for some examples.
Which reminds me - I need to write my How to on rescuing panoramas that seem incapable of stitching.
If I think of anything else, or learn any more from my next couple of testing sesstions, I’ll edit and make a note at the bottom, here, as to what I’ve changed/added/deleted.