Resleeve started with a specific frustration: I wanted a clean, poster-style wallpaper of an album I'd been listening to, and everything I could find online was low-resolution, watermarked, or ugly. So I built it. The core idea was simple - pull album metadata and render it into something that looks designed - but the implementation turned out to be a proper engineering problem.

The data layer

Resleeve is built on the MusicBrainz API, an open, community-maintained music database. I wrote a wrapper around their REST API that handles artist disambiguation, release group resolution, and cover art retrieval via the Cover Art Archive. MusicBrainz's data model is more nuanced than most music APIs - it distinguishes between release groups, releases, and recordings - so understanding that hierarchy was necessary to reliably get the right cover at the right resolution for the right edition of an album.

The rendering pipeline

All image composition happens server-side with Pillow. There's no client-side canvas, no SVG export - the final image is built pixel by pixel in Python and served as a PNG. The render function:

  • Fetches and decodes the high-resolution cover art into a Pillow image object.
  • Samples the cover using a k-means colour clustering approach to extract a palette - dominant colour, a saturated accent, and a readable foreground - that adapts to both dark and light artwork.
  • Composes the layout on a fixed canvas: artwork positioned to a grid, tracklist split into balanced columns, runtime and metadata in a footer strip.
  • Exports at wallpaper resolution with correct DPI metadata.

The design constraint that drove everything

The hard problem in Resleeve isn't fetching data or composing images - it's writing layout rules that hold up across every album. A minimalist white cover and a dense psychedelic painting are both valid inputs. A seven-track EP and a thirty-song deluxe edition both need to produce something legible and balanced. Every layout decision - column count, type scale, padding, how the palette gets applied - had to be expressed as an adaptive rule rather than a fixed value.

This meant building a small system of layout logic: tracklist column balancing that splits tracks as evenly as possible regardless of count, font size scaling tied to available canvas area, and a palette application layer that determines contrast ratios before choosing whether to render light or dark text. The code that does this isn't complex, but writing it required making a lot of explicit decisions about what "looks right" means and encoding those decisions in a way a machine can follow.

The engineering was the straightforward part. The hard part was making judgement calls that scale.

What it shipped with

V1 launched with a single layout template, a Bootstrap frontend, full MusicBrainz integration, and a barcode Easter egg embedded in the output image. It handled everything from standard albums to multi-disc releases, and the palette extraction produced results I was genuinely happy with across a wide range of artwork styles.

V1 seemed solid. So why did I rebuild the whole thing from scratch? That's the next post.

For the finished project overview, read the Resleeve case study.