Two Pipelines, One Asset: Designing Reviewable Image Cleanup and Motion Jobs

The hidden bug is often a review bug

A creative tool can make two operations look like one smooth flow: upload a clothing image, clean up a visible crease, then turn the result into a short video. From an engineering perspective, those are different jobs with different acceptance criteria.

This is an interface-level design proposal based on public product workflows. It does not infer private model routing, backend architecture, quality benchmarks, or production guarantees. The goal is to make the handoff between a retouched still and a generated clip explicit enough to test.

Define the two jobs before defining the button

PhotoGenerator AI presents a broad creative workspace, but a shared asset library should not force every operation into one generic status. A garment correction asks whether a target region was improved without damaging texture. A motion job asks whether a clip changes in the requested way while keeping approved details stable.

type ReviewStatus = "draft" | "processing" | "needs-review" | "approved" | "rejected" | "failed";

type GarmentEditJob = {
  id: string;
  sourceId: string;
  target: "garment-region";
  protectedDetails: string[];
  revision: number;
  status: ReviewStatus;
  previewUrl?: string;
};

type MotionBrief = {
  subjectMotion?: string;
  cameraMotion?: string;
  keepStable: string[];
};

type ImageVideoJob = {
  id: string;
  sourceRevision: number;
  brief: MotionBrief;
  status: ReviewStatus;
  previewUrl?: string;
};

protectedDetails is a human review contract, not a promise that a model will preserve every pixel. It might contain “shirt color,” “brand mark,” “seam,” and “body silhouette.” The user should see this list when comparing the source, edited still, and generated clip.

Keep the retouch boundary visible

The AI Clothes Wrinkle Remover workflow can be represented as upload, garment-focused correction, preview, and export. A product interface should show the source thumbnail beside the result and make the edit target readable. If the user asked for fabric cleanup, an accidental change to hair or background should not be hidden behind a generic “completed” badge.

The acceptance state needs more than a boolean:

type EditReview = {
  sourceId: string;
  resultId: string;
  checked: Array<"texture" | "color" | "silhouette" | "print" | "non-target-area">;
  decision: "approve" | "revise";
  note?: string;
};

This is useful for batch processing too. Ten catalog images may share a task but still require individual review. “Batch complete” should mean that outputs exist, not that every garment image is approved for publication.

Create a deliberate handoff to video

After a still is approved, the Image to Video AI workflow can accept a JPG or PNG, a motion description, and a preview step before export. The handoff should carry the approved still revision, not merely a filename.

type MotionRequest = {
  sourceEditJobId: string;
  sourceRevision: number;
  prompt: string;
  keepStable: string[];
  requestedAt: string;
};

function canStartMotion(edit: GarmentEditJob, review?: EditReview) {
  return edit.status === "approved" && review?.decision === "approve";
}

If the user changes the garment edit after creating a video request, the video should be marked stale or tied to the older revision. Otherwise a reviewer may approve a clip without realizing that it was generated from a superseded still.

Use separate review questions

For the edited image, ask:

• Is the crease that motivated the edit less distracting?
• Does the fabric retain believable grain, color, and shape?
• Did any non-target region change?

For the generated video, ask:

• Does the requested subject or camera movement appear?
• Does the garment keep its approved identity through the clip?
• Do labels, seams, hands, faces, and edges remain usable at the destination crop?

These questions should not be collapsed into one “looks good” action. A still can pass its garment review and still fail the motion review. An animation can be visually interesting while being unsuitable for a product claim.

Test stale revisions and safe retries

The important cases are not only successful uploads. Test revision identity, refresh behavior, and export gating.

test("motion job becomes stale after source revision changes", async ({ page }) => {
  await page.getByRole("button", { name: /approve edit/i }).click();
  await page.getByRole("button", { name: /generate video/i }).click();
  await page.getByRole("button", { name: /revise garment/i }).click();
  await expect(page.getByText(/video source is outdated/i)).toBeVisible();
});

test("export requires motion review", async ({ page }) => {
  await page.getByRole("button", { name: /generate video/i }).click();
  await expect(page.getByRole("button", { name: /export/i })).toBeDisabled();
});

The role names are illustrative and must be confirmed against the real UI. Add cases for a failed edit, a failed video request, a double submit, a changed prompt while processing, a deleted source, and a browser refresh during generation. A retry should either create a visible new revision or reuse a documented idempotency key; it should not silently replace the only preview.

Make the asset history useful

The result list should show source image, edit revision, motion prompt, status, and destination notes. A filename such as shirt-final-final-2.mp4 is not an audit trail. A compact history lets a designer explain why one version was selected and lets QA reproduce the review.

The same model helps accessibility. Announce progress with text, not only color. Give preview and replay controls meaningful names. Make the protected-details checklist available to keyboard users. Reviewability is a product capability, not a decorative layer added after generation works.

It is also worth making the comparison reversible. Let a reviewer open the original still, the edited still, and the selected video from the same record. If the user cannot return to the source without leaving the job, small visual decisions become difficult to verify. A clear “compare source” action is often more useful than another style preset because it keeps the acceptance decision tied to the asset that started the workflow.

Evidence has a boundary

Public page descriptions can establish an interaction pattern, but they cannot prove how a private implementation stores files or how every fabric behaves. Keep the original image, confirm rights to use people and garments, and inspect final outputs before publication. For commercial work, verify the current service terms and the destination platform’s media rules.

The durable design pattern is simple: treat garment cleanup as an image revision, treat motion as a new job, and make the relationship between them visible. Two pipelines can share an asset library while keeping their review contracts honest.