I contributed today's Square Root of Minus Garfield strip:

Readers who have been away from the Internet for the past several years, please see Lolcats at TV Tropes. Or the Other Wiki.

It's easy enough to create a Garfield lolcat. The trick is to find a framing such that Garfield is kept even remotely in character.

Original strip from 2007-02-14.


Dissociated Garfield

I contributed today's Square Root of Minus Garfield strip:

Taking "remixed Garfield strips" fairly literally, I created these three strips using a generalisation of the Dissociated Press algorithm to two dimensions. Here is how it works, more or less:

  1. Construct a source image consisting of all regular non-Sunday Garfield strips from 2007, forced into a common 216-color palette. (Avoid dithering; that gives bad results).
  2. Generate the pixels of the output image in pseudo-random order, as follows:
  3. Set N=32 and find the N pixels closest to the target pixel coordinates that have already been generated.
  4. Locate all pixels in the source image that have exactly the same colours in the same relative positions as the neighbour pixels found in step 3
  5. If no source pixels were found in step 4, decrease N by one and start over from step 3.
  6. Otherwise, set the target pixel to the colour of a randomly chosen one among those found in step 4.

I generated a dozen-odd images – each takes about 6 hours of CPU time – and selected the most interesting ones. They tend to be more chaotic than I had hoped (and increasing the initial N does not seem to help), but still they are not complete failures.


Thrichromatic Garfield

I contributed today's Square Root of Minus Garfield strip:

Like many other "funny" newspaper strips, the colour in Garfield seldom really adds value to the joke. It seems that colour is just added as an afterthought, because surely the newspapers did not invest in full-colour-on-every-page capable offset machines just to run monochrome line art!

However, for a strip that does not really need colour for its artistic message, we could put the colour process to better use, to wit, saving paper by printing three panels of line art in the space of one.

In this strip from 2004-04-16, the first panel is in cyan ink, the second in magenta and the third in yellow.


Trackmap.net update: Central Berlin

My summer vacation this year went to Berlin. I spent a week riding trains, photographing tracks, sketching track maps. Like last year I had no trouble with authorities, despite people in DB Sicherheit uniforms often being around as I took pictures.

Unlike last year, this year I've taken the time to draw fair digital track maps from my photos and sketches. The first part of the results are now available at http://trackmap.net/de/bea. More will follow in the coming weeks. I hope.


Garfield IN SPACE!

I contributed today's Square Root of Minus Garfield strip:

Strip from 1982-11-01. Original dialogue.

Obligatory TV Tropes link.


Xcftools 1.0.7: This is getting embarassing

I missed a single GPL blurb as I changed the license notices in xcftools 1.0.6. Yet another version fixes it: http://henning.makholm.net/xcftools/xcftools-1.0.7.tar.gz with SHA-1 checksum 3c3cf07ad6183605a3febf5a8af9f2bd4cb4ef83 and signature



Xcftools 1.0.6: Murphy strikes again

What gives? Just a few hours after I released xcftools 1.0.5, I hit another bug myself. It turns out xcftools would malfunction for canvas-sized layers that have a layer mask but no alpha channel. And while looking through the code for the right place to fix this, I discovered yet another bug sitting in the code.

So here is version 1.0.6, the second patch release in 24 hours. Quite some interesting times to live in, given that nothing happened to the software for three full years previously.

The source tarball is a http://henning.makholm.net/xcftools/xcftools-1.0.6.tar.gz. Its SHA-1 checksum is 1cda6fb03116028a516e87c25113a1d61338703b. And here's a digital signature:



While I was at it, I changed the licensing of xcftools from GPL-2 to Public Domain.

Now I wonder what I'm going to discover a few hours from now ...

Xcftools 1.0.5: a security fix release

Some years ago, I wrote a set of small command-line programs that can extract image data from Gimp's native file format XCF. I call them xcftools and use them for automating some of the steps in the production of track maps. Others have, allegedly, found them useful too. (They are among the top Google leads to my personal website, which I'll admit may not be saying much).

A few weeks ago, J├Ârgen Grahn filed a bug report through Debian's bug tracking system, pointing out that the program would crash when its -C option was used on a test image he provided. This turned out to be a buffer overrun bug, which provides a security hole. An attacker could infect a victim's account by constructing a special XCF file and then tricking the victim into using my tools on the XCF file, giving particular options to them. This vulnerability was assigned the tracking number CVE-2009-2175.

A bare-bones patch for the security issue has been available for some time in the Debian bug report log, but now here is an official source code release that fixes the bug along with a number of other, not security sensitive bugs.

This release also includes a small patch from Marcus Alanen that should make it easier to build an RPM package of xcftools.

The source tarball for xcftools 1.0.5 is available at http://henning.makholm.net/xcftools/xcftools-1.0.5.tar.gz. Its SHA-1 checksum is f4f532b6f32001ca6994e7cf5d0a94eb0d620ad8; and here is a digital signature for the tarball:



Now I just have to wait for somebody to upload the new version to the Debian repository. Typical of this to happen only a few months after I renounced my own upload privileges after they'd been unused for two years ...