DEV Community: Image2

Treat a Product Main Image Like a Constrained Transform: Turn a Phone Snapshot into a Pro White-Background Shot with GPT-Image-2

Image2 — Sun, 12 Jul 2026 16:44:02 +0000

As an engineer who helped a friend launch a small online store, I got stuck for ages on the main product image. A photo snapped on a phone — messy background, dim light, desk clutter — looks amateur on a listing. Hiring a photographer is expensive; setting up a light tent is a pain. Then it clicked: this is just a constrained image transform. The product is the invariant; the background and lighting are free parameters. Spell that constraint out to an image model and the output gets predictable.

This post walks through using the image-to-image (edit) capability of GPT-Image-2 to turn a casual product photo into a professional main image in one step. No light tent, no photo editor — the whole trick is pinning the constraint in the prompt. The method ports to any image model that supports image-to-image.

The core: declare the product as an invariant

A common first attempt is a one-liner like "make this product into a white-background main image" — and the model helpfully "optimizes" the label text, colors, and button placement into a different product. In e-commerce, that's fatal.

The fix is to pin the constraint. Upload your product photo, then paste this:

Turn this product photo into a professional e-commerce main image:
- Replace the background with a pure white seamless backdrop, keeping only the product;
- Center the product at a three-quarter angle, crisp clean edges, realistic material texture;
- Soft studio lighting with a natural contact shadow beneath the product;
- Leave clean negative space around it. No text, no logo, no watermark, no extra props.

Important: keep the product itself exactly the same — model, shape, color, material, buttons, labels, and packaging text must not change. Only swap the background and lighting; do not redesign the product.

Engineering notes:

Repeat "keep the product consistent, don't redesign" — that's the invariant constraint; without it the model improvises;
Set ratio to 1:1 — universal square main image for Amazon, Etsy, Shopify;
Choose 2K — generate large, then scale down to platform size; it stays sharper than generating small (upscaling a small image looks soft).

Free parameters: three main-image variants

Keep the prompt above as the base and only change the background/lighting lines per placement:

Use	Background / lighting	Prompt note
Marketplace hero (compliant)	Pure white #FFFFFF seamless	Product fills ~85%, zero text/badges
Detail page / feed ad	Real lifestyle scene	Describe a concrete scene, product is the hero
Brand / featured slot	Dark textured + directional light	Rim light, material close-up, cinematic

For the lifestyle variant, swap the background lines for:

Place this product photo into a real lifestyle scene:
- Scene: a corner of a minimalist Scandinavian desk in soft morning window light (replace as needed);
- The product is clearly visible, true to scale, naturally integrated, and the clear hero;
- Shallow depth of field, soft natural light, a clean editorial composition.

Keep the product's shape, color, material, and label text exactly the same. Do not alter the product design.

The post-processing pipeline

The generated main image is 1:1, but every platform has its own pixel spec. Two built-in tools close the loop:

Need a transparent PNG (collages, detail-page compositing) → change the background line in the prompt to "transparent background, output PNG, keep only the product" so the model outputs transparency directly;
Need a platform size → Image Resizer — Amazon recommends 1600×1600+, many marketplaces use 800×800.

The first pass won't be perfect — patch locally

AI generation takes a little luck: sometimes the background isn't cleanly swapped, or a label gets altered. Don't start over:

Off overall? Same prompt, Generate again for a fresh seed;
Only a local issue (a logo got changed)? Continue editing: "Only restore the logo and text on the front of the bottle to match the original; keep everything else unchanged";
One change at a time — piling on requests tanks the success rate.

Wrap-up

"Shooting a main image" sounds like a photography task, but at the prompt level it's a constraint-solving problem: declare the invariant (the product), parameterize the variables (background, lighting), iterate in small steps. Learn this "base template + three variants" and you can ship professional main images without a camera — and keep a whole storefront visually consistent.

If this was useful, I'd love to hear how it works on your own listings in the comments.

The demo uses image-2.net. The method is general — any image model with image-to-image and adjustable ratio/resolution works the same way.

Behind a Single "Paste" Button: The Tale of Two Completely Different APIs

Image2 — Sun, 05 Jul 2026 18:30:58 +0000

I used to think that adding a "paste image" feature to an upload component would be a one-liner. But when I tried to support both Ctrl+V and a clickable "Paste Button," I realized I was actually dealing with two fundamentally different browser APIs.

The Passive Approach: `clipboardData` (The `paste` Event)

When a user presses Ctrl+V, the browser fires a paste event, and the data is packed inside event.clipboardData:

const handlePaste = (event: React.ClipboardEvent) => {
  const files = Array.from(event.clipboardData?.items || [])
    .filter((it) => it.kind === 'file' && it.type.startsWith('image/'))
    .map((it) => it.getAsFile())
    .filter(Boolean) as File[];

  if (files.length) handleFiles(files);
};

The Upside: It requires no permissions and has universal browser support. Because the user explicitly initiates the paste, the browser trusts the action.

The Active Approach: `navigator.clipboard.read()` (Button Triggered)

Clicking a button to read the clipboard is a whole different story. The user didn't press Ctrl+V; instead, your code is actively trying to read their data:

const items = await navigator.clipboard.read();
for (const item of items) {
  const type = item.types.find((t) => t.startsWith('image/'));
  if (type) {
    const blob = await item.getType(type);
    handleFiles([new File([blob], `pasted.${type.split('/')[1]}`, { type })]);
  }
}

The Catch: It prompts the user for permission on the first try, and Firefox has poor support for read() when handling images. These aren't just two ways to write the same feature—they are two completely separate paths.

Feature	`clipboardData` (`Ctrl+V`)	`clipboard.read()` (Button)
Permission Prompt	None	Required
Browser Compatibility	Fully supported	Poor image support in Firefox
Focus Requirement	Required (see below)	Not required

The Sneakiest Trap: The Focus Pitfall

Developers usually bind onPaste to a specific UI element. However, DOM elements don't receive paste events by default unless they are focusable and currently focused. So, many people end up writing this:

<div tabIndex={0} onPaste={handlePaste}>...</div>

It looks fine on paper, but it's a ticking time bomb: Ctrl+V will only work after the user explicitly clicks this div to give it focus. In reality, when a user takes a screenshot and switches back to your page, the focus is almost never on the upload box. The paste silently fails, and the user feels cheated by a feature that "doesn't work".

The correct approach is to listen to the entire window so you can catch the paste event from anywhere on the page:

useEffect(() => {
  if (!enableWindowPaste) return; // Prevent multiple upload boxes from fighting over the event

  const onPaste = (e: ClipboardEvent) => { /* Extract files as shown above */ };
  window.addEventListener('paste', onPaste);

  return () => window.removeEventListener('paste', onPaste);
}, [enableWindowPaste, items.length]);

We polished all these edge cases into the upload component for Image2. The takeaway is simple: "Pasting" isn't a single feature; it's a combination of two APIs and a focus model. If you want it to be bulletproof, you need to know exactly which path you are taking.

This post isn't really about the technical nitty-gritty, though. It’s about something I find much more interesting: What it's actually like to polish a feature alongside an AI.

It all started with a vague request: "We support Ctrl+V upload now, but users don't know it exists. Help me brainstorm some solutions." What followed wasn't just a "one-shot code generation"—it was a genuine back-and-forth conversation.

It asked questions instead of rushing to code. When I suggested adding a paste button, it didn't just blindly implement it. Instead, it laid out the fact that buttons and hotkeys use entirely different clipboard APIs. It mapped out the trade-offs regarding permissions, browser compatibility, and focus requirements, and then asked: "Are you okay with the permission prompt?" It left the executive decision to me rather than making assumptions.
It caught the blind spots I didn't even think to ask about. While reviewing the code, it spotted the "focus trap"—the fact that Ctrl+V would fail unless the upload box was focused. This was completely absent from my requirements because I hadn't realized it was an issue. The true value of a great programming partner is seeing what lies outside your own peripheral vision.
It used multiple-choice options perfectly. When we were debating where to place the button, it didn't choose for me. It presented three different layout strategies, complete with text-based mockups, and let me pick. I chose "to the right of the header section," and only then did it write the implementation. It gave guidance when needed and let me steer when appropriate.
It knew how to tie up loose ends. Once the core functionality was working, it didn't stop there. It went ahead and added internationalization (i18n), accessible tooltips, and even proactively verified the aria-label tags for several icon buttons—the exact kind of polish I usually forget about.

After four rounds of iteration, my biggest takeaway is this: the value of an AI partner isn't just "speed." It’s how it forces a small feature to expose the depth it truly deserves. Focus models, API compromises, component communication, i18n, accessibility—we didn't miss a thing. It didn't do the thinking for me; it helped me think the problem all the way through.

This heavily refined feature is now live in Image2's image upload component. If you're curious, feel free to try it out and let me know what you think!