為甚麼修復閉眼照片時，編輯邊界至關重要

A group photo can be almost perfect: good light, everyone in the frame, a moment worth keeping.

Then you notice that one person blinked.

For a developer, this looks like a small image-editing task. But the real requirement is more demanding:

Open the eyes while preserving everything the user already likes about the photo.

I'm building MomentRescue, a photo-repair project. This post looks at one engineering question behind its Open Eyes workflow: how do you constrain a generative edit when the requested change is tiny?

1. Define what is allowed to change

“Make this photo better” is an open-ended request.

“Repair the selected person's closed eyes” has a much narrower boundary.

That distinction should appear in the system design, not just in the prompt. A useful contract is:

• One selected person per operation.
• A repair region around the eyes.
• Original image pixels outside that region.
• A separate output file, with the original kept intact.

The model may generate more than you intend to use. Your application still decides which generated pixels reach the final image.

That is the difference between asking for restraint and enforcing it.

2. Separate generation from composition

A practical conceptual pipeline looks like this:

Original photo
  -> detect faces and confirm the selected person
  -> prepare a face crop and optional reference
  -> generate a candidate repair
  -> align the candidate to the original coordinates
  -> blend it through a bounded eye-area mask
  -> compare, review, and export

This is a design outline, not a complete implementation or a claim that every photo-repair tool works this way.

The important separation is between producing a candidate and accepting pixels into the final photo.

For an opaque RGB image, the basic blend is:

// Illustrative RGB compositing, not production image-processing code.
function blendPixel(original, candidate, maskAlpha) {
  const a = Math.max(0, Math.min(1, maskAlpha));
  return original.map((channel, i) =>
    Math.round(channel * (1 - a) + candidate[i] * a)
  );
}

Outside the permitted region, maskAlpha must be zero. At the boundary, a gradual transition can soften the seam.

The difficult work sits around this small formula: coordinate mapping, alignment, mask placement, and handling the edges of glasses. A soft mask cannot fix a misaligned eye.

Also, preserving decoded pixels is different from preserving an original file byte for byte. Exporting can change compression and metadata.

3. Treat a reference as evidence, not a guarantee

Closed eyelids hide information. There is no reliable “sharpen” operation that reveals the person's actual eyes underneath.

An open-eye reference of the same person provides visual clues. But a sharp reference with a very different head angle can still be a poor match.

For a reference picker, useful guidance is concrete:

• Choose the same person with both eyes visible.
• Prefer a similar head angle and lighting.
• Try a neighboring shot from the same session.
• Avoid sunglasses, heavy blur, or a face that occupies very few pixels.

If the reference contains several people, the interface needs to confirm the matching person there too.

A reference reduces guesswork. It does not establish that the generated result is accurate.

4. Inspect an example at two scales

Here is an existing MomentRescue Open Eyes test.

These images use synthetic people. They are a product demonstration, not a customer photo, endorsement, or benchmark. Results vary.

Before: the center person has closed eyes.

After: the existing test result.

A full-photo view answers, “Does the picture still feel coherent?”

A close inspection answers different questions: Are both eyes looking in a compatible direction? Do the eyelids fit the face? Are the glasses frames continuous? Is there a visible blend boundary?

A result can pass one view and fail the other.

5. Give “finished” and “good” different meanings

An API response tells you that processing finished. It does not tell you whether someone looks like themselves.

I would evaluate a focused repair with three separate checks:

The first check can be automated by comparing decoded images outside the mask, before export. The other two still need visual judgment.

Useful evaluation cases include small faces, side profiles, glasses, mismatched references, and groups with more than one person blinking. A clean demonstration image cannot establish performance across those cases.

The broader engineering lesson

For a narrowly scoped AI edit, the output boundary is part of the feature.

The same question applies to removing a distraction, repairing a document region, or changing one object in a product photo:

Which parts of the input is the system actually allowed to rewrite?

A clear answer gives you something concrete to implement, inspect, and test.

How would you evaluate identity preservation in a small face edit, beyond checking whether the result looks plausible?

Disclosure: I am the developer behind MomentRescue. AI assistance was used to draft this article. The compositing snippet is illustrative; it is not the project's production implementation.

Workflow reference: MomentRescue's description of its selected-face repair pipeline.