Drawing a labelled overlay on a user photo with SVG (no canvas, no library)

PalmReading.pro — Sun, 01 Nov 2026 11:56:29 +0000

When an AI feature returns coordinates on top of a user's photo, such as detected objects, document fields, or the lines on a palm, the drawing layer is where a lot of bugs hide. The model is right, but the box is in the wrong place on a phone, or the labels overlap, or the overlay drifts when the page resizes.

This post walks through a small, framework-free way to draw a labelled overlay with SVG, using the example of a palm photo where the result is three named curves. I work on PalmReading.pro, a palm reading web app that shows a labelled map of the palm, so the examples come from that kind of output. (Palmistry itself is folklore; the app is for entertainment. The rendering problem is the same for any image-to-annotation tool.)

1. Keep the model's coordinates normalized

Ask the backend to return points in the range 0 to 1, relative to the image it actually analyzed:

{
  "width": 1024,
  "height": 1365,
  "lines": [
    {"name": "Heart line", "points": [[0.18,0.36],[0.42,0.33],[0.71,0.30]]},
    {"name": "Head line",  "points": [[0.20,0.45],[0.47,0.47],[0.69,0.52]]},
    {"name": "Life line",  "points": [[0.24,0.44],[0.30,0.62],[0.38,0.82]]}
  ]
}

Normalized points survive resizing on the server, retina screens, and CSS changes. Pixel coordinates tie you to one size, and one forgotten downscale step breaks everything.

2. Use an SVG with a viewBox that matches the image

Put the image and the SVG in the same positioned container, and give the SVG a viewBox equal to the analyzed image size:

<figure class="overlay">
  <img src="palm.jpg" alt="Uploaded palm photo">
  <svg viewBox="0 0 1024 1365" preserveAspectRatio="xMidYMid meet"></svg>
</figure>

.overlay { position: relative; display: inline-block; }
.overlay img, .overlay svg { display: block; width: 100%; height: auto; }
.overlay svg { position: absolute; inset: 0; height: 100%; pointer-events: none; }

Because the viewBox and the image share the same aspect ratio and meet scaling, the browser does all the resizing math. No resize listeners are needed.

3. Draw smooth curves, not polylines

A few points joined by straight segments look robotic. A Catmull-Rom spline converted to cubic Bezier commands gives a natural curve through every point:

function smoothPath(pts) {
  if (pts.length < 2) return "";
  let d = `M ${pts[0][0]} ${pts[0][1]}`;
  for (let i = 0; i < pts.length - 1; i++) {
    const p0 = pts[i - 1] || pts[i];
    const p1 = pts[i];
    const p2 = pts[i + 1];
    const p3 = pts[i + 2] || p2;
    const c1 = [p1[0] + (p2[0] - p0[0]) / 6, p1[1] + (p2[1] - p0[1]) / 6];
    const c2 = [p2[0] - (p3[0] - p1[0]) / 6, p2[1] - (p3[1] - p1[1]) / 6];
    d += ` C ${c1} ${c2} ${p2[0]} ${p2[1]}`;
  }
  return d;
}

function render(svg, result) {
  const { width: w, height: h } = result;
  svg.setAttribute("viewBox", `0 0 ${w} ${h}`);
  svg.innerHTML = "";
  for (const line of result.lines) {
    const pts = line.points.map(([x, y]) => [x * w, y * h]);
    const path = document.createElementNS("http://www.w3.org/2000/svg", "path");
    path.setAttribute("d", smoothPath(pts));
    path.setAttribute("class", "trace");
    svg.append(path);
  }
}

4. Make strokes readable on any photo

User photos have unpredictable colors. A stroke that is visible on pale skin vanishes on a dark background. Two stacked strokes fix this: a wide dark halo and a narrow bright line. Use vector-effect so the width stays constant at any zoom:

.trace { fill: none; stroke-linecap: round; vector-effect: non-scaling-stroke; }
.trace.halo { stroke: rgba(0,0,0,.55); stroke-width: 6px; }
.trace.main { stroke: #ffd166; stroke-width: 2.5px; }

5. Place labels where they do not collide

Labels at the first point of each curve often overlap, because the lines start close together. A simple rule works well: anchor each label at the point of the curve farthest from the others, then nudge vertically if two labels' boxes intersect. Measure with getBBox() after inserting the <text>, and move the later label down by the overlap plus a small gap. For three to five labels this greedy pass is enough.

6. Handle EXIF orientation once

Phone photos often carry an orientation flag. Modern browsers rotate the <img> automatically (image-orientation: from-image is the default), but your server or model may not. Normalize orientation before analysis, or the curves will appear rotated by 90 degrees on exactly the devices you did not test. The simplest fix is to draw the file into a canvas with createImageBitmap(file, { imageOrientation: "from-image" }) and upload that.

7. Accessibility

An overlay is visual only. Repeat the result in text next to it, give the SVG role="img" with an aria-label summarizing what is drawn, and keep the labels as real <text> elements rather than baked into an image.

Wrap-up

Normalized coordinates, a matching viewBox, smoothed paths, halo strokes, and a collision pass cover most of what an annotation overlay needs, with no canvas redraw loop and no library. The same approach works for bounding boxes, keypoints, or any curve your model returns.

Shipping an image-to-text AI feature without a signup wall: notes from a palm reading app

PalmReading.pro — Sun, 18 Oct 2026 07:07:50 +0000

Most AI image tools ask for an account before they show anything. That is the safe engineering default: you know who is uploading, you can rate-limit per user, and you can bill. It is also the point where many visitors leave. This post looks at the other option, a free preview with no signup, using an AI palm reading web app as the example, and lists the engineering problems that option creates.

A quick disclaimer about the domain: palmistry is folklore, not science. The app presents its readings as entertainment and self-reflection. The interesting part for developers is the product and pipeline shape, which is the same for any "upload a photo, get a written result" tool.

The flow

The visitor uploads a photo of an open hand.
A vision step locates the palm and traces the major creases (life, heart, head, fate, and the short marriage lines under the little finger).
The traced lines are shown back as a labelled map of the palm.
A language model turns the line descriptions into a short reading covering love, career, life, and marriage.
The visitor can stop there, or pay for a longer full report.

Steps 1 to 4 happen before any form. That single decision drives most of the work below.

Problem 1: abuse without identity

Without accounts you lose the easiest rate-limit key. Options that work for anonymous endpoints:

Rate-limit by IP plus a short-lived signed session cookie, and accept that shared IPs will occasionally hit the limit.
Put a cheap validation step before the expensive one. If the image is not a hand, or is too dark or blurred, reject it before calling the model that writes text.
Cap image size and resolution on the client and again on the server. Phone photos are large, and the vision step does not need 12 megapixels.

The cheap-check-first ordering matters more than any limiter, because it moves most bad requests to the lowest-cost path.

Problem 2: input quality is the real accuracy problem

Palm lines are low-contrast: skin-coloured creases on a skin-coloured surface. Shadows, motion blur, and a half-closed hand hide exactly what the model needs. As with OCR, the biggest gains come from the capture step, not the model:

Tell the user what a good photo looks like before they take it (open hand, even light, palm filling the frame).
Detect the obvious failures (no hand, too dark, too blurry) and ask for a retake instead of producing a confident reading from a bad image.

Problem 3: make the intermediate result visible

Showing the traced line map is a small UI decision with a large effect. If the overlay sits in the wrong place, the user sees it immediately and retakes the photo, instead of trusting text built on a bad trace. Exposing the intermediate output of a pipeline is a cheap way to make an AI feature debuggable by its own users.

It also keeps the two stages separately testable. The vision stage can be checked against labelled images; the writing stage is where tone, length, and safety wording are controlled.

Problem 4: where the paywall goes

If the preview is free, the paid tier must add something the preview does not have, rather than withholding the preview itself. Here the split is depth: the preview is free, and the full report is an optional paid upgrade. The rule that keeps this honest is that the free result must be complete on its own terms, not a teaser with the useful part blurred out.

Problem 5: framing the output responsibly

Any tool that writes text about a person's life needs clear framing. The app labels readings as entertainment and self-reflection, not prediction or professional advice. If you build anything in this space (horoscopes, personality quizzes, "what does your handwriting say"), put that framing in the prompt and the UI, not just the terms page.

Takeaways

A no-signup preview is an engineering choice: it moves rate limiting, validation, and cost control to anonymous requests.
Validate the image cheaply before running the expensive model.
Show the intermediate result so users can catch bad inputs.
Make the free result complete, and charge for depth.
Frame generated content honestly, inside the output itself.

DEV Community: PalmReading.pro