hodapp/blag
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

A few more links on Pi pan tilt part 2

Browse Source
This commit is contained in:
Chris Hodapp 2016-10-05 16:39:05 -04:00
parent 3aaffefc87
commit 9310b715ac
1 changed files with 36 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

58
posts/2016-10-04-pi-pan-tilt-2.md
View File

@ -6,12 +6,16 @@ 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.
of the project I've been working on. This post is a little more
technical; if you don't care, and just want to see a 91 megapixel
image from inside [Hive13][], skip to the end.
Those of you who thought a little further on the first post 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,
@ -19,14 +23,19 @@ 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 pan and tilt axes aren't perfectly perpendicular.
- The camera might have a slight tilt or roll to it due to being built
that way, due to the sensor being mounted that way, or due to the
whole assembly being mounted that way.
- 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])
position that they must account for.
([No, it's not the nodal point. No, it's not the principal point.][npp]
More on this will follow later. Those shifts in position can also
cause parallaxing, which is much more annoying to account for. To
get what I mean, close one eye and look at a stationary item in the
foreground, and then try to rotate your head without the background
moving behind it.)
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
@ -53,13 +62,13 @@ 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. All that's needed is to add up the steps
taken to reach each shot, convert steps to degrees, which for these
steppers means using 360 / 64 / 63.63895 = about 0.0884 (according to
[this][steps]), and making sure that the positive and negative degrees
correspond to the right direction in each axis.
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. All that's needed is to add up the
steps taken to reach each shot, convert steps to degrees, which for
these steppers means using 360 / 64 / 63.63895 = about 0.0884
(according to [this][steps]), and making sure that the positive and
negative degrees correspond to the right direction in each axis.
With no refining, tweaking, or optimization, only the per-image
stepper motor positions and my guess at the lens's FOV, here is how
@ -105,13 +114,16 @@ exposure fusion, lens correction, and so on), is linked below:
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).
flare, chromatic aberration, overexposure, sensor 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
through - which I find quite impressive for cheap optics and a cheap
sensor.
Further posts will follow on some other details, and hopefully other
images!
[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
@ -127,3 +139,5 @@ sensor.
[projection]: http://wiki.panotools.org/Projections
[szeliski]: http://szeliski.org/Book/
[pto]: http://hugin.sourceforge.net/docs/manual/PTOptimizer.html
[pto_gen]: http://wiki.panotools.org/Pto_gen
[pto_var]: http://wiki.panotools.org/Pto_var