Newsletter
Stay Ahead
Occasional, engineering-led notes on applied AI — what we're building, running, and learning in production.
Occasional, engineering-led notes on applied AI — what we're building, running, and learning in production.
Use case: Reverse image search with a single uploaded photo
Reverse image search answers a narrower question than catalogue browsing: given one photo someone just handed you — a screenshot, a competitor's product shot, a customer's snapshot of a damaged item — does anything in your own image library match it, and how confident should you be in that match? Webanto embeds the uploaded photo with DINOv3 into a 1280-dimensional vector and compares it against your pre-indexed library, returning the closest candidates ranked by similarity. Unlike a bulk indexing job, this is a one-off, ad-hoc lookup: a single query image comes in, gets embedded, gets compared, and the result either clears a confidence bar or it doesn't. Below that bar, the correct answer is no match at all, not a forced best guess dressed up as a real result.
Support and operations teams can check an incoming photo against known reference images without a human manually scrolling a library.
A confidence threshold on the similarity score means low-quality or unrelated queries return nothing rather than a misleading closest-available result.
Query cost is tiny and predictable per lookup — a single-image embedding call, not a batch job — so ad-hoc verification workflows stay cheap even at moderate volume.
The same indexed library can answer many different one-off queries over time without re-indexing, as long as the library itself hasn't changed.
Pick the reference library this feature checks against — a design-asset archive, past product photography, or a set of previously verified images — and give every entry a stable id.
Index that library once via POST /api/v1/image-embeddings using 'urls' (https only) or 'images' (base64), up to 60 per batch, storing each 1280-dimensional vector against its id in your own vector store.
For a 15,000-image internal library that's 15,000 divided by 20 per credit = 750 credits for the one-time index — a small fraction of even the Starter plan's 10,000 monthly credits.
At query time, accept the uploaded photo from a user or system. If it's a raw upload, base64-encode it into the 'images' field for a single-image request; if it's already hosted at an https URL, pass 'urls' instead — and keep in mind the endpoint's roughly 4.5MB request body limit, so downsize large phone-camera photos before sending.
Embed the query photo and run a cosine-similarity nearest-neighbour lookup against the indexed library vectors.
Apply a confidence threshold to the top result. Only surface candidates above that threshold as a match; treat anything below it as 'no match found' rather than returning the closest vector as if it were reliable.
Log every query — the top candidate's id, its similarity score, and whether it cleared the threshold — so you can retune the threshold as real false positives and false negatives show up in production.
Visual product search is catalogue browsing — a shopper's photo returns a ranked list of similar products to buy, and a mediocre match is still a useful suggestion. Reverse image search is a verification check on a single incoming photo — the question is whether a specific match exists in your library at all, so a mediocre match should be rejected rather than shown, which is why the confidence threshold matters much more here.
There's no fixed number that works everywhere — it depends on how similar your library images are to each other and how costly a false positive is for your workflow. Start conservative, review a sample of borderline results, and adjust the threshold based on where you actually see incorrect matches slipping through or good matches getting rejected.
No. You can send it directly as base64-encoded bytes through the 'images' field, which is the usual path for a photo a user just uploaded from their device. If the photo already lives at a public https URL, you can pass that URL instead — either works, but not both in the same request.
The nearest-neighbour lookup will still return the closest vector it can find, because similarity search always returns something. That's exactly why the confidence threshold exists on your side — below your chosen threshold, treat the result as no match, since a low similarity score for the 'best available' candidate is not the same thing as a real match.
It won't tell you if two images are pixel-for-pixel identical — that's a job for file hashing, not embeddings. It also doesn't read text baked into an image, count or localise multiple objects within a frame, or verify authenticity or ownership; it only reports visual similarity to what's already in your indexed library, so it's not a substitute for a proper rights-management or OCR system.
Shoppers who spot a product in the wild, on someone else's feed, or on a competitor's site rarely know the right keywords to find it in your catalogue. Visual search closes that gap: a shopper uploads
Large media libraries accumulate redundancy fast — the same product shot re-exported at a different crop, a stock photo uploaded twice under different filenames, a banner re-saved at a lower compressi
Invoices, purchase orders, delivery notes and scanned contracts arrive as PDFs and photos, not structured data, which means someone on your team is retyping totals, line items and dates into your acco
Start a 14-day free trial on any paid plan. No credit card required.