That middle step is a browser-side canvas pipeline, and it is the least glamorous and most bug-prone code I have written. This post is about the geometry it has to solve and the four bugs that took me longest to find — all of which failed silently, which is the worst kind.

The problem in one sentence

A sneaker upper is not one surface. It is a set of flat panels cut from a hide, printed, then sewn together — 2 panels on our slipper, 4 on the blade pattern, 10 on the everyday sneaker, 14 and 18 on the two low-tops. Sixty-six panels across eight styles.

So "print this image on a shoe" decomposes into: for each panel, take a rectangular region of the user's artwork, scale it to that panel's production resolution, mask it to the panel's actual outline, and flip it if the pattern piece is mirrored.

The data model

Every panel is four numbers and two files:

{
  id: 1,
  sampleBox: { x: 112.24, y: 29.89, w: 440.06, h: 455.83 }, // where to read from the artwork canvas
  width: 1342, height: 1106,   // production raster for this panel
  mask: 'piece-01-mask.png',   // the panel outline, as an alpha mask
  mirrored: false
}

The artwork itself sits on a logical canvas — 611 × 800 for the low-top, roughly 3:4. Coordinates in sampleBox are in that space, so the same layout can be reprinted at any physical scale without touching the data.

The cutting step is then genuinely short:

const cut = new OffscreenCanvas(p.width, p.height);
const ctx = cut.getContext('2d');
if (p.mirrored) { ctx.translate(p.width, 0); ctx.scale(-1, 1); }
ctx.drawImage(artwork, sb.x * s, sb.y * s, sb.w * s, sb.h * s, 0, 0, p.width, p.height);
ctx.setTransform(1, 0, 0, 1, 0, 0);
ctx.globalCompositeOperation = 'destination-in';
ctx.drawImage(mask, 0, 0);

Eight lines. It took a week to make those eight lines trust each other.

Bug one: the masks looked like masks but were not

The panel outlines came from the pattern department as PNGs. Some of them were real alpha masks — opaque inside the panel, transparent outside. Others were exported from a design file: white shape, grey backdrop, red construction lines.

The second kind looks correct in any image viewer. It is not correct for canvas.

Canvas compositing is premultiplied. An RGBA pixel of (255, 255, 255, 0) is stored as (0, 0, 0, 0) — the colour is discarded the moment alpha hits zero. So a "white shape on transparent" export, where the white actually carries alpha = 0, arrives as pure transparent black. drawImage with destination-in then erases everything. No exception, no warning, just an empty canvas.

I tried to patch it at runtime: read the pixels, find the bright ones, rebuild alpha from luminance. It never worked, because by then the RGB values were already gone. The information was destroyed at export time, not at draw time.

The fix was to stop patching at runtime and rebuild the masks offline, once:

// per panel, decide which encoding it actually uses
const hasBlackCover = blackPixels / total > 0.01;  // a grey overlay layer, alpha ~153, luminance < 70
let on;
if (hasBlackCover) on = !isBlackCover(r, g, b, a);  // the cover marks what is *not* the panel
else               on = a > 120;                    // honest alpha mask

66 masks rebuilt as binary alpha, 658 KB total — smaller than the originals, and now unambiguous. The runtime code went from ~40 lines of guessing to a validity check.

Lesson: if a shape has to survive a compositing step, the shape has to be in alpha before it reaches the canvas. Luminance is not a mask.

Bug two: garbage coordinates fail silently

One panel's sampleBox came out of the geometry export as:

{ x: -2.18e+22, y: -2.64e+22, w: 4.81e+22 }

drawImage with those numbers throws nothing. It draws nothing. There is no error to catch, no onerror, no rejected promise — the panel just renders blank and you assume your mask is wrong.

I spent most of an afternoon on the mask before printing the source numbers.

The guard is now a magnitude check rather than a sign check, because negative coordinates are legitimate — a panel can sample from outside the artwork canvas and let canvas clamp it:

const sane = (sb, mw, mh) =>
  Math.abs(sb.x) <= mw * 4 && Math.abs(sb.y) <= mh * 4 &&
  sb.w > 0 && sb.h > 0 && sb.w <= mw * 4 && sb.h <= mh * 4;

Lesson: validate geometry against the canvas bounds it is supposed to live in, not against "looks reasonable".

Bug three: revokeObjectURL kills the image you are still drawing

The first version loaded uploads the obvious way:

const url = URL.createObjectURL(file);
const img = new Image();
img.src = url;
URL.revokeObjectURL(url);   // "free the memory"

This works exactly once. Redraw the panel grid — switch style, change the layout — and every drawImage silently produces an empty canvas, because the blob URL backing the image is gone. The <img> element still reports naturalWidth > 0, which is what made it confusing.

createImageBitmap is the right tool here: it decodes once into an immutable bitmap that stays valid until you close it, and it is also faster to draw repeatedly.

const bmp = await createImageBitmap(file);
userImage?.close?.();
userImage = bmp;

Lesson: if a decoded image is going to be drawn more than once, own the bitmap, not a URL that points at it.

Bug four: fast clicks race the render loop

Switching styles fires an async render. Switch twice quickly and the first render's results land after the second one's, painting the old style's panels into the new style's grid.

The fix is a monotonic token checked at every await point:

let renderSeq = 0;
async function render() {
  const mySeq = ++renderSeq;
  for (const cell of cells) {
    const mask = await getMask(cell.panel.mask);
    if (mySeq !== renderSeq) return;   // a newer render owns the canvas now
    // ...
  }
}

Unglamorous, and the only version that survives a user with a fast mouse.

What the numbers look like

The pipeline is not just slicing; it is upscaling, and that decides whether a user's file is good enough.

To fill a 1342-pixel panel from a 440-unit window on a 611-unit canvas, the artwork needs to be about 1,860 px wide to arrive at full resolution with no interpolation. Across the library, the median enlargement is 2.9× and the worst case is 4.8× (the 360 × 566 window feeding a 1598 × 1958 panel).

That is a real product constraint disguised as a geometry detail. Telling someone "your image needs to be 2,000 px on the short edge" is only credible if you can derive it from your own pipeline — which is exactly what the sampling windows give you.

Why I shipped the tool instead of a diagram

The pipeline runs entirely in the browser, so I exposed it: upload an image, pick a style, and see every panel of that style cut from your artwork at production size. No upload, no account, no server round trip — the same destination-in compositing you just read about.

It turned out to be a better explanation than any diagram I could draw, and it cost nothing extra to run: bukefootwear.com/panel-preview.

The written version, with all 66 panels and the per-style numbers, is at bukefootwear.com/guides/artwork-across-shoe-panels.

If you are doing anything with panel-based printing, garment mapping or texture atlases, I would like to hear how you handle seam continuity — that is the part I still consider an open problem rather than a solved one.