Forem: byeval

How Face Blur Patches Stay Aligned During Export

byeval — Thu, 23 Apr 2026 17:55:24 +0000

Blurring a face is easy if you only care about a static demo.

It gets more interesting when the user can redetect faces, expand padding, move patches, resize them, disable individual faces, change blur strength, and then export the final image without everything drifting out of alignment.

The architecture that held up best for us was patch-based.

The full companion guide is here:

https://happyimg.com/guides/how-face-blur-patches-stay-aligned-during-export

First build one blurred source image

Instead of blurring each patch independently, the editor creates a blurred version of the entire source image first:

ctx.filter = `blur(${blurStrength}px)`;
ctx.drawImage(image, 0, 0, canvas.width, canvas.height);
ctx.filter = "none";

That gives the editor one reusable blur source for every detected face.

The advantage is practical:

blur strength changes rebuild one source image
existing patches can keep their geometry
face interactions stay fast

Every face is a cropped image patch

Each detected face becomes a FabricImage patch that points into the blurred source image:

const patch = new FabricImage(this.blurredSourceElement!, {
  left: region.left + region.width / 2,
  top: region.top + region.height / 2,
  width: region.width,
  height: region.height,
  cropX: region.left,
  cropY: region.top,
});

That is the key design choice.

The editor is not blurring arbitrary rectangles on demand. It is showing cropped windows into a precomputed blurred image.

Geometry and crop source have to move together

If the user drags or resizes a blur patch, the patch cannot only change its visible rectangle. The crop window inside the blurred source has to stay aligned too.

That is why the implementation normalizes the patch back into real geometry and updates cropX and cropY alongside position and size:

patch.set({
  left: geometry.left + geometry.width / 2,
  top: geometry.top + geometry.height / 2,
  width: geometry.width,
  height: geometry.height,
  cropX: geometry.left,
  cropY: geometry.top,
  scaleX: 1,
  scaleY: 1,
});

That reset is important. It turns temporary drag/scale transforms back into stable source-image coordinates.

Padding matters before editing starts

Face detections are usually too tight on their own, so the code expands each detection by a configurable percentage before converting it into a patch.

That gives users a better starting point and reduces the number of patches that need manual resizing just to cover the edges of a face properly.

It is a small step, but it makes the blur tool feel much less fragile.

Export should replay the current patch set

When the user exports, the editor builds a fresh StaticCanvas at original size, adds the untouched base image, then re-adds each visible blur patch with its current geometry and crop source.

That means the saved file reflects:

current blur strength
current patch positions
current patch sizes
current enabled or disabled state

Nothing depends on the on-screen viewport.

Why patch-based blur works

This model stays understandable under real editing pressure:

one blur source
many editable crop windows
normalized geometry after interaction
export rebuilt from source pixels

That is what keeps blur regions aligned even after several rounds of detection, adjustment, and export.

More implementation details:

https://happyimg.com/guides/how-face-blur-patches-stay-aligned-during-export

Auto-Detect Should Not Auto-Apply: Building Reviewable Redaction Overlays

byeval — Thu, 23 Apr 2026 17:53:55 +0000

The easiest way to make automatic redaction feel unsafe is to skip the review step.

OCR, barcode detection, license-plate heuristics, and signature detection all make mistakes. If the product silently bakes those guesses into the exported image, users cannot tell whether the result is cautious, incomplete, or just wrong.

The better architecture is to turn detections into normal editor objects first.

The full companion guide is here:

https://happyimg.com/guides/how-reviewable-redaction-overlays-work-before-export

Normalize detector output before it reaches the editor

Different detectors can start from very different internals:

OCR text blocks
barcode APIs
plate-specific filters
connected-component image analysis

The editor should not need to know about any of that once a candidate region exists.

The useful boundary is one normalized shape:

left
top
width
height

Once every detector emits that region format, the editor can stay consistent even while the detection engines stay totally different.

Detection results should become editor objects

In the markup editor, automatic suggestions are inserted as ordinary objects.

Text detections can create redact rectangles. Blur and pixelation detections can create effect patches. The important part is that the result is editable:

moveable
resizable
deletable
visible before export

That is a much better interaction model than "the detector already changed your image."

Tag what the detector owns

The next implementation detail is the part that makes re-detect usable.

Auto-generated objects are tagged with a source identifier:

redact.data = {
  objectType: "shape",
  filled: true,
  autoGenerated: options?.autoGenerated,
};

That means the editor can distinguish OCR-generated regions from QR-generated regions and both from manual user edits.

Without that tag, every new scan risks wiping out the user's manual cleanup.

Replace only the detector's previous suggestions

Once objects carry a source tag, rerunning detection becomes much safer:

replaceAutoRedacts(regions: RedactRegion[], sourceTag: string) {
  this.clearAutoGenerated(sourceTag);
  regions.forEach((region) =>
    this.addRedact(region, {
      autoGenerated: sourceTag,
      select: false,
    })
  );
}

That gives you a clean behavior model:

detector reruns replace only their own old suggestions
manual edits stay intact
the user keeps control of the final reviewed state

This is one of those small code decisions that has huge product consequences.

Export still happens after review

The overlay architecture also keeps the export path honest.

Instead of baking detection results in immediately, the editor rebuilds the final image from the source plus the current object set. So the saved file always reflects the reviewed state, not the detector's first guess.

That is exactly where privacy tooling should land. Detectors propose. Users decide. Export serializes the decision.

The practical lesson

If an automatic detector can be wrong, it should create editable overlays rather than an irreversible export.

That rule works for OCR, QR codes, signatures, license plates, and basically every other privacy-sensitive suggestion pipeline I have seen.

It is also the point where an auto-detection feature stops feeling like a demo and starts feeling like a tool people can trust.

More implementation details:

https://happyimg.com/guides/how-reviewable-redaction-overlays-work-before-export

Stop Exporting The Viewport: How Zoomed Image Editors Map Back To Original Pixels

byeval — Thu, 23 Apr 2026 17:52:12 +0000

One of the easiest ways to break an image editor is to confuse the viewport with the image.

The screen needs zooming, centering, and a comfortable interaction scale. The exported file needs exact source-pixel geometry. If those two layers get mixed together, the UI might look fine while the saved result is wrong.

That boundary shows up in tools such as crop editors, screenshot redactors, and browser-side markup tools.

The full companion guide is here:

https://happyimg.com/guides/how-zoomed-image-editors-map-back-to-original-pixels

The viewport is for comfort, not truth

In the editor code, the Fabric canvas is sized to the visible container, then the viewport is transformed to fit the uploaded image:

const scale = Math.min(clientWidth / width, clientHeight / height) * 0.5;
const offsetX = (clientWidth - width * scale) / 2;
const offsetY = (clientHeight - height * scale) / 2;

this.canvas.setZoom(scale);
this.canvas.setViewportTransform([scale, 0, 0, scale, offsetX, offsetY]);

That is exactly what the UI should do. Users should not be forced to edit an 1800-pixel image at a 1:1 screen scale.

The important part is what this transform does not mean. It does not mean the viewport has become the source of truth for export.

Keep objects in image space

The source image and editor objects are still inserted using the original image dimensions:

this.image = new FabricImage(image, {
  left: image.width / 2,
  top: image.height / 2,
  selectable: false,
  evented: false,
});

That means a crop box or redaction region is defined in source-image coordinates even while the visible canvas is zoomed and centered for editing.

Once that boundary is in place, zooming becomes a viewing concern instead of a geometry problem.

Resizing is where geometry bugs usually appear

The subtle failure mode shows up during scaling handles.

If you keep committing transformed width and height on every live scaling event, the numbers start compounding and the box drifts away from the correct geometry.

The safer approach is to read the current temporary size from the base dimensions plus scale:

const width = (this.moveableRect.width ?? 0) * (this.moveableRect.scaleX ?? 1);
const height = (this.moveableRect.height ?? 0) * (this.moveableRect.scaleY ?? 1);

Then normalize the box back into real width, height, left, and top values once the interaction should be committed.

That sounds small, but it is the difference between a stable editor and a resize tool that gets weirder every time the user drags a corner.

Export should rebuild from source pixels

The other common mistake is exporting the visible viewport as if it were the artifact.

For crop export, the editor creates a fresh canvas sized to the normalized crop region and draws directly from the original image:

context.drawImage(
  this.sourceImage,
  Math.round(nextRect.left),
  Math.round(nextRect.top),
  width,
  height,
  0,
  0,
  width,
  height
);

For full markup export, the same idea appears as a clean StaticCanvas at the original image dimensions, with the base image re-added and the current overlay objects replayed onto it.

That is what makes the saved result accurate even if the editor viewport was zoomed out, zoomed in, or centered differently when the user clicked export.

The useful mental model

I think the cleanest rule is:

viewport transform is for viewing
object geometry is for editing
export canvas is for truth

If those three concerns stay separate, the math stays understandable and the output stays aligned.

If they get mixed together, you usually end up debugging "why is the export offset?" bugs that are really just architecture bugs.

More implementation details:

https://happyimg.com/guides/how-zoomed-image-editors-map-back-to-original-pixels

How To Auto-Detect QR Codes, Signatures, and License Plates In The Browser

byeval — Wed, 22 Apr 2026 13:51:26 +0000

One of the easiest mistakes in privacy tooling is trying to solve every target type with one detector.

QR codes, signatures, and license plates all end up as "regions to hide," but technically they are different problems:

QR codes are machine-readable symbols
license plates are structured text with strong visual constraints
signatures are image shapes more than readable words

If you force all three through generic OCR, the output gets noisy fast.

The companion guide for this piece is here:

https://happyimg.com/guides/how-to-auto-detect-qr-codes-signatures-and-license-plates-in-the-browser

Mixed detection works better than one universal pipeline

From the product side, these features all look related. The user wants the tool to suggest privacy-sensitive regions automatically.

From the engineering side, they need different signals.

The more useful architecture is:

multiple detector functions
one normalized region format
one editor surface
one review step before export

That keeps the interaction model simple without pretending the detection problem is simple.

QR codes and barcodes: use the browser when the browser already knows

For QR codes and barcodes, the cleanest path is usually BarcodeDetector when the browser supports it.

const detector = new BarcodeDetector({
  formats: ["qr_code", "code_128", "ean_13", "pdf417"],
});

const results = await detector.detect(source);

That gives you native symbol detection plus bounding boxes you can pad into safer blur or redaction regions.

The product lesson here is mostly about failure modes. If BarcodeDetector is unavailable, the UI should say so explicitly. Silent failure is worse than no feature because it makes the user trust an absence of results that may be false.

License plates: OCR is useful, but only as a candidate generator

License plates are text, but not ordinary text. A raw OCR pass usually gives too much junk unless you filter aggressively.

The pattern we used is:

start from OCR blocks and lines
normalize candidate text to uppercase alphanumeric characters
require both letters and digits
filter by plausible string length
reject impossible aspect ratios
ignore text in unlikely vertical positions

That turns OCR into a candidate generator instead of pretending it understands the full context of a vehicle image.

This is often the right level of ambition for privacy tooling: narrow heuristics on top of a broad detector.

Signatures: image analysis beats text recognition

Signatures are the opposite case. OCR often performs poorly because handwriting is inconsistent and the goal is not to read the text anyway. The goal is to find the signed region.

So the better signal was image analysis on a scaled canvas:

const imageData = context.getImageData(0, 0, canvas.width, canvas.height);
const threshold = estimateSignatureThreshold(data);

From there, the detector walks connected dark components, measures each region, and filters by heuristics like:

width
height
fill ratio
relative position on the page

Then nearby candidates can be merged into one more useful region.

This is not a universal signature model, and that is exactly the point. It is a practical heuristic for one narrow job.

Detection quality depends on what happens after detection

Even when the detector logic is correct, the raw output is usually not ready for users.

The post-processing layer matters a lot:

add padding so the target is fully covered
merge nearby fragments
deduplicate overlapping results
normalize everything into the same region shape the editor understands

If you skip those steps, the result is usually a screen full of tiny, fragmented boxes that nobody trusts.

One review model for many detectors

The biggest architecture win was not in the detectors themselves. It was in the shared output model.

Every detector returns the same kind of region object, and every region is inserted into the same editor as a reviewable overlay.

That gives the product a stable interaction model:

QR detection can suggest a region
signature detection can suggest another
plate detection can suggest blur regions
the user still reviews all of them the same way

That is much easier to maintain than building a special-case UX for every detector type.

The practical lesson

Privacy-sensitive detection gets better when you stop looking for one perfect detector and start using the right signal for each target.

The useful stack is often not:

one model
one answer

It is:

multiple detectors
narrow heuristics
normalized region output
explicit human review before export

That combination is usually much more reliable than a single generalized pass.

More implementation details:

https://happyimg.com/guides/how-to-auto-detect-qr-codes-signatures-and-license-plates-in-the-browser

Building Browser-First Image Redaction Without Uploading Files

byeval — Wed, 22 Apr 2026 13:50:54 +0000

If a redaction tool starts by uploading a sensitive screenshot to a server, the product has already created a trust problem.

That is why I think browser-first redaction is more than a frontend implementation choice. It is part of the product claim.

The companion guide for this piece is here:

https://happyimg.com/guides/how-browser-first-image-redaction-works-without-uploads

What "browser-first" should actually mean

A lot of products say they run in the browser. That statement is too vague to be useful.

For privacy-sensitive editing, the more meaningful boundary is this:

the original image stays local by default
editing happens on the client
export is rebuilt locally from the source image
the final file is downloaded directly in the browser

That does not make the implementation simpler. It just makes the privacy boundary explicit.

The visible canvas is not the source of truth

One of the first problems in a real editor is coordinate systems.

Users need a comfortable viewport with zooming and panning. The exported redaction, however, has to map back to the original image dimensions.

So the visible canvas should be treated as an interaction surface, not as the canonical image.

The implementation pattern we use is:

keep the original image dimensions as the source of truth
add the source image as the editor base layer
fit the viewport to the available screen space
keep overlays aligned to the original image coordinate system

That split is what makes browser-side editing and accurate export compatible.

Overlays are better than destructive mutations

The next decision was to treat edits as overlay objects rather than immediately mutating the bitmap every time the user interacts with the tool.

That gives the editor a much better operating model:

redaction boxes can still be moved and resized
blur and pixelation patches can react to strength changes
auto-detected regions can be replaced without touching manual edits
the user can review the exact objects that will affect the export

This is especially important in privacy tools because auto-generated suggestions should never feel permanent before review.

Export should rebuild the result, not capture the screen

Many browser image tools get loose at export time. They save the current editor state too literally, or effectively take a screenshot of the viewport.

That is not good enough for a privacy workflow.

The more reliable pattern is to create a clean export canvas at the original image dimensions, add the source image again, then replay the overlays on top of it.

In our case that starts with a fresh Fabric static canvas:

const exportCanvas = new StaticCanvas(util.createCanvasElement(), {
  width: this.sourceImageElement.width,
  height: this.sourceImageElement.height,
});

Then each visible overlay is cloned or reconstructed before generating the final file.

That matters because the editor may contain:

manual redaction shapes
blur or pixelation effect patches
auto-detected regions
text or annotation objects in adjacent tools

Export should represent the intended result, not whatever happens to be visible on a scaled viewport at that instant.

Local download is part of the privacy boundary

Once the export exists as a data URL or blob, the browser can download it directly:

const anchor = document.createElement("a");
anchor.href = dataUrl;
anchor.download = fileName;
anchor.click();

That seems basic, but in a privacy product it matters. If the editing workflow is local and the export path is local, the product story is easier to understand and easier to trust.

The hard parts are around the edges

Drawing a rectangle on a canvas is not the challenge.

The real engineering work shows up in the boundaries around the editor:

keeping original coordinates stable while the viewport zooms and pans
making auto-detection additive instead of destructive
rebuilding blur and pixelation patches accurately during export
keeping the editor responsive with large images
cleaning up canvas resources and workers on teardown

Those are the concerns that determine whether the tool feels credible.

Browser-first is a product decision

The main lesson for me was that "runs in the browser" is not the interesting sentence.

"Keeps sensitive editing local by default" is the interesting sentence.

That is the real boundary users care about, and it should shape the implementation.

If a product claims privacy-safe redaction, the architecture should reflect that claim:

local source handling
editable overlays
explicit review
local export

That will usually earn more trust than adding another server-side processing step and asking users not to worry about it.

More implementation details:

https://happyimg.com/guides/how-browser-first-image-redaction-works-without-uploads

OCR Is Not Redaction: Building Safer Auto-Redaction With Tesseract.js

byeval — Wed, 22 Apr 2026 13:49:57 +0000

OCR demos usually stop too early.

They show recognize(), print some text, and imply that automatic redaction is basically done. In a real product, that is maybe 20 percent of the job.

What users actually need is a safer pipeline:

Run OCR on the image.
Classify risky spans such as emails, phone numbers, account references, dates, and IDs.
Map those matched spans back to OCR word boxes.
Pad the boxes so the text edges are fully covered.
Insert them as editable regions instead of exporting immediately.

That is the pattern we use in a browser-first redaction flow built around Tesseract.js.

The full companion guide is here:

https://happyimg.com/guides/how-ocr-assisted-redaction-works-with-tesseract-js

Why we kept OCR in the browser

Sensitive screenshots are exactly the wrong kind of asset to upload to a server by default just to detect an email address or account number.

Running OCR in the browser gave us a cleaner privacy boundary:

the image stays local by default
the user can review the result immediately
the OCR pass can feed directly into the editor without waiting on a round trip

That still leaves the hardest part unsolved: turning OCR output into something safe enough to help with redaction.

Geometry matters more than text

For redaction, plain OCR text is not enough. The editor needs coordinates.

So instead of treating Tesseract.js as a text extractor, we ask it for structured layout data:

const result = await worker.recognize(
  asset.ocrSource,
  { rotateAuto: true },
  { blocks: true }
);

That gives us paragraphs, lines, and words with bounding boxes. Without those word-level bounds, there are no usable redaction candidates. There is only text.

We also lazily create and reuse the worker instead of rebuilding it on every scan:

if (!ocrWorkerRef.current) {
  const createWorker = await loadOcrWorkerFactory();
  ocrWorkerRef.current = await createWorker("eng", 1, { logger });
  await ocrWorkerRef.current.setParameters({
    tessedit_pageseg_mode: "11",
    preserve_interword_spaces: "1",
  });
}

That keeps the editor responsive across repeated scans and makes the OCR step feel more like a tool and less like a blocking batch job.

The useful trick: match text, then map back to words

The main implementation trick was simple and practical.

For each OCR line, we rebuild a single line string, but we also keep the character offsets of every OCR word inside that string. That gives us a bridge between pattern matching and image geometry.

So the flow becomes:

Reconstruct the OCR line as plain text.
Run regexes for categories like email, phone, URL, date, or ID.
Find which OCR words overlap each matched character range.
Merge those word bounds into one redaction region.

That lets us keep the matching logic simple while still ending up with coordinates we can draw and edit.

Tight boxes are risky

One thing that became obvious very quickly: exact glyph bounds look precise in demos, but they are risky in real privacy tooling.

If the box is too tight, the export can still leak fragments of the text around the edges. So after merging the matched word boxes, we expand the region with padding before inserting it into the editor.

That padding step ended up being one of the most important product decisions in the whole flow:

too little padding leaves readable fragments
too much padding hides useful surrounding context

So OCR quality alone is not the main issue. Region construction is just as important.

OCR should propose, not finalize

This was the biggest product lesson.

OCR-assisted redaction should not silently modify an image and export the result. It should insert reviewable regions into the editor and let the user confirm, delete, resize, or add more regions before saving.

For privacy tools, review is not a fallback. It is part of the feature.

That design also helped with the predictable OCR failure cases:

low-contrast screenshots
dense tables with tiny text
mixed-language content
broken OCR segmentation
labels like ID or Total that match patterns but are not always sensitive

Once you accept that OCR is a candidate generator instead of a perfect decision-maker, the whole interaction model gets better.

The real implementation boundary

Tesseract.js is only the OCR engine. The hard part is the boundary around it.

What actually made the feature useful was:

keeping the scan client-side
reusing the worker efficiently
preserving stable geometry
matching only the categories we cared about
padding regions conservatively
requiring review before export

That is the difference between an OCR demo and a privacy tool.

If you are building something similar, I would strongly recommend optimizing for reviewable suggestions instead of "one-click automatic redaction." The first approach ships. The second usually overpromises.

More implementation details:

https://happyimg.com/guides/how-ocr-assisted-redaction-works-with-tesseract-js