Croquet

Intro

Basic croquet rules, as played by a bunch of uncultured Northerners. Northern-monkey terminology is in “quotes”:

There are two teams, ideally with the same number of people on each.

There are six hoops (“goals”), arranged in a 3×2 grid (central hoops are closer to each other compared to other pairs):

 ╭───╮                                  ╭───╮
 │ 2 │                                  │ 3 │
                   ╭───╮
                   │ 6 │



                     ↑




                   ╭───╮
                   │ 5 │
 ╭───╮                                  ╭───╮
 │ 1 │                                  │ 4 │

There’s also a peg in between the middle hoops.

Each team has one ball. This definitely is not how croquet is supposed to be played, but it makes things more fun and is also your only option if you have less than three balls available. Each team also has a mallet (“hammer-shaped thing”).

How to play (kinda)

Each team takes it in turn to hit their ball *once* with the mallet. Like in Pool. Also like in Pool, you get an extra shot if you score. “scoring” happens when you knock your team’s ball through the next goal. And if you do that, you get an (one) extra shot.

At this point, I should mention the actual flow we play:
One team (“us guys”) starts at hoop #1 and goes 1-2-3-4-5-6.
The other team (“you fat wasters”) either do the same which makes things more fun when you involve croqueting/roqueting (see below), but which is also not correct according to “the actual rules”. If you’re bothered about such things, then the other team goes 3-4-1-2-6-5, so basically the same pattern as the first team but rotated by π radians.

The objective is to go through your sequence of hoops TWICE (note: not quite correct, the order for the second time is slightly different according to “the actual rules”), then to hit the weird little peg that’s in the middle.

So each team is trying to score 12 goals hoops, then hit the middle peg to win. This also isn’t correct according to “the actual rules”, as there’s some point-scoring system involved too, but keeping track of points is difficult after 38 pints of stella so we apply some “UX design” to “the actual rules”.

Where it gets fun/daft/pretentious

This brings me onto the croqueting and roqueting crap. This is where the game sounds kind of pretentious and silly if you use “the actual names” for things. If on your turn, your ball hits the enemy’s your opponent’s ball, then it has made roquet on that ball and that ball is now fucked croqueted, and you get an extra hit. This extra hit is a croquet stroke and you start it by first moving your ball so that it’s touching the ball that you croqueted. Then you hit. If in this extra stroke, you hit and move the roqueted ball and do so without violating any of “the actual rules” then you get an extra hit.

Extra hits don’t accumulate though. If you hit the croqueted ball and also put yours through a hoop, then you only get one extra hit not two. If you roquet (“hit”) the other team (“enemy”)’s ball and also put yours through a hoop then you only get one extra stroke (but still get an extra one if you move the croqueted ball on your next stroke).

If you knock the other team (“fat bastard”)’s ball through a hoop then even if yours goes through, you don’t get an extra turn and instead they get a point (which doesn’t matter since we don’t do the “points” thing). You can substitute this “point” by requiring the fouling team to get in another round of stella.

And that, fellow monkeys, is not actually how you play croquet.

Also, if you go past a “goal” then you can’t just go through it in the opposite direction. You have to go behind it again and go through it in the “correct” direction, otherwise Zalgo will rise through the center and o̰̤̮̱̲h̖ ̻͞m̗̗̼͍̜̗̼y̫̜̪̰͔̣ ̷̰̝̦̙̘g͎͟o̜̝̗̪̼̹d̵̲͚̜̙ i̫̣̮̫͕̞t̩͓̹̖̹̤̰̼ ̡̪̭̗̼̭͠b̴̟͇͡u̮͇͎͔̺r̲͉n̰̼̱̻s̸̵̤̫̯̘̰̰͇ͅ ͈͘i̴̢͚̺̱̫̳͕͈ͅt͏̰͚͇̦͎͚̭̮̥ ̧҉̯̪̣̮b̨͖̯͔̼͔̤̺̝̭u̧̲̗͓͖̝͉͓͓r̗͙̬̟̺̫͓̟̼n̳̯͟͜ͅs̼̹ ͙͕̦̮̱̻m̧̬̺̲͍̹a̛̯̮̫͡k̝̠͈̕e͓͇̼̹̘̫̻ ̹̞̩i҉̧͙͔͖͟t͞҉͙̲͈̰͓͈̬̕ ̛̼͈̞s̘̠̱͎̠̀t̖̤͕͚̹͖́͠o͕̼̖͉̻͔̕ͅp҉̷͓͇͎ ̵̲̻͉̤̩̳̩̹͢i̷̗̪̪̣͕̬͇̳̻͎͚͔̩͎̯͡ ͏̦̳͔̞́͢c̴̵̟͓̱̣̻͖͉̪̭ͅà̴̳̟͔͚̺̩̩̖̯̰͔̖͟͟ͅͅn̵̴̨̥̫͉̗̤͓̙̻͕̠͚͔͟ṭ̹̱̺̭̪͢ ̛̮̣̳̦̭̞̼̺̀͜ţ̶͇̜̭͉̫̫̲̣́ͅa̷̫̣͍̺̫̟͍̦͇̤̳̕͡͠͠k̸̡̩̼͈͇̕e̸̘̝̻̯͉̟̰̙͎͇̕͟ ͏̶̡̥͇̝̬̦̱̭͔̞̙͍̟̳́i̧̛̜͎͈͇̕͘͢t̷͚̖͇̫͉͎̲̼̭̪̕͞ ̢̱͍̲͙͙̪̤̻̲͎̞͙̳̣͟a͏̴̢̟͚͇̠͙̫̹̰̬͕͖̗ǹ̷̸͕̼͓͖̳͇̗̠̫̜͢͞ͅy̴̡̡҉̼̦͔̪̦ ̷̨̢̡͇͚͕̭̮͡m̵̼͉͎̘͎̤̯̖͔͘ò̸̝͙̹͖̮̲͍͙̲̜̜͎̘̬̯̫͝r̢̛̻̹̘̪̩̼̘̮̟̯͘͜͢é̖̟̝͚͚̟͉͍̲͇͓̫͈̞̝͢͡

Arctic storm and more aurora

The Pi-day solar storm in 2016 was quite powerful (four terawatts), but unfortunately Kiruna was cloudy that night. The night after however, was somewhat clearer.

On my walk home, I was suddenly aware of green bands in the sky, one crossing over the moon. It was a full moon, so they couldn’t be aurora since aurora would be drowned out by the moon’s brightness. But these bands ran across the full length of the sky and were slowly moving… I rushed home to get my camera and tripod then headed out again.

We had strong winds that kept trying to knock my tripod over (despite it being set into an inch of ice), and the aurora kept appearing and stopping in different parts of the sky, so it was hard to photograph. Added onto that, my D5100 doesn’t have great sensitivity, so I couldn’t capture this at a decent frame rate to really show how fast-moving and detailed the sky was – but it’s still my best aurora clip yet!

After I got back home, the wind became more severe. There was a strong airflow coming *in* through the extractor in the bathroom. We lost power completely for several hours, and lost internet for several days. At the time of writing (five days later) many buildings here still have no internet connectivity – and out of the ones that do, none have wifi with easily-crackable WEP encryption for me to freeload :(.

Box packing: printing a load of photos at low cost

I wanted to publish online, and also to print, some of my favourite travel photos from the past two years. After going through my collection, I had slightly over a hundred favourites. These were of different sizes and orientations. I also wanted to add text captions to them.

Printing 100+ odd-sized photos individually would be quite expensive, wasting a lot of paper, so I opted to pack the annotated photos onto A0 posters (841x1189mm area) then print just a few A0 posters, which could be cut down as needed to separate the individual photos.

Doing this all manually would have been a boring and time-consuming procedure, so I automated it.

Automated “favourites” collection, linked to on-line photo stream

First, I created a “FAVOURITES” file and a “Print” folder:

  ~/photos/
    FAVOURITES        <---- Favourites list
    000 Collection/   <---- Symbolic links to favourite photos
    ...
    081 Iceland day 1/
    082 Iceland day 2/
    ...
    198 Party in Helsinki/

Then I added the filename of each “favourite” photo to the FAVOURITES file, one per line. Since the photos all have paths of the form “999 Album name/_DSC1234.nef”, I simply put the album nunber and photo number for each “favourite” photo in the file rather than listing full paths. A one-liner of Bash expanded these to full paths afterwards.

I then ran my new “update-favourites” script. This does five steps:

  1. Create symbolic links in ‘000 Collection’ folder, to each photo listed in ‘FAVOURITES’.
  2. Render each photo to some easily-handled format (JPEG or PNG). Store in ‘000 Collection/fullsize’.
  3. Scale each photo down and compress for web, adding a watermark (via my existing watermark script). Store in ‘000 Collection/web’.
  4. Create a web page (HTML file) for viewing the photos, grouping them by album.
  5. Upload the scaled-down, watermarked photos to my web server. Also upload the HTML file.

A downscaled, watermarked image:

Iceland, watermarked

Now I can just add/remove paths to photos to the FAVOURITES file, then run “update-favourites”, and after a few minutes my photo stream will be updated with the new photos (downscaled, watermarked and compressed).

Downscaling, watermarking, and uploading new photos to my stream is basically a one-liner in the terminal now.

Another bonus of this is that the entire ‘000 Collection’ subtree can be reproduced from the source photos and the FAVOURITES file. So the size of my photos backups has only increased by the size of the FAVOURITES text file – I don’t have gigabytes of duplicated photos.

Optimising for print

I created another folder for managing printables:

  ~/photos/
    FAVOURITES
    000 Collection/
    000 Print/         <---- Print folder
      large/           <---- I want some photos to be larger than others
      small/
      annotated-resized/
    ...
    081 Iceland day 1/
    082 Iceland day 2/
    ...
    198 Party in Helsinki/

From the ‘fullsize’ (not watermarked) renderings from the previous script, I can copy photos into the ‘large’ and ‘small’ folders in the ‘Print’ folder.

I then have four separate scripts to automate different steps of the print layout process (and also a shared configuration which is sourced by each of those scripts). The scripts are as follows:

  1. Index generator – this creates a human-readable TSV-format table listing:
    • The filename of each photo
    • The desired output size (small/large)
    • The image dimensions (in pixels)
    • EXIF data (shutter speed, aperture, focal length, timestamp)
  2. Annotator – this scans the EXIF data of the indexed photos for comments, and prompts me to modify/add comments to the photo metadata. The comments specify the photo location and the photo title.
  3. Renderer – this uses ImageMagick to pad the image, add text below it (photo title, location, EXIF data), add a border to it, and also a margin. The resulting images are stored in the ‘annotated-resized’ directory. These files depend on the configured size limits for “large” and “small” photos, but not on the desired output page size.
  4. Layout generator – I wrote this in Python, it (very approximately) solves the (NP-hard) 2D box-packing problem. It generates a layout which places images on the page such that:
    • Images do not overlap
    • Wasted space between images is kept fairly low (so less pages are needed, ergo lower cost)
    • The order of the photos is roughly chronological, so photos are easy to find.

    It has two different layout strategies: one wastes less space while the other preserves ordering better. Both strategies require only a single pass over the image index so they are quite fast. They are essentially Markov processes, with the layout as the state and the dimensions of the next image as the random input.

    After generating a layout, the layout is exported as an SVG file, with coloured boxes representing the images and with each box numbered to indicate which image should be placed in it.

    Immediately after exporting the SVG layout, ImageMagick is invoked to render the actual collage which will be then printed.

The index generator just produces a text file, while the annotator just stores text metadata to the images. The renderer generates captioned, boxed image tiles such as:

Icebar, Stockholm

The layout generator produces a layout like this (click to view in new tab):

layout

It then renders each page, producing ready-for-print images like these:

Montage of box-packed pages

Automation paying off

After initially rendering with large (12mm) text, large padding and margins (10mm each), I decided that I didn’t like the amount of white-space in the resulting pages.

After changing a dozen numbers in the configuration file, I re-ran the render script and the layout script. One coffee later, all images had been re-labelled, re-framed, and the layout had been re-calculated and re-generated.

I then decided that printing onto A0 paper would cause a headache when I try to take these poster rolls onto a RyanAir flight to the UK – so I changed one line in the configuration, re-ran the layout script, and was left with a new collage to print on six pieces of A1 paper instead three pieces of A0.

I then wanted there to be less “large” photos, so I moved some of the less impressive ones from the “large” folder to the “small” folder. I then ran scripts 1, 3, 4 again (build index, render annotated/padded tiles, generate and render layout). So three lines of shell later, I had new montages on my screen, which looked ready to print.

Without automation, I would have had to re-size and re-annotate each image manually, then manually lay them out to form the montages.