Fixing Closed Eyes with AI: Why the Edit Boundary Matters

A developer building MomentRescue, a photo-repair project, outlined an engineering approach to constraining generative edits for its Open Eyes workflow, arguing that the application — not the prompt — must enforce which generated pixels reach the final image. The design separates producing a candidate repair from accepting pixels, aligning the candidate to original coordinates and blending it through a bounded eye-area mask so pixels outside the permitted region stay unchanged. The developer proposes three evaluation checks — edit containment, local quality, and user acceptance — noting only the first can be automated.

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? “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: 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. A practical conceptual pipeline looks like this: php 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. 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: 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. Here is an existing MomentRescue Open Eyes test https://momentrescue.com/ . 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. 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: | Check | Question | |---|---| | Edit containment | Did any decoded pixels outside the permitted region change? | | Local quality | Do gaze, eyelids, lighting, and glasses look plausible? | | User acceptance | Does the person still look like themselves to the user? | 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. 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 https://momentrescue.com/about .