DEV Community: Ravi Verma

Clean Product Cut-Outs: A Practical Guide to Background Removal for Catalogues and Marketplaces

Ravi Verma — Sat, 17 Oct 2026 11:22:36 +0000

How automatic background removal works

Modern background removers use a segmentation model, a neural network trained to decide which pixels belong to the subject and which belong to everything else. Background pixels become transparent, and the result is saved as a PNG, because PNG has an alpha channel and JPG doesn't.

The model judges edges, shapes, colour and context together. That's why it handles irregular outlines much better than a "magic wand" selection. It's also why the input photo matters so much: the model can only separate what the camera actually captured as separate.

Step 1: Shoot for the cut-out, not the final image

Most messy edges are decided at capture time. A few habits make the biggest difference:

Contrast between subject and background. A white mug on a white sheet is a hard case. Put light products on a darker backdrop and dark products on a lighter one.
Even, soft lighting. Hard shadows on the backdrop can be read as part of the product. Shoot near a window on an overcast day, or bounce light off a wall.
Space behind the product. Pull the product a little away from the backdrop so it doesn't cast a shadow right against it.
Sharp focus. Motion blur and soft focus make edges ambiguous.
Enough resolution. A tiny thumbnail gives the model little detail to work with.
One subject per photo. Overlapping products, or products sitting on top of similar-coloured props, are much harder to separate.

Some materials are hard for any automatic tool: fine flyaway hair, transparent glass, thin wires and reflective surfaces. Plan for a manual touch-up on those.

Step 2: Remove the background

For one-off images or a small batch, the free PKD Ventures Background Remover takes a JPG, PNG or WEBP image and returns a transparent PNG. It uses an AI model to separate the product from the background. The first image can take a little longer while the model loads, and later ones are faster. Very large images can be slow on older phones.

If the source photo is small or soft, upscale it before removing the background. The Image Enhancer uses the Real-ESRGAN model to enlarge images 2X, 4X or 8X. Keep expectations realistic: it reconstructs plausible detail but can't recover detail that was never captured.

Step 3: Inspect the edges

Don't judge a cut-out against a white page, because white hides a light halo. Preview it against a dark colour and then a bright one. Look for:

a thin fringe of the old background colour around the edges,
missing chunks where the product matched the backdrop,
leftover patches of shadow under the product.

Small fringes can usually be fixed in any photo editor with a slight edge contract or a soft eraser. If you see big missing chunks, it's usually quicker to reshoot with better contrast than to repair the image.

Step 4: Keep a transparent master, then export per destination

Treat the transparent PNG as your master file. You can always flatten it onto any background later, but you can't get transparency back out of a JPG.

From that master you can export:

Transparent PNG or WEBP for websites, slide decks and composites where the product sits on a designed background.
White-background JPG for catalogues and marketplace main images.
Brand-colour versions for profile photos and social posts, with everyone on the same colour so a team page looks unified.

One shortcut for white backgrounds: the Image Compressor fills transparent areas with white when you choose JPG output. Choose WEBP or PNG output instead if you want to keep the transparency. You can also set quality and a maximum width to shrink phone photos.

If you prefer the command line, ImageMagick does the same flattening:

# Flatten a transparent PNG onto pure white and save as JPG
magick product.png -background white -alpha remove -alpha off product.jpg

# Check the colour of the top-left pixel (should be white for a white-background image)
magick product.jpg -format "%[pixel:p{0,0}]\n" info:

Step 5: Check the destination's rules

Every marketplace publishes its own image guidelines, and they change, so read the current version for each platform you sell on instead of relying on memory. Typical rules cover background colour, how much of the frame the product fills, minimum image size, and whether text, logos or props are allowed in the main image.

Amazon is a common example. Its main product image is expected to be on a pure white background (RGB 255, 255, 255), with no added text or graphics. "Looks white" isn't always enough. A light-grey backdrop straight from the camera can fail this check, so a flattened cut-out is often the more reliable route. The pixel check above is a quick way to confirm.

WhatsApp Business catalogues are more relaxed, but the same background, framing and canvas size across products still makes a small catalogue look organised.

A repeatable routine

Shoot every product against the same contrasting backdrop, in the same light, from the same angle.
Upscale any small or soft photos first.
Remove backgrounds in one sitting and check edges against dark and light previews.
Save transparent PNG masters, named by product code.
Export per destination: white JPG, transparent WEBP or a brand-colour version.
Compress and resize before uploading, then spot-check against each platform's current rules.

Closing note

This guide comes from PKD Ventures, a Kanpur-based company that builds websites, business apps and custom software. We also keep a set of free tools for everyday image and file jobs at pkdventures.in. If your store handles hundreds of product photos a week, it's usually worth building background removal and resizing into the upload pipeline itself, so every new image comes out consistent without any manual steps.

Scanned PDF or Text PDF? A Practical Guide to Getting Text Out (Including Hindi and Urdu OCR)

Ravi Verma — Sat, 17 Oct 2026 10:35:40 +0000

Sooner or later someone hands you a PDF and asks you to "just pull the text out". Maybe it's a vendor contract you need to diff, a stack of scanned forms you want to search, or an old Urdu notice someone needs retyped. Whether this takes two seconds or an afternoon depends on one question: does the PDF actually contain text?

This post walks through how to answer that question, which approach to use for each case, and the small habits that make OCR output far less painful to clean up.

Step 1: Find out what kind of PDF you have

PDFs come in two broad flavours:

Text PDFs are exported from Word, Google Docs, LaTeX, a reporting tool, and so on. The characters are stored as real text with fonts attached.
Image PDFs come out of scanners and phone scanner apps. Every page is basically a picture. There's nothing to extract until something reads the picture.

The lazy check is to open the file and Ctrl+F for a word you can see. If search finds it, there's a text layer.

If you're on the command line, poppler-utils gives you a more reliable signal:

# Lists the fonts embedded in the PDF.
# An empty table usually means the pages are images (a scan).
pdffonts document.pdf

# Try a direct extraction and see if anything meaningful comes out.
pdftotext -layout document.pdf - | head -40

Watch out for mixed files. A scanned contract with a typed cover page will show fonts, but only page 1 has text. If you're processing a batch, check per page instead of per file (pdftotext -f 3 -l 3 extracts just page 3).

Step 2: For text PDFs, skip OCR entirely

If the text layer exists, use it. Running OCR on a perfectly good text PDF is slower and less accurate than reading the characters that are already there.

A few things to expect:

Line breaks are visual, not semantic. PDFs store positioned lines, so a paragraph often comes out as several hard-wrapped lines. Most extractors try to rejoin them, but you'll still see odd breaks around hyphens and headings.
Multi-column layouts can interleave. Two columns may come out mixed line-by-line. pdftotext -layout keeps the columns side by side, which is often easier to fix by hand.
Tables flatten. Plain-text extraction drops cell borders, so a table turns into rows of words separated by spaces.

If you just need the wording in a usable format, a plain .txt (UTF-8) is the most portable target. If someone non-technical has to edit it afterwards, a .docx is friendlier. For a quick conversion without installing anything, I've used the PDF to TXT tool for plain UTF-8 output and the PDF to Word converter when the result needs to land in Word or Google Docs. Both extract text only, so layout, tables and images aren't recreated. That's the honest trade-off with any text-extraction approach.

Step 3: For scans, OCR is the only way in

Once you've confirmed the pages are images, you need optical character recognition. Tesseract is the usual open-source engine, and the CLI workflow looks like this:

# Render pages to images at 300 DPI
pdftoppm -r 300 -png scan.pdf page

# OCR each page (eng, hin and urd are Tesseract's codes
# for English, Hindi and Urdu; install the language data first)
for f in page-*.png; do
  tesseract "$f" "${f%.png}" -l urd
done

Two settings matter more than anything else here.

Resolution

Low-resolution renders destroy small text. Around 300 DPI is the commonly recommended target for printed text. Below that, thin strokes and dots start to merge, and accuracy drops off quickly. Complex scripts suffer the most. Urdu in Nastaliq has diacritic dots and joined letter shapes that just disappear at low DPI.

Language

OCR engines don't read "all writing" at once. They load a model for one script and language. Run English OCR on a Hindi page and you get a scatter of Latin characters, because the engine is hunting for letters that aren't there. Switch to hin and the same page becomes readable Devanagari.

If a page mixes scripts, for example English headings over Hindi body text, pick the language that covers most of the text. Tesseract can also take combined languages (-l hin+eng), but expect it to be slower.

Urdu has one more catch: it's written right to left. If you paste OCR output into an editor that assumes left-to-right, punctuation and numbers can look scrambled even when the recognition itself was fine. Check the paragraph direction before blaming the OCR.

Step 4: Improve the input, not the engine

Most "bad OCR" is really a bad scan. Before you tweak engine settings, fix the source:

Flatten and straighten the page. Skewed lines and curled book pages break line detection.
Use even lighting for phone scans. Shadows across the page and glare on glossy paper hide characters.
Avoid copies of copies. Every photocopy generation loses contrast, so scan the original if you have it.
Crop out the clutter. Fingers, desk edges and dark borders add noise the engine tries to read.
Test a few pages first. On a long document, OCR two or three representative pages, check the quality, then run the rest.

Step 5: Proofread the parts that matter

Even on a clean scan, OCR confuses similar shapes: 0 and O, 1 and l, rn and m. Before you trust the output, spend your proofreading time where mistakes are costly:

Names, amounts, dates and ID numbers
Headlines and anything set in a decorative font
Handwriting, which general-purpose OCR doesn't recognise reliably

If you're piping OCR output into code, validate the fields you care about (dates parse, totals add up, IDs match their expected format) rather than assuming the text is correct.

Quick decision checklist

pdffonts shows fonts and pdftotext returns real words? → Extract directly, no OCR.
Empty font table, or garbage text? → It's a scan. Render at around 300 DPI and OCR it.
Non-English text? → Set the OCR language explicitly (eng, hin, urd).
Output looks scrambled in Urdu? → Check right-to-left paragraph direction first.
Huge file? → Test a few pages before running the full batch.

Closing note

I put this together while working on document tools at PKD Ventures, a Kanpur-based company that builds websites, business apps and custom software. We also keep a set of free tools for everyday file jobs like these at pkdventures.in. If your team handles a steady stream of scanned forms or invoices, it's usually worth going beyond one-off conversion to proper field extraction and validation. Either way, getting Step 1 right will save you the most time.