A prompt can describe a convincing scene. A useful photo editor also has to preserve the parts of the image that the user never asked to change.
Consider a simple request: put a ceramic mug on a different background. The background may look excellent while the handle changes shape, the glaze becomes smoother, or the small lettering drifts. The image succeeds as a composition and fails as an edit.
A reliable workflow has to answer two questions: did the requested change happen, and did everything else remain acceptable?
Turn the request into an edit contract
“Make this photo better” leaves too many decisions open. Separate the intended change from the constraints:
- Change the surroundings and supporting shadow.
- Preserve the subject’s silhouette, color, texture, and readable text.
- Keep the original asset available for comparison.
- Deliver the requested dimensions without cutting off important details.
These constraints do not guarantee model compliance. They establish a review target. Masks can narrow the edit region, but transparent materials, thin chains, and openings still need inspection.
Separate file validity from visual correctness
An output can be a valid image file and still be the wrong result.
File checks can establish that an image decodes, has the expected dimensions, and uses a format that supports transparency. They cannot establish that a label still says the same thing or a reflection makes physical sense.
Use separate checks:
- Technical validity: readable file, expected format and dimensions, appropriate alpha handling.
- Edit accuracy: requested changes appear in the intended region.
- Subject fidelity: shape, text, material, and identifying details remain acceptable.
- Delivery quality: crop, contrast, and composition work at the final display size.
Automate objective rules. Keep a side-by-side view for visual judgments. A thumbnail helps assess composition; lettering and edges need full-size inspection.
Three operations hiding behind “retry”
Repeated submission: the user clicks twice or a client repeats a request after losing a response. This should not accidentally create two independent paid jobs.
Transport retry: a temporary provider condition, such as throttling, triggers a bounded retry policy.
Creative retry: the user wants another result because the first image is unsatisfactory. This is a new decision, with its own cost and output history.
These operations should not share one undifferentiated “Try again” path. A timeout does not prove that remote generation never started.
A useful task-creation pattern is:
begin transaction
find existing task by workspace and idempotency key
if found: return existing task
create task and reserve credits
commit
enqueue task after commit
This is a control-flow sketch. A production implementation also needs to handle concurrent requests and enforce the intended uniqueness in its persistence layer.
Application-level idempotency does not make an external provider call exactly-once. If a provider completes work but the response is lost, blindly calling it again can still duplicate remote work. Provider request IDs, status reconciliation, and explicit uncertain states matter where supported.
Keep the task lifecycle separate from the prompt
PicViva provides a concrete implementation example: task creation includes a workspace-scoped idempotency lookup, task creation and credit reservation happen in a transaction, and queueing is deferred until after commit.
Its shared external-call wrapper retries qualifying throttling failures within a configured attempt limit, using increasing waits. Other errors are propagated.
Those choices address submission and accounting consistency. Visual quality remains a separate concern.
The general design principle is to give each concern its own owner:
- Task creation handles duplicate submissions.
- The provider boundary handles eligible transport failures.
- The review workflow handles whether a generated image is worth keeping.
Export is part of the edit
A resize may cut through the subject. A transparent image may be flattened unexpectedly. A preview may hide that the downloaded file has different dimensions.
Check the actual downloaded output. Keep crop position explicit and choose transparency deliberately. Review every channel-specific version rather than assuming one successful crop transfers to every aspect ratio.
Start with a small acceptance set
Choose three inputs: a straightforward subject, one with difficult boundaries, and one with readable text or reflective material.
Run the same task and record what needed correction. Count accepted outputs, retries, and review effort. Reuse this acceptance set when changing a model, prompt, or export step.
The prompt remains important. The surrounding workflow makes its result inspectable, recoverable, and ready to use.
Top comments (0)