Design

Systems

About

YDH

Get in touch

Problem and Context

Most car dealers aren't photographers. Cars get shot on messy forecourts, with inconsistent angles and poor lighting — and the resulting images don't sell.

Existing tools take one of two approaches, each with real limitations:

Background replacement (the standard approach among car-dealer tools) cuts the car out and swaps in a new background. This creates three consistent problems: reflections stay tied to the original environment rather than the new one, camera angle and focal length carry over unchanged even when they don't match the new background, and the car/background perspective rarely aligns — all of which read as fake immediately.

General-purpose image editing tools (GPT Image, Nano Banana) solve the perspective problem but introduce two new ones: the background isn't pixel-consistent across a slideshow of the same car, which is an instant tell to anyone browsing a dealer's website, and scale isn't consistent between cars — a Mini Cooper can end up looking larger than an SUV.

Process and approach

Finding the base model. I tested GPT Image, Seedance, and Nano Banana directly. GPT Image gave the best results, but introduced "background pixel drift" — small shifts in background texture (leaves, surfaces) between angles of the same car, breaking the slideshow consistency dealers need.

Fixing drift — first approach. I tried several fixes: JSON-structured prompting in Nano Banana, hybrid 3D-compositing approaches, and shadow-generation LoRAs, before landing on a three-step pipeline: generate in GPT Image, use Qwen Image Edit with ControlNet to regenerate the same car on a clean white background with position locked, then composite — cut the car out again, place it on a template background, and multiply the shadow pass back in with the car masked out.

This worked, but Qwen Image Edit only runs locally and took up to 2 minutes per pass at half resolution — a real problem for a business that only works at volume. Shadow accuracy was also inconsistent.

Fixing drift — final approach. I realised the GPT Image output already contained the shadow data I needed — I didn't need Qwen to generate a second version at all. The final pipeline: generate in GPT Image, then composite by cutting the car out, placing it on the clean template background, dividing the GPT output by the clean background, and multiplying that difference back onto the template using a median filter and levels adjustment. This dropped compositing time from roughly 40 minutes to 2 minutes per car.

Parallelizing generation. With compositing fast, generation itself became the bottleneck — GPT Image takes up to 2 minutes per call, and a full car needs 8 angles fired one after another, putting total generation time back up around 20 minutes per car. Using the OpenAI API to fire up to 50 images concurrently brought that down to roughly 3 minutes per car, end to end.

Automating client operations. With image processing solved, client management became the time sink. I mapped every manual step end to end to find what could be automated:

  • Clients upload to a Dropbox request link

  • A Python script polls every 10 minutes, and infers whether new uploads represent one car or several by comparing upload timing, photo count, and capture timestamps

  • Each detected car gets a source folder, then a JSON manifest the orchestrator reads — car ID, client, car height (for accurate compositing scale), model, separate exterior/interior photo lists, and whether license plate replacement is needed

  • The manifest triggers the GPT Image step, then automated compositing via the ComfyUI API

  • Output is compressed, stripped of metadata, and dropped into a ready-to-upload JPG folder

  • Any failed step or angle can simply be deleted — the system regenerates only what's missing

Outcomes

End-to-end pipeline, from client upload to ready-to-publish images, in under 5 minutes per car — versus days for traditional photography

  • Roughly 90% success rate on well-lit, reasonably clean input photos

  • No training required on the client side — competitors typically require dealers to learn specific rigs or shooting angles; this system only needs photos uploaded to a folder

What generalizes

The core technique — generating without pixel drift, then compositing with consistent scale — isn't car-specific. It applies to any product that needs multi-angle shots on a consistent background, particularly where floors or surfaces are low-detail (it degrades on high-detail textures like grass or sand). Product catalog photography and social content are the most direct adjacent use cases.

Challenges and future direction

Economics. The addressable market is currently independent used-car dealers specifically — larger dealers already employ photographers or have invested in turntable rigs, often have existing vendor contracts (e.g. Spyne), and higher-end dealers have less incentive to risk an AI-generated look at high price points. That leaves a market with thin margins: at £5–15 per car against roughly £0.40 in processing cost, margins are healthy in principle, but only if quality control is fully automated. Currently every image gets a manual check, which erodes the margin the automation was supposed to create. A vision-model QC step is the likely next fix.

Technical accuracy limits. The system preserves visible damage (bumps, scratches) well, but reflection accuracy varies — high-detail reflections (trees, leaves) transfer less reliably than overcast or low-reflectivity conditions. Not yet 100% consistent.

Compliance. AutoTrader's policy is a genuine grey area: background and lighting edits are explicitly allowed, but editing the car itself is not, and it's unclear whether this system's process counts as the latter. I've asked AutoTrader directly for clarification and haven't had a response yet. Separately, damage-accurate reproduction is harder than it sounds — the system currently maps all inputs to 8 fixed angles (0°, 30°, 90°, 135°, 180°, 215°, 270°, 330°), and matching a specific source photo to a specific output angle would require vision models to reliably distinguish close angles like 30° from 330°, which they currently don't do well enough to keep the pipeline both accurate and fast.

Not yet automated. Delivery to the client is still manual. The pipeline currently runs from a local terminal with ComfyUI kept open throughout — moving this to a persistent, always-on service is the next infrastructure step.