Pi pan tilt, first two parts: fixed some links, updated titles

posts/2016-09-25-pi-pan-tilt-1.md

@@ -1,5 +1,5 @@
 ---
-title: Raspberry Pi pan-tilt mount for huge images, part 1
+title: Pi pan-tilt for huge images, part 1: introduction
 author: Chris Hodapp
 date: September 23, 2016
 tags: photography, electronics, raspberrypi
@@ -91,7 +91,7 @@ produce:
 
 [![](http://i.imgur.com/zwIJpFn.jpg){width=100%}](http://i.imgur.com/zwIJpFn.jpg)
 
-More posts will follow soon on this!
+Follow along to [part 2](./2016-10-04-pi-pan-tilt-2.html).
 
 [cs6475]: https://www.omscs.gatech.edu/cs-6475-computational-photography
 [ArduCam]: http://www.arducam.com/camera-modules/raspberrypi-camera/

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

@@ -1,5 +1,5 @@
 ---
-title: Raspberry Pi pan-tilt mount for huge images, part 2
+title: Pi pan-tilt for huge images, part 2: Hugin & PanoTools integration
 author: Chris Hodapp
 date: October 4, 2016
 tags: photography, electronics, raspberrypi
@@ -44,20 +44,22 @@ 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
+If we look at the [PTO file format][pto] (which Hugin & PanoTools use)
-use), it has pitch, yaw, and roll for each image.  Pitch and yaw are
+in its i-lines section, it has pitch, yaw, and roll for each image.
-precisely the axes in which the steppers move the camera (recall the
+Pitch and yaw are precisely the axes in which the steppers move the
-pictures of the rig from the last post); the roll axis is how the
+camera (recall the pictures of the rig from the last post); the roll
-camera has been rotated.  We need to know the lens's angle of view
+axis is how the camera has been rotated.  We need to know the lens's
-too, but as with other parameters it's okay to just guess and let the
+angle of view too, but as with other parameters it's okay to just
-optimization fine-tune it.  The nominal focal length probably won't be
+guess and let the optimization fine-tune it.  The nominal focal length
-exact anyhow.
+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
+grid in which I shot images.  All that's needed is to add up the steps
-convert steps to degrees, which for these steppers means using 360 /
+taken to reach each shot, convert steps to degrees, which for these
-64 / 63.63895 = about 0.0884, according to [this][steps].
+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
@@ -110,11 +112,6 @@ 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
@@ -129,4 +126,4 @@ TODO:
 [hive13]: http://hive13.org/
 [projection]: http://wiki.panotools.org/Projections
 [szeliski]: http://szeliski.org/Book/
-[pto]: ???
+[pto]: http://hugin.sourceforge.net/docs/manual/PTOptimizer.html