Supplier image folders are where catalog standards go to test their self-esteem. One vendor sends excellent 4,000-pixel JPEGs named by SKU. Another sends a ZIP containing CMYK TIFFs, tiny web thumbnails, a price list, two logos, and a folder called new new photos. Both expect the products online this week.

The answer is not a larger manual cleanup folder. I would build a quarantine-and-manifest pipeline that separates file handling, product identity, image cleanup, standardization, review, and publishing. Each stage should produce evidence the next stage can trust, and uncertain identity should stop the asset before it reaches the catalog.

This guide focuses on the operational work around background removal because that is what determines whether scale is useful. A model can produce a clean cutout in seconds. It cannot know that IMG_0048.jpg is the walnut finish rather than the oak finish unless the workflow gives it that relationship.

The intake rule

Quarantine first. Identify second. Transform third.

  • Preserve every received file and inventory it before processing.
  • Resolve product and variant identity from a manifest, not filename guesswork.
  • Normalize decoding, orientation, color, and format before background removal.
  • Use category recipes and review lanes for difficult materials and geometry.
  • Feed rejection data back to suppliers so the same defects do not become permanent operations.

01

Land every delivery in quarantine

Treat each supplier delivery as an immutable batch. Copy the archive, shared-drive folder, SFTP upload, or portal submission into a batch prefix before opening or renaming anything. Record supplier, received time, original path, transport, and the checksum of the package. If the supplier updates the delivery, create another version rather than merging files into the first one.

Receive Quarantine Inventory Match products Normalize Clean Review Publish

Quarantine is not only for security, although archives and unexpected files deserve safe handling. It protects provenance. Six weeks later, when a merchant asks why a navy product is using a black image, you can inspect exactly what arrived and which mapping rule ran. Without the original batch, the investigation becomes a group exercise in remembering an email attachment.

Inventory before image processing

  • Archive and nested-folder paths, including files that are not images
  • Byte size, checksum, detected file type, and extension
  • Decoded width, height, orientation, color space, and alpha presence
  • Filename tokens that may represent SKU, variant, view, or sequence
  • Duplicate and near-duplicate candidates
  • Decode errors, password-protected archives, and suspicious payloads

Never execute what arrives

Unpack archives with path traversal protection, file-count and uncompressed-size limits, and malware scanning appropriate to your environment. A supplier ZIP is input data, not a tiny software distribution channel.

02

Build the product manifest before touching pixels

The manifest connects source assets to catalog entities. It should contain supplier ID, supplier product code, internal product ID, SKU, variant ID, view type, intended order, source asset ID, and mapping confidence. Get it from a PIM export, purchase-order data, supplier spreadsheet, or a reviewed mapping interface.

Normalized manifest entry

{
      "batchId": "supplier-aurora-2026-06-18",
      "sourceAssetId": "asset_4d901a",
      "supplierCode": "AR-991-WAL",
      "productId": "P-8821",
      "sku": "P-8821-WALNUT",
      "variantId": "V-8821-WALNUT",
      "view": "front",
      "sequence": 1,
      "matchMethod": "supplier-code-exact",
      "matchConfidence": 1,
      "status": "ready_for_normalization"
    }

Use exact mappings first: supplier code to internal variant, explicit spreadsheet row to filename, or a barcode known to the PIM. Fuzzy filename parsing can suggest matches, but ambiguous results should enter a mapping queue. If both 991-WAL and 991-WALNUT exist, “close enough” is not a catalog strategy.

Identity outcomes
OutcomeAction
One exact product and variant matchContinue automatically
Product matches, variant missingHold for mapping; do not attach at product level as a shortcut
Multiple possible matchesShow candidates and source context to a reviewer
No catalog matchQuarantine as an unmatched supplier asset
Several source files claim one viewRun duplicate comparison and retain an explicit selection
One file claims several productsRequire an intentional shared-asset relationship

Keep the original supplier filename even after assigning a clean internal key. It is useful when asking the supplier about a defect. Rename copies and derivatives, not the historical evidence.

03

Remove exact duplicates and expose near-duplicates

Exact checksums catch byte-for-byte duplicates, which are common when folders are copied into other folders before delivery. Perceptual hashes or image embeddings can find files that were resized, recompressed, lightly cropped, or renamed. Do not automatically delete near-duplicates; use them to group candidates for one product and view.

Exact

Same bytes, different path

Keep one canonical source record and record every supplied path as provenance. Skip duplicate processing calls.

Visual

Same photo, changed encoding

Group for review or choose the largest clean decode when product identity and view agree. Preserve both source records.

Similar

A real alternate or variant

Do not collapse based on resemblance alone. A slightly different angle, label, finish, or package can be commercially meaningful.

Duplicate detection belongs before background removal because it saves work and prevents identical outputs from appearing twice in a gallery. It also catches a frequent supplier pattern: one high-resolution original plus several web exports with different suffixes. Choose the best source once, then generate your own known derivatives.

Largest is not always best

A 10,000-pixel TIFF with broken color and sharpening halos may be worse than a clean 3,000 pixel JPEG. Rank candidates by decodability, real detail, compression artifacts, clipping, color profile, and dimensions rather than file size alone.

04

Normalize decoding before background removal

Background removal should receive a predictable raster, not every eccentricity the supplier's export software can produce. Decode orientation, verify dimensions, convert supported color profiles to sRGB, and create a high-quality working image when the source container or pixel count is unsuitable. Preserve the original untouched beside it.

Common supplier input problems
ProblemNormalization response
EXIF-rotated JPEGApply orientation before measuring or resizing
CMYK JPEG or TIFFConvert through the embedded profile to a known RGB working space
Huge dimensionsCreate a high-quality bounded working derivative; retain the source
Tiny web thumbnailReject below the category's useful resolution floor
Transparent PNG with prior cutoutInspect alpha; avoid flattening useful work before deciding whether to reprocess
Animated or multi-page inputSelect an intentional frame or page; never silently take the first
Extension does not match bytesTrust the decoder and detected content, then rename the working copy correctly
Corrupt or partial filePermanent intake failure; request a replacement

Avoid aggressive preprocessing. Heavy JPEG recompression, denoising, sharpening, and small resizing can damage the fine boundary information the model needs. Normalize enough to make the input safe and supported. Leave aesthetic cleanup for a deliberate downstream recipe.

Working-file record

  • Original asset ID and checksum
  • Decoder and normalization version
  • Applied orientation and color conversion
  • Source and working dimensions
  • Working format, quality, and checksum
  • Reason a derivative was required

05

Clean with category recipes, not one universal preset

Once inputs are known, process them with a recipe selected by category and destination. The background-removal request may be similar, but review rules and derivatives differ. Furniture needs a stable floor line. Jewelry needs generous resolution and scrutiny around chains. Apparel may need hair or fabric fringe preserved. Glassware needs transparency-aware review.

Opaque goods

The fast lane

Shoes, boxes, many appliances, and ordinary packaged goods often have a clear subject boundary and can move through automated canvas rules with sampling.

Open geometry

Inspect internal gaps

Chairs, bicycle parts, handles, baskets, and racks need checks for holes that were filled or thin pieces that disappeared.

Transparent

Treat alpha as appearance

Glass, clear plastic, veils, and translucent packaging cannot be judged only as foreground or background. Route to a specialized recipe or review.

Soft edges

Protect texture

Hair, fur, knit fringe, feathers, and plants need review on contrasting backgrounds and may tolerate less aggressive cropping.

Create a transparent master first when the asset may feed several channels. From that master, generate the supplier-clean archive, white marketplace image, storefront card, thumbnail, and any review preview. Store recipe versions so a future padding or background change does not require another round of background removal.

06

Build review around reasons, not a generic inbox

A review queue should explain why the image is there and show enough context to decide quickly: source, output on light and dark backgrounds, product identity, category recipe, intended channel, and nearby images from the same product. A reviewer should not need three tabs and a spreadsheet to determine whether the walnut chair is actually walnut.

Exception reasons and next actions
ReasonNext action
Identity uncertainResolve product or variant mapping before any pixel decision
Source clippedRequest another source or approve a channel-specific exception
Foreground detail missingRetry specialized recipe or send to manual retouch
Background remainsReprocess or manually refine the mask
Halo visibleInspect working-file compression and edge treatment
Unexpected transparencyCheck material behavior and internal openings
Scale or alignment outlierApply category geometry or approve intentional composition
Duplicate or wrong viewCorrect sequence or suppress the redundant asset

Capture approve, reject, reprocess, manual-retouch, and supplier-replacement outcomes with reason codes. Free-form notes are useful, but they cannot tell you that 31% of one vendor's images are below the resolution floor. Structured reasons turn review from cleanup labor into supplier and pipeline feedback.

The review queue is not where automation goes to hide its mistakes. It is where uncertainty becomes a recorded decision.

A healthier operating rule

07

Process batches with backpressure and idempotency

Supplier deliveries arrive in bursts, so separate intake speed from processing capacity. Inventory the batch quickly, then enqueue one job per selected source. Workers should lease jobs, cap concurrency, pace API requests, and retry transient failures with exponential backoff and jitter. Permanent input failures should stop immediately rather than enjoying the same bad request eight more times.

Idempotency

Skip equivalent work

Key processing by source checksum and normalized recipe version. If the output already exists and validates, reuse it.

Backpressure

Let the queue absorb the burst

Scale workers within API, storage, and catalog limits. A backlog is visible and recoverable; an overloaded downstream system is mostly just educational.

Checkpointing

Continue after partial success

Record output storage, review, derivative creation, and publish separately so a retry resumes from the first incomplete stage.

Automated supplier cleanup requires API access. BackgroundErase Business is $20 monthly or $200 annually plus $0.01 per API image; the 1,000 calls are trial calls only, not a recurring allowance. Starter is Studio-only at $5 monthly or $50 annually. For sustained high-volume processing, Enterprise pricing can be as low as $0.0025 per image. Include retry and reprocessing rates in forecasts, then use duplicate detection and idempotency to keep them low.

Batch metrics worth keeping

  • Assets received, matched, unmatched, duplicate, invalid, and selected
  • Processing success, permanent failure, retry, and duplicate-skip rates
  • Review rate and rejection reasons by supplier and category
  • Accepted images per API attempt and per human review minute
  • Queue age and time from delivery to channel-ready output
  • Publish failures, identity blocks, and rollbacks

08

Turn cleanup data into a supplier feedback loop

The cheapest bad image is the one the supplier stops sending. Produce a batch report with unmatched filenames, corrupt files, duplicate rate, dimensions below the minimum, clipped sources, missing required views, and repeated background problems. Include a few annotated examples and the exact naming and delivery contract for the next batch.

Score

Supplier batch quality

Track identity match rate, usable-source rate, duplicate rate, review rate, and time to catalog-ready assets. Compare suppliers using product mix as context.

Explain

Actionable defects

Say “14 front views were under 900 pixels” rather than “quality was inconsistent.” Specific defects can be fixed upstream.

Improve

A versioned delivery contract

Publish required naming, manifest columns, minimum source quality, accepted formats, view labels, and archive structure. Note the version on each batch.

Roll out the pipeline supplier by supplier. Start in shadow mode, review every result, and compare against the current manual process. Then auto-approve low-risk categories while keeping random samples in review. The goal is not merely to survive messy inputs faster. It is to make the inputs less messy over time.

Make intake explainable

Scale the decisions around the image, not just the transform.

Keep immutable batches, resolve identity before processing, normalize conservatively, route by category risk, and report defects back upstream. That turns supplier cleanup from recurring archaeology into a system that improves.

Standardize the marketplace outputs
Maxwell Meyer

Written by

Maxwell Meyer

Cofounder at BackgroundErase

Maxwell is a cofounder of BackgroundErase, where he works on image-processing research and developer infrastructure.