DEV Community: mcinstinct

Printing a cross-stitch chart is the hard part: symbols, skein math, and tiling 262,144 cells

mcinstinct — Mon, 28 Sep 2026 15:36:38 +0000

Nobody frames a screenshot of a cross-stitch app. The artifact that matters is a printed chart taped to the wall next to the couch, and print is unforgiving in ways screens are not. Symbols must stay legible at 6 points. Page edges must not eat stitches. And the legend has to answer the only question that costs money: how many skeins do I buy?

I work on Threaded (https://threaded.diy), a browser studio that turns photos into cross-stitch and needlepoint patterns. Our first post walked the image pipeline; this one is about the PDF at the end of it. All the code is real.

Ninety symbols, and every one has to survive a laser printer

Each thread color in a chart gets a symbol. Screens make this easy (just color the cells); paper makes it hard, because your chart prints in black and white more often than not. We keep a fixed glyph alphabet:

export const LABEL_CHARS =
  "●■▲▼◀▶◆⬟⬢⬣⯁○□△▽◁▷◇⬠⬡◯◐◑◒◓◧◨◩◪⬗⬖★☆✦✧✪✯✶✷❂✚✕✖✜⊕⊗⊙⊠♥♦♣♠♡♢♧♤⬮⬯⚑⚐☀☁☂☘✔✿ΑΒΓΔΕΖΗΘΙΚΛΜΝΞΟΠΡΣΤΥΦΧΨΩ⋈⋂⋃⊖⊘⋉⋊≈$%#@&!?"
    .split("");

Ninety-ish glyphs, ordered so the most visually distinct pairs land first: filled vs. outline (●/○), orthogonal vs. diagonal (■/◆), half-filled circles (◐◑◒◓) for the middle of the alphabet where confusion is most likely. Filled and outline variants of the same shape are never assigned to adjacent colors - adjacent palette entries are usually near each other in color space, and near-identical colors with near-identical symbols is how miscounts happen.

The symbol ink also adapts to the cell. A dark thread gets a white glyph, a light thread gets black, decided by plain luma:

export function isDarkColor(hex: string): boolean {
  const v = hex.replace("#", "");
  const r = parseInt(v.slice(0, 2), 16);
  const g = parseInt(v.slice(2, 4), 16);
  const b = parseInt(v.slice(4, 6), 16);
  return 0.299 * r + 0.587 * g + 0.114 * b < 128;
}

Yes, it is the ITU-R 601 luma from 1982. It outperforms fancier contrast formulas here because the decision is binary and the input is a solid fill, not text on a gradient.

The half-pixel grid line trick

Grid lines help you count; grid lines also drown symbols when cells get small. Two rules came out of real print tests:

export function shouldDrawGridLines(cellSize: number): boolean {
  return cellSize >= 3;
}

Below 3 pixels per cell the lines cost more legibility than they add, so they vanish. And when lines do draw, they are stroked at x * cellSize + 0.5 - the classic canvas half-pixel offset. Without it a 1px stroke straddles two physical pixels and prints as a fuzzy gray 2px line. With it, the line lands exactly on one row of device pixels. This one character (+ 0.5) is the difference between a chart that looks printed and a chart that looks photocopied.

Skein math, or: the legend is a shopping list

The thread table is the page stitchers photograph before driving to the craft store. For every color it shows symbol, brand and code (DMC 310, Anchor 403, ...), stitch count, yardage, and skeins. The skein estimate is where most apps hand-wave; we made the constants explicit and honest:

export const SKEIN_PIECES = 17;        // a pulled-apart skein yields ~17 pieces
export const USABLE_PER_PIECE_IN = 15; // usable inches per piece after tails
export const THREAD_PER_STITCH_NUM = 6; // inches of floss per stitch = 6 / fabric count
export const STRANDS_PER_SKEIN = 6;
export const DEFAULT_STRANDS = 2;      // most people stitch with 2 of 6 strands
export const YARDS_PER_SKEIN = 8.7;    // a standard DMC skein

The math: one stitch on 14-count aida at 2 strands consumes 6/14 inches of a strand. A skein gives you 17 pieces x 15 usable inches x (6 strands / 2 used). So stitches-per-skein is computed per color, divided into that color's actual stitch count, and rounded UP - because "you need 1.1 skeins" means you buy 2, and a chart that tells you 1 sends you back to the store mid-project. Every constant is wrong for somebody (needlepointers on 13-mesh use more thread, some stitchers waste less), which is why the fabric count and strand count are inputs, not assumptions baked into the output.

Tiling 262,144 cells across Letter pages

A 512x512 pattern does not fit on a page. It becomes a poster you assemble:

export const SECTION_COUNTS = [1, 4, 9, 16]; // 1x1, 2x2, 3x3, or 4x4 pages
export const DPI = 150;                       // raster resolution per section

The grid splits into tiles with integer boundary math (x0 = floor(col * grid.w / cols)) so no stitch ever lands on two pages or none. Each section renders to canvas at 150 DPI, and the PDF assembles the pages in reading order with the section grid labeled on the key page. The document also embeds the Merriweather family directly, because a PDF that substitutes fonts at the print shop is a PDF that lies about symbol alignment.

What we deliberately did not build

No overlap duplication between sections. Overlaps sound helpful until you realize every duplicated stitch is a stitch you can count twice; clean tile boundaries plus a labeled key page do the job with zero ambiguity. No color blocks behind symbols on the key page (wastes toner, and the symbol IS the reference). No vector charts (canvas raster at 150 DPI prints identically everywhere and renders in milliseconds on a five-year-old phone).

Try it at https://threaded.diy - the full editor is free, so you can run your own photo through the pipeline and watch the chart take shape before deciding whether the printable PDF is worth Pro. If your estimate differs, the comments are open; the constants are right there to argue with.

Turning a photo into a cross-stitch pattern in the browser: the actual pipeline

mcinstinct — Sat, 26 Sep 2026 15:30:31 +0000

A photo you took this morning contains millions of distinct colors. A skein of DMC embroidery floss comes in a few hundred. A stitchable pattern wants maybe 10 to 40. Bridging that gap - automatically, in a browser tab, fast enough to feel instant - is the core engineering problem of a pattern maker.

I work on Threaded (https://threaded.diy), a browser-based studio that turns photos into cross-stitch and needlepoint patterns. This post walks through the real pipeline in our codebase, with the actual tradeoffs we made. No pseudocode: this is what ships.

Step 1: median-cut quantization, capped at 64 colors

The first job is palette reduction. We use median-cut quantization (via the quantize package) over the opaque pixels of the source image:

export function quantizeImage(
  image: ImageData,
  n: number,
): { palette: string[]; pixels: Pixels } {
  const { data, width, height } = image;
  const samples: [number, number, number][] = [];
  for (let y = 0; y < height; y++) {
    for (let x = 0; x < width; x++) {
      const i = (y * width + x) * 4;
      if (data[i + 3] === 0) continue; // fully transparent pixels don't stitch
      samples.push([data[i], data[i + 1], data[i + 2]]);
    }
  }
  // ...median cut down to n cluster centroids, then snap every pixel
  // to its nearest centroid
}

Two details matter here:

The cap is 64 colors (MAX_N), not a marketing number. More than ~64 distinct threads makes a pattern physically unenjoyable to stitch - every new color is another needle to thread and another symbol to track on the chart. Most stitchers stay under 30.
Transparent pixels are excluded before sampling. A PNG with a knocked-out background should not waste palette slots on a background you'll never stitch.

The grid itself is capped at 512x512 cells and we accept source images up to 50 megapixels, since phone cameras don't ask permission.

Step 2: snapping the palette to real thread you can buy

A quantized palette is useless if it says "#B7414E" and your local shop sells skeins, not hex codes. So every palette color gets matched to the nearest color in a real thread library - DMC, Anchor, Cosmo, Madeira, and 45 more, 49 libraries in total:

export function nearestBrandColor(hex: string, shorthand: string): ThreadColor {
  const brand = BRAND_BY_SHORTHAND.get(shorthand);
  if (!brand || brand.colors.length === 0) {
    throw new Error(`Unknown or empty brand: ${shorthand}`);
  }
  const target = hexToRgb(hex);
  let best = brand.colors[0];
  let bestD = Infinity;
  for (const c of brand.colors) {
    const d = dist2(target, hexToRgb(c.hex)); // squared Euclidean distance in RGB
    if (d < bestD) { bestD = d; best = c; }
  }
  return best;
}

Here's the honest part: squared Euclidean distance in RGB is not perceptually uniform. CIEDE2000 exists precisely because two colors can be far apart in RGB but look identical to the eye, or vice versa. We know this. We ship it anyway, deliberately:

It's O(palette x brand) with zero dependencies, and it runs on every keystroke in the editor. A CIEDE2000 implementation with Lab conversion is heavier, and the difference at thread-palette granularity is smaller than the difference between dye lots.
The match is palette-relative. Even if a red lands one skein off from perceptually perfect, every red in the photo lands on the same skein, so the pattern stays internally consistent. Consistency is what the eye reads.
Stitchers routinely swap one or two colors by preference anyway. The editor is built around that: click a cell, flood-fill a region, reassign a color to a different skein, and the whole legend updates.

If you're building something similar and only take one thing from this post: perfect colorimetry is not the bottleneck. Iteration speed is.

Step 3: killing confetti stitches

Quantized photos produce "confetti" - single isolated stitches of one color marooned inside a field of another. Confetti is the number one reason printed patterns get abandoned halfway through: each orphan stitch means threading a needle for exactly one X.

We run a despeckle pass that examines each cell's 8-connected neighborhood and relabels orphans into the surrounding region:

const NEIGHBORS = [
  [-1, -1], [0, -1], [1, -1],
  [-1, 0],           [1, 0],
  [-1, 1],  [0, 1],  [1, 1],
] as const;

export function despeckleRegion(pixels: Pixels, cx: number, cy: number, reach = 1) {
  // flood-fill the region around (cx, cy), then reassign cells whose
  // neighborhood votes overwhelmingly for a different color
}

This one pass does more for "does the finished piece look like the photo" than any color-space upgrade ever will. Faces survive. Text survives. The 400 singleton stitches that made your grandmother's pattern software unusable do not.

Step 4: the PDF is the product

The on-screen editor is only half the job. The artifact people actually use is a printed chart, and print has hard requirements a screen doesn't:

every color gets a distinct, legible symbol (and 64 distinguishable glyphs is genuinely hard),
a legend maps symbol to thread brand, code, name, and stitch count,
the chart tiles across pages with overlap marks so you don't lose your place,
fonts must be embedded or Kinko's will freelance for you.

We generate the PDF client-side with the Merriweather family embedded directly in the document, so the file prints identically anywhere. Stitch counts per color are computed during export, because that's what tells you how many skeins to buy.

Why all of this runs in your browser

Everything above - quantization, thread matching, despeckle, PDF generation - executes locally in the tab. Your photos never touch our servers. That started as a privacy decision (people stitch their kids, their dogs, their weddings), and it turned out to be an architecture decision too: no upload round-trip means the editor can re-run the pipeline on every slider movement.

If you want to see the pipeline from the other side, Threaded is free to try at https://threaded.diy - upload a photo, drag the color-count slider, and watch steps 1 through 3 re-run in the time it takes to move your thumb.

Happy stitching. And if you've solved the CIEDE2000-at-60fps problem in a way you're proud of, I genuinely want to read about it in the comments.

I Built a Free Library of 100,000+ Custom Emojis for Microsoft Teams

mcinstinct — Sat, 12 Sep 2026 06:43:46 +0000

If you've ever tried to add a custom emoji to Microsoft Teams, you know the two problems: finding anything good, and getting it sized right. Teams, Slack and Discord all have different limits, and half the "emoji resizer" tools out there are built for Twitch streamers.

So I built Teamsmoji:

100,000+ free custom emojis, memes and reaction GIFs, searchable and organized into packs (party parrot, blob cats, dancing bananas...)
Every emoji downloads at the right size for Teams, Slack or Discord
A free Emoji Maker that turns any image, GIF or video into a perfectly sized emoji, entirely in your browser: crop, GIF speed control, video-to-GIF, and party effects (rainbow, spin, shake, pulse, wave)
Short guides on adding custom emojis to Teams, Slack and Discord, including what to do when your admin has locked uploads down

No login, no watermark, and nothing leaves your device in the maker.

Would love feedback from anyone who runs a workspace - what's missing?