People send us a 1200px PNG, it looks crisp in the browser preview, and then the printed shoe comes back with a slightly soft edge on one panel. Not all panels. One.
That asymmetry is the interesting part. A sneaker upper is cut into flat panels — 2 on our slipper, 4 on the blade pattern, 10 on the everyday sneaker, 14 and 18 on the two low-tops. 66 panels across 8 styles. Each panel takes a different region of the uploaded artwork, so each panel magnifies that upload by a different factor.
If you assume "the image is big enough", you are assuming it for the panel you happened to look at.
So I stopped guessing and measured all 66.
The geometry that makes the numbers different
Each panel in our data file is four numbers plus a mask:
{
id: 4,
mask: "assets/panel-masks/DF2/piece-04-mask.png",
w: 702, h: 752, // production resolution
sb: { x: 197.83, y: 573.11, w: 146.7, h: 216.91 }, // region of the artwork it samples
mirror: false
}
w/h is how many pixels the printer wants for that panel. sb is the rectangle the panel reads from the user's artwork, expressed in canvas units (the canvas for that style — 611×800 for the low-top, for example).
The pipeline is: scale the artwork to cover the canvas, then for each panel crop sb, stretch it to w × h, and mask it to the panel outline. Which means:
magnification = w / sb.w
For that DF2 panel, 702 / 146.7 = 4.79. That single panel needs roughly five times the pixel density of the artwork compared to a panel that happens to sample a wide region.
The distribution across 66 panels
I computed w / sb.w for every panel (65 valid entries; one panel in XB2 has a dirty sb of 1e22 and is skipped in the tool):
| statistic | magnification |
|---|---|
| min | 2.40× |
| median | 2.91× |
| max | 4.79× (DF2 panel 4: 146.7×216.91 → 702×752) |
Nothing under 2.4×. So "the artwork is roughly panel-sized" is never true — every single panel is upscaling by at least 2.4×, and the worst one by almost 5×.
That number alone doesn't tell you what to ask users for, because magnification is relative to canvas units. Inverting it does: for a given upload width, how many panels can be rendered at 1:1 or better?
// required artwork width for a 1:1 render, per panel
// the binding axis is the larger of the two ratios, not just the width
const scale = Math.max(panel.w / panel.sb.w, panel.h / panel.sb.h);
const need = model.w * scale;
That Math.max is not cosmetic. A tall narrow panel — a heel strip, an eyestay — can be comfortably satisfied on the horizontal axis and still be short of pixels vertically, so measuring only panel.w / panel.sb.w overstates coverage at small upload sizes. With both axes in play, across all 65 panels:
| upload width (px) | panels rendered at 1:1 |
|---|---|
| 1400 | 25% |
| 1600 | 29% |
| 1800 | 54% |
| 2000 | 78% |
| 2400 | 98% |
| 3000 | 100% |
Median requirement: 1673px. 90th percentile: 2267px. Worst case: 2916px (KJ1BM, panel 6).
What we changed because of this
Before: "upload a high resolution image, at least 1000px".
After: short side ≥ 2000px, and we tell people 2400px if they want every panel sharp.
2000px is the point where four out of five panels render at native resolution and the remaining ones are upscaled by 1.45× at most — which survives printing because output is leather at ~300 DPI equivalent, not a 4K display. 3000px is where the requirement stops growing; above that you are paying upload time for nothing.
Two things I did not do:
- I did not raise it to 3000px. The last 2% of panels cost every user a slower upload and a bigger file, for a difference nobody can see on a curved panel under stitching. 2000px is the practical knee.
- I did not silently upscale in the pipeline. A blurry 900px image that we quietly resample to 2900px looks worse than an honest soft render, because interpolation adds ringing around edges before the print does its own.
The two silent failures that cost more than resolution
Resolution problems are visible. These are not.
1. Aspect ratio drift. The artwork is stretched to cover the canvas. If the uploaded image's aspect ratio differs from the canvas by 3%, nobody notices on screen — but the distortion is applied before the panel crop, so all 66 panels inherit it, and the seam between two adjacent panels stops lining up. Hard requirement: artwork ≥ canvas and the same aspect ratio, otherwise the pipeline stretches it and does not complain.
2. Multiplying by a dead alpha channel. This one is specific to canvas: if a mask PNG's visible content lives in RGB with alpha = 0 (which is what a designer's visual mockup export looks like), drawImage composites with premultiplied alpha and the RGB is multiplied by zero. You get a fully transparent draw. No exception, no console warning — the panel just renders empty. We hit it on 7 of 8 styles and now rebuild masks offline rather than trusting exports.
Both of these are "check your inputs" problems that no amount of extra resolution fixes.
A tool so users can check before ordering
Measurement is only useful if it reaches the person choosing the file. So the same geometry now runs client-side as a panel preview: upload an image, see the crop for every panel, in the browser, nothing uploaded to a server.
That is also how I found the dirty 1e22 sample box — a preview that draws 65 of 66 panels correctly is a better test suite than any assertion I would have written.
The takeaway
"High resolution" is not a spec. Every multi-panel print has a distribution of magnifications, and the useful question is not "is the image big enough" but "for which panel is it not".
If you are building anything that maps one image onto many physical pieces — shoes, garments, packaging, tile — spend an afternoon computing outputPixels / sampledRegion for every piece. In our case it turned a hand-wavy guideline into a number (2000px) that a support person can state and a user can check.
The full per-style table and the method behind it is published here: how much a shoe panel enlarges your artwork. The geometry write-up, including the four pipeline bugs that failed silently, is mapping one image across 66 shoe panels. And the panel-by-panel preview tool is at bukefootwear.com/panel-preview if you want to see the crops for our 8 styles.
Top comments (0)