Web maps, e.g. Google Maps, normally don’t print well, as their resolution is much lower than normal print resolution, not to mention the various other unwanted text and elements that print along with the map. While the unwanted elements can be cropped out, the only fix for the low resolution is to render a higher resolution image (or use vectors). Formerly, this required installing GIS software, which also requires a suitable data source. Print Maps changes that by leveraging Mapbox GL JS and OpenStreetMap data to render print resolution maps in the browser. After the user selects the map size, zoom, location, style, resolution, and output format, PNG or PDF, Mapbox GL JS is configured as if it was being used on a very high pixel density display and used to render the map output. To use Print Maps, visit printmaps.org.
The site’s source code is available on GitHub. Also, slides from my HopHacks presentation on the project.
A digital light wand, used to paint images in long exposure photography, has been around for a few years, since the advent of cheap, controllable RGB LEDs. While there are freely available designs and code for such a device, I wasn’t happy with them, so I decided to design and build my own. The control electronics for the design I looked at used a Arduino Mega 2560, with a display and control shield as well as other components; I found this far too bulky. Furthermore, the design used a grossly underpowered voltage regulator rated for 1A with a strip of LEDs that draws upwards of 2.5A. The LED strip, however, is one of the nicest ones available, with 144 individually controllable WS2812B RGB LEDs on a one meter strip.
Two years ago, I took a large set of photos at the George Peabody Library. Among those were a very wide angle image looking up at the skylight and an image looking down. The latter was taken with a point-and-shoot camera suspended between the sixth floor railings with the help of fishing line and office supplies. Unfortunately, the field of view was much too narrow, leaving the stacks out completely, so the photo fell short of my vision for it, and it didn’t complement the photo looking up. I needed to use my DSLR and fisheye lens, but there was no way the previous method would have supported it. However, I just revisited this idea and finally got the photo I wanted.
Over the past five months, I have continued working on Pannellum and just released version 2.1.0. This release includes a number of improvements including a loading bar for equirectangular panoramas, “inertia,” configuration from Photo Sphere XMP data, more descriptive error messages, and more documentation. The loading bar is something I’ve wanted since the beginning but never had a good way of implementing before, since
Image objects don’t have progress events. To add support for using Photo Sphere XMP data, I needed access to raw data that wasn’t available with
Image objects. Researching that, I learned that XMLHttpRequest Level 2 supports blob objects that allow the raw image to be transfered; before, it was possible but was a bad idea as it involved some ugly character code hacks. This extended functionality is a few years old at this point, but since the name didn’t change, plenty of information sources are out of date. Configuration from Photo Sphere XMP data seems to work, but without an Android device capable of making them, I was not able to test a number of corner cases. The improved error messages should hopefully resolve one of the most commonly reported issues, why a large panorama doesn’t work, since it now explicitly says that the image is too big and lists what the device’s largest supported image size is. Also of note, I changed the naming of a few configuration parameters for consistency; this breaks some existing configurations, but it will be better going forward. Lastly, numerous bugs were also fixed.
Having been a long-time user of free and open source software, I began giving back to the community in the summer of 2010 by producing Windows builds for Hugin, after the project had gone four releases without a Windows build. This was followed a year later by Windows builds for FontForge. At the time, I was a Windows user who occasionally dabbled with Linux. I created the builds so I could use them, but also shared them with the community. In the fall of 2012, roughly two years after I began building for Windows, I switched primarily to Linux but still ran Windows XP on a laptop. When Microsoft ended support for Windows XP this spring, I stopped using Windows altogether, since it became a security risk. My Windows use is now limited to the occasional use of virtual machines. As my use of Windows declined, so did my interest in building for it. First, I stopped building FontForge, and now I’ve stopped building Hugin.
Compared to Linux, building on Windows is a real pain. Linux’s package manager takes care of all the dependencies, so building a piece of software only involves building that piece of software. Building on Windows, on the other hand, requires building all the dependencies and any sub-dependencies, before one can build the piece of software that one wants to build. While much of these built dependencies can be reused between releases, there is no standard location for accessing these dependencies, unlike on Linux, so configuring the build is much more time consuming. Additionally, Windows’ lack of a package manager induces further headaches when trying to integrate Python support, as one can’t just specify it as a automatically resolved dependency as on Linux.
As I write this, my Windows builds of Hugin have been downloaded over 1.4 million times, and my builds of FontForge have been downloaded around 350 thousand times. If even only a very small fraction of those users responsible for the downloads contributed back to the community because of the downloads, I think the time I’ve spent creating the builds has been a good thing. That being said, I no longer plan on producing builds for Windows, as I can no longer justify the time and effort.