DEV Community: David Gao

Building a Photo to Coloring Page Tool with WebAssembly and AI

David Gao — Fri, 16 Oct 2026 05:05:46 +0000

A photo of a dog can become two very different coloring pages. One keeps the fur, fabric and small edges close to the source. The other redraws the dog with broader outlines and more room for crayons.

While building ColorWillow, a printable coloring site for parents and teachers, we kept both approaches: a free conversion running on the user's device, and an AI service that can simplify and restyle a photo.

The interesting engineering work was deciding what each path should promise, how much work belongs in the browser, and what happens when a remote generation takes longer than the page stays open.

The same photo reveals the tradeoff

Start with this dog resting in a person's arms.

Photo by Kristin Hardwick on StockSnap, CC0 1.0. Resized for this example.

Free conversion. Fine fur and the checked shirt remain visible as many small lines.

AI conversion with Classic style, Medium detail, Standard lines and Keep background. It leaves larger white areas, but changes the dog's facial features and coat markings.

That last point matters. A cleaner illustration can be easier to color while being less faithful to the individual animal. We show both methods so people can choose based on their own photo.

Running a line drawing model in the browser

Our free photo to coloring page converter uses an ONNX line drawing model executed through ONNX Runtime Web's WASM backend.

The local model is derived from Informative Drawings by Caroline Chan, Frédo Durand and Phillip Isola. We retain the model and runtime license notices with the distributed assets.

Although the interface calls this mode Free and the remote mode AI, the local path also uses machine learning. The distinction is where the processing happens and how much the picture is reinterpreted.

The pipeline is:

Decode the selected image and fit it within a bounded working size.
Composite transparency onto white.
Convert RGBA pixels into a normalized RGB tensor.
Run the model in a dedicated Web Worker.
Turn its single channel output into a grayscale PNG.

Here is the session setup, shortened from our worker:

import * as ort from 'onnxruntime-web/wasm';

// This code already runs inside our own Web Worker.
ort.env.wasm.numThreads = 1;
ort.env.wasm.proxy = false;
ort.env.wasm.wasmPaths = assetPrefix;

const session = await ort.InferenceSession.create(modelBytes, {
  executionProviders: ['wasm'],
  graphOptimizationLevel: 'all',
  enableCpuMemArena: true,
  enableMemPattern: false,
});

We use one inference thread in this implementation. The ONNX Runtime configuration guide explains the additional cross origin isolation requirement for WASM multithreading. Running inside our own worker lets us control cancellation and its lifetime directly; we do not enable the runtime's additional proxy worker.

The model file is about 8.6 MB, excluding the runtime. We fetch it from a versioned asset directory and verify its expected byte length and SHA-256 before creating a session. The JavaScript runtime and WASM binaries must also come from the same build, as the ONNX documentation specifies.

The first conversion includes downloads and initialization. WASM moves inference onto the device, but loading the page and its assets still needs network access.

Preprocessing and memory need explicit limits

A successful session initialization does not guarantee a useful image. The model expects RGB channel planes, while canvas gives us interleaved RGBA pixels.

Our conversion code preserves the aspect ratio, pads the working dimensions to multiples of four with a minimum of 32, and uses reflected pixels at the boundary. After inference, it removes that padding.

The channel conversion looks like this, with padding omitted for clarity:

const plane = width * height;
const data = new Float32Array(3 * plane);

for (let i = 0; i < plane; i++) {
  data[i] = rgba[i * 4] / 255;
  data[plane + i] = rgba[i * 4 + 1] / 255;
  data[2 * plane + i] = rgba[i * 4 + 2] / 255;
}

const input = new ort.Tensor('float32', data, [
  1, 3, height, width,
]);

The current device policy uses a 512 pixel maximum working edge on phones and tablets, and 1024 on desktop. These are inference dimensions; they do not imply that every source photo gains printable detail at that resolution.

Memory use includes decoded pixels, tensors, intermediate activations, the model and PNG encoding. We close image bitmaps, dispose tensors and shrink temporary canvases when their work finishes.

We also separate line thickness adjustments from inference. A small grayscale buffer lets us strengthen neighboring dark pixels without running the model again. On phones and tablets we terminate the worker after a result; on desktop we allow a short idle window before releasing it. The grayscale buffer can survive that worker teardown so an adjustment does not need to reload the model.

Free conversion does not upload the selected photo. Choosing to save its result to an account is a separate upload action. The remote AI path has a different data flow, so the interface explains it separately.

AI gives more control over the drawing

The AI photo to coloring page converter can request simpler details, a simplified background, different line weights and illustration styles.

These are structured product options. The server validates them and builds the generation instructions; it does not accept an arbitrary prompt from the browser.

That gives each control a specific job. Simple detail asks for larger coloring areas. Bold lines strengthens contours. Simplifying a background should preserve the main subjects. A style choice should keep the output usable as black outlines on white paper.

Those instructions express intent, not a guarantee of exact preservation. In the dog example, the AI reduced texture but changed recognizable details. Comparing the result with the original remains part of using the tool.

Remote generation needs a durable job

The browser path can finish with a local PNG. Remote generation introduces an upload, an external provider, private storage and credits.

Our backend runs on Cloudflare Workers. A Durable Object with SQLite storage coordinates generation state and credit reservations, while private R2 storage holds originals and results.

The job progresses through queued, dispatching, uncertain or pending output states, and finally a terminal result. An uncertain provider response stays unresolved while the system checks what happened. A browser timeout alone does not prove that generation failed.

Three details make this manageable:

Repeated submissions have an identity. Reusing a job ID with the same input and options returns the existing job. Reusing it with different parameters is rejected.
Processing uses a lease. A worker claims the job temporarily, and state changes check its lease token so an older attempt cannot complete over a newer claim.
Completion follows storage. The runner validates and normalizes the returned image, records output metadata, writes it to private storage and confirms the stored object before completing the job and consuming the credit reservation. Confirmed failures release the reservation.

The output write and the database transaction are separate operations. Keeping an intermediate output state gives recovery code something concrete to reconcile if execution stops between them.

Private images also need authorization at retrieval time. We keep them separate from the public coloring library and check the requesting owner's access before serving them.

Choosing the path by the result

For this product, local inference is useful when someone wants a free outline that stays close to the photo, with processing on their device. Remote AI is useful when they want broader coloring areas or a different illustration style and accept that details may change.

Both paths end with a practical task: inspect the picture, download it or print it, and color it on paper.

The wider ColorWillow library of printable coloring pages is available when a ready made illustration suits the activity better. Photo conversion adds another starting point: a familiar pet, object or moment that someone wants to turn into a page of their own.

Building a Mandala Maker: From a Single Stroke to Printable Art

David Gao — Thu, 15 Oct 2026 15:34:02 +0000

Draw a small curve, repeat it around a center, and it starts to look like a flower. Add another shape, and the whole pattern changes.

That interaction is the idea behind the mandala maker I recently added to ColorWillow, a website with printable coloring pages and tools for creating your own.

An actual Surprise pattern exported from the maker with rainbow ink on a black background.

The free online mandala maker combines freehand drawing, reusable shapes, and generated starting patterns. You can edit the result, download it as SVG, PNG, or PDF, or print it as a coloring page. Drawing and pattern generation run in the browser, without an account or image upload.

The interesting part of building it was deciding how much the tool should do for you, and how much control it should leave in your hands.

One stroke repeated around a center

The basic drawing model is small: record a stroke once, then render rotated copies around the center.

With eight repeats, each copy is rotated another 45 degrees. Mirror mode adds reflected copies, giving a different rhythm to the same mark. A loose curve can become a ring of petals; a short angular stroke can become a border.

SVG fits this well: define the original path once in <defs>, then use <use> to instance it at different angles. This is a simplified version of the rotation-only rendering step:

function rotatedCopies(pathId, folds) {
  return Array.from({ length: folds }, (_, i) =>
    `<use href="#${pathId}" transform="rotate(${i * 360 / folds})" />`
  ).join("");
}

The SVG viewBox is centered on (0, 0), so each rotation happens around the drawing center. The original path stays shared across its repeats, and the export retains vector geometry.

I keep the repetition settings with each stroke. Changing the symmetry control affects what you draw next, which lets one design combine different rhythms without unexpectedly rearranging earlier work.

There are also shapes such as petals, leaves, circles, and decorated fans. You can place one and drag to rotate it, then build outward from there.

The live editor combines a drawing surface, a generated starting pattern, and controls for individual layers.

Giving random patterns some structure

An empty canvas can be a demanding first screen. “Surprise me” gives you a complete pattern to react to.

The generator combines motif families, repeat counts, silhouettes, and levels of detail. Those choices sit inside layout rules: different elements occupy different distances from the center, and their sizes account for the space available between repeats.

I use a seeded pseudo-random sequence to make those choices reproducible. The core is small:

function seededRandom(seed) {
  let state = seed >>> 0;
  return () => {
    state = (Math.imul(state, 1664525) + 1013904223) >>> 0;
    return state / 4294967296;
  };
}

With the seed, density, and other inputs held fixed, the same generator recipe produces the same strokes. That lets the density control rebuild a pattern from a consistent starting point, rather than drawing a completely unrelated composition on every slider movement.

That structure matters. Repeating an elaborate petal too many times can turn its details into a knot of lines. Increasing density needs to preserve enough space for the pattern to remain readable.

Layer overlap needed attention too. Painting a petal white to cover the lines behind it would leave white patches on a dark or transparent export.

Instead, I wrap the accumulated earlier layers in an SVG mask: white keeps the existing ink, and a black copy of the new petal's boundary hides the covered area. I then draw the new petal's outlines above it. Using maskUnits="userSpaceOnUse" keeps the mask in the same coordinates as the artwork. The covered region becomes transparent, so the chosen background shows through.

The density slider gives people a way to explore simpler and more intricate versions. While a Surprise remains unedited, it can reshape that generated pattern live. After you edit a layer, density applies to the next Surprise, preserving the changes you have made.

These patterns come from geometry and composition rules running locally. They need no image-generation service or per-design inference call.

Keeping the generated result editable

The most useful property of Surprise is that its output uses the same drawing model as the rest of the editor.

Each repeated motif remains a layer. Select a petal layer and you can move, resize, recolor, or hide all of its repeats together. You can remove a busy border, open up the center, or add your own strokes.

Selecting one layer highlights its repeated petals together. The highlight is an editing guide and does not appear in the export.

Keeping structured drawing data makes that possible. A flattened image would lose the relationships between the original mark, its repeats, and its settings.

The SVG scene is derived from that data. The editor and exports share the rendering code, which helps keep the downloaded artwork consistent with what you were editing.

It also means a generated pattern can become something quite different through a few deliberate changes. Surprise supplies the initial composition; the layers give you a way to take it somewhere else.

Designing for both the screen and the printer

A colorful mandala on black makes a striking screen image. A coloring page needs a different presentation: clear black outlines, white paper, and space for pencils or markers.

Ink and output background are separate controls. Choosing a white export background keeps your ink colors; turning on Black & white produces black outlines. That distinction lets you explore color on screen and then prepare a paper version of the same design.

Rainbow rings use a shared radial gradient centered on the artwork. Colors change with distance from the center, so motifs around the same ring stay visually connected. Setting gradientUnits="userSpaceOnUse" makes the gradient use the drawing's coordinate system, rather than fitting a separate gradient into each shape's bounding box.

The same pattern exported with Black & white enabled and a white background, ready to use as a coloring page.

The formats serve different purposes. SVG keeps vector paths for scaling and further use. PNG provides a raster image. PDF places the artwork on A4 or US Letter, with an adjustable print size and a small paper preview.

PNG is rasterized from the SVG scene. The PDF embeds that rendered image on the selected paper size.

For a quick printable result, choose Black & white, keep the output background white, and select your paper size. If you would rather start with a finished illustration, ColorWillow also has a collection of printable mandala coloring pages.

Making it easy to return to a drawing

The maker saves up to ten editable drawings in the current browser. A saved drawing keeps its layers and settings, so you can continue adjusting it later.

There is also an editable-file download and a restore option. Browser storage can be cleared or become unavailable, so a downloaded file gives people a portable copy of work they want to keep.

This keeps the first session simple: open the page, try a pattern, and start changing it. Signing in is unnecessary for this tool.

Building it reinforced three choices I would make again: let a small gesture produce an immediate result, give randomness a composition to work within, and preserve enough structure for people to keep editing.

You can try the mandala maker yourself, or explore ColorWillow for more free printable coloring pages.

I would love to see what you make with it—and hear which parts of drawing, editing, or printing could feel better.