I’ve played with the Javascript interface to Photoshop for a couple of years. Conceptually, it’s great — a simple, powerful, interpreted language like Javascript, with an API to interface to one of the best image-processing packages available. In practice, it’s not as good as it is in concept, but it’s still pretty good. The API doesn’t include all of Photoshop’s functionality directly, and there are a lot of things you need to execute as fairly obscure event actions. These event actions aren’t documented, but can be determined by activating a plug-in which logs everything that you do using the Photoshop GUI — you can then read through these logs, and copy the actions you need.

Still, there are some real advantages to using this Javascript interface, as opposed to something designed for the purpose like, say, Processing. You can use the Photoshop UI for controlling inputs to your script (set foreground colors, select portions of the image, select specific layers, etc.), and output your manipulations directly into Photoshop layers.

I’ll be posting here shortly a library I’ve created for easily building dialog panels for setting script options. I find that most manipulations I want to do have a set of variables, and I’d rather not tweak the code each time I want to change them.

This library was originally written under Photoshop 10 (aka CS3). Under version 11 (aka CS4), it was less stable. Sometimes it would crash out at odd places complaining that I was referencing properties of undefined objects. Because there have been memory leaks and other issues with the Javascript interpreter, these seemingly random failures were annoying but not too surprising. When it came to version 12 (aka CS5), I was rarely able to run my scripts at all. What made it frustrating was the apparent randomness of the crashes. I could print a variable to the console, and the very next line would crash out with an “undefined object” error when referencing that variable.
To make a long story short, I was able to track down the issue. It turns out that in iterations, declaring variables matters. That is to say:
for (i in someCollection)
{
$.writeln(i['someAttribute']);
}

will cause random crashes, but
for (var i in someCollection)
{
$.writeln(i['someAttribute']);
}

runs beautifully. Now, I “knew” that the var keyword is optional and used for specifying scope, but I never had any idea that there could be an issue within the scope of a simple loop. Obviously, Javascript didn’t know that I intended i to be a variable on each iteration — perhaps it thinks I meant for i to be a 1957 Chevy Belair on some iterations.

In any case, having cracked the code as it were, I have proceeded to enhance and add to my library. After a little more testing, I’ll be posting it here or on GitHub.

I’ve been processing a collection of product videos which came to me in a huge variety of sizes, aspect ratios, and qualities. I need to re-encode them to work in HTML 5, but, more importantly, I need to make them fit into a common player space on the web page.

It turns out that newer versions of ffmpeg support not only cropping, but also padding, and you can even do both operations at once!

For example, I had a source video that was originally 16:9, but had been letterboxed to 4:3, and then had two different sets of labels added. I needed to crop out the letterboxed portion and the top set of labels, and make the result fit nicely into 16:9. So I used VLC, a screen capture utility, and Photoshop to get the measurements. Then I used ffmpeg to crop the relevant section and pad it out to fit into my space (in this case, I’m left aligning the video in the padded output):


ffmpeg -i original/converted.wmv -vf crop=394:295:6:0,pad=524:295:0:0:0xFFFF00 -sameq converted.mov


That’s cropping a 394 x 295 piece out of the original video (with the origin at 6 pixels from the left, and 0 pixels from the top), and then padding it out to 524 x 295 filling the padded area with bright yellow. The 524 x 295 is really close to 16:9 — and in a later process, it gets resized to the more standard 480 x 272¹.

You can string together the padding and cropping in either order, depending on the effect you’re trying to achieve.

¹I’m sure some educated person out there could tell me why video standards are so confused/confusing, down to the non-square pixels. While a true 16:9 would dictate 480 x 270 pixels, everybody seems to use 480 x 272. Why? The only thing I can figure out is that 272 is evenly divisible by a power of 2, which probably made display hardware cheaper to manufacture. As you can see, my resizing adds a bit of distortion, but at these resolutions, it doesn’t really matter.

We’ve had some new hatches in the Butterfly Fort, and there are at least six chrysalids which will be eclosing in the next couple of days¹. This reawakens my interest in time-lapse photography.

I used to have a setup with a Harbortronics D2000 which I hooked up to my Nikon Coolpix 950 (and, later, Coolpix 995). It was good for a lot of things, but I succeeded in burning a nice streak across the sensor of the camera when the sun passed directly through the scene — the Coolpix line didn’t have a physical shutter, so the lens focused the sun onto the delicate sensor for the full time it was in view.

I’ve been using the Brinno Gardenwatch Cam that I received as a gift
a few years ago. It’s a dedicated, all-in-one time-lapse device. Once I learned a few things, I was able to use it successfully. First off, it really needs to be run on Nickel-metal hydride batteries. Next, you have to listen carefully when turning it on, because it’s not always obvious when you’ve powered it on and then off again by holding down the button a bit too long.

The Gardenwatch Cam does a decent job. It creates AVI format movies. It has 7 interval settings ranging from 1 minute to 24 hours. It has two focus settings, one for close up, and one for landscape.

With the monarchs, though, I want to be able to get in closer, and have sharper images than the Gardenwatch cam will give me. I still have a Nikon D70 which served me well for many years, but has been supplanted by the D90 in recent years. I also have a small assortment of lenses that I’ve accumulated over the past fifteen years. I’m thinking that the six megapixels of the D70 should be far more than adequate for doing some nice macro time-lapse work.

So the only problem is intervalometry — how do I trigger the camera to take pictures? Nikon sells intervalometers for most cameras, but the D70 is notably excluded from that list. There are a number of people making kits (or generously giving away their designs). I thought I might be able to rig something together.

I was successful. Taking an ancient Gateway Solo 9300 notebook that I’d bought for a king’s ransom back in 1998 or 1999, I installed Ubuntu 11.4 desktop on it. This was a mistake. The machine has a 366MHz Pentium II processor, and 128 MB of memory — lesser specs than your iPhone². It got part way through the boot sequence, and locked up (terminal swapping? driver issues? I don’t know). I then installed a version of Ubuntu 8 Server for which I happened to have a CD. After installation, I booted into Matrix-esque screen garbage, but after some fighting with boot parameters was able to get running cleanly. Next, I installed gPhoto2. Putting the D70 into PPT mode, I hooked it up to the notebook with a USB cable.

Voilà! Now, all it took was a few commands:

Find the camera:

gphoto2 --auto-detect

Store pictures on the camera’s compact flash card:

gphoto2 --set-config capturetarget=1

And take pictures at a 30-second interval:

gphoto2 --capture-image --interval 30


If I get any worthy results, I’ll post ’em on Archie’s Garden.

¹ There sure are a lot of great insect words. “Eclose” and “chrysalid” are just two among many.
² The two generations of iPhone had 128 MB of memory, and a 412 MHz ARM processor.

An iPhone locator app I’ve been building had a weird thing happen: if you denied it access to Location Services and entered a valid ZIP code, it would work — but an invalid ZIP code would always home in on Lancaster, Pennsylvania. At first, I thought it was a bug in how I was sending coordinates to MKMapView, but I quickly was able to confirm that the problem originated in my server-side geolocation service.

My server-side geolocation service uses Google’s deprecated Geocoding API version 2. The problem arose from sloppy coding on my side, coupled with Google’s map intelligence, and the v2 API’s reporting. Here’s how:

My code would assemble an address string from street number, city, state, and ZIP code (if provided). In this particular case, however, it was only receiving a ZIP code. But my code was crappy, and the address string it assembled looked like “null, null, null 90066”. If the ZIP code was legit (like 90066), Google’s geolocator is smart enough to figure out that it’s a ZIP code, ignore the “nulls,” and do the right thing. But the interesting thing happens when the ZIP code is not legit. Google’s algorithm evidently tries its best to match up the provided address with something you might be looking for. Perhaps due to previous searches with the API key we were using, perhaps for other unknown reasons, those “nulls” were matched to Noll Airport, East Hempfield, Lancaster, PA 17603.

Interestingly, the Geo Address Accuracy resolution value returned for that specific match is 9, or “Premise level accuracy” — the highest level of accuracy. Again, my crappy code had assumed that the Geo Address Accuracy was a confidence factor, not a resolution indicator. So that guess appears to be a really good fix, when, in fact, it’s no better than any other guess.

Revising the code to leave out the “nulls” resulted in another interesting result. Again, legitimate ZIP codes were found right off. Bad ZIP codes ended up being matched against other numeric codes, so, for example, “90000” ended up matching Belfort, France, and “91000” ended up matching Tawau, Malaysia. These results all come back with a Geo Address Accuracy of 5, or ZIP-code level.

One solution to this problem is to validate ZIP codes before submission to Google. Another solution would be to upgrade to the v3 API, where there’s more information about what’s going on.

Several years ago, we replaced our commodity hardware firewall (a Sonicwall SOHO from ’01) with pfSense running on an unused Dell 4100 desktop from that same year.

pfSense was a little confusing to configure the first time through (doing 1-to-1 NAT with virtual IPs and CARP was initially confusing, but the pfSense forums and The Google came to our rescue). Once in place, though, it did a great job. And when I say a great job, I mean that we could pretty much forget about its existence. It just hummed away in the background, and everything worked. When we needed to check up on our ISP, we discovered that quality of service logging was already supported, as well as pretty graphs of various connection properties. Very nice!

Over the last weekend, the 4100 locked up, and our connection was interrupted. Rebooting gave a firmware error about a bad disk in drive A: — but there was no disk in the drive. Power cycling, opening the machine, wiggling some cables, and blowing out some dust brought it back up, and all was well. Except it wasn’t, really. The machine spontaneously rebooted a number times over the next few days, and occasionally got into the “bad disk in drive A:” boot failure, requiring a hard power cycle. As I watched on the console, I saw the kernel fault out after too many memory checksum errors. The old machine was giving up the ghost.

After commissioning another old desktop (an ’07 vintage Dell, this time), I was able to install pfSense on it. I had to disable some of the extraneous hardware in the BIOS, but after about an hour I had it installed, booting, and ready to go. I was able to simple dump the configuration from the old firewall, load it into the new machine, reassign the LAN and WAN interfaces to the proper devices, and swap the boxes out. voila! Back in business!

With any luck, I won’t have to repeat this process for another five years.