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.
Another Beamer Theme Matrix’s source code is available under an MIT license on GitHub. While inspired by the existing Beamer Theme Matrix, it is a complete rewrite in Python.
Yesterday, a paper was published in Science on the creation of new, higher resolution maps of the ocean floor using gravity anomaly data collected via satellite. The authors write, “at scales smaller than 200 km, variations in marine gravity primarily reflect sea-floor topography.” Since rock has a different density than water, precise gravity measurements allow for an estimation of ocean depth. One of my first thoughts was to use this data in a map.
The authors provide their data for download; however, it is provided as GMT grid files, which are apparently common for oceanography research, instead of something more standard for GIS such as GeoTIFF. Using GMT, I was able to convert the data to the GDAL supported NetCDF format, although I had to reencode the file with CDO before GDAL would handle it. Using GDAL, I then reprojected the data in EPSG:3857, converted it from floating point to integer, and created a GeoTIFF file to be more friendly to web mapping applications.