AI inpainting: why manual redrawing of areas does not scale
Filling image areas manually looks like a simple operation: select a mask, choose a texture, blend edges by light and perspective. On a single frame, this is tens of minutes of editor work — and only if the background is uniform.
As soon as complex geometry appears in the frame (reflection on gloss, translucent packaging, intersecting shadows), edits go in iterations, and the mask is redrawn several times.
The bottleneck is not the speed of a single frame, but how it scales.
A catalog of several thousand items means thousands of masks and thousands of decisions about “what the edge looks like”: different editors produce different contrast, grain, and temperature, and neighboring cards begin to drift apart in style.
The Photoshop file with layer history does not restart in this process — when the source image or background requirements change, the work has to be explained and redone from scratch.
AI inpainting changes the scheme itself: the mask is set once, generative area filling follows the frame context and text prompt, and the engineer controls attachment to the source, edge overlap, and output resolution.
A batch of hundreds of images is processed in a single run instead of hundreds of hours of manual redrawing, and re-running on updated source images yields the same style without a new round of approvals. Below we break down how this is delivered as turnkey inpainting.
What changes after implementation: pace, consistency, failure class
Editing a single card before implementation is a chain of task setup, finding a suitable fragment, manual retouching, approval, and re-export.
After implementing AI inpainting, three or four links disappear: the mask and reference sample define the result immediately, and approval comes down to accepting the finished file.
Image processing speed increases not by making hands faster, but by shortening the route. The catalog’s unified style stops depending on who is on shift today: light, tone, shadow direction, and texture are set by filling parameters, so the tenth card looks the same as the first.
Control shifts from “like it / don’t like it” to measurable attributes: hue match, gradient continuity, absence of a visible transition at the area boundary.
Some defects disappear as a class — seams and halos along the patch edge, duplicated textures, “drifting” perspective, random fragment repeats.
These are exactly the errors manual retouching produces under time pressure: mask-based filling does not reproduce them, and questionable areas are flagged for manual refinement.
Scaling edits stops being a separate project — the same workflow handles both ten cards and several thousand.
A change log lets you return to any version of an image and avoid losing source files. Generation quality is assessed by the share of files accepted without edits — this metric becomes the main one during acceptance.
AI inpainting modes: comparing approaches and limitations
Filling modes differ not by model, but by how much scene context we give to the generator and how much we leave as a hard constraint.
Fully automatic area filling works when the background is even or repeating; a partial mask preserves object edges and changes only part of it; hybrid processing combines generation with manual refinement.
The key selection criteria are whether there is a reference from the same series, how critical the geometry is (lines, perspective, reflections), and what share of manual edits we are prepared to include.
| Mode | When it fits | Limitations of the approach |
|---|---|---|
| Fully automatic filling of the entire area | Even background, repeating textures: sky, wall, water | On structural scenes, geometry “drifts”: lines and perspective do not align |
| Partial mask with edge anchoring | Need to replace a fragment of an object while preserving its contour | Sensitive to mask precision: a shift by a couple of pixels creates a halo along the boundary |
| Reference-based generation | There is a sample of the object or style from the same series | The reference limits variability of angle and pose |
| Hybrid processing | Complex scenes: face, hands, text, reflections | Longer cycle, requires manual work on the mask |
On complex scenes, no single mode delivers a stable result: the generator stretches the texture but breaks the structure.
Here we assemble a cycle from an automatic draft pass, mask editing, and boundary finishing — more costly in time, but the result is repeatable across the entire series of frames.
How we implement: from data review to handover
Implementation of generative processing starts not with model selection, but with inventorying materials: we look at source resolution, presence of an alpha channel, defect types, background uniformity, and how many manual edits a person makes after the current automation.
This determines the solution architecture — where one network is enough, and where a cascade of annotation, filling, and post-processing is needed.
- Material audit. We compile into one table the image classes, recurring defects, and result requirements: what we consider a reject, what boundary error around the object is acceptable.
- Solution architecture. We define how the mask is formed, what fills the area, and what steps follow generation — color correction, boundary blending, halo cleanup.
- Mask annotation and data preparation. We assemble masks automatically according to current rules, then selectively verify them manually and adjust the rules where automation consistently errs.
- Tuning and training. We select modes for the specific material and aim for predictability across different frame types, not a high metric on one lucky set.
- Test batch. We run a fixed sample, compare the result with reference retouching, and calculate the share of frames that pass without edits.
- Result quality control. We set thresholds and spot-check procedures: the system flags questionable cases itself, and the operator reviews only those.
- Handover of the solution into operation. We deploy processing in your environment, document the procedure and train the team, and set up quality monitoring when new material types appear.
Handover is not “we gave you a script and left”: a description of the architecture, annotation rules, run log, and procedure for quality degradation remain. Describe the task — we will come back with an estimate and work plan.
Project artifacts: tuned models, annotation, procedures
We hand over not a “working demo”, but a pipeline your team can run itself: edit the result, further train the model on new data, and check quality against formal criteria. Below is what remains with the client.
- Tuned model. The weights and run configuration reside with you, not on our side: the same input produces the same result, and training is not tied to someone else’s infrastructure.
- Set of masks and references. Masks for typical tasks — seams, glare, removed objects, texture retouching — and before/after pairs with evaluations, against which every new frame is checked. The “like it / don’t like it” dispute is replaced by comparison with a reference.
- Editing guide. What can be changed independently: mask boundaries, inpainting strength, order of area processing, rejection threshold. It separately notes where an edit requires rebuilding the model rather than tuning it.
- Quality procedure. Batch acceptance criteria: share of areas without visible seams, preservation of texture and small details, absence of halos along the mask boundary. Plus a rollback rule to the previous version if the new one underperforms on these metrics.
- Solution documentation. Processing architecture, input file requirements, dependencies, deployment procedure, and common failures with causes. An engineer who did not participate in the project can bring up the pipeline from the document.
- Test set and further training procedure. Fixed scenes for regression and a description of how to assemble annotation for a new task so the model improves on your data without our involvement.
Acceptance is performed on your images: you accept not a report, but a working pipeline with clear rules for independent changes.
Case study: how manual redrawing was reduced on a large catalog
The project is an e-commerce image catalog: more than 40,000 cards, shot in batches. Glare on gloss, a foreign object in the corner, a cropped background edge — before implementation, such frames went to manual redrawing: about 40% of shots, from 8 to 15 minutes each.
The result depended on who took on the task: one person left a noticeable edge, another changed the background hue, and the catalog came out uneven.
What was restructured in the process
The mask is now built by automation: a detector finds the defective area, boundaries are refined along the object edge, and filling is performed by a generative model based on Stable Diffusion.
Every frame undergoes quality control — color, brightness, and boundary continuity are compared at the junction of the filled area with its surroundings.
A threshold decides whether a person is needed: above it, the frame goes into the catalog without editing; below it, into the retoucher’s queue, but already with a prepared mask and a mark of the problem area.
Settings are versioned, so one batch with one version produces the same result — the very repeatability that was absent with manual redrawing.
After implementation, the share of frames requiring manual editing fell from 40% to 7%: the rest is handled in seconds instead of minutes.
Re-running a batch produces deviations within noise, and rolling back to the previous settings version restores the previous appearance in one run.
How does generative filling differ from manual retouching?
These are two different paths to the same result, and they differ not in image quality, but in the distribution of control. Manual retouching is a sequential decision: the specialist builds up texture, light, and perspective themselves, and every change passes through their hand.
Generative filling — AI inpainting — solves the inverse task: the model completes the area based on surrounding context, while the person sets the mask and selects the variant.
Hence the difference in speed. On uniform backgrounds, sand, sky, foliage, the generative pass fills the area in seconds, and the amount of work almost does not depend on area. For the hand, the dependency is linear: the larger the area, the more hours.
On regular structures — masonry, tile, repeating pattern, font — the model errs at seams, and fixing the seam consumes all the savings.
Controllability is also different. Retouching is reproducible: the same edit is repeated by the same action.
With generative filling, repeatability comes from fixing parameters, but the model responds to context pixels, not to intent — when the source image changes or the mask expands, the variant drifts.
The boundary of applicability runs along the criticality of details. Background replacement, object removal, frame expansion, cleanup of small defects — here automation wins on all parameters.
Faces, logos, text, continuation of precise geometry, and shots with authenticity requirements remain with the human.
The practical mode is not a choice of one of the two, but a combination: the model provides a draft layer, the specialist aligns it with the source and maintains final control. A human is needed at the edges of meaning, not at the edges of the area.
Technical doubts: where the solution errs and how it is caught
Filling accuracy is determined not by the model itself, but by how the mask is prepared and the area boundaries are blended.
If the contour is cut off pixel-by-pixel, a halo from the old content appears at the junction — on textures and gradients it is noticeable when zoomed in, even when everything looks clean in the preview.
Therefore we build the mask with overlap inward and outward, and blend the result along the edge while preserving the grain and noise of the source shot.
A separate part of the work is result control and source protection. Below are four questions that most often come up during acceptance.
How accurately does the filling match the style of the rest of the frame?
Before launch, we assemble a reference set of 20–30 fragments from the same shoot and test the model on a held-out part: compare tone, grain, and light direction. If the deviation is above a set threshold, we add pairs to further training rather than tweaking parameters blindly. The output shows the share of frames that passed verification on the first run.
Will artifacts be visible at area junctions?
The mask is made with overlap into the area, and edges are blended smoothly, so no sharp line remains. We check the result when zoomed in, on solid backgrounds, and in grayscale — that is exactly where differences in contrast and grain appear first. We separately inspect repeating textures, where the model tends to “draw in” extra rhythm.
What happens to the source images?
Originals go read-only to separate storage and are not overwritten by any run. Each result is stored as a separate version linked to the mask and settings, so any frame can be rolled back to its pre-processing state. Access is role-based: an editor sees their images, an administrator sees version history.
Are editor edits taken into account during further training?
Yes, every manual edit is saved as a before/after pair and goes into the further training set. Once per cycle, the model is retrained and run on a held-out sample: if metrics on it drop, the build is not rolled out. This way the style gradually aligns with the editorial requirements, not with random frames.
Let’s discuss the task: we’ll review your images and come back with a plan
So that the estimate of material volume is based on data rather than assumptions, a test sample of images and a short task description are enough to start.
Send not “ideal” frames, but those that most often break automation: heavily compressed, with complex backgrounds, with several objects in the frame, and with overlaid text.
What is needed for the review:
- 15–30 source images in the formats in which they are stored on your side — JPEG, PNG, TIFF, PSD with layers; separately mark the most problematic ones.
- Masks or their description: where exactly the area needs to be filled — pixel mask, object bounding box, or text description of the result.
- 2–3 reference before/after examples: from your team, from a past project, or a contractor reference — they show what quality class is considered acceptance.
- Domain rules: what must not be changed during redrawing — logos, faces, numbers, element placement.
- Output requirements: resolution, format, whether transparency and preservation of source metadata are needed.
- Flow volume: how many images per day and what peak must be sustained, where the file comes from — manual upload, a call from your service, or batch processing from storage.
On the test sample, we run several filling modes, measure the share of frames that pass without manual refinement, and the processing time per image.
After that, we discuss the task concretely and come back with an implementation plan: stages, what will be required on your side, what acceptance looks like, and on which sample it is performed.
