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: Visual product search from a shopper's own photo
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 or snaps a photo, Webanto embeds it with DINOv3, and the resulting 1280-dimensional vector is compared against the pre-embedded vectors for every SKU in your catalogue to surface the closest visual matches. DINOv3 responds to shape, colour, texture, and composition rather than metadata, so it finds the pale-blue linen jacket a shopper photographed at a friend's house even when the product title says nothing about colour or fabric. The vectors themselves are stateless outputs — Webanto never stores or indexes them, so your product-to-vector mapping and the nearest-neighbour search both live in infrastructure you control.
Shoppers can find items using a reference photo instead of guessing keywords, which is a documented driver of visual-search adoption in ecommerce generally.
A single embedding call per catalogue image means the recurring cost is just the query-time embedding for each shopper photo, not a per-search licensing fee.
Matches are driven by the item's actual visual attributes, so near-identical products from different suppliers surface together even with inconsistent titles.
The nearest-neighbour index is entirely yours, so you can combine it with in-stock and pricing filters however your storefront already works.
Export one clean, front-facing photo per SKU from your product catalogue, keeping each SKU's identifier attached to its image URL or file.
Batch the images to POST /api/v1/image-embeddings, at most 60 per call, and store the returned 1280-dimensional vector against its SKU id in your own database or vector store (pgvector, Pinecone, or similar — Webanto does not persist vectors).
For a 40,000-SKU catalogue that's 40,000 images divided by 20 per credit = 2,000 credits for the initial index, well inside a single month on the Growth plan (50,000 credits/mo, $79).
Build a nearest-neighbour index over the stored vectors (an IVFFlat or HNSW index in pgvector, or a Pinecone index) so lookups stay fast as the catalogue grows.
On the storefront, accept a shopper-uploaded or camera photo, send that single image to the same embedding endpoint, and query your index with the resulting vector.
Join the returned SKU ids against live inventory and pricing before rendering results — the embedding carries no stock or price information, only visual similarity.
Re-embed new or replaced product photos as they're uploaded rather than reprocessing the whole catalogue, so ongoing credit spend tracks catalogue churn, not catalogue size.
It answers a different question. Text search matches what a shopper types against your titles and tags; visual search matches what a photo actually looks like against your product images. DINOv3 has no concept of price, size, or brand, so visual search works best layered alongside your existing search and filters rather than replacing them outright.
No. Embed each new or changed product photo once, when it's added or replaced, and append it to your existing index. There is no need to reprocess SKUs that haven't changed — the credit cost scales with catalogue churn, not catalogue size.
Wherever you put them. Webanto's API returns the vector and does not retain or index it, so you're responsible for storage and search — typically pgvector inside an existing Postgres database, or a dedicated vector database like Pinecone if you need managed scaling.
Clean, well-lit, front-facing shots with the product as the dominant subject work best. Heavy watermarking, busy lifestyle backgrounds, or collage-style images with multiple products in one frame reduce match quality because DINOv3 is embedding the whole frame, not a cropped product region.
Skip it for very small catalogues (a few hundred SKUs or fewer), where filters and a decent text search already find everything quickly enough that a separate embedding pipeline is not worth maintaining. It's also a poor fit for catalogues of visually near-identical items — plain capsules, blank labels, uniform packaging — where DINOv3 has little visual signal to discriminate on.
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
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 —
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.