update links master
authorBdale Garbee <bdale@gag.com>
Thu, 10 Sep 2020 03:06:54 +0000 (21:06 -0600)
committerBdale Garbee <bdale@gag.com>
Thu, 10 Sep 2020 03:06:54 +0000 (21:06 -0600)
bdale/blog/posts/Digital_Photo_Creation_Dates.mdwn [new file with mode: 0644]
rockets/research/2019.11.23.mdwn [new file with mode: 0755]
rockets/research/2020-test-1.mdwn [new file with mode: 0755]
rockets/research/2020.08.31.mdwn [new file with mode: 0755]
tags/tags/photography.mdwn [new file with mode: 0644]

diff --git a/bdale/blog/posts/Digital_Photo_Creation_Dates.mdwn b/bdale/blog/posts/Digital_Photo_Creation_Dates.mdwn
new file mode 100644 (file)
index 0000000..f807d05
--- /dev/null
@@ -0,0 +1,147 @@
+[[!tag tags/debian]]
+[[!tag tags/misc]]
+[[!tag tags/photography]]
+I learned something new yesterday, that probably shouldn't have shocked me
+as much as it did.  For legacy reasons, the "creation time" in the 
+[Exif](https://en.wikipedia.org/wiki/Exif) metadata attached to digital
+camera pictures is not expressed in absolute time, but rather in some
+arbitrary expression of "local" time!  This caused me to spend a long evening 
+learning how to twiddle Exif data, and then how to convince
+[Piwigo](https://piwigo.org/) to use the updated metadata.  In case I or 
+someone else need to do this in the future, it seems worth taking the time
+to document what I learned and what I did to "make things right".
+The reason photo creation time matters to me is that my wife Karen and I are
+currently in the midst of creating a "best of" subset of photos taken on our
+recently concluded family expedition to Antarctica and Argentina.  Karen 
+loves taking (sometimes
+nature photos, and during this trip she took thousands of photos using her
+relatively new
+[Nikon COOLPIX P900](https://www.nikonusa.com/en/nikon-products/product/compact-digital-cameras/coolpix-p900.html) 
+camera.  At the same time, both of us and our kids also took many photos 
+using the cameras built into our respective Android phones.  To build our 
+"best of" list, we
+wanted to be able to pick and choose from the complete set of photos taken,
+so I started by uploading all of them to the [Piwigo](https://piwigo.org/) 
+instance I host on a virtual machine on behalf of the family, where we
+assigned a new tag for the subset and started to pick photos to include.
+Unfortunately, to our dismay, we noted that all the photos taken on the P900 
+weren't aligning correctly in the time-line.  This was completely unexpected,
+since one of the features of the P900 is that it includes a GPS chip and adds
+geo-tags to every photo taken, including a GPS time stamp.  
+# Background 
+We've grown accustomed to the idea that our phones always know the correct 
+time due to their behavior on the mobile networks around the world.  And for
+most of us, the camera in our phone is probably the best camera we own. 
+Naively, my wife and I assumed the GPS time stamps on the photos taken by 
+the P900 would allow it to behave similarly and all our photos would just
+automatically align in time... but that's not how it worked out!
+The GPS time stamp implemented by Nikon is included as an Exif 
+extension separate from the "creation time", which is expressed in the 
+local time known by the camera.  While my tiny little mind revolts at this
+and thinks all digital photos should just have a GPS-derived UTC creation
+time whenever possible... after thinking about it for a while, I think I 
+understand how we got here.  
+In the early days of Exif, most photos were 
+taken using chemical processes and any associated metadata was created and 
+added manually after the photo existed.  That's probably why there are 
+separate tags for creation time and digitization time, for example.  As
+cameras went digital and got clocks, it became common to expect the 
+photographer to set the date and time in their camera, and of course most
+people would choose the local time since that's what they knew.  
+With the advent of GPS chips in cameras, the hardware now has access to an 
+outstanding source of "absolute time".  But the Nikon guys aren't actually
+using that directly to set image creation time.  Instead, they still assume 
+the photographer is going to manually set the local time, but added a 
+function buried in one of the setup menus to allow a one-time set of the 
+camera's clock from GPS satellite data.
+So, what my wife needs to do in the future is remember at the start of any
+photo shooting period where time sync of her photos with those of others is
+important, she needs to make sure her camera's time is correctly set, taking
+advantage of the function that allows here to set the local time from the 
+GPS time.  But of course, that only helps future photos...
+# How I fixed the problem
+So the problem in front of me was several thousand images taken with the 
+camera's clock "off" by 15 hours and 5 minutes.  We figured that out by a
+combinaton of noting the amount the camera's clock skewed by when we used
+the GPS function to set the clock, then noticing that we still had to account
+for the time zone to make everything line up right.  As far as I can tell, 12 
+hours of that was due to AM vs PM confusion when my wife originally set 
+the time by hand, less 1 hour of daylight savings time not accounted for, 
+plus 4 time zones from home to where the photos were taken.  And the remaining 
+5 minutes probably amount to some combination of imprecision when the clock 
+was originally set by hand, and drift of the camera's clock in the many 
+months since then.
+I thought briefly about hacking Piwigo to use the GPS time stamps, but quickly
+realized that wouldn't actually solve the problem, since they're in UTC and
+the pictures from our phone cameras were all using local time.  There's 
+probably a solution lurking there somewhere, but just fixing up the times in
+the photo files that were wrong seemed like an easier path forward.
+A Google search or two later, and I found 
+which fortunately was already packaged for Debian.  It makes changing Exif
+timestamps of an on-disk Jpeg image file really easy.  Highly recommended!
+Compounding my problem was that my wife had already spent many hours tagging
+her photos in the Piwigo web GUI, so it really seemed necessary to fix the
+images "in place" on the Piwigo server.  The first problem with that is that
+as you upload photos to the server, they are assigned unique filenames on
+disk based on the upload date and time plus a random hash, and the original
+filename becomes just an element of metadata in the Piwigo database.  Piwigo
+scans the Exif data at image import time and stuffs the database with a 
+number of useful values from there, including the image creation time that is
+fundamental to aligning images taken by different cameras on a timeline.  
+I could find no Piwigo interface to easily extract the on-disk filenames for
+a given set of photos, so I ended up playing with the underlying database
+directly.  The Piwigo source tree contains a file piwigo_structure-mysql.sql
+used in the installation process to set up the database tables that served as
+a handy reference for figuring out the database schema.  Looking at the
+piwigo_categories table, I learned that the "folder" I had uploaded all of
+the raw photos from my wife's camera to was category 109.  After a couple 
+hours of re-learning mysql/mariadb query semantics and just trying things
+against the database, this is the command that gave me the list of all the
+files I wanted:
+select piwigo_images.path into outfile '/tmp/imagefiles' from piwigo_image_category, piwigo_images where piwigo_image_category.category_id=109 and piwigo_images.date_creation >= '2019-12-14' and piwigo_image_category.image_id=piwigo_images.id;
+That gave me a list of the on-disk file paths (relative to the Piwigo
+installation root) of images uploaded from my wife's camera since the start 
+of this trip in a file.  A trivial shell script loop using that list of 
+paths quickly followed:
+        cd /var/www/html/piwigo
+        for i in `cat /tmp/imagefiles`
+        do
+                echo $i
+                sudo -u www-data jhead -ta+15:05 $i
+        done
+At this point, all the files on disk were updated, as a little quick checking 
+with exif and exiv2 at the command line confirmed.  But my second problem
+was figuring out how to get Piwigo to notice and incorporate the changes.  That
+turned out to be easier than I thought!  Using the admin interface to go into
+the photos batch manager,  I was able to select all the photos in the folder
+we upload raw pictures from Karen's camera to that were taken in the relevant
+date range (which I expressed as taken:2019-12-14..2021), then selected all
+photos in the resulting set, and performed action "synchronize metadata".  All
+the selected image files were rescanned, the database got updated...
+Voila!  Happy wife!
index 4b303decec36914317d75e41bcb3988c88b35b66..54247363b007892a0a143755afcb6162460d3a8a 100644 (file)
@@ -8,17 +8,17 @@ After retiring at the end of August, 2012, from my long-held position as
 part-time for [Samsung](http://samsung.com) as Senior Adviser to the Open 
 Source Group that is part of Samsung Research America.  In September of 2014,
 I was recruited back to HPE and served for 25 months as an 
-[HPE Fellow](http://h20195.www2.hp.com/v2/GetDocument.aspx?docname=c04839247)
+[HPE Fellow](http://www.hp.com/united-states/Bdale-Garbee-External-Bio-V2.pdf)
 in Martin Fink's Office of the CTO at what became
 [Hewlett Packard Enterprise](http://hpe.com), driving open source 
 strategy and advocacy for the company.  At the end of September 2016, I
 returned to early retirement... and am now enjoying "Retirement v2.0".
-I serve on the boards of [Aleph Objects](http://alephobjects.com).  
-the [FreedomBox Foundation](http://freedomboxfoundation.org), and the
-[Linux Professional Institute](http://lpi.org).  I'm also a member of the
-[Evaluation Committee](https://sfconservancy.org/about/eval-committee/)
-for the [Software Freedom Conservancy](https://sfconservancy.org).
+I serve on the boards of
+the [Software Freedom Conservancy](https://sfconservancy.org),
+the [FreedomBox Foundation](http://freedomboxfoundation.org), 
+the [Linux Professional Institute](http://lpi.org),
+and [Amateur Radio Digital Communications](http://ampr.org).
 I served for a decade as President of 
 [Software in the Public Interest](http://spi-inc.org), and as a member of
@@ -109,9 +109,9 @@ small and large model [rockets](http://gag.com/rockets).  I hold a
 "Level 3 certification", and am a federally-licensed user of
 low explosives, which means I'm authorized to buy, store, and fly the largest
 motors currently available in the rocket hobby.  My personal confirmed 
-flight altitude record is 21,654 feet above ground, my highest recorded
-acceleration is 86 g, and I've flown a rocket to beyond Mach 2.2.  I served
-on the committee that defined the [Tripoli Mentoring Program](http://www.tripoli.org/Certifications/TripoliMentoringProgram/tabid/322/Default.aspx), and am
+flight altitude record is 32,635 feet above ground, my highest recorded
+acceleration is 86 g, and I've flown a rocket to beyond Mach 3.1.  I served
+on the committee that defined the [Tripoli Mentoring Program](http://www.tripoli.org/TMP), and am
 proud that my son aced the test to become one of the earliest TMP 
 participants.  My current focus combines rocketry with my electronics 
 background and strong interest in radio, see the 
@@ -129,7 +129,7 @@ Cool Stuff on the Web
 * [Cabell Garbee](http://www.garbee.net/~cabell), Bdale's brother, restores 
        neat old vehicles as a hobby.
-* [Allen B. Loyd](href="http://sites.google.com/site/allenloyd/Home),
+* [Allen B. Loyd](http://sites.google.com/site/allenloyd/Home),
        one of Bdale's first cousins, has a site documenting his theatrical set
        designs, paintings, and other fun stuff.
 * [Space Machine & Engineering Corp](http://space-machine.com),
diff --git a/rockets/research/2019.11.23.mdwn b/rockets/research/2019.11.23.mdwn
new file mode 100755 (executable)
index 0000000..e72528e
--- /dev/null
@@ -0,0 +1,33 @@
+# Batch 2019.11.23 #
+A solid slug of KNSB propellant cast in PML 75mm coupler tube, intended to be
+cut into 1" long grains to be used in James' ballistic test motor.  For
+6 grains, thinking about saw kerfs and shrinkage, we'll try casting about a 7" 
+length.  That calculates to about 1321g.
+After trying with and without RIO last year, then losing the notes on which 
+tests were which, I'm kind of starting over.  For prior with-RIO motors, I 
+used 1% RIO and about 1.5 drops per 100g of Polystep-B1 surfactant.  At this
+motor size, I don't think the surfactant is useful, but I do think some RIO
+helped with igniteability.  So this time, let's try running with less RIO 
+and no surfactant.  Like 0.25% RIO.
+Formula for a batch size of 1325g:
+* KNO3, 859.10g
+* Sorbitol, 462.59g
+* red iron oxide, 3.31g
+This formula is completely fluid with 225F indicated on the Presto Multicooker.
+## Results ##
+These grains were cast on 23 November 2019, in the wee hours.
+The actual measures of the batch (using shipping scale for primary ingredients
+and my 0.01g resolution scale for the RIO) were:
+* KNO3, 860g
+* Sorbitol, 462g
+* red iron oxide, 3.4g
diff --git a/rockets/research/2020-test-1.mdwn b/rockets/research/2020-test-1.mdwn
new file mode 100755 (executable)
index 0000000..c350a8c
--- /dev/null
@@ -0,0 +1,20 @@
+# Test 2020-1 #
+8 grain 75mm sorbitol motor with pyrodex pellet ignition in 4-inch Wildman
+re-rebuilt airframe flown on 7 September 2020 at Airfest in Argonia, KS.
+48" purple "Woody" case, Loki #58 (long) nozzle with 2 o-rings, customized
+forward bulkhead with 1600psi pressure sensor and EasyMotor prototype.
+The original model using Kuker's Motorsim said this should be a 43% M-2690 
+with a slightly progressive burn about 2.5 seconds long, using 5355g of 
+propellant or 73% volume loading, and a max pressure of 825 psi.
+After casting and weighing the grains, we ended up with a net propellant
+mass of 4924g.  The grains seemed to have fairly uniform density.
+## Results ##
+Motor cato'd just off the rail on pad 61.  Airframe and electronics a 
+total loss.
diff --git a/rockets/research/2020.08.31.mdwn b/rockets/research/2020.08.31.mdwn
new file mode 100755 (executable)
index 0000000..20295d8
--- /dev/null
@@ -0,0 +1,54 @@
+# Batch 2020.08.31 #
+8 grains of 75mm KNSB, intended to be a reload for my long purple case.
+with Loki-style #58 nozzle.  Grain length 5.125" with 0.125" spacing per 
+grain planned using o-rings.  Delrin coring rods of 0.75" diameter since 
+that's what I have bases and caps for, then bored out to 0.875" final ID 
+before assembly.
+Kuker's Motorsim says this should be a 43% M-2690 with a slightly progressive
+burn about 2.5 seconds long, using 5355g of propellant or 73% volume loading,
+and a max pressure of 825 psi.
+Since this is too much propellant to handle in one batch, we'll plan to use
+two 2700g batches, the formula for each of which is:
+* 65% KNO3, 1755g
+* 35% Sorbitol, 945g
+* 1% red iron oxide, 27g, added after melt
+* 41 drops Polystep-B1, added before pour using eye dropper
+This formula is completely fluid with 225F indicated on the Presto Multicooker,
+but viscosity is noticeabley lower making for easier pouring at 250-275F.
+These grains were cast on 2020.08.31.
+## Results ##
+The 5.125" grains were poured to a 119mm fill line, and then an 0.75" Delrin
+coring rod was twisted down into the goo puncturing foil over the coring rod
+hole at the grain base.  About 18 hours later, the grains were "topped off" 
+and smoothed level to compensate for shrinkage.  The coring rods were pulled 
+about 48 hours after casting, and each grain was observed to have some bubbling 
+around the base of the coring rod, presumed to be due to air below the foil on 
+the casting base pushing up as the rod went down.  We should arrange for 
+explicit venting of that in the future.  The top faces of the grains were knife
+scraped smooth, the cores were bored out to 0.875", and the bottom of each grain 
+was chamfered around the core to eliminate the bubbly bits.  Thus, the grain 
+masses were highly likely to be less than anticipated.
+* Grain 1, 630g gross, 16.21g casting tube, 613.79g net
+* Grain 2, 634g gross, 16.20g casting tube, 617.80g net
+* Grain 3, 640g gross, 16.14g casting tube, 623.86g net
+* Grain 4, 632g gross, 16.17g casting tube, 615.83g net
+* Grain 5, 626g gross, 16.34g casting tube, 609.66g net
+* Grain 6, 628g gross, 16.11g casting tube, 611.89g net
+* Grain 7, 628g gross, 16.17g casting tube, 611.83g net
+* Grain 8, 636g gross, 16.28g casting tube, 619.72g net
+Average casting tube weight 16.2g.  Measured total propellant mass of 4924g, 
+or about 616g per grain, which is 92% of what Kuker's simulator projected.
+Borrowed Terry's Loke #58 nozzle, which is a few thousandths over-sized.
+The as-built motor is projected to be a 30% M-2300 or so.
index a2379964f1b5add50a4f2e17d1603eb8770e0f45..ce5420414a7781d268ac3b5013e7c550a8569e9d 100755 (executable)
@@ -4,11 +4,17 @@
 * [Richard Nakka's Site](http://www.nakka-rocketry.net/)
 * [Scott Jolley's Site](http://ajolleyplace.com/scott.html)
-* [Scott Fintel's Site](http://www.thefintels.com/aer/rocketindex.htm) - defunct?
+* [Scott Fintel's Site via Wayback Machine](https://web.archive.org/web/20160727001518/http://www.thefintels.com:80/aer/rocketindex.htm)
 * [James Yawn's Site](http://jamesyawn.net/index.htm)
+* [Loki Research Tech Info Page](https://lokiresearch.com/page/Tech_Info)
 ## Activity Log ##
+### 2020 ###
+* [2020 batch 01](2020.08.31.html) - 31 August 2020 - 8 75mm KNSB grains
+* [2020 test 01](2020-test-1.html) - 7 September 2020 - 8-grain 75mm KNSB at Airfest
 ### 2019 ###
 * [2019 batch 01](2019.01.07.html) - 7 January 2019 - 4 54mm Everclear APCP grains
diff --git a/tags/tags/photography.mdwn b/tags/tags/photography.mdwn
new file mode 100644 (file)
index 0000000..09aa412
--- /dev/null
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged tags/photography"]]
+[[!inline pages="tagged(tags/photography)" actions="no" archive="yes"