---
title: Raspberry Pi pan-tilt mount for huge images, part 2
author: Chris Hodapp
date: October 4, 2016
tags: photography, electronics, raspberrypi
---

In my [last post](./2016-09-25-pi-pan-tilt-1.html) I introduced some
of the project I've been working on.  Those of you who thought a
little further on this might have seen that I made an apparatus that
captures a series of images from fairly precise positions, and then
completely discards that position information, hands the images off to
[Hugin][] and [PanoTools][], and has them crunch numbers for awhile to
calculate *the very same position information* for each image.

That's a slight oversimplification - they also calculate lens
parameters, they calculate other position parameters that I ignore,
and the position information will deviate because:

- Stepper motors can stall, and these steppers may have some
  hysteresis in the gears.
- My pan and tilt axes aren't perfectly perpendicular.
- The camera might have a slight tilt or roll to it.
- The camera's [entrance pupil][] may not lie exactly at the center of
  the two axes, which will cause rotations to also produce shifts in
  position that they must account for.  (More on this will follow
  later.  Those shifts in position can also cause parallaxing, which
  is much more annoying to account for.
  [No, it's not the nodal point. No, it's not the principal point.][npp])

That is, the position information we have is subject to inaccuracies,
and is not sufficient on its own.  However, these tools still do a big
numerical optimization, and a starting position that is "close" can
help them along, so we may as well use the information.

Also, these optimizations depend on having enough good data to average
out to a good answer.  Said data comes from matches between features
in overlapping images, say, using something like [SIFT][] and
[RANSAC][].  Even if we've left plenty of overlap in the images we've
shot, some parts of scenes can simply lack features like corners that
work well for this (see chapter 4 of
[Computer Vision: Algorithms and Applications][szeliski] if you're
really curious).  We may end up with images for which optimization
can't really improve the estimated position, and here a guess based on
where we think the stepper motors were is much better than nothing.

If we look at the [PTO file format][pto] (which Hugin & PanoTools
use), it has pitch, yaw, and roll for each image.  Pitch and yaw are
precisely the axes in which the steppers move the camera (recall the
pictures of the rig from the last post); the roll axis is how the
camera has been rotated.  We need to know the lens's angle of view
too, but as with other parameters it's okay to just guess and let the
optimization fine-tune it.  The nominal focal length probably won't be
exact anyhow.

Helpfully, PanoTools provides tools like `pto_gen` and `pto_var`, and
I use these in my script to generate a basic .pto file from the 2D
grid in which I shot images.  The only real conversion needed is to
convert steps to degrees, which for these steppers means using 360 /
64 / 63.63895 = about 0.0884, according to [this][steps].

With no refining, tweaking, or optimization, only the per-image
stepper motor positions and my guess at the lens's FOV, here is how
this looks in Hugin's fast preview:

[![Hive13](../images/2016-10-04-pi-pan-tilt-2/hugin-steppers-only.jpg){width=100%}](../images/2016-10-04-pi-pan-tilt-2/hugin-steppers-only.jpg)

*(This is a test run that I did inside of [Hive13][], by the way.  I
used the CS-mount [ArduCam][] and its included lens.  Shots were in a
14 x 4 grid and about 15 degrees apart.  People and objects were
moving around inside the space at the time, which may account for some
weirdness...)*

Though it certainly has gaps and seams, it's surprisingly coherent.
The curved-lines distortion in Hugin's GUI on the right is due to the
[projection][], and perfect optics and perfect positioning information
can't correct it.  Do you recall learning in school that it's
impossible to put the globe of the world into a flat two-dimensional
map without distortion?  This is exactly the same problem - which is
likely why Hugin's GUI shows all the pictures mapped onto a globe on
the left.  That's another topic completely though...

Of course, Hugin pretty much automates the process of finding control
points, matching them, and then finding optimal positions for each
image, so that is what I did next.  We can also look at these
positions directly in Hugin's GUI.  The image below contains two
screenshots - on the left, the image positions from the stepper
motors, and on the right, the optimized positions that Hugin
calculated:

[![Hugin comparison](../assets_external/2016-10-04-pi-pan-tilt-2/hugin-comparison.png){width=100%}](../assets_external/2016-10-04-pi-pan-tilt-2/hugin-comparison.png)

They sort of match up, though pitch deviates a bit.  I believe that's
because I shifted the pitch of the entire thing to straighten it out
(or perhaps it did this automatically to center it), but I haven't
examined this in detail yet.

A full-resolution JPEG of the result (after automated stitching,
exposure fusion, lens correction, and so on), is linked below:

[![Hive13 full](../assets_external/2016-10-04-pi-pan-tilt-2/hive13-20161004-fused-smaller.jpg){width=100%}](../assets_external/2016-10-04-pi-pan-tilt-2/hive13-20161004-fused.jpg)

It's 91 megapixels. The full TIFF image is 250 MB, so understandably,
I didn't feel like hosting it, particularly when it's not the
prettiest photo or the most technically-perfect one (it's full of lens
flare, chromatic aberration, overexposure, noise, and the occasional
stitching artifact).

However, you can look up close and see how well the details came
through - which I find pretty impressive for cheap optics and a cheap
sensor.

TODO:

- This was done completely with a raw workflow, blah blah blah
- How did I wire the steppers, vs. how does Hugin see things?

[ArduCam]: http://www.arducam.com/camera-modules/raspberrypi-camera/
[forum-raw-images]: https://www.raspberrypi.org/forums/viewtopic.php?p=357138
[raspistill]: https://www.raspberrypi.org/documentation/raspbian/applications/camera.md
[25mm-lens]: https://www.amazon.com/gp/product/B00N3ZPTE6
[Hugin]: http://wiki.panotools.org/Hugin
[PanoTools]: http://wiki.panotools.org/Main_Page
[entrance pupil]: https://en.wikipedia.org/wiki/Entrance_pupil
[npp]: http://www.janrik.net/PanoPostings/NoParallaxPoint/TheoryOfTheNoParallaxPoint.pdf
[steps]: https://arduino-info.wikispaces.com/SmallSteppers?responseToken=04cbc07820c67b78b09c414cd09efa23f
[SIFT]: https://en.wikipedia.org/wiki/Scale-invariant_feature_transform
[RANSAC]: https://en.wikipedia.org/wiki/RANSAC
[hive13]: http://hive13.org/
[projection]: http://wiki.panotools.org/Projections
[szeliski]: http://szeliski.org/Book/
[pto]: ???
