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.

Laser cutting and constructive solid geometry (CSG)

My brother is an artist – he has business cards that reflect this quite nicely, using his artwork as the background behind his typography. I decided that I could also do with some “domain specific” business cards. (Micro-)miniature electronics such as tiny LEDs are a common gimmick nowadays, so I took a more mechanical route with my designs. A key criterion was that the design should incorporate sufficient complexity and domain knowledge that the average Google-graduate and script-kiddy couldn’t replicate it easily.

While 3D printing is nice, it isn’t great for producing precise planar objects, and can also be quite expensive and slow. Forms of CNC cutting (e.g. plotters, laser cutters) are more suitable, although getting a decent quote is proving to be a challenge.

There were several mechanisms that interested me and which would look “elegant” if embedded in a business card. These included:

The first would be difficult to get into an ultra-thin form-factor, and would have issues with friction. The third would be very complex, requiring a thin hairspring and repeatable manufacturing precision. So I’m left with some form of geartrain. The geartrain must work in any orientation, so some of the cool designs in that video which require gravity are not suitable. Epicyclic geartrains are generally simple to manufacture and look quite cool, so I settled for a simple planetary configuration.

I was relieved to find that I can use OpenSCAD and FreeCAD to produce designs for laser cutting, so I can use my existing software and acquired skills from designing 3D-printable objects for this laser-cut project.

The design will be cut from thin sheets of aluminium or steel, and perspex or polycarbonate. My name and contact details will be engraved into the underside of the transparent plastic, so the external face remains smooth.

A rendering is shown in the video below:

(Rendered with OpenSCAD, Imagemagick, FFMPEG, Bash)

OpenSCAD was never intended to produce high-quality renderings (Blender and POV-RAY already meet that goal very nicely), but it has done a respectable decent job nonetheless.

I designed another card, on the theme of “cloud computing”:

Selective USB power saving on Linux Laptop

When using a USB keyboard/mouse on my laptop, I found that if I started typing after a few seconds of not using the keyboard, it would drop the first few keys that I pressed. This is due to USB power saving being enabled on my laptop: USB devices are automatically suspended on inactivity.

Solutions to this problem online generally involve disabling USB power saving completely. That would be a very blunt solution and would hurt battery life. I want to keep the power-saving behavious for all devices excluding input-devices, so I can get a decent battery life, but without the dropped input events.

Initially, I used lsusb to get vendor/product codes for my Das Keyboard and mouse, then started adding udev rules for the devices. This was too precise a solution though, it would only affect my particular model of keyboard and mouse.

I wrote more general rules instead, to disable power saving for any input device:

/etc/udev/rules.d/92-usb-input-no-powersave.rules
-------------------------------------------------
ACTION=="add", SUBSYSTEM=="input", TEST=="power/control", ATTR{power/control}="on"

This rule just says “when a device is added, if it’s an input device and it has a «power/control» node in sysfs, write «on» to that node” – a value of “on” (in contrast to “auto”) for this node will result in power saving (notable autosuspend) being disabled.

Problem solved 🙂