Project profile
Automating the full lifecycle of missing product images
This system was built to solve a concrete catalog-maintenance problem: products can exist in BAYNAO without usable product images. Instead of requiring a person to search, download, rename, resize, upload, and register every image manually, the updater performs that workflow automatically and leaves a structured image set that the storefront and later quality-control processes can use.
The operational problem
A large e-commerce catalog continuously accumulates products whose image sets are incomplete or missing. The manual version of this task requires identifying the product, finding reliable images, checking that the files are valid, removing duplicates, deciding which image should be first, creating every size required by the website, uploading the files, and updating the catalog record. The updater turns those repeated steps into one deterministic pipeline.
- Targets a product that currently needs imagery.
- Reads its title, reference/SKU and internal product ID from BAYNAO.
- Uses the reference as the primary search key and the product title as a fallback.
- Processes the resulting files into the exact naming and size structure expected by the catalog.
Missing-image product discovery
The crawler begins from BAYNAO's internal missing-image workflow. It retrieves the product page and extracts three pieces of context used throughout the run: product title, product reference/SKU, and product ID. This keeps the image automation tied to a real catalog record rather than operating on an isolated folder of files.
SKU-based web image search
The system queries Google Custom Search in image mode using the product reference/SKU. If the SKU search returns no candidates, it automatically retries using the full product title. This is important because the SKU is usually the strongest identifier for matching a specific product model, while the title provides a practical fallback for products whose reference has weak search coverage.
- Google Custom Search API provides candidate image URLs.
- Safe Search is enabled.
- Known low-value social-media domains such as Instagram, Facebook, Pinterest and TikTok are skipped.
- Each candidate is downloaded with retries and rejected when the response is not actually an image.
Download, normalize, deduplicate and rank
Downloaded candidates are not sent directly to the storefront. Pillow opens each file, normalizes it to RGB/JPEG, and converts transparent images onto a white background so catalog presentation remains consistent. The pipeline then calculates perceptual hashes to remove duplicate candidates and selects the highest-resolution surviving image as the first image in the final sequence.
- Automatic retry handling for failed downloads.
- Content-Type validation before image processing.
- Transparent PNG/palette content normalized onto white backgrounds.
- Average perceptual hashes used to eliminate duplicate downloaded candidates.
- Image area (width × height) used to promote the strongest-resolution candidate to the first position.
- Final files are renumbered sequentially so gaps left by rejected or duplicate candidates do not propagate into the catalog.
Catalog-specific naming and image variants
The final assets are organized using BAYNAO's own product-image convention: product-{product_id}-01.jpg, -02.jpg, and so on. The updater then creates the image variants required by different storefront contexts rather than storing only one generic source file.
Each variant is resized proportionally and centered on a white canvas. This means the automation is aware of the presentation requirements of the existing e-commerce system instead of simply downloading arbitrary images.
Hash engine for traceability and later validation
After the final sequence has been established, the system calculates an average perceptual hash for every retained image and stores the fingerprint in MySQL together with the product ID and image filename. Before inserting the new set, previous hashes for that product are cleared so the table represents the current processed image set.
The hashes are useful beyond this updater: they create machine-comparable fingerprints that can support duplicate detection and later catalog-audit workflows without depending only on filenames or URLs.
Cloudflare R2 storage integration
Every generated catalog variant is uploaded programmatically to the BAYNAO Cloudflare R2 bucket through its S3-compatible API. Object keys preserve the site's image hierarchy, for example baynao_images/1/..., /2/..., /3/..., /4/... and /portada/....
- The same run performs local processing and cloud publication.
- Each output is uploaded with the correct JPEG content type.
- Folder organization matches the existing storefront image architecture.
Synchronizing the result with the product record
The workflow does not stop after uploading files. It counts the final images generated for the product and uses a headless Selenium session to open BAYNAO's internal product-management interface, update the cant_fotos field, and submit the form. This closes the loop between external image discovery, cloud storage, and the existing catalog administration system.
The run also reports operational statistics including candidates found, successful downloads, failures, duplicates removed, final image count, and total processing time.
End-to-end architecture
The updater combines API search, web retrieval, deterministic image processing, database fingerprints, object storage and browser automation in one pipeline.
How this connects to the AI Image Quality Auditor
The updater and the quality auditor solve different stages of the same catalog problem. This updater is the acquisition and preparation layer: its job is to populate missing image sets and put them into the correct technical structure. The separate AI Image Quality Auditor is the inspection and reinforcement layer: it can revisit catalog imagery in greater depth to identify quality, correctness, repetition, watermark, unavailable-image, or other visual problems that a fast acquisition pipeline should not be expected to solve alone.
Visual evidence
Real product examples show missing-image discovery, SKU-based search, downloaded candidates, final numbered image sets, Cloudflare R2 organization, stored hashes, and the resulting catalog page.
Engineering decisions
- SKU first, title second: use the strongest product identifier first while retaining a fallback when search coverage is poor.
- Validate before processing: URLs are not trusted to be images merely because they came from image search.
- Perceptual duplicate removal: avoid filling a product gallery with repeated candidates under different source URLs.
- Best-resolution image first: promote the strongest surviving candidate before final numbering.
- Deterministic catalog structure: filenames, dimensions, folders and cover-image behavior match the existing storefront.
- Separate acquisition from deep auditing: keep this pipeline focused on reliably filling missing imagery, while the AI Image Quality Auditor provides a second, more intensive validation layer.
Implementation note
The current implementation shown in this case study generates and stores image hashes and catalog image variants. The supplied crawler code does not itself show generation of SEO metadata, so this page does not claim that step as part of this specific implementation.