DEV Community: tony huang

"Film look" is a contrast curve, not a noise stamp — what style presets actually change

tony huang — Mon, 26 Oct 2026 15:40:16 +0000

"Make it look like film" sounds like a texture request. It is really four separate changes to how your pixels behave, and the difference between applying them and just stamping noise on top is the difference between a photo that reads as scanned film and a photo that reads as a filtered phone shot.

Here is what actually changes, and how to tell what a tool did.

The four components of a film look

Grain sits in the midtones, not everywhere. Organic film grain is strongest in the middle values and nearly invisible in deep shadows and blown highlights, because it is an artifact of dye clouds, not an overlay. A noise layer applied uniformly at a fixed opacity is the single most recognizable tell of a fake: grain over jet-black areas does not happen on real film.

Highlights roll off instead of clipping. Film negative handles overexposure gracefully — bright areas compress into a soft shoulder rather than snapping to white. Digital sensors clip hard. A film grade pulls that shoulder back, which is why overexposed windows in a graded photo keep some detail.

Halation adds a faint glow around bright sources. Light passing through the emulsion reflects off the film base and back into the layers, producing a red-orange halo around highlights — most visible on small bright points (street lights, jewelry, backlit hair). It is subtle; heavy halation filters read as costume.

The contrast curve is a color-negative curve, not a contrast slider. Analog color negative has a long, gentle S-curve with lifted blacks and compressed saturation in the extremes. This is the biggest single contributor to "the film feel" and the one a noise stamp completely skips: you can add perfect grain to an untouched digital curve and it still looks digital.

How to check what a tool actually did

Four checks, no expertise needed:

Zoom to 100% on a dark area. Grain there means a uniform noise stamp; clean shadows with grain only in midtones suggests a real grade.
Find a bright light source. Is there a soft glow around it (halation) or a hard white blob (clipped)? Was a faint warm rim added or nothing?
Compare highlights before and after. Did detail appear in previously blown areas (a shoulder was applied) or is it the same clipping with noise on top?
Look at the blacks. Lifted, slightly faded blacks are film; pure zeros with grain are a stamp.

If a tool fails all four, it sold you a texture, not a look.

Where style presets get more aggressive

Grading presets (film look, Polaroid fades, cross-process) stay in tonality: your edges, faces and composition are untouched. Render presets (watercolor, pencil sketch, oil painting) are a different operation entirely — the image is re-interpreted, hatching and paper texture replace pixels, and fine details like eyelashes can be simplified. Neither is wrong, but they answer different needs: grade when you want the same photo with a different mood; render when you want a different medium. Problems start when a "sketch" tool quietly re-renders faces — that is when likeness drifts, and it is worth checking at 100% before you print.

I build aiphotoeditor.best, where the film-grain preset is an AI re-grade of the whole image — grain, highlight roll-off, halation and the color-negative curve together, with your scene and faces kept intact — alongside watercolor, pencil sketch and six other style presets. The AI path is three free edits a day, no account; simple local filters, including a mono film look, are unlimited and never upload your photo.

Honest limits: a re-grade can slightly soften faces (that is the film curve doing its job), and no preset fixes an out-of-focus source — grading changes mood, not optics.

Animating a Photo Into a Dance Video: What Image-to-Video Models Actually Preserve

tony huang — Sun, 25 Oct 2026 15:38:24 +0000

Last week I shipped a small tool that turns a single photo into a short dance video — one picture, pick a style (skirt-dance twirl, hip-hop, shuffle, K-pop, disco, breakdance), get back a vertical MP4 with music. It runs on Kling O3 image-to-video through fal.ai. This post is the engineering notes: what an I2V model actually preserves from the source photo, and where the honest limits are.

What carries over — and what doesn't

The model animates the person who is actually in the photo: face, hairstyle, and outfit are carried into the motion. That's the whole appeal and the whole risk. If the input is a full-body shot facing the camera, identity survives the twirl surprisingly well. If the input is a cropped torso or a three-quarter back view, the model starts inventing — and inventing is where uncanny results come from.

Practical input rules we ended up documenting (all learned from failed renders):

Full body visible, facing the camera. Feet included — the twirl ends where the photo ends.
Even lighting on the face. Hard side light makes the model re-guess facial geometry mid-spin.
One person per photo. Two people get merged or one gets dropped.

The 5s vs 10s decision is really a credit decision

A 5-second render costs one credit; 10 seconds costs two. That sounds trivial until you watch the outputs: the model spends the first ~1.5 seconds on the wind-up, so a 5-second clip gets you one full move, while 10 seconds gets the move plus a landing. For the skirt-dance twirl specifically, the fabric flare peaks around second 3–4 — the 5s cut is fine, the 10s cut is comfortable.

We price it as one-time credit packs (2 videos $6.99, 6 for $19.99, 18 for $59.99), credits never expire, and failed renders refund automatically. No subscription, no account. The refund rule isn't generosity — with I2V, a moderate share of renders fail outright, and charging for failures is how you lose trust in one screenshot.

The direction box is the underrated feature

Besides picking a preset style, you can write free-text direction that gets blended into the choreography — "arms up on the drop" type notes. It works about as well as you'd expect from current models: it biases the motion, it doesn't guarantee it. Worth setting expectations honestly: it's a nudge, not a director's chair.

Native audio changes the output contract

Kling O3 generates audio with the video, so the MP4 comes out with music already synced. That removes an entire editing step (finding a track, cutting to length, syncing), which is the part casual users never do well anyway. The tradeoff: you don't pick the track. For trend-style clips that's fine; for anything brand-driven you'd still take the output into an editor.

Where this should NOT be used

Photos of real people without their consent. This one's a hard line, and we enforce it in the terms rather than pretending detection will save anyone.
Anything where fabric or hands matter more than the silhouette. Hands during fast motion are still the classic I2V failure case.

If you want to try the pipeline without wiring up fal.ai yourself, the tool is at dancegenerator.best — one photo in, pick a style, MP4 out. And if you're building your own: the interesting engineering isn't the API call, it's the input validation and the honest failure handling around it.

Image to SVG: the three tracing algorithms, and what a cut-ready file actually needs

tony huang — Sat, 24 Oct 2026 15:35:52 +0000

Generating an SVG from a reference image is sold as one button. What you get back varies more than the marketing suggests, because "tracing an image" covers at least three different algorithms, and each produces a file that behaves differently in a cutting machine.

If you cut vinyl, HTV or laser stock, the differences are not cosmetic — they decide whether the file weeds in ten minutes or becomes a fight with tweezers.

The three families of image-to-SVG

1. Threshold tracing (black and white). The software picks a luminance cut-off and turns everything above it into a filled path. This is what most free converters do, and it is the right choice for silhouettes, stencils and single-colour decals. It is also the only family that reliably produces a true single-path cut line.

2. Multi-colour posterization. The image is quantised down to N colours, then each colour region becomes its own path on its own layer. This is what you want for layered vinyl — one sheet per colour. The quality lives or dies on two numbers: how many colours the tool commits to, and how it handles the anti-aliased boundary between them. A tool that dumps 40 colours because the source photo had 40 shades has not done the work; 3-6 well-chosen layers are what a craft cutter actually wants.

3. Centerline tracing. Instead of outlining shapes, it follows the middle of each stroke — essential for line art, text and anything you want to draw or score rather than fill. Most free tools skip this entirely, which is why a hand-lettered logo converts into solid blobs instead of strokes.

Check which one your tool runs before you judge the output. A bad result from family 1 is often the right algorithm with the wrong threshold, not a reason to switch tools.

What a cut-ready file actually needs

The SVG spec is generous; cutting software is not. A file that previews fine in a browser can still be unusable in Design Space or Silhouette Studio. The things to check:

Closed paths. Every shape must be a closed contour. Open paths become unpredictable cuts — some software closes them for you, some cuts down the open edge and back.
Actual fill, not stroked outlines. A path that is "a 2px black stroke with no fill" looks identical to a filled shape on screen. On a cutter, the stroke usually disappears and the machine has nothing to cut. This is the single most common failure in converted files.
Groups per colour layer. For layered vinyl, each colour's paths should be grouped, so "send this layer to this mat" is one click rather than a manual sorting session.
Sane node counts. A trace of a 4000-pixel photo can emit tens of thousands of nodes. Design Space slows to a crawl above a few thousand. Simplification is not cosmetic; it is the difference between a file that loads and one that freezes the app.
Physical scale. SVGs are unitless until someone assigns a size. Check the file imports at a real-world dimension (width in mm) rather than arriving at 40 kilometres wide or 4 pixels tall.

The honest test before you cut

Load the file into your cutter's software and zoom to 100% at the size you will actually cut. Two failure modes show up only there:

The thin-feature problem. Strokes finer than roughly 1.5-2 mm on 651 vinyl (and a bit more on HTV) become unusable: the weeding tool lifts the whole island, or the material tears. A good preview shows the thinnest stroke in millimetres so you can make this call before cutting, not while weeding.

The island problem. Inside a letter "o" is an island that must be held by a bridge to the surrounding vinyl. Traces that forget bridges produce letters whose counters fall out on the transfer tape. Text-heavy designs need either manual bridges or a font-based rebuild — a trace alone will not save you.

Where AI generation fits, honestly

Text-to-SVG is a different product from image tracing. A generation model produces clean, closed, layer-grouped paths by construction — no threshold artefacts, no anti-aliasing residue — because it is drawing shapes rather than interpreting pixels. The trade is fidelity: it draws what it understands your prompt to mean, not your exact reference. For an original design, that is fine. For reproducing a specific logo, tracing is the right tool and generation is the wrong one.

The combination is more useful than either alone: trace the reference for shape fidelity, then use generation to produce a cleaned variant when the trace is too noisy to weed.

I build AISVG Pro, which does both under one rule: show the honest numbers before you pay. The free preview reports path count, colour layers and the thinnest stroke in millimetres, so you can compare against your material before spending a credit. The trace runs in your browser — free, no account, nothing uploaded — and a credit unlocks the full pack: layered SVG, transparent PNG, DXF for Silhouette and a real-size PDF.

Honest limits: browser tracing is 2D and threshold-based; it will not reconstruct occluded parts of an image or vectorise a 3D render reliably. And generation costs real GPU time per image, which is why it is the paid half while local tracing stays free.

JPEG, WebP, PNG: the four decisions hiding inside a format conversion

tony huang — Fri, 23 Oct 2026 15:32:35 +0000

Converting an image between JPEG, WebP and PNG sounds like a format setting. It is really three different decisions, and getting them confused is why converted images sometimes come back with a grey box, a wrong size, or visibly worse quality than the file you started with.

Here is what each format actually stores, and what changes when you convert.

What each format holds

JPEG stores a lossy DCT-compressed image, 8 bits per channel, no alpha. Its strengths are photographic data and small files; its weaknesses are sharp edges, text, and anything that will be edited again.

PNG stores lossless pixels with a full alpha channel. Great for screenshots, UI, logos and anything with transparency or hard edges; large for photographs.

WebP does both: lossy and lossless modes, plus alpha in either. It is typically 25-35% smaller than JPEG at comparable perceived quality, and it supports transparency that JPEG cannot.

So the first decision is not "which is better" but "does this image have transparency or hard edges, and will it be re-edited".

Decision 1: alpha

If the image has transparent pixels, JPEG is out — full stop. Converting RGBA to JPEG has to flatten the alpha channel onto something, and what it flattens onto depends on the encoder:

Some flatten onto white.
Some flatten onto black (visibly catastrophic on dark logos).
Some flatten onto the background colour stored in the file, which may itself be undefined.

This is the source of the classic "my PNG became a black box" bug. If you must have JPEG, flatten deliberately onto a colour you chose, and check the result rather than assuming.

Decision 2: repeated lossy conversion

Every JPEG save is a new lossy generation. Decode → re-encode at quality 85 → decode again is not the same image; each pass loses a little high-frequency detail and adds a little ringing, concentrated around edges.

The visible symptom after 3-4 generations is "mushy text and haloed edges", which people usually blame on the source. If a workflow requires multiple edits, keep a lossless master (PNG, or a full-quality JPEG at q95+) and export derivatives from it, rather than editing the last export.

WebP has the same property in lossy mode. Being newer does not make it immune.

Decision 3: the colour profile

Here is the one that quietly ruins conversions: an image tagged with a wide-gamut profile (Display P3) converted by a tool that ignores the profile will display with shifted, oversaturated colours. A tool that honours the profile but then strips it from the output produces a file that looks right on your machine and wrong on someone else's.

For web delivery the safe pattern is:

Convert to sRGB if the image is not already.
Keep the sRGB profile embedded (or at minimum, do not leave an image tagged P3 but containing sRGB data).
Verify by opening the output in a different tool than the one that produced it.

Most "the colours changed after upload" reports are this, not compression.

Decision 4: resampling, which is separate from format

Changing pixel dimensions is a different operation from changing format, and both are often presented in the same dialog.

Downscaling is safe if you use a decent filter (Lanczos or a two-pass box filter). Done naively — nearest neighbour — it aliases, and thin lines become dotted.
Upscaling cannot add information. Bicubic interpolation produces a soft, slightly blurry result; model-based upscalers produce plausible invented detail. Neither restores what was never captured.
DPI is metadata, not pixels. Changing 300 DPI to 72 DPI without changing pixel dimensions does not change the image at all; it changes the number a printer reads. A 3000×2000 image at 72 DPI is the same data as at 300 DPI. People routinely "resize for print" by only changing DPI and get a file no sharper than before.

A checklist that catches all four

Before publishing a converted image:

Does the output have the alpha you expect? (Open it somewhere that shows a checkerboard.)
Are the pixel dimensions what you intended — not just the DPI field?
Did you edit the master, or a derivative of a derivative?
Do the colours match when opened in a second application?
At 100% zoom, is the text still crisp? (The most sensitive test for lossy damage.)

Five checks, thirty seconds, and they catch the entire class of conversion accidents.

I build aiphotoeditor.best, where format conversion and compression run in the browser as ordinary pixel operations — JPEG, PNG and WebP in and out, with the pixel dimensions shown before you download. That layer is free and unlimited because it costs nothing to run; the AI features (enhance, restore, cutout, headshots) are a separate, explicitly counted path with three free runs a day.

Honest limits: the converter does not invent detail when upscaling, and it does not run colour-profile conversion for you — if your source is Display P3, convert to sRGB in a tool that manages profiles before the file reaches the web. That is a real gap, not a hidden feature.

Why 'enhance' often makes old scans look worse (and which of the three operations you actually need)

tony huang — Thu, 22 Oct 2026 15:32:45 +0000

"Enhance" is the most oversold button in photo software. On a scanned print it often makes the image measurably worse, and the reason is structural rather than a tuning problem.

Here is what actually happens inside the three things people mean by enhance, and when each one helps.

Three different operations sold under one word

1. Sharpening — an unsharp mask. It does not add detail; it increases local contrast along existing edges. Give it a blurry edge and it produces a crisp-looking halo around nothing.

2. Upscaling — resampling to more pixels. Classical methods (bicubic, Lanczos) interpolate; they cannot create information. Model-based upscalers generate plausible detail, which is better looking and less truthful.

3. Generative restoration — a diffusion model that repaints regions it thinks are damaged. This is the one that can double the perceived quality, and the one that can silently replace a face.

A tool that labels all three "Enhance" is telling you nothing about which is about to run.

Why sharpening makes scans worse

A 1985 print scanned at 600 dpi has film grain, paper texture, and dust. Unsharp mask does exactly what it says: it amplifies the difference between neighbouring pixels. On a clean digital photo that means crisper edges. On a scan it means amplified grain and amplified dust, and the eye reads that as "noisier", not "sharper".

If you use radius values tuned for a 12-megapixel digital photo — typically 0.5–1.5 px — on a 3000 dpi scan you are operating at the wrong scale entirely. The same radius now sits inside the grain rather than across the edge.

The practical fix is to denoise before sharpening, and to sharpen with a radius proportional to the scan resolution. There is no single slider value that works for both a phone photo and a flatbed scan.

Why upscaling a blurry photo does not rescue it

Upscaling is a bet about what the missing pixels probably look like. On a photo that is merely small but sharp, that bet is easy and the result is good. On a photo that is blurry — out of focus, motion blur, or heavily compressed — the missing information is not "smaller detail", it is "no detail", and the model fills the gap with plausible texture.

That texture reads as detail at 100% zoom and as mush at print size, because the fabric of the invented detail does not follow the scene's own geometry. Watch for hair strands that merge into a single wavy plane, and text that becomes decorative squiggles.

The test: downscale the result back to the original resolution and compare. If it looks like the original, the upscale added pixels without adding information. If it looks different in character, the model invented structure — which may be fine for a thumbnail and wrong for a document.

Where generative restoration genuinely wins

On physical damage — creases, tears, water stains, dust, faded areas — a model is doing the job no classical filter can: inferring what the paper probably looked like underneath the damage. That is real value and it is why these tools exist.

The cost is that the same model cannot tell "damaged area" from "unusual face". Give it a photo where the subject's eyes are partly shadowed and a face-restoration stage will happily reconstruct eyes in a shape the person never had.

Two rules that keep it honest:

Disable face restoration when identity matters. Global restoration of damage, none of the face-specific stage.
Process twice with different settings and compare. If the two results differ in ways that change who the person is, the pipeline is generating rather than restoring.

A workflow that avoids the trap

Assess first. Is the image small, blurry, damaged, or all three? Each needs a different operation, and doing them in the wrong order compounds errors.
Denoise before sharpening. Always on scans.
Upscale before generative restoration, not after — a model working on more pixels has more constraints.
Keep an untouched copy. The single most useful habit: the original is the only version that cannot be wrong.
Compare at 100% and at the size you will actually use. Most disappointments live between those two views.

I build aiphotoeditor.best. The local layer — brightness, contrast, saturation, warmth, sharpening, filters, crop, resize, format conversion — runs in the browser as plain pixel math and is unlimited and free, because none of it can invent anything. The generative stage (enhance, restore, background removal, cartoonize, headshots) is a separate, explicitly labelled operation with three free runs a day and credit packs after that.

The split exists precisely because of the problem in this post: when the generative step is a separate button, you can tell which parts of the result are yours. When it is buried inside "enhance", you cannot.

Honest limits: the sharpening is a standard unsharp mask, not a scene-aware algorithm; the upscaler is conservative by design and will not rescue a genuinely out-of-focus shot; and no tool can tell you which of the three operations your particular photo needed — that judgement is still yours.

Verifying a white background programmatically (and the two export mistakes it catches)

tony huang — Wed, 21 Oct 2026 15:34:17 +0000

Marketplace image checks are usually automated, and "looks white" is not the same as "is 255,255,255". If you process product photos in a browser, this is a five-line check worth adding to your pipeline.

Why the naive check fails

Monitors and image previews apply gamma and colour management, so two files that look identical on screen can differ by 4-6 levels per channel. A background at 250/251/249 passes your eyes and fails a strict white check.

Compression makes it worse. JPEG at quality 85 puts ringing artifacts around high-contrast edges — precisely at the product boundary — so the pixels nearest the subject drift away from white even when the flat field is fine.

The check: sample the flat field, not one corner

async function whiteFieldReport(file) {
  const bmp = await createImageBitmap(file);
  const c = new OffscreenCanvas(bmp.width, bmp.height);
  const ctx = c.getContext("2d", { willReadFrequently: true });
  ctx.drawImage(bmp, 0, 0);
  const { data } = ctx.getImageData(0, 0, bmp.width, bmp.height);

  // sample a border band, skipping the product area
  const band = Math.max(2, Math.round(Math.min(bmp.width, bmp.height) * 0.02));
  let n = 0, minC = 255, offWhite = 0, alphaZero = 0;
  const visit = (x, y) => {
    const i = (y * bmp.width + x) * 4;
    const a = data[i + 3];
    if (a === 0) { alphaZero++; return; }          // transparent, not white
    const m = Math.min(data[i], data[i + 1], data[i + 2]);
    if (m < minC) minC = m;
    if (m < 250) offWhite++;
    n++;
  };
  for (let y = 0; y < bmp.height; y++)
    for (let x = 0; x < bmp.width; x++)
      if (x < band || y < band || x >= bmp.width - band || y >= bmp.height - band) visit(x, y);

  return { sampled: n, minChannel: minC, offWhitePct: (100 * offWhite / n).toFixed(2), alphaZero };
}

Three numbers come out of it, and each maps to a different failure:

minChannel === 255 → the field is a true white; safe for a strict check.
alphaZero > 0 → the file has transparency, not white. If the marketplace wants flattened white, you have the wrong export.
offWhitePct high but min near 255 → you have a few dirty pixels, usually from JPEG ringing at the product edge or a stray shadow. Re-export as PNG, or clean the matte.

The two export mistakes this catches

1. Saving the cutout as JPEG. No alpha channel survives, so transparent regions get flattened — usually to white, sometimes to black depending on the encoder. You then cannot tell a real white background from a flattened one without checking alpha, which is gone.

2. Compositing onto near-white. People composite onto #fefefe or a "paper" swatch that came from a design system. It looks white and reads 254. If the check is a strict equality or a threshold above 254, that fails.

What I do in practice

Export PNG with alpha for the working file, composite onto true 255 white only at the final step when the target wants a flattened file, then run the check above on the exported bytes — not on the canvas you composited on. The canvas is the thing you built; the file is the thing that gets uploaded.

For batches, treat minChannel as the pass/fail and offWhitePct as a quality score: anything above roughly 1-2% off-white means you have edge contamination worth looking at before upload.

I build aiphotoeditor.best, where the background removal outputs PNG with alpha preserved and the export step tells you which format you are getting before you spend a credit. Three free AI edits a day, no account; the local adjustments run in the browser and are unlimited.

Honest limits: the matte is imperfect on fine hair against a similar-toned background, and this check tells you nothing about whether the marketplace accepts a soft shadow — that is a rules question that varies by category and platform.

Local-first photo editing in the browser: what the pipeline split actually looks like

tony huang — Mon, 19 Oct 2026 19:08:19 +0000

If you build anything in the browser that touches user photos, you eventually run into the same wall: the cheap operations want to be local, and the expensive ones cannot be.

Here is how I ended up splitting the pipeline, and the constraints that forced each decision.

The cost asymmetry nobody mentions in the docs

A brightness slider is a loop over pixels. A crop is a coordinate transform. A JPEG re-encode is a codec call. None of these need a server, and if you put them behind one you have added latency, bandwidth and a privacy problem to something that costs you nothing to run locally.

A diffusion step is different. It needs a GPU, it costs real money per call, and there is no version of it that runs acceptably in a browser tab today. That is not a temporary limitation of my code — it is the state of the hardware.

So the pipeline naturally splits: everything deterministic runs in the client, everything generative runs on a server, and the boundary between them is the honest place to draw your pricing model.

What the local layer actually costs

Canvas-based operations are fast until they are not. The three things that bit me:

1. getImageData is a synchronous trap. Every pixel-level pass that reads back from the canvas stalls the main thread while the GPU drains. On a 4000×3000 photo that is a visible freeze. The fix is to do the pixel work once per adjustment change, not once per frame, and to debounce slider input — otherwise you are running the full loop on every mousemove event.

2. Re-encoding is the real cost, not the filter. Applying a filter is milliseconds; encoding the result to JPEG at quality 0.9 to show a preview is where the time goes. Previewing at display resolution and only re-encoding at full resolution on export makes the interaction feel instant.

3. Memory is worse than you think. An RGBA buffer for a 12-megapixel photo is 48 MB. Keep a source copy, a working copy and an undo stack and you are at a few hundred megabytes on a phone. Mobile Safari will kill the tab without ceremony. Downscaling the working copy to the viewport size and keeping the original as a compressed blob is the only thing that survived real testing.

None of that is exotic, but it means "local-first" is an architectural commitment rather than a checkbox.

The network panel is the honest test

The nice side effect of this split is that it is verifiable from outside. Open DevTools, switch to the Network tab, and:

Apply a tone adjustment. Requests appearing there means the claim is false.
Use the generative feature. Requests are expected — that part really does cost money per call.
Export. If the only difference between the free and paid path is this step, you have found the business gate, which is a separate thing from a technical limit.

A tool that passes the first check and is open about the second is telling you the truth about its own cost structure. That is a better signal than any badge.

The privacy argument is a side effect

I did not start with a privacy pitch. But once the local layer exists, the useful consequence follows: photos that never leave the device are photos people are willing to use. Scans of documents, pictures of kids, product shots under NDA — the category that gets excluded from every cloud editor by default becomes available.

That is a real product difference, and it comes from the architecture, not from a policy page.

Where the split breaks

Two honest limits, because anyone claiming otherwise is selling something.

WebAssembly models are not a shortcut. You can run a small model in the browser, and people do. But it is slow enough to be unusable for anything interactive on a laptop, and it drains the battery doing it. For the operations people actually want (restoration, background removal, upscaling, style generation) the server is the only option that produces good output in reasonable time.

The boundary moves. Every year a model that needed a GPU gets smaller. The split I have today will be wrong in a couple of years, and rebuilding around a new boundary is cheaper than pretending the old one is permanent.

I build aiphotoeditor.best along these lines: the local layer (tone, filters, crop, resize, format conversion, compression) is free and unlimited because it costs nothing to run; the AI layer is capped at three free edits a day and then one-time credit packs, because each call costs money. If you want to check the split for yourself, the network panel test above works on it too.

What it costs to run an AI baby-photo generator: ~4¢ an image, and an honest promise

tony huang — Thu, 15 Oct 2026 15:00:10 +0000

I build small browser-first tools. One of them, OurBaby, answers the oldest question couples ask — what will our baby look like? — by blending one photo of each parent into an imagined baby portrait.

Two questions come up from other developers every time I describe it, so here are both answers with real numbers.

The unit economics (real numbers, October 2026)

Generation runs on a multi-image model of the "nano-banana" class via fal.ai. The actual billed cost per image, from my fal usage export:

$0.0398 per generated image (identity-blending edit, two reference photos)
Same engine for every scene — studio, Christmas, beach, family-of-three

So the math is simple: a $2.99 pack of 5 photos is ~80%+ gross margin, and the free tier is a bounded acquisition cost rather than a leak. The free tier is deliberately small and capped three ways:

1 free preview per visitor IP per day
a per-site daily spend circuit breaker (cost-estimate accumulation in KV)
no API key in the deployment → the endpoint returns a waitlist 503 instead of ever going bare

That last one matters. An earlier project of mine shipped an AI endpoint without a daily cap and someone found it within hours — the cap is the difference between a marketing cost and an incident.

The pipeline, in one paragraph

Photos never touch my servers as files: the browser downscales each to a 768px JPEG, sends them as data URIs, and a Cloudflare Pages Function makes a single queued call to the model with both references. The interesting part is not the plumbing, it's the prompt: the model is told to inherit specific features (eye color and shape, nose, smile, hair color and texture, skin tone) from both references, rather than averaging two faces — averaging is why first-generation "baby generators" produced children that looked like nobody.

The part every "baby predictor" gets wrong

Here's where I have to argue against my own product category. A baby's face cannot be predicted — by my tool or any other. Appearance is polygenic: eye color alone involves several genes (the OCA2/HERC2 region does most of the work, not all of it), and each parent passes on one of two copies of every gene. The recombination is random. Even two full genomes don't compute a face.

What a good generator can honestly claim is fidelity to the parents — the imagined child should visibly inherit from both of you — not prediction of the child. So the copy on the site says exactly that: the result is a fictional, imagined person, and the page even explains why prediction is impossible. It turns out that honesty is also good SEO: it's the question people actually type.

Privacy structure, since your users' faces are your users

Photos go encrypted to the model provider only to generate the image
No gallery, no public results wall — if you show other people's uploads, assume yours joins them
The generated images live on the provider's temporary storage, not in my database

If you're building anything that eats faces (headshots, restorations, family photos), I'd treat this as the baseline, not a feature.

What I'd tell you before you build in this space

Bound your free tier with per-IP and global daily caps on day one
Label outputs as fictional — it's the difference between a keepsake and a scam
Put the honest limit in the title of your main content page; being straight about what AI can't do outperforms promising predictions

If you want to see the result, the generator is at ourbaby.shop — first preview free, no signup, and the free tier is documented in plain numbers.

AI Photo Restoration Keeps Changing Faces — Here's the Pipeline That Stops It

tony huang — Wed, 14 Oct 2026 15:37:54 +0000

If you've run old family photos through an AI restorer, you've probably hit the failure mode nobody advertises: it changes faces. Heavy restoration on a low-resolution scan doesn't recover a face — it re-draws a plausible one. You end up with a stranger wearing your grandmother's expression.

Why faces drift

Face restoration models are trained to produce plausible faces. With a high-signal source, "plausible" and "correct" converge. Below a certain signal level — small scan, compression, damage sitting on the features — the model stops restoring and starts re-drawing. It's a fidelity-versus-strength trade-off baked into every tool of this class.

The pipeline

Scan at 600 dpi, in color — color even for black-and-white originals, because the stain and tone information helps separate damage from image. A flat daylight photo of the print beats nothing, but a real scan beats everything.
Repair damage first, enhance faces second, upscale third — separate passes, not one mega-pass. Scratches and fading act like added noise, and face restoration running on top of damage is where the drift starts.
Bias toward fidelity, not strength — the "beautiful" results that swap identity are usually high strength on low-res input.
Verify at 100% zoom on eyes, smile, hairline — if any of the three changed, reject the pass and re-run with less strength. That's the identity check.
Colorize last — colorization is a guess about the past, not a record of it. Keep the black-and-white original as the archival master.

The hard ceiling

Past roughly half of the facial detail missing, no model can recover identity — anything it produces is invention. That's manual-restoration territory. Below that threshold, the order of operations above is the difference between a sharper version of the same person and a stranger.

What I built with this

I packaged this workflow into AI Photo Editor: free local adjustments (crop, tone, contrast — nothing uploaded) plus a few free AI edits a day for enhance / restore / background removal. The local layer handles the prep steps without spending an AI credit, and the AI pass only ever sees the cleaned scan.

Honest limits: it won't fix a photo beyond the reconstruction threshold above, and keeping the period look is the goal by design — if you want a "modernized" face, this is the wrong tool.

Building browser-only tools that never upload your files (the local-first web stack)

tony huang — Wed, 30 Sep 2026 06:09:06 +0000

Most online tools quietly ship your files to a server: your photos, your invoices, your subtitle files, your client documents. There is a different way — build the whole tool client-side, so nothing ever leaves the device. I've been shipping a family of free tools built on this principle, and this post is the practical stack behind them.

The core pattern

Static site export. The app is a Next.js static export on Cloudflare Pages — there is no backend to receive your files in the first place. Privacy is structural, not a policy promise.
Canvas API for anything pixel-shaped: downscaling, palette quantisation, crops.
WebAssembly for codecs that never shipped in browsers: HEIC decoding, WebP/AVIF encoding, GIF optimisation.
WebCodecs + seeking for video work without ffmpeg.
Plain text processing where "format" just means text with rules.
Web Workers so the main thread keeps breathing during heavy transforms.

What this looks like in practice

Image format conversion — wasm builds of libheif/libwebp mean you can convert HEIC or WebP entirely locally, with batch support and no file-size ceiling. Live example: ImageConverter.
GIF compression — scale, colour-reduce and drop frames in a worker. Live example: GifCompressor.
Video frames — the browser can decode and seek video natively now: pull evenly spaced frames with timestamps, grab one exact frame, or scan a long clip for motion. No ffmpeg install, nothing uploaded. Live example: FrameExtractor.
Pixel art conversion — canvas downscale + palette quantisation turns photos into game-ready sprites. Live example: PixelArt.
Subtitle repair — SRT/VTT/ASS are just text with rules, so parsing, resyncing and merging run instantly client-side. Live example: SubToolbox.
Calculators — pure JavaScript, zero I/O: aspect ratios (https://aspectratio.site), marketplace seller fees (https://sellerfees.org), construction materials (https://buildcalcs.best), electrical/HVAC tables (https://tradecalcs.best), even baby wake windows (https://wakewindows.best).

The honest trade-offs

Client-side is not free of constraints. Large files on low-RAM phones will hurt; you're bounded by the device instead of a server farm. Heavy AI inference is still mostly a server story (though small models in WASM are getting real). And some features — accounts, sync, sharing — reintroduce a backend by definition.

But for a huge category of "give me a file, give me a different file back" problems, the browser is now enough. The user gets instant results, offline capability, and privacy that isn't just a checkbox. If you're building tools in 2026, it's worth asking first: could this run entirely on the client? For us, the answer is usually yes — and it makes the product better, not just cheaper.

All the tools linked above are free, require no sign-up, and run 100% in your browser. Feedback welcome in the comments.