From 9310b715ac67d09718cf86743b9c0f11b45d851b Mon Sep 17 00:00:00 2001 From: Chris Hodapp Date: Wed, 5 Oct 2016 16:39:05 -0400 Subject: [PATCH] A few more links on Pi pan tilt part 2 --- posts/2016-10-04-pi-pan-tilt-2.md | 58 +++++++++++++++++++------------ 1 file changed, 36 insertions(+), 22 deletions(-) diff --git a/posts/2016-10-04-pi-pan-tilt-2.md b/posts/2016-10-04-pi-pan-tilt-2.md index ae10b19..011cac6 100644 --- a/posts/2016-10-04-pi-pan-tilt-2.md +++ b/posts/2016-10-04-pi-pan-tilt-2.md @@ -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