Reporting a bad cutout usefully

By Support writer

A useful bad-cutout report explains what failed, where it failed, and how to reproduce it. Start with the symptom, source format and dimensions, browser and extension version, input method, and whether first-run model setup had finished.

Do not send a private original automatically. First try to reproduce the issue with a harmless substitute or a tightly cropped, redacted example. A support report rarely needs a person’s identity, document text, location, or complete client asset.

First decide whether it is a quality issue or a failure

“Bad cutout” can mean several different things:

the image would not open;
processing never started;
processing crashed or stalled;
the subject mask removed an important part;
background remained around the subject;
hair, fur, glass, or thin objects broke apart;
a halo appeared only after export;
Copy failed while Download worked;
the result looked right in the editor but wrong in another application.

Name the category in the first sentence. “The handle disappeared after processing” gives support a starting point. “It does not work” does not.

If processing completed and only the edge needs a small correction, that may be a normal refinement case rather than a software failure. Include what the automatic result did before you used Add or Erase brushes.

Record the shortest reproduction path

Write the steps as if another person must follow them on a clean installation:

Open the extension from the toolbar.
Drop a local JPG with dimensions 2400 × 1600.
Wait for processing to finish.
Inspect the gap inside the object’s handle.
Download PNG.
Observe that the gap is filled in both preview and export.

Use only the steps needed to reach the symptom. Mention alternatives that change the result, such as “the same file works when saved as PNG” or “Download works, but Copy does not.”

For a page-image issue, include whether the failure happens only through the right-click route and whether saving the same image locally works. Some websites deliver images in ways that prevent the page workflow from reading them; that evidence separates delivery restrictions from model quality.

Include environment details that can change behavior

A compact environment block is enough:

extension version;
browser version;
operating system;
approximate device memory if processing crashes on large files;
whether the model download had completed;
source format, pixel dimensions, and approximate file size;
input route: choose, drop, paste, or page image;
output route: Download PNG or Copy;
whether the issue repeats after reopening the editor.

Avoid sending a full system inventory. Hardware serial numbers, account names, network addresses, installed-app lists, and unrelated browser history usually add risk without helping reproduce an edge defect.

Describe the image geometrically

When you cannot share the source, describe the visual conditions:

dark, curly hair against a dark wall;
transparent glass rim on a bright background;
narrow bicycle spokes crossing a textured street;
pale product edge against an off-white backdrop;
soft floor shadow touching the subject;
low-resolution screenshot with compression blocks;
subject partly cropped at the frame edge.

Mention where the error appears: top-left edge, enclosed gap, contact shadow, semi-transparent area, or one-pixel fringe around the export. This vocabulary is more actionable than saying the model “did not understand the photo.”

Use a safe substitute when possible

Try to recreate the same visual problem with an object you can share. If a client product has a missing handle, photograph a plain mug against a similar background. If private hair detail fails, use a wig, brush, yarn, or plant with a similar edge structure.

A substitute is useful only if it reproduces the symptom. State clearly that it is a reproduction, not the original. Include both success and failure conditions:

fails on low contrast, works on high contrast;
fails above a certain image size, works after resizing;
fails through page-image action, works from saved file;
preview is correct, exported PNG shows a fringe in a named local viewer.

That comparison often reveals more than the original alone.

If you must share an image, minimize it

Obtain the owner’s permission and follow any client or workplace policy first. Then remove everything the investigation does not need:

Duplicate the file so the original stays untouched.
Crop closely around the failing edge.
Remove metadata if your approved workflow requires it.
Redact names, screens, addresses, faces, and identifying marks outside the relevant area.
Confirm the redaction in the actual exported copy.
Share only through the designated feedback route.

Painting black over text can be inadequate if the document format preserves layers or hidden content. A flattened, tightly cropped raster copy is usually easier to reason about, but follow your organization’s rules.

Never submit identity documents, intimate images, children’s photos, medical records, credentials, or confidential evidence merely to improve a bug report.

Capture before and after without oversharing

For an edge-quality report, a close crop of three states can help:

source edge;
automatic mask result;
desired result after manual refinement.

Keep the crop large enough to show local contrast and texture, but small enough to remove identity and context. Label each state. If screenshots include browser tabs, bookmarks, notifications, filenames, or account avatars, crop those out before sending.

When the issue concerns export, inspect the PNG against both a light and dark local background. A pale halo may disappear on white while remaining obvious on dark gray. Say whether the defect exists in the editor preview, the exported file, or only the destination application.

Report timing and frequency honestly

Useful timing is approximate: “processing hangs for more than two minutes after the progress indicator starts” or “failure is immediate after choosing the file.” Do not report a precise benchmark from one distracted run.

State frequency:

every attempt with this safe sample;
two of five attempts;
once, not reproduced after restart;
only on first launch;
began after an extension update.

A one-time event still matters, but labeling it accurately keeps investigation focused.

What not to include

Leave out:

passwords, tokens, or account credentials;
complete browser logs you have not reviewed;
unrelated personal files;
the original private image when a safe crop reproduces the problem;
assumptions about server upload based only on seeing network activity;
aggressive claims about the cause without evidence.

Describe observations first. “The worker error appears after 40 seconds on this 30-megapixel file” is evidence. “The server rejected my photo” is speculation, especially when the cutout path is designed to run locally.

A report template

Use this compact structure:

Summary: One sentence naming the failed object or stage.
Expected: What should remain transparent, opaque, copied, or downloaded.
Observed: What actually happened and where it appears.
Steps: The shortest numbered reproduction.
Environment: Versions, system, model-setup state, source format and dimensions.
Frequency: Every time, intermittent, or once.
Safe sample: Attached reproduction, cropped example, or “cannot share.”
Workaround: Resize, re-export, use local file, refine manually, or none.

Use the extension feedback flow if your installed build provides one. Otherwise retain the report text so you can paste it into the current support route without rebuilding the evidence from memory.

Make the report useful and privacy-conscious

The strongest report is not the one with the most data. It is the one with the smallest reproducible example and the clearest boundary between observation and guess.

For immediate fixes, check Troubleshooting. Before attaching any sample, use the habits in Safe test image habits. Good reports improve cutout quality without turning private content into unnecessary support material.