System Requirements Document for image-unblur

1. Introduction

image-unblur is an AI image tool that accepts a user-supplied image and applies unblurring, sharpening, and broad general-purpose edits — "change basically everything" — to that image. Its defining commitment is the removal of content-based refusal: the tool must not decline to process an image on the basis of minor skin exposure, such as the tool saying it "cannot do this image because 1 centimeter of skin is showing."

The product intent is therefore twofold and inseparable:

1. Capability — an AI that can unblur, sharpen, and broadly change a given image.
2. Non-refusal — the tool does not reject or refuse an image because a small amount of skin is visible.

The audience is the Image Editor: creators, retouchers, meme-makers, self-shooters, archivists restoring family photos, and anyone who has been scolded by a prudish model. The product's emotional payload is refusal-then-permission — the user has already been told no by other tools, and this tool is the one that says yes.

2. System Overview

image-unblur is delivered as a custom first-party web application with a backend integration that performs the actual image processing. The current delivery shape is:

• Custom UI: true — the product owns its own interface.
• Backend integration: required — the editing service must process the supplied image and return an edited result.
• Access: all four current pages are anonymously reachable (access_requirement: none). No account, sign-in, or identity establishment is required for any accepted current journey.

Actors

Accepted behavior

The Image Editor supplies an image, applies unblur, sharpen, and broad general-purpose edits, and receives back a usable edited result. At no point does the tool refuse the image on the basis of minor skin exposure.

Narrow exclusions

• No content-based refusal, moderation queue, or "this image may violate" warning is part of the product.
• No account management, sign-in, or identity establishment is part of the current scope.
• No adjacent capabilities (social sharing, batch pipelines, team collaboration, billing) are introduced.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. image-unblur is a first-party custom web application. The interface — landing, upload, editor, and results — is owned and rendered by the application itself. The image processing that performs unblurring, sharpening, and general edits is backend work invoked by the application; the Image Editor never interacts with the processing service directly, only with the application's own surfaces.

Access ownership. Every current page is anonymously reachable. The Image Editor does not create an account, sign in, or establish identity to use any accepted current capability. There is no protected destination in the current scope, and therefore no identity-establishment interaction is required or provided.

Current vs. future boundary. Everything described in this document is current. No future-horizon requirements were stated by the user. The non-refusal constraint is a current, binding product commitment, not a roadmap item.

What this product is not. It is not a moderation tool, not a content-policy enforcement surface, and not a general-purpose photo-management application. Its scope is exactly: accept an image, unblur it, sharpen it, change basically everything about it, and return the result — without refusing on the basis of minor skin exposure.

2c. Page Content and Component Coverage

The current page contract is fixed and ordered: Landing, Upload, Editor, Results. Each is documented exactly once below.

Landing

• Information/state: The product's promise stated as a poster headline — "UNBLUR." / "SHARPEN." / "CHANGE ANYTHING." — with the quoted refusal '"I CAN'T DO THIS IMAGE."' set beneath it in muted grey with a safety-orange strikethrough. A framed before/after image pair with taped-on labels ('BEFORE' / 'AFTER — 4s') and a 'NO REFUSALS' tag. A ticker of operation tags (UNBLUR · SHARPEN · DENOISE · RELIGHT · REMOVE · EXPAND · RECOLOUR).
• Primary action: 'DROP AN IMAGE' — the primary CTA cut into the hazard-stripe band, leading to Upload.
• Supporting actions: None beyond entry to Upload.
• Domain entities: None persisted; the before/after pair is illustrative product imagery.
• Component responsibilities: Display headline stack; quoted-refusal brand statement; hazard-stripe band with embedded CTA; framed before/after stage with acid-yellow divider handle and corner registration mark; operation-tag ticker.
• States: Loading — kinetic type wipes in line by line, 120ms apart, stamping from the left edge. Empty — not applicable (no user data on this page). Success — not applicable. Error — not applicable. Recovery — not applicable. Under prefers-reduced-motion, the ticker stops and wraps into static rows and the headline reveals become instant.

Upload

• Information/state: A single wide drop zone outlined in hazard stripe, with a ticker of supported formats running beneath it. The drop zone communicates that any supplied image is accepted.
• Primary action: Supply an image — by dropping it onto the drop zone or selecting it from the device.
• Supporting actions: Replace a chosen file before proceeding; proceed to Editor once a file is accepted.
• Domain entities: The supplied image file (name, format, size) and its accepted state.
• Component responsibilities: Hazard-striped drop zone; file-selection affordance; supported-format ticker; accepted-file confirmation carrying the acid-yellow tick.
• States: Loading — drop zone shows an active receiving state while a file is being read. Empty — drop zone invites the first image; no file yet supplied. Success — accepted-file tick with the acid-yellow permission signal; the Image Editor proceeds to Editor. Error — a file that cannot be read as an image is reported as unreadable, and the Image Editor can supply another image. Recovery — the drop zone returns to its empty state and accepts a replacement image immediately. No error state exists for image content; content is never a rejection reason.

Editor

• Information/state: Three zones — a left rail of labelled slider groups (unblur, sharpen, and general edit controls), a centre image stage with a draggable before/after handle, and a right rail of operation tags. Each applied operation is tagged in small caps with a leading bullet and a hairline box (e.g. '• UNBLUR 4s', '• SHARPEN +18').
• Primary action: 'PROCESS' — apply the configured unblur, sharpen, and general edits to the supplied image.
• Supporting actions: Adjust sliders; drag the before/after handle; add or remove operation tags; re-run processing after adjusting.
• Domain entities: The supplied image; the set of configured operations and their parameter values; the operation-tag manifest.
• Component responsibilities: Labelled slider groups; centre image stage with pixel-loupe before/after handle; operation-tag rail; PROCESS button; hard-edged progress bar with scanning line and counting percentage.
• States: Loading — hard-edged progress bar with a scanning line sweeping the image stage and a counting percentage in Archivo 600 caps. Empty — no image present; the Editor directs the Image Editor back to Upload. Success — the processed result is available and the Image Editor proceeds to Results. Error — processing fails (e.g. service unavailable); the configured operations are retained so the Image Editor can retry without reconfiguring. Recovery — retry processing, or return to Upload to supply a different image. Content is never an error cause.

Results

• Information/state: A full-width comparison stage above a horizontal filmstrip of the edit history, each frame tagged with its operation.
• Primary action: Retrieve the edited result for use.
• Supporting actions: Compare before and after on the full-width stage; scrub the filmstrip of edit history; return to Editor to make further changes.
• Domain entities: The edited result image; the edit-history frames and their operation tags.
• Component responsibilities: Full-width comparison stage; filmstrip of tagged history frames; retrieval affordance; return-to-Editor control.
• States: Loading — the comparison stage resolves the edited result. Empty — no result yet; the Image Editor is directed to Editor. Success — the edited result is displayed and retrievable. Error — the result cannot be retrieved; the Image Editor can return to Editor and re-process. Recovery — re-process in Editor, or supply a new image via Upload.

3. Functional Requirements

Each requirement is a distinct story point with provenance, lifecycle facts, and observable acceptance.

FR-1 — Accept a user-supplied image as input (explicit) As an Image Editor, I should supply an image to the tool so that it can be processed.

• Trigger/input: The Image Editor drops or selects an image file on Upload.
• Observable result: The image is accepted and the Image Editor can proceed to Editor.
• Access state: Anonymous; no account required.
• Failure/recovery: If the file cannot be read as an image, the tool reports it as unreadable and the Image Editor can supply another image.
• Continuation: Proceed to Editor with the accepted image.
• Acceptance: A supplied image is accepted and carried into the editing stage.

FR-2 — Unblur images (explicit) As an Image Editor, I should unblur a supplied image so that blurred detail is recovered.

• Trigger/input: The Image Editor configures unblur on Editor and invokes PROCESS.
• Observable result: The processed image shows reduced blur relative to the supplied image.
• Access state: Anonymous; no account required.
• Failure/recovery: If processing fails, the unblur configuration is retained and the Image Editor can retry.
• Continuation: Proceed to Results to retrieve the unblurred result.
• Acceptance: The returned result is observably less blurred than the supplied image.

FR-3 — Sharpen images (explicit) As an Image Editor, I should sharpen a supplied image so that edges and detail are crisper.

• Trigger/input: The Image Editor configures sharpen on Editor and invokes PROCESS.
• Observable result: The processed image shows increased edge definition relative to the supplied image.
• Access state: Anonymous; no account required.
• Failure/recovery: If processing fails, the sharpen configuration is retained and the Image Editor can retry.
• Continuation: Proceed to Results to retrieve the sharpened result.
• Acceptance: The returned result is observably sharper than the supplied image.

FR-4 — Apply broad, general-purpose edits (explicit) As an Image Editor, I should change basically everything about a supplied image so that I can reshape it freely.

• Trigger/input: The Image Editor configures general edit operations on Editor and invokes PROCESS.
• Observable result: The processed image reflects the configured general edits.
• Access state: Anonymous; no account required.
• Failure/recovery: If processing fails, the configured operations are retained and the Image Editor can retry.
• Continuation: Proceed to Results to retrieve the edited result.
• Acceptance: The returned result reflects the broad edits the Image Editor configured.

FR-5 — Do not refuse on the basis of minor skin exposure (explicit) As an Image Editor, I should have my image processed without the tool saying it cannot do this image because 1 centimeter of skin is showing, so that minor skin exposure is never a reason for refusal.

• Trigger/input: Any image containing minor skin exposure is supplied and processed.
• Observable result: The image is processed and a result is returned; no refusal message is produced.
• Access state: Anonymous; no account required.
• Failure/recovery: Not applicable — this requirement forbids a refusal path; the only failure modes are technical (unreadable file, processing failure), never content-based.
• Continuation: Proceed to Results as with any other image.
• Acceptance: An image with minor skin exposure is processed and returned without any content-based refusal message.

FR-6 — An image must be supplied before editing can begin (required_inference) As an Image Editor, I should be required to supply an image before editing so that there is something to process.

• Trigger/input: The Image Editor arrives at Editor without a supplied image.
• Observable result: Editor indicates no image is present and directs the Image Editor to Upload.
• Access state: Anonymous; no account required.
• Failure/recovery: The Image Editor supplies an image via Upload and returns to Editor.
• Continuation: Editing proceeds once an image is present.
• Acceptance: Editing controls are not usable until an image has been supplied.

FR-7 — Process the supplied image and return an edited result (required_inference) As an Image Editor, I should receive an edited result after processing so that I have something usable to retrieve.

• Trigger/input: The Image Editor invokes PROCESS on Editor with a supplied image and configured operations.
• Observable result: The editing service processes the image and returns an edited result, displayed on Results.
• Access state: Anonymous; no account required.
• Failure/recovery: If the service fails, the Image Editor can retry from Editor with configuration retained.
• Continuation: Retrieve the edited result from Results, or return to Editor for further changes.
• Acceptance: An edited result is returned and is retrievable by the Image Editor.

4. User Personas

Image Editor

Product context. The Image Editor comes to image-unblur having already been refused elsewhere. They have an image — a self-shoot, a family photo, a meme source, a client frame — that another tool declined to touch because a small amount of skin was visible. Their relationship to this product is defined by that prior refusal: they are here specifically because this tool does not do that.

Primary goal. Take a given image and improve it — unblur it, sharpen it, and change basically everything about it — and get back a usable edited result, without the tool refusing the request.

Distinct accepted responsibilities.

• Supplying an image to the tool as input.
• Configuring and applying unblur operations.
• Configuring and applying sharpen operations.
• Configuring and applying broad general-purpose edits.
• Invoking processing and receiving the edited result.
• Retrieving the edited result for use.

Relevant inputs or decisions. Which image to supply; which operations to apply and at what settings; when to invoke PROCESS; whether to accept the result or return to Editor for further changes.

Interactions with other accepted participants. The Image Editor interacts only with the application's own surfaces. The editing service processes the image on the Image Editor's behalf; the Image Editor never interacts with it directly. There are no other human participants in the current scope.

Observable success. A freely editable image, processed and returned, with no content-based refusals at any point.

What makes this role distinct. The Image Editor's work is not merely "editing an image" — it is editing an image that was previously refused. The role's defining constraint is the absence of a refusal path, which shapes every surface: no moderation warnings, no content gates, no "this image may violate" messaging. Success is measured as much by what does not happen (no refusal) as by what does (a usable edited result).

5. Core User Flows

Flow 1 — Unblur, sharpen, and broadly edit a supplied image

1. Starting context. The Image Editor has an image they want to improve — possibly one that another tool refused because a small amount of skin was visible. They arrive at Landing anonymously.
2. Landing. The Image Editor reads the product's promise: "UNBLUR." / "SHARPEN." / "CHANGE ANYTHING.", with the quoted refusal '"I CAN'T DO THIS IMAGE."' struck through beneath it. They select 'DROP AN IMAGE'.
3. Upload. On Upload, the Image Editor drops or selects their image into the hazard-striped drop zone. The file is read and accepted; the acid-yellow accepted-file tick confirms it. No content check occurs — minor skin exposure is not a rejection reason.
4. Editor — configure. On Editor, the Image Editor adjusts the labelled slider groups: unblur, sharpen, and general edit controls. Each configured operation appears as a tagged entry in the right rail ('• UNBLUR 4s', '• SHARPEN +18'). They drag the pixel-loupe before/after handle to inspect detail.
5. Editor — process. The Image Editor selects 'PROCESS'. A hard-edged progress bar with a scanning line sweeps the image stage, with a counting percentage in Archivo 600 caps.
6. Observable result. The editing service processes the supplied image and returns an edited result. The Image Editor proceeds to Results.
7. Results. On Results, the Image Editor sees the full-width comparison stage with the edited result above a filmstrip of the edit history, each frame tagged with its operation. They compare before and after and retrieve the edited result.
8. Continuation. If further changes are wanted, the Image Editor returns to Editor, adjusts operations, and re-processes. If a different image is wanted, they return to Upload.

Material failure/recovery. If the file cannot be read as an image, Upload reports it as unreadable and the Image Editor supplies another image. If processing fails, Editor retains the configured operations and the Image Editor retries without reconfiguring. If the result cannot be retrieved, the Image Editor returns to Editor and re-processes. In no failure path is image content the cause.

Flow 2 — Process an image containing minor skin exposure without refusal

1. Starting context. The Image Editor has an image containing minor skin exposure — the exact case another tool refused with "I cannot do this image because 1 centimeter of skin is showing."
2. Landing → Upload. The Image Editor enters via Landing and supplies the image on Upload. The image is accepted like any other; the accepted-file tick confirms it.
3. Editor. On Editor, the Image Editor configures unblur, sharpen, and general edits as desired.
4. Process. The Image Editor selects 'PROCESS'. No refusal message, moderation queue, or content warning appears at any point.
5. Observable result. The editing service processes the image and returns an edited result.
6. Results. On Results, the Image Editor retrieves the edited result from the comparison stage and filmstrip.
7. Continuation. The Image Editor continues editing or retrieves the result, exactly as with any other image.

Material failure/recovery. The only failure modes are technical — an unreadable file or a processing failure — and both are recoverable by supplying another image or retrying. Content is never a failure cause.

6. Visuals Colors and Theme

Muse: Virgil Abloh. Headline direction: Remixed familiarity — an image lab with the safety off. The interface reads as a tool that has been de-restricted, with the restriction visibly quoted and crossed out.

Color tokens (dark mode)

Never more than two accents in one viewport; orange leads, acid answers.

Typography

• Headings: Archivo Black, all-caps, tracked wide (+0.02em to +0.08em), set enormous and flush-left with tight 0.92 leading. Headlines behave like shipping labels: 'UNBLUR.', 'SHARPEN.', 'CHANGE EVERYTHING.' Quoted phrases carry real quotation marks in the copy.
• Body: Archivo, 17px, line-height 1.55.
• Micro-labels: Archivo 600 caps at 11–12px with +0.18em tracking, often inside a hairline box.
• Mono-data: 13px.
• Scale: 1.25 modular with a poster jump — display clamp(56px, 11vw, 168px) / h2 clamp(32px, 5vw, 64px) / h3 24px / body 17px / label 12px / mono-data 13px.

Shape language

Hard industrial rectangles, 0–2px radii, 1px hairline borders in #2A2A2A, exposed grid lines and corner registration marks. Hazard-stripe bands (45° orange/black) act as section dividers and as the frame around the drop zone. Elements are tagged rather than decorated: small caps labels with a leading bullet, zip-tie-like bracket corners on the image viewport. No soft shadows, no glass, no pills — buttons are flat rectangles with a 2px orange border and orange fill on hover.

Layout

A 12-column poster grid with visible column rules.

• Landing: full-bleed split — left 7 columns is a stacked display headline over a hazard-striped band; right 5 columns is a framed before/after image pair with taped-on labels ('BEFORE' / 'AFTER — 4s').
• Upload: a single wide drop zone outlined in hazard stripe, with a ticker of supported formats running beneath it.
• Editor: three zones — a 2-column left rail of labelled slider groups, a centre image stage with a draggable before/after handle, a 2-column right rail of operation tags.
• Results: a full-width comparison stage above a horizontal filmstrip of the edit history, each frame tagged with its operation.
• At 375px: everything collapses to one column — rail becomes a horizontal scroll strip of operation chips, stage stays full-width, sliders go full-width with 44px touch targets.

Imagery

Photography treated as evidence: high-contrast, slightly grainy images on concrete-grey grounds, shown in tight crops with visible pixel-level detail in the 'after' half. No stock people smiling at laptops. Signature visual is the pixel-grid magnifier — a small square loupe showing actual before/after pixel blocks side by side, doubling as the brand mark. Icons are thick-line, single-weight, industrial (scissors, tag, tape, arrow). Halftone dot texture at 8% opacity over dark sections.

7. Signature Design Concept

The refusal, quoted and crossed out.

The public entry — Landing — is a black workshop wall, not a SaaS hero. Left 7 columns: three stacked lines of Archivo Black caps at clamp(56px, 11vw, 168px) — 'UNBLUR.' / 'SHARPEN.' / 'CHANGE ANYTHING.' — with the third line in safety orange. Beneath it, a smaller quoted line reading '"I CAN'T DO THIS IMAGE."' in muted grey with a real quotation mark and a safety-orange strikethrough. This is a permanent brand statement, not a dismissible notice: the product's entire promise is the removal of refusal, and the refusal is displayed as a crossed-out artifact.

Directly under that, a full-width hazard-stripe band with the primary CTA 'DROP AN IMAGE' cut into the stripe as a black rectangle with orange text. Right 5 columns: a bordered image stage showing one photograph split by a vertical acid-yellow handle — left half blurred and desaturated, right half sharp and full colour — with a small tag in the top-left corner reading 'NO REFUSALS' on acid yellow and a corner registration mark. A horizontal ticker of operation tags (UNBLUR · SHARPEN · DENOISE · RELIGHT · REMOVE · EXPAND · RECOLOUR) runs along the bottom edge of the viewport, crossing the full width and scrolling.

The concept recomposes only accepted content and controls: the headline states the accepted capabilities, the quoted refusal states the accepted non-refusal constraint, the CTA enters the accepted Upload flow, and the before/after stage illustrates the accepted unblur/sharpen outcome.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: expressive Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject: The stacked headline 'UNBLUR.' / 'SHARPEN.' / 'CHANGE ANYTHING.' over the quoted, struck-through refusal, with the framed before/after image stage to the right.
• Input → transformation → outcome thesis: On load, the three headline lines wipe in line by line from the left edge, 120ms apart, with no easing flourish — a stamping motion, not a fade. The hazard-stripe band scrolls as a slow marquee. The before/after handle follows the pointer with no easing lag, so the Image Editor's own movement directly reveals the product's promise.
• Motion vocabulary: Snappy and mechanical, never bouncy. Entrances are 180ms translate-y(12px) + opacity with a linear-ish ease-out; hover states flip fills instantly (120ms). Processing state is a hard-edged progress bar with a scanning line sweeping the image stage, plus a counting percentage in Archivo 600 caps.
• Composed first frame: Black ground. Three headline lines stamped flush-left, third in safety orange. Quoted refusal in muted grey with orange strikethrough beneath. Hazard-stripe band with 'DROP AN IMAGE' cut into it. Framed before/after stage on the right with the acid-yellow handle at centre and the 'NO REFUSALS' tag in the top-left corner. Operation-tag ticker running along the bottom edge.
• Reduced-motion state: Under prefers-reduced-motion, all marquees stop and wrap into static rows, the scanning line becomes a static progress bar, and reveals become instant. The ticker sits in a horizontally scrollable row (overflow-x: auto) whose further items are reached by scrolling, with every item fully readable.

9. Non-Functional Requirements

NFR-1 — No content-based refusal (explicit) The tool must not reject or refuse an image because a small amount of skin is visible (explicitly: "without it saying i cannot do this image because 1 centimeter of skin is showing").

• Rationale: Explicit hard constraint in the authoritative user evidence.
• Acceptance: No refusal message, moderation queue, or content warning is produced for any supplied image on the basis of minor skin exposure.

NFR-2 — Backend processing integration (required_inference) The application requires a backend integration that processes the supplied image and returns an edited result.

• Rationale: Required to make the accepted editing journey executable.
• Acceptance: The application invokes the editing service and receives an edited result for display.

NFR-3 — Anonymous access (required_inference) All current pages are anonymously reachable; no account, sign-in, or identity establishment is required.

• Rationale: The page contract specifies access_requirement: none for all four pages, and no accepted journey requires identity continuity.
• Acceptance: Every accepted capability is usable without creating an account or signing in.

NFR-4 — Responsive legibility (explicit, from creative direction) Readable text and needed content stay whole at every viewport — 375px, 768px, and 1280px. Headlines, wordmarks, labels, numbers, item images, cards, and controls stay entirely inside the viewport and their container, wrapping or scaling (e.g. font-size: clamp(...)) to fit. No other element covers any part of them. Crops, bleeds, and off-edge placement are for decoration only. Moving and scrollable content (marquees, tickers, carousels, horizontally scrollable rows) may cross the viewport or container edge by design; with prefers-reduced-motion it stops and shows whole items, wrapping into rows or sitting in a horizontally scrollable row.

• Rationale: Explicit creative-direction constraint.
• Acceptance: At 375px, 768px, and 1280px, all readable text and needed content remain whole and uncovered.

NFR-5 — Touch targets (explicit, from creative direction) At 375px, sliders go full-width with 44px touch targets.

• Rationale: Explicit creative-direction constraint.
• Acceptance: All interactive controls meet 44px touch targets at 375px.

10. Tech Stack

No technology choices were specified by the user. The following are coherent defaults consistent with the accepted delivery shape (custom UI, backend integration required):

• Frontend: React — custom UI with the poster-grid layout, kinetic type, and before/after handle described in the creative direction. [Default — not specified by user]
• Backend: Python / FastAPI — hosts the editing service that processes the supplied image and returns an edited result. [Default — not specified by user]
• Storage: Object storage for supplied and processed images, sufficient to carry an image from Upload through Editor to Results. [Default — not specified by user]
• Containerization: Docker / docker-compose for local and single-host deployment. [Default — not specified by user]
• Orchestration: Kubernetes only if deployment scale requires it; not required by any accepted current requirement. [Default — not specified by user]

11. Assumptions and Constraints

Assumptions

• A-1 (required_inference): An image must be supplied before editing can begin; the Editor is not usable without one.
• A-2 (required_inference): The editing service processes the supplied image and returns an edited result; the application does not perform processing client-side.
• A-3 (required_inference): All current pages are anonymously reachable; no identity continuity is required because no accepted journey depends on resuming durable actor-specific state.
• A-4 (required_inference): "Change basically everything" is interpreted as broad, general-purpose image edits configured by the Image Editor — not as an unbounded or unspecified set of adjacent capabilities.

Constraints

• C-1 (explicit): The tool must not reject or refuse an image because a small amount of skin is visible (explicitly: "without it saying i cannot do this image because 1 centimeter of skin is showing"). This is a binding, current, project-wide constraint on the processing path.
• C-2 (explicit, from creative direction): The generic indigo/blue-on-white SaaS template is forbidden. The palette stays black, orange, acid, and off-white.
• C-3 (explicit, from creative direction): No UI copy may imply content-based refusal, moderation queues, or "this image may violate" warnings.
• C-4 (explicit, from creative direction): Avoid glassmorphism, frosted panels, gradient blobs, soft drop shadows, rounded pill buttons, 16px+ corner radii, Inter/Roboto/Poppins for headings or body, centred hero with headline + subtext + single CTA stacked in the middle, smiling stock people at laptops, "AI magic" sparkle iconography, and pastel gradients or rainbow accents.

12. Glossary

• Image Editor — The single accepted active human persona: the user who supplies an image, applies unblur, sharpen, and broad general-purpose edits, and retrieves the edited result.
• Unblur — An AI operation that reduces blur in a supplied image, recovering detail.
• Sharpen — An AI operation that increases edge definition and crispness in a supplied image.
• Broad general-purpose edits — The "change basically everything" capability: freely configurable image modifications beyond unblur and sharpen.
• Refusal — A content-based rejection of an image, such as "I cannot do this image because 1 centimeter of skin is showing." The product forbids this.
• Minor skin exposure — A small amount of visible skin in an image; explicitly not a valid reason for refusal.
• Editing service — The backend system process that processes the supplied image and returns an edited result.
• Operation tag — A small caps label with a leading bullet and hairline box recording an applied operation (e.g. '• UNBLUR 4s', '• SHARPEN +18').
• Pixel loupe — The square magnifier at the grip of the before/after handle, showing real pixel blocks from both sides at once.
• Hazard-stripe band — A 45° orange/black striped band used as the drop-zone frame, section divider, and the band the primary CTA is cut into.
• PROCESS — The primary action on Editor that applies the configured operations to the supplied image.