Mischievous Ramblings II

"River of Meat Blood"

From Gizmodo:

Drone Pilot Discovers River of Meat Blood

Seems like a "Dallas drone hobbyist" was flying his camera equipped drone around when he "...discovered a huge stream of blood emptying into the Trinity River..."

Seems like the meat packing plant (aka slaughterhouse?) he was flying near was (probably) illegally discharging, um, waste material into the local watershed.

As more and more drones get into private hands, this is an example of the way that we, the people, can turn the tables on the wholesale surveillance state -- by turning the cameras on them.  Turn the cameras on the police, the corporations, the politicians... on The Man!

Apropos of, well, everything about this: Eye3; Engadget; TechCrunch

Geotagging Photos

Image capture, Google Earth, by Evan Robinson

Because I use a Canon, I don't have an easy option for GPS equipping my SLR.  So if I want to geotag photos, I have to find a less integrated solution.

The cheapest solution is to manually tag photos using some kind of map software.  Aperture provides the Places feature to do this.  There are plug-ins (I downloaded and tested Maperture, which worked fine).  Flickr lets you put photos on a map, and I imagine that other photo hosting services provide similar services.

But geotagging thousands of images manually is a pain, and it will continue to be a pain.  In vernacular of my day job, it does not scale.  I have thousands (maybe tens of thousands) of untagged photos, and I will be generating many more.  On an ongoing basis, manual geotagging is right out.

That leaves some sort of GPS logging.  There are many devices, including many if not all smartphones and standalone GPS units, which will periodically record your GPS position for later use.  These log files can be imported and converted for use with Google Earth and other software to track your position over time.

I have an iPhone, and could well have found logging software for it.  But I have several use cases counter to that solution, especially long periods out of phone service (camping, hiking, the Big Island, etc.).  I suspect that running logging software on the iPhone would reduce battery life below my minimum needs.

So I went looking for a standalone GPS logger.  My search was complicated by the fact that I'm a Mac user, of course.  Google and Amazon led me to a set of five possibles (prices at Amazon):

•   Amod AGL3080 ($65)
•   Qstarz BT-Q1300S ($100)
•   Holux M-241 ($66)
•   Columbus V-900 ($102)
•   Sony GPS-CS3KA ($94)

My first test was basic functionality: I turned each device on and carried it for a day or two.  The QStarz and Columbus units had a really hard time getting GPS lock in downtown Seattle, so they were out.  Next was communication with my Mac.  I got the other units (Amod, Holux, and Sony) to talk to my Mac.  Next I compared the tracks with my actual paths.  That eliminated the Amod, which apparently had trouble getting a good position even when it said it was locked on.

The Holux and the Sony passed all the basic tests.  Both these units use single AA batteries (I use Eneloop rechargeables), which is a plus because they don't require special chargers or cables.  Both connect using standard small USB connectors, which is a plus because that's the same cable I use to talk to my external USB drives.  Both have screens, which means they don't require specialized (usually Windows-only) software to configure them.  The Sony has a nicer form factor and carrying pouch and supports on-card geotagging of photos.  It also connects to the computer as an external drive, which makes acquiring log files very easy (the Holux requires a special USB driver be installed and software to pull log files off the device).  The Holux can be configured for more different logging options (log every 1, 5, 10, 15, 30 seconds; log in metric/english measurements; log based on distance moved; etc.) and seems to use less power.  It also appears, in my basic testing, to lock on faster and more reliably.  It's also about $30 cheaper.  And it has the only toggle power switch in the bunch (every other device uses a push button of some kind to turn the device off and on, sometimes holding it down for X seconds to turn on and Y seconds to turn off -- a toggle switch shows you instantly whether the device is supposed to be on or off, which helps diagnose dead batteries, among other things).

Geotagging workflow on the Mac with the Holux M-241

The first necessary activity with the Holux is to get it to talk to the Mac.  I had to install a special USB driver, the SP210x USB to UART Bridge VCP Driver.  Once that was done, the Holux talks to the Mac through a standard USB cable, and logs can be acquired using free software called HoudahGPS, which is a graphical front end to gpsbabel.

If you are only going to acquire log files, HoudahGPS will do you.  It reads data off the Holux and converts it to several standard formats.  If you want to view your track in Google Earth, for instance, this is how you do it.

If you want a standalone geotagging app, HoudahGeo ($30) is what you need.  I had a license lying around from some Mac Bundle or another I'd acquired, so I didn't actually even need to buy the software.  HoudahGeo includes HoudahGPS' functionality and can extract GPS information from the Holux directly, without using HoudahGPS as an intermediate.

How you use HoudahGeo will depend upon your existing workflow.  I use it as part of pulling photos off my cards.  I copy the files off my card to a standard location, run a couple of droplets on them to separate the images by day shot and rename them to my standard (YYYYMMDD-###, which will have to change to -#### or even -##### because of the speed of the 60D).  Then I drop the resulting folders on HoudahGeo, which imports the Canon Raw (CR2) files and associates them (by timestamp) with the positions logged on the Holux.  Getting the log into HoudahGeo can happen two ways: direct import from the device, or by using HoudahGPS to extract the log file from the device and then using HoudahGeo to import the log file (which is obviously more work, but it's the way I did it first, so I know that it works as well as direct import).  HoudahGeo can be instructed to wipe the log file from the device after import.

There is one thing which you must verify in order for all this to work properly and relatively automatically: Your camera's clock must be closely in sync with GPS time.  This is one reason why the screen on the M-241 (and the Sony) is so important: it allows you to see GPS time and set your camera time to a close match (I find that within a second or so is adequate).

HoudahGeo will automatically associate GPS position data with photos according to timestamp.  Since I've set my camera time to closely match GPS time, it's been seamless.  Without that match, it's a #@&%^@(# pain in the butt.

HoudahGeo is then happy to export the CR2 files with GPS information embedded in metadata (it's entirely possible that sidecar files are in use here, but I don't know and for now I don't need to know -- it just works).  Once the files have been tagged with the GPS information, I import them into Aperture as a Project.

New Photo Gear

Gull Wing 20110723-019, by Evan Robinson,
Canon 60D wih 70-200mm f/4L
Click to embiggen

As I've previously noted, I recently upgraded my camera kit for the first time in 8 years.  Here's the basic new gear list:

Canon 60D Body Only

Canon 24-105mm f/4L IS USM

Canon 70-200mm f/4L IS USM

Canon Speedlite 430EX II

Replacing a Canon 300D (Digital Rebel), Canon 18-55mm EF-S, and Sigma 70-300mm.  I'm keeping, at least for a while, my 50mm f/2.5 Sigma Macro lens and my 28-105 f/2.8 Tamron.

Why the 60D?

So why did I pick the 60D over the 7D?

The first reason I even looked at the 60D was that I had trouble finding anybody who had a 7D in stock.  The Japanese earthquake and tsunami appear to have wreaked havoc on Canon's supply chain.  When I could find a 7D, the body was going for a 10-25% premium over its list price.  I didn't want to pay that.  And I had a deadline: we're going on a trip, and I wanted a month or two to work into the new gear.

The second reason was the articulating screen.  I love being able to turn the screen into the body so it's not exposed (I have a Zagg protective film on it, but still), and the potential for low or high angle viewing seems like a nice feature.

Third, the price difference.  I got my 60D for list ($899, including the $100 rebate Canon has running until 3 September 2011).  If I could have found a 7D for list, it would have been $1599 (with rebate included): nearly 80% more.

Fourth, the 60D uses SD cards, not CF cards.  I have a small library of CF cards, but SD cards are nicely smaller, generally a bit cheaper, and my "darkroom" (a 13" MacBook Pro) has a built-in reader, so that's one less thing to carry, use, lose, and replace.  And I get official eye-fi support, which may or not turn out to be a big thing.

What was I losing by not getting the 7D?  8fps instead of 5.3fps; dual DIGICs instead of a single DIGIC; 100% viewfinder instead of 96%; .122s less shutter lag; and more focus points (and more cross-type).

What else would I lose if I didn't get the 60D?  About 300 shots per battery change and about 100g.

In the end, I just ended up on the 60D side.  I might get a 7D (mark 2? 8D?) next time (which I hope won't be 8 years!), but this time, the availability, price, screen, and SD came out ahead of the FPS, 100% viewfinder, shutter lag, and focus points.  The 60D is such an incredible technological leap ahead of the 300D that the extra bells and whistles just didn't seem important.

Why the f/4 lenses instead of f/2.8?

The other thing I've been asked is why I sprung for L lenses but didn't get f/2.8 lenses.  There are basically two reasons.  There's the price: the f/2.8 version of the 700-200 costs nearly twice as much.  Next, there's the weight: it also weighs more than twice as much.  I'm going to be hauling this basic kit around a lot.  I'd love to have the more capable lenses (although there is no 24-105mm f/2.8L, you have to be content with the 24-70mm), but I won't be happy with the extra 37oz (well over a kilogram!) and the lost overlap from 70-105mm.

So why buy the L lenses to begin with?  I spent more on each of those lenses then on the 60D body, or almost all the lenses I had in my old kit put together (that's a little bit of an exaggeration but not much)!  Because I expect to use these lenses not just until I get my next body, but the next body after that, and so forth.  Unless Canon goes through a technology change like from the FD lenses to the EF lenses, I expect to have these lenses for the rest of my life: they're not a consumable like the body, they're an investment.

Carrying Gear

With new kit and a trip planned, I wanted to get a new bag as well.  I went through a bunch of options and ended up buying three and sending two back.  The winner is the Tamrac Adventure 9 Photo/Computer Backpack, which beat out the Tamrac 5788 Evolution 8 Photo/Laptop Sling Backpack Bag by two features: the upper compartment on the Adventure 8 holds my iPad, and the one on the Evolution 8 doesn't.  They both beat out the Crumpler Sinking Barge Deluxe which I thought was ingenious, but had a number of issues for me.  Most notably, I didn't feel the dividing walls were strong enough to keep my gear in place, and it was really hard to get stuff in and out of -- which has the advantage that your gear isn't likely to get out by mistake.  On the other hand, the Crumpler has by far the best waiststrap.  For trips where I'm not constrained by carry-on restrictions, I use a Lowepro Classified 250AW, which I first carried at the 2008 DNC.  It's big but easy to get stuff in and out of.

When I was at Glazer's (near work, and easier to fondle gear than online), I discovered the Black Rapid straps, and got myself an RS-7.  It's not perfect, but it's very nice.  There's a KickStarter design called the Lens Loop which is very much the same idea.  It moves the camera off your neck and across your body, with some sort of ring at the camera connection, which allows the camera to slide up the strap to your face and then drop back to your side.

 

I find myself both very enthusiastic about taking pictures and interested in blogging in a way I haven't been, oh, since the 2008 election.  We'll see about that.

Testing

Puget Sound Panorama 20110716 by Evan Robinson
Click to embiggen

I've updated my camera gear for the first time in years (my previous camera is a Canon Digital Rebel aka Canon 300D which I purchased in 2003 IIRC).  So I've been out playing with the new equipment (which there will probably be more than one post about).  The above is an example.  The original is 9583 x 2358, made from 18 images, is 6.6MB as a JPG (pretty small!), and nearly 60MB as a TIF.  Pretty much everything on it, from camera settings to Hugin settings to Aperture settings, was default.

Rogers Wireless Bait-and-Switch on Canada/US iPhone Data Plan

On 2010.02.04, Rogers Wireless announced new data plans for the iPhone.  Special data plans, because they eliminated data roaming charges in the US.

A wonderful thing if you cross the border regularly -- as I do.  So far as I know, these are the first cross-border data plans available, not only in Canada, but anywhere!

Can you imagine my delight?

We switched immediately, giving up the 6GB plan ($30/month) we'd signed up for when we got the iPhones on launch day -- knowing we'd never get them back at that price.  But frankly, Sara rarely uses even 200MB and I usually use about 500MB, so I signed her up at 500MB ($35) and me at 1GB ($40).  For $5 a month (and reduced data headroom that we don't seem to need), we got free data roaming in the US!

And it was sweet.  No more lobotomy at Lynden.  No more checking anxiously to see when the Rogers 3G came back on the way north (sometimes not until we're north of the border, actually).  Free data!  Data wants to be free!

Being a geek, I had to see what would happen if I tried tethering my MacBook Pro while I was in the US.  A good friend suggested it would not work because tethering had to be enabled at the cell tower level via provisioning.  I figured that, since I'd had to modify the phone (Rogers downloaded an additional/alternate firmware or carrier provisioning bundle when I asked them to turn tethering on), it should work.

At least it was worth a try.

But when I attempted it, I got this message:

 

 

OK, no big deal.  No tethering in the US -- that makes me just like any other poor iPhone user attached to the AT&T network (which, BTW, I agree sucks compared to Rogers -- data transfers are slower, tend to drop out more, and it generally doesn't achieve the level of "service" I'm used to getting).

Unfortunately, I got that very same message the next time I tried to tether while over town.  Dang.

I assumed (dangerous word) that Rogers had accidentally turned off my tethering while changing my data plan.  So I called support.

After three calls, I've discovered that it wasn't an accident.  On my first call, customer service told me that they couldn't enable tethering on my plan so I'd have to call technical support.  On my second call, tech support told me that tethering wasn't available on my plan and then out-waited me when I asked for a manager to explain the discrepancy between what they were telling me and the web site.  On my third call, customer support told me that I'd have to upgrade from the 1GB on Smartphones, Canada & US One Rate Data Plan for $40/month to the Mobile Internet Flex-Rate, Canada & US One Rate Data Plan at $60/month.

After some back and forth, she offered to "open a ticket" to find out why my plan doesn't offer tethering.  She said that I'd get a callback in 3-5 business days with either: a solution to adding tethering to my existing plan; or "other options".

I'm betting those "other options" are limited to "pay us $20 more a month".

Despite Rogers' web site claiming:

Tethering is the use of your phone as a wireless modem to connect to the Internet from your computer. For a limited time, if you subscribe to a data plan which includes at least 1GB of data transmission, and if you have a compatible device, you may use tethering as part of the volume of data included in your plan at no additional charge. Tethering cannot be used with data plans of less than 1GB.

I can't tether.

R.I.P. Sun Microsystems: 1982 - 2010

(h/t James Gosling, Inventor of Java)

Fujitsu's IPAD is Apple Canada's EasyPay

Apple's iPad device is getting a certain amount of attention just because of the name.  Not only does iPad sound like a feminine hygiene product, Apple is actively attempting to recover Fujitsu's "abandoned" trademark in the US.

It turns out that there's a closer relationship between Apple and Fujitsu's IPAD than has been generally acknowledged.  The Wall Street Journal provides the pieces:

The two companies could agree to share the trademark, with Apple potentially paying money in the settlement, legal experts say.

Apple has until late February to file an opposition to Fujitsu's trademark application at the U.S. Patent and Trademark Office. The agency awards trademark registrations, which put other parties on notice that a company has claimed trademark rights. Even if Fujitsu succeeds in getting a trademark registration, it won't necessarily help the company prevail in a potential future court battle with Apple over the name, legal experts say.

And the article includes this picture of the Fujitsu IPAD:

 

The Fujitsu IPAD is instantly recognizable to anyone who visits an Apple Store here in Canada as an EasyPay POS (Point of Sale) terminal -- used by Apple Store employees to scan product barcodes and process credit card payments.

Is there an app for that?

(h/t to Daring Fireball)

XCode Error: dsymutil failed with exit code 10

I have been struggling for a while with what appears to be a systemic problem using XCode. Periodically, my projects will begin to display an error:
        ‘Command /Developer/usr/bin/dsymutil failed with exit code 10’
Once the error appears, it can sometimes be eliminated by some combination of:

• doing a clean build
• restarting XCode
• rebooting the computer
• reinstalling the developer tools

Sometimes, of course, it can’t be eliminated. As documented here and here, I found a workaround. But the problem recurs. Sometimes very quickly after implementing the workaround (which isn’t a real quick fix).

At the moment, I’m trying a full command-line uninstall of all developer tools to be followed by a re-install. Perhaps that will help. In the meantime, if anyone out there knows what’s going on here, I’d love to hear the cause and a solution.

The Joys of Memory Management, part 1

I've been playing with the iPhone SDK recently, and for whatever reason, I'm having much more success wrapping my head around the NextStep programming model adopted by Apple years ago.  Previous attempts were, shall we say, less than thrilling.

My first iPhone app is approaching beta, which means that I think the first version is done and I'm waiting on feedback from someone else before I consider submitting it to the App Store.

This morning I had a wrangle or two with memory management.  That's not surprising, because memory management is one of the bête noires of programming in c or c++, and Objective-c isn't going to be that different.

Or so I thought.

After creating a generally functional version of App#1, I decided to run it through some torture testing.  So I added a few buttons to the UI and wired them up to some test routines.  Essentially, I simulated thousands of uses of the basic functions.  There are two buttons that the user will press and three textfields, so I wired up the test buttons to call each button's target 10,000 times and one to change the value in each textfield 10,000 times and to call the various functions which use those values.

Everything worked, but Instruments told me that there was some serious memory usage going on.  Not a lot of leakage (although there was some), but some serious usage.  Not good. Especially since this is a simple program, without anything fancy going on, except for rolling about 14 million dice.

So I refined my tests a bit, and discovered some stuff worth recording.  Others may find this useful or not, but I know I need to remember this, and writing it down will help do that, even if I never come read it again.

This is a memory leak:

dcsText.text = [[NSString alloc] initWithFormat:@"%d", 15 + (i % 10)];

This is not:

NSString *temp = [[NSString alloc] initWithFormat:@"%d", 15 + (i % 10)];
dcsText.text = temp;
[temp release];

Discussion:

I wasn't actually using the first version, but the second. But I wanted to know if the first version was going generate a memory leak, so I tried it. And confirmed that I knew how the tool was working and that the version I had written was working correctly.  The first version is a memory leak because the allocated string is created and has a retainCount of 1, but it's never released to reduce the retainCount to 0, so dealloc never gets called.  It might be nice if it were an AutoPtr so that it got released when it goes out of scope, but that is a big whopping can of worms that I'd just as soon not open, so we'll let it go at that.  I will, however, write me a few helper routines of the second general form.

NSArray

Once I had established the validity of the above form, I went on to see if I could figure out why the app was: 1) slowing down over time; and 2) using so frickin' much RAM.  I'd been pretty careful, and I was reasonably certain that everything I was allocating was being deallocated, so where was the leak?  Instruments pointed me right at it.  Every leaked block was associated with an Array class of some sort.  I was only using two arrays: one of NSMutableArray and one of NSArray (basically I built the array using the NSMutableArray and then created an NSArray from that so that client code couldn't alter the array).  So what if I just use the NSMutableArray, eliminating the creation of the NSArray?  No help.  What's the retainCount on the NSArray immediately after I create it?  2?  2?  2!

That's not right.  It should be one.  So try releasing it immediately after creation.  Big time crash later in the program.  Obviously something is holding onto it for some reason.  Look at the documentation.  Whenever you use a factory method, the allocated object is added to the autorelease pool.  But the top-level autorelease pool isn't drained until the end of the program, which is why every last one of the 1 million NSMutableArray and NSArray instances are still hanging around.  Obviously I need to add a nearer-scope autorelease pool.  But it's recommended in iPhone programming that you limit your use of autorelease pools.

Clearly that advice is not meant for this situation.  By adding a local autorelease pool where the NSArray is being created and then draining that pool in the same method which creates the NSArray, only one NSArray is kept around at a time, drastically (like, 30MBs of RAM) reducing my memory footprint.  Also, incidentally, locating the spot where I was not releasing one bit of allocated memory, thus the actual memory leak.

The most commonly used function now operates nearly 100x faster than it used to, probably because of vastly decreased memory usage.

Live and Learn.