DEV Community: LION ZHANL

Designing an AI Sticker Removal Workflow With Real User Control

LION ZHANL — Thu, 30 Jul 2026 05:37:57 +0000

The model call is only one part of an AI image editor. The surrounding workflow has to make uncertainty visible and give the user a way to correct it. That is the product idea behind Remove Sticker From Photo.

The editor begins in Auto Detect mode. This is useful for visually distinct emojis, labels, and digital stickers. Detection will never be perfect, so the second mode—Brush Area—lets the user draw a mask over the exact overlay. The model then reconstructs the selected pixels using nearby image context rather than regenerating the entire photo.

An edit costs 4 credits. After processing, the output is rendered inside the editing frame and can be checked through a before-and-after comparison. The job is also recorded in task history, including work that is still processing and completed images that can be reopened later. These details matter because an asynchronous result should not disappear when a user navigates away.

The interface deliberately avoids claiming that AI “uncovers” hidden content. Once a sticker is flattened into an image, the original pixels are unavailable; the output is a generated approximation. Users should edit only material they own or have permission to modify. The service should not be used to remove ownership marks, manipulate documentary evidence, impersonate someone, or create deceptive media.

Good AI UX pairs convenient automation with precise manual control, inspectable results, persistent state, and honest limits.

Face Swap Group Photos: Target Selection and Cropping

LION ZHANL — Thu, 30 Jul 2026 04:39:33 +0000

Group photos are among the hardest inputs for an AI face swap. The problem is not simply that there are more faces. Each face can have a different size, angle, expression, lighting condition, and level of obstruction. The model also has to decide which detected face or faces should receive the reference identity.

In the current faceswap workflow, you upload a target image and use either the built-in face reference or a permitted custom reference. There is no precise face-number selector. If control over one person matters, cropping is the most reliable selection tool.

This guide explains how to prepare group photos without throwing away more of the scene than necessary.

First Decide What You Want the Result to Contain

Before editing the file, describe the intended result in one sentence.

Examples:

“Keep the entire group, but transform the person standing in the center.”
“Create a close meme crop of the person on the left.”
“Transform every clearly visible face with the same reference.”
“Keep two people, but remove the distant background crowd from the working image.”

These are different tasks. A single upload cannot always solve all of them reliably.

If your goal is one person, isolate one person. If the group context is essential, accept that face selection and consistency may be less predictable. Do not assume that the largest face, the first person from the left, or the central face will always be selected.

How Face Detection Changes in a Group

A human instantly separates foreground people, background faces, reflections, posters, and partially visible heads. A model sees candidate facial patterns.

Detection can be influenced by:

face size in pixels;
sharpness and contrast;
how much of the face is visible;
head angle;
distance from the image edge;
overlap with another person;
whether a face appears in a screen, mirror, or poster; and
preprocessing performed by the model provider.

A small but front-facing background face can sometimes be easier to detect than a larger foreground profile. That is why “the obvious subject” to a person may not be the obvious subject to the system.

The Three Group-Photo Scenarios

Scenario 1: One intended person, group context not required

Crop the photo to a head-and-shoulders or upper-body composition around that person. This gives the most control and usually the highest output quality.

Leave enough space around the hair, ears, and jaw. Do not crop exactly along the face boundary. The model needs surrounding pixels to blend edges and preserve the scene’s light.

Scenario 2: One intended person, group context must remain

This is more difficult because faces you do not intend to transform remain detectable.

Use a two-stage workflow:

Create a working crop that includes the intended person and enough nearby context.
Generate and evaluate the face result in that crop.
If you have the rights and editing skills, place the reviewed result back into a copy of the original using a normal image editor.

This gives you selection control without asking the face-swap model to understand the entire group. The final composite still needs careful edge, lighting, and disclosure review. Do not use this method to create false evidence or deceive viewers.

Scenario 3: Several intended faces

Expect more variation. The same reference can look different across people because each target face has different geometry, pose, and light.

For a stylized meme, variation may be acceptable. For a polished image, process people in separate crops and review each result. A single group-level pass is faster, but it gives you less control over which faces change and how consistently they blend.

A Reliable Cropping Workflow

Step 1: Start from the original file

Do not begin with a screenshot if the original photo is available. Screenshots often reduce resolution, add interface borders, and introduce an extra compression cycle.

Duplicate the original so you can return to it. Never repeatedly save over the only copy.

Step 2: Identify every detectable face

Look beyond the intended subject. Check:

background guests;
people partly outside the frame;
faces on phones or monitors;
mirrors and windows;
posters, printed shirts, or signs; and
faces hidden behind text or stickers.

If an unwanted face remains recognizable, assume it may be detected.

Step 3: Draw the first crop around the intended subject

For a close result, include the full head, neck, shoulders, and a small amount of background. For a medium crop, keep the upper body and relevant objects.

Avoid cuts through:

hairline or top of head;
chin or jaw;
ears;
hands touching the face; and
another person’s overlapping shoulder if that overlap defines the jaw edge.

A crop that is too tight can improve face size but damage boundary information. The goal is not the smallest possible rectangle; it is the cleanest useful context.

Step 4: Check pixel detail after cropping

Cropping makes the face larger on screen, but it does not add real detail. View the crop at 100%. If the eyes and mouth are still blocky, return to the original and choose another image.

A useful crop should make the target unambiguous while preserving enough pixels for feature edges. Use the photo quality scorecard to compare the original and crop.

Step 5: Match the reference

The built-in reference is designed to provide a stable default identity. If you upload a custom reference, choose one person only and use a clear portrait.

Do not use a group photo as the reference image. The reference should answer “which identity?” while the target answers “which scene and pose?” Multiple faces in both images create two layers of ambiguity.

Step 6: Export once

Use JPG for a normal photograph when file size matters, or PNG/WebP when your workflow requires those formats. Export at high but not excessive quality and avoid several save-and-reopen cycles.

The current upload interface displays the accepted formats and file-size limit. Follow that displayed limit rather than assuming a large camera original will upload unchanged.

Step 7: Inspect the generated result at two scales

At normal viewing size, ask whether the intended person changed and whether the group still reads naturally.

At 100% zoom, inspect:

eyes and eyewear;
hairline and ears;
jaw overlap with nearby people;
skin color under mixed light;
teeth and open mouths; and
any untouched faces that may have changed unexpectedly.

Do not share a result merely because the intended face looks acceptable. A background person may contain a more serious artifact.

Uneven Face Sizes Create Uneven Quality

Consider a photo with three people:

person A is close to the camera and fills 400 pixels from chin to forehead;
person B is farther away and fills 160 pixels;
person C is a blurred background guest with a 60-pixel face.

Even if all three are detected, the model does not have equal information for them. Person A may look convincing, person B may be soft, and person C may become a distorted patch.

This is not a single “quality setting” problem. It is an information problem inside the source image. Increasing the output resolution does not make person C’s original face more detailed.

If every person matters, use an image where the faces are similar in scale and focus.

Overlap Is Harder Than Simple Occlusion

A pair of glasses covers part of one face but belongs to that person. In a group, another person’s hair, hand, shoulder, or face may cross the target boundary. The model must decide which pixels belong to whom.

Common failures include:

the target jaw blending into the neighboring cheek;
hair from one person crossing the transformed forehead;
duplicated eye or mouth shapes near an overlap;
a skin-colored seam around a hand; and
the reference identity appearing partly on the wrong face.

Cropping cannot repair a severe overlap. Choose another frame when the target face is physically blocked by another person.

What to Do When the Wrong Face Changes

Do not immediately submit the same file again. A repeat may produce a slightly different image, but it does not remove the ambiguity.

Use this order:

Crop out every other visible face.
Keep the full intended head and some surrounding context.
Confirm the target face is the largest clear face in the crop.
Remove screenshot borders or irrelevant reflections by cropping, not by painting over the face.
Try a reference with a more compatible angle.
Generate once and compare.

If the intended scene requires several unmodified people around the target, use the two-stage workflow described earlier.

A Pre-Upload Group Checklist

Before generating, confirm:

I can name the exact person or people I intend to transform.
I have permission or another lawful basis to use the photo and depicted likenesses.
The target face is not severely covered or cropped.
The crop excludes irrelevant faces, screens, mirrors, and posters.
The target remains detailed at 100% zoom.
The reference contains one clear face.
The final image will not be presented as evidence of a real event.
I am prepared to label the result as AI-edited parody where context could be misunderstood.

If you cannot answer the first question clearly, the model will probably face the same ambiguity.

Privacy and Consent Matter More in Groups

A group photo can contain people who never expected their image to be processed by an AI service. Public availability does not automatically grant every privacy, publicity, biometric, copyright, or contractual permission.

Use photos you are allowed to process. Avoid images involving minors, private settings, sensitive events, or people who have objected. For public sharing, consider whether every identifiable person could reasonably understand the result as a joke rather than a factual record.

Review the Content Policy, AI Disclosure, and Privacy Policy before uploading sensitive material.

Final Recommendation

For reliable control, treat cropping as target selection:

One person wanted: isolate one person.
Group context wanted: test a controlled crop, then use a lawful, clearly disclosed editing workflow if you need to restore context.
Several faces wanted: expect variation and review every face separately.

The best group input is not necessarily the widest or highest-megapixel image. It is the image where the intended faces are clear, similarly lit, minimally overlapped, and easy to distinguish from every other face-like object.

When your crop is ready, open the faceswap tool. If the result contains eye, hairline, jaw, or skin artifacts, continue with our face-swap artifact troubleshooting guide.

Originally published at https://charliekirkface.net/blog/face-swap-group-photos-target-selection-and-cropping. This cross-post points search engines to the original canonical article.

How I Built a Privacy-First Browser Game Portal with Click-to-Load Iframes

LION ZHANL — Thu, 30 Jul 2026 03:24:32 +0000

Embedding a browser game looks simple:

<iframe src="https://games.example.net/my-game"></iframe>

That line lets a third party join the page lifecycle immediately. It can download a large bundle, establish connections, run scripts, request storage, display advertising, or fail before the visitor decides to play.

AI-assistance disclosure: I used AI to help draft and edit this article, then reviewed its architecture, code, claims, and limitations before publication.

For a game directory, that default is both expensive and surprising. A visitor may have opened the page to read the controls, compare games, or check whether the game works on a phone. Loading the player before that intent is known wastes bandwidth and collapses two separate decisions—visiting the guide and opening the third-party game—into one.

While working on a browser-game portal, I treated the site and the embedded player as two different trust and performance boundaries. The page renders first-party information immediately. The third-party frame is created only after an explicit Play action.

This article explains that pattern and the engineering details that made it useful rather than merely decorative.

Start with a two-layer model

The outer page should be a complete page without the game:

A descriptive heading and summary
Controls and gameplay tips
Developer and platform information
Related games and category navigation
A poster or cover image
A real button that starts the player

The inner layer is a small launcher responsible for the game lifecycle:

Validate the requested game.
Wait for an intentional Play action.
Create the provider iframe.
Report loading state.
Offer recovery when loading is slow or blocked.
Remove the frame when the player resets it.

Do not put the remote URL in the initial markup

Native iframe lazy loading is helpful below the fold, but it is not an intent gate. Browsers decide when a loading="lazy" frame is close enough to fetch. If the goal is “no third-party game request before Play,” the iframe must not exist yet, or it must not have a remote src.

The initial markup can be ordinary, semantic HTML:

<section class="game-launcher" aria-labelledby="launcher-title">
  <img
    src="/covers/sky-hoops.webp"
    width="960"
    height="540"
    alt=""
  />

  <div class="launcher-copy">
    <p id="launcher-status" aria-live="polite">Ready to play</p>
    <h2 id="launcher-title">Sky Hoops</h2>
    <button id="play-game" type="button">Play now</button>
  </div>

  <div id="game-mount"></div>
</section>

The empty mount is intentional. It prevents speculative loading, makes the initial DOM inexpensive, and gives JavaScript one controlled place to attach and remove the player.

Resolve games through an allowlist

Never copy a URL from a query parameter directly into iframe.src. A route such as /play?url=... becomes an open embed proxy and can make a trusted-looking domain display an attacker-controlled page.

Resolve a stable slug against server-owned configuration instead:

type Game = {
  slug: string;
  title: string;
  embedUrl: string;
};

const catalog: Record<string, Game> = {
  "sky-hoops": {
    slug: "sky-hoops",
    title: "Sky Hoops",
    embedUrl: "https://games.example.net/embed/sky-hoops",
  },
};

function getAllowedGame(slug: string): Game | null {
  const game = catalog[slug];
  if (!game) return null;

  const url = new URL(game.embedUrl);
  const allowed =
    url.protocol === "https:" &&
    url.hostname === "games.example.net" &&
    url.pathname === `/embed/${game.slug}`;

  return allowed ? game : null;
}

Validate protocol, hostname, and path—not just whether a string starts with an expected domain. A prefix test can be fooled by values such as trusted.example.attacker.test.

I also keep the source page URL separate from the embed URL. The former is useful for attribution and a fallback link; the latter is an implementation detail and should be narrowly allowlisted.

Create the iframe only in the click handler

The launcher can now transition from ready to loading to playing:

const mount = document.querySelector<HTMLDivElement>("#game-mount")!;
const button = document.querySelector<HTMLButtonElement>("#play-game")!;
const status = document.querySelector<HTMLElement>("#launcher-status")!;

function createGameFrame(game: Game): HTMLIFrameElement {
  const frame = document.createElement("iframe");
  frame.title = `${game.title} game`;
  frame.src = game.embedUrl;
  frame.allow = "autoplay; fullscreen; gamepad";
  frame.allowFullscreen = true;
  frame.referrerPolicy = "strict-origin-when-cross-origin";
  frame.sandbox =
    "allow-scripts allow-same-origin allow-forms allow-pointer-lock allow-fullscreen";
  frame.tabIndex = 0;
  return frame;
}

button.addEventListener("click", () => {
  const game = getAllowedGame("sky-hoops");
  if (!game) {
    status.textContent = "This game is currently unavailable.";
    return;
  }

  button.disabled = true;
  status.textContent = `Loading ${game.title}…`;

  const frame = createGameFrame(game);
  frame.addEventListener(
    "load",
    () => {
      status.textContent = `${game.title} is ready.`;
      frame.focus();
    },
    { once: true },
  );

  mount.replaceChildren(frame);
});

In production, keep launcher state in one place rather than inferring it from scattered CSS classes and flags. A small reducer makes repeated starts, resets, timeouts, and fullscreen transitions easier to reason about.

Treat `load` as a transport signal, not proof of playability

An iframe load event means the browser completed a navigation. It does not prove that the game rendered successfully. A provider may return an error page, a regional block, an authentication prompt, or a page that refuses to work inside a frame. Cross-origin isolation prevents the parent from reading the frame body to distinguish those cases.

Build the recovery UI around that limitation:

Show progress immediately after Play.
If no load event arrives after a reasonable timeout, reveal help.
Keep a link to open the provider’s source page in a new tab.
Offer Retry, which removes the old frame before creating a new one.
Let the user return to the launcher without reloading the entire page.
Record coarse start, load, timeout, and reset events only when analytics consent permits it.

A timeout should not claim that the provider is down. “Still connecting” is accurate; “server offline” is usually not.

If a provider documents a postMessage ready event, verify event.origin and the message schema. Never accept a generic { type: "ready" } from any origin.

Use sandboxing as one layer, not a magic shield

The sandbox attribute is powerful, but game compatibility often requires a considered set of capabilities. Canvas games may need scripts, pointer lock, fullscreen, forms, audio, or a same-origin context inside the provider’s own origin.

Grant only what a tested game needs. Be especially deliberate about combining allow-scripts and allow-same-origin. The risk depends on frame origin and control: a cross-origin provider is different from untrusted content served on your own origin.

Then add surrounding controls:

A Content Security Policy with a narrow frame-src allowlist
A restrictive Permissions Policy
HTTPS-only embed URLs
referrerPolicy="strict-origin-when-cross-origin" or a stricter policy when compatible
rel="noopener noreferrer" on new-tab fallback links
No secrets, user tokens, or sensitive data in frame URLs

Sandboxing does not make an unreviewed provider trustworthy. Confirm that you are allowed to embed the game, test the provider’s behavior, and keep a kill switch in the catalog.

Accessibility belongs in the launcher state machine

The iframe boundary makes keyboard and screen-reader behavior easy to overlook:

Use a native <button>, not a clickable <div>.
Give every iframe a specific title.
Announce loading and failure status through an aria-live region.
Move focus into the frame only after the user initiated the action.
Return focus to the Play button after Reset.
Keep focus indicators visible and do not make fullscreen the only playable mode.
Respect reduced-motion preferences in loading animation.

Cross-origin games may have accessibility limitations the host cannot repair. The host can still provide clear controls, honest status, keyboard-reachable recovery actions, and text instructions outside the frame.

Performance: optimize the page you control

Click-to-load removes the largest third-party cost from the initial path, but the outer page still needs discipline.

Reserve poster dimensions to prevent layout shift. Serve responsive, compressed covers. Avoid preconnecting to every provider in a large catalog; a preconnect is itself a network and privacy-relevant action. If you use one, add it only when the user is likely to start that specific game—or after pointer intent—after evaluating the tradeoff.

Code-split the launcher if it is not needed above the fold. Keep the game catalog small or load only the selected entry. Do not run a carousel, several animated covers, and a video background while claiming the frame is the performance problem.

Measure page readiness separately from game readiness (the time from Play to the best available ready signal). One combined “load time” hides whether the host or provider needs work.

SEO: index the guide, not the empty shell

A remote game frame is not a substitute for first-party content. Give each game a stable, canonical URL with a unique title, description, heading, and useful guide. Add breadcrumbs and relevant internal links. Where accurate, structured data can describe the page and game, but it should match visible content.

The launcher document itself is plumbing. If it has its own route, keep it out of the sitemap and prevent it from competing with the game detail page. The public detail page should be the canonical result.

This also improves resilience: if an embed is temporarily unavailable, the page remains a useful guide rather than a blank rectangle.

Test privacy and failure behavior, not only the happy path

My minimum test matrix includes:

Load a game page and verify that no provider frame exists before Play.
Inspect the network log and confirm that no game host request occurs before Play.
Start the game using keyboard only.
Simulate a slow connection and check that recovery help appears.
Block the provider with CSP and verify the fallback remains usable.
Click Play, Reset, and Play again; confirm only one iframe exists.
Test a modified slug, narrow viewport, rejected fullscreen request, and denied analytics.

The important architectural choice is not the button color or the loading animation. It is preserving a meaningful boundary between “I opened this page” and “I chose to run this third-party game.”

That boundary gives visitors more control and gives developers cleaner performance metrics, smaller failure domains, and a page that remains useful even when the embedded service does not.

Disclosure: I help maintain Play Basketball Bros, the independent browser-game guide used as the implementation case study in this article. Third-party games remain controlled by their respective providers; this article does not claim ownership of them.