Image background removal and classification

Renable can process the images in your product feeds in two ways: categorize them (sort each one into Product, Lifestyle, Information and so on) and remove their backgrounds. Which images get processed is up to you, per catalog and, with a rule, per product. An image that isn't processed is still in your feed: the Image link and Additional image link placeholders always carry the feed's own images.

Feed images and processed images#

A product has two kinds of image, and they behave differently:

• A feed image is your own image, at its place in your product feed. Image link gives the main one and Additional image link the others, for every product, whether or not the image is processed. In a channel's fields they carry each image's address exactly as your product feed lists it, from the moment the product is imported — whatever your store's server sends for that address is what the destination gets. In a template or a prompt they use Renable's own copy of the same image, so there they show once Renable has fetched it — see When a template or prompt first uses a feed image. A feed image has no image card: it can't be approved, rejected, categorized, tagged or made primary, and nothing you do to a processed image changes it.
• A processed image is a feed image that went through the catalog's Image processing settings or a Process images rule — categorized, background removed, cropped, or none of these when no step applies to it. It's what Product image, Lifestyle image and the other category placeholders show, it's what appears as an image card on the product and on the project's Content page, and it's the only kind of image that approve, reject, category, tags and primary act on.

So a channel field that should carry an image Renable prepared — background removed, cropped — binds Product image, usually with Image link as its fallback ("Product image, else Image link"): the processed image where there is one, your own image where there isn't. A field bound to Image link sends your own image as it is, and nothing Renable does to the image changes what that field carries.

On a product's page, the feed images are listed read-only under each catalog in Product feed entries. An image listed there that isn't processed says "This image is shown straight from your product feed. It isn't processed, so it has no image card." When none of a product's images are processed, its Media section says "Image processing is off for this product's images, so its feed images are used as they are. To get processed images here, turn on Image processing in the catalog's settings or add a Process images rule." The Media section also shows images that are neither kind: ones you uploaded, ones a prompt generated, and ones included from another catalog.

When a template or prompt first uses a feed image#

A template or a prompt that shows Image link or Additional image link uses Renable's own copy of that image. Renable keeps a copy of every image it processes. When it has no copy of an image it doesn't process, it fetches one the first time a template or prompt needs it — the image is being fetched so it can be shown in a design. You don't have to do anything; this is what happens meanwhile:

• A design in a channel waits for it. The channel's run holds the update until the image has arrived, and your live feed keeps its previous contents meanwhile, just as it does while new designs are still rendering. In the channel's preview and trace the design shows its fallback, or shows as still being prepared, and fills in on its own.
• If the image hasn't arrived within an hour, the run publishes what's ready. If the placeholder showing the image has a fallback, the design goes out made with the fallback, and no warning is raised for it. Without a fallback, the product goes out without that design for that run — treated like any other missing content, so on a Meta channel it goes out archived — and the channel shows the warning that it was published before its media finished. Either way, Renable keeps going and corrects the feed on a later run once the image arrives.
• A prompt waits for it instead of skipping the product, and generates once the copy is there — usually within the hour after it arrives. When you test the prompt in its editor, the test says "The image is being fetched so it can be used.", and a later test run uses the image.
• If the image can't be fetched, the placeholder is empty: a design falls back if it has a fallback and is otherwise reported as missing content, and a prompt skips the product with the reason "The image could not be downloaded." Renable tries again automatically, and when a later attempt succeeds, the design and the prompt update on their own. If it keeps failing, the fix is on your store's side — see Why can't my images be retrieved?

A copy Renable keeps only so that templates and prompts can show it — an image that isn't processed — is removed when no channel design or prompt has used it for 45 days, and fetched again the next time one needs it. That next use waits for the image again, as above.

A channel field bound to Image link never waits for any of this: it carries your image's address as your feed lists it.

So "Product image, else Image link" works in templates and prompts as well as in channel fields: where there's no processed image, the feed's own photo is fetched and used.

Which images are processed#

A catalog's settings decide which of its images are processed. An image is processed when either of these holds:

• Categorize images is on — every image is then processed, because categorizing needs to look at all of them; or
• a background-removal step applies to it as a product image — a step whose Use for content types includes Product (or is left empty). A step set to Only apply this step to the main image covers only the main image.

So with Categorize images off and no steps, none of the catalog's images are processed. With Categorize images off and a main-image-only step, only each product's main image is processed. A catalog that only forwards its feed's images to your channels needs nothing more than that.

An image that isn't processed:

• isn't categorized, isn't sent to a background remover, and uses no credits;
• isn't a Product image, a Lifestyle image or any other image category — those placeholders only ever show processed images;
• doesn't appear among the product's images on the project's Content page;
• still reaches your channels through Image link (the feed's main image) and Additional image link (its other images), as described in Feed images and processed images.

If you change the settings so that an image stops being processed, it leaves the product's processed images after you publish. Anything you did to it is kept. A corrected category or a rejection comes back if the image is processed again later. An approval comes back only if the image is processed to the same result as before; if the result is different, it shows as unapproved again.

Templates and channels: Product image versus Image link#

Product image and the other category placeholders mean "an image that went through your processing". They don't promise a transparent cutout: a processed image's background is removed only if a step removed it, and the step scored well enough or was picked by hand.

When a product has no processed image of the kind a placeholder asks for, that placeholder is empty. Two ways to handle it:

• Fall back to the feed's image. Add a fallback to the placeholder (the ⋮ menu → Add fallback) and choose Image link, so it reads "Product image, else Image link". Use this where showing the feed's own photo is fine — in a template it's fetched the first time it's needed, as described above. The fallback applies whenever there is no processed image to show, including when you rejected it or it was filed under another category: rejecting a processed image does not remove the feed's original. See Placeholders.
• Adapt the template. Add an automation whose condition is Product image is blank, and let it change the design for those products — hide a background shape, show a different frame. See Automations.

Without either, an empty placeholder is missing content, and the channel treats the product the way its automations say — on a Meta or TikTok channel, for example, the built-in Status automation archives it. See Channel automations. Renable also says why a placeholder came up empty — still downloading, not processed, Categorize images off, and so on — see Why an image placeholder is empty.

Background removal#

Background removal is an ordered list of steps you configure on the catalog: each step picks a model version, which content categories it applies to, whether it should run on the main image only, whether to crop, and an acceptable quality score. If a step's result scores below its acceptable quality, the image goes to the next step in the list — for example, "try v1, and fall back to v3 if the quality is too low."

The steps are all there is to background removal. A new catalog starts with one Make transparent (v3) step. With no steps, there is no background removal: processed images stay as they came from the feed.

If no step scores high enough, the best result of all the steps is kept, and that image is flagged for review. The image is never silently left as the original, and it never lands in your ads unnoticed: flagged content failed an automatic quality check, so it shows up on the project's Content page for you to look at. Approving it clears the flag.

The available model versions:

• v1 — Renable's original background-removal model. Fast and inexpensive, and works best on images with a clean, plain white background.
• v3 — Renable's newer background-removal model, and the default for new catalogs. Handles colored or busy backgrounds better than v1.
• v2 — a premium third-party background-removal model. The highest quality option and handles almost anything well, but is by far the most expensive of them all, and can occasionally over-remove parts of product packaging or cartons.
• v4-medium — Renable's newest background-removal model. It costs about 1.4 times what v3 does per image.
• None — skip background removal for that step; the image is still cropped if the step's crop switch is on. With crop off as well, the step leaves the image exactly as it came from the feed.

It's common to chain models in several steps rather than rely on just one — for example, try the cheaper v1 first, and fall back to v3 only when v1's quality score is too low.

You build the chain on the catalog's Settings tab, in the Image processing section: the Categorize images switch sits in its own box at the top, and the steps follow under the Background removal heading. With Categorize images on and no steps, the section says "No steps, so backgrounds aren't removed." When the last step is a No transparency step and an earlier step removes backgrounds, a line under the list says "If no step scores high enough, the best result is kept and the image is flagged for review."

Removing the last step asks you to confirm first when it changes something. With Categorize images on, it asks "Remove the last step?": backgrounds will no longer be removed (or, for a No transparency step that crops, images will no longer be cropped), and after you publish, images go back to their originals. With Categorize images off, it asks "Stop processing images?", because with no steps and categorizing off, the catalog's images won't be processed at all, and after you publish, Product image will be empty. A last step that changed nothing — a No transparency step that doesn't crop, or, with Categorize images off, a step that leaves out Product — is removed without asking.

Under + Add step, a short note says when part of the catalog's images isn't processed: "No images are processed, so Product image is empty. Image link still has your product photos." when nothing is, or "Only main images are processed. Additional image link still has your other product photos." when only main images are.

Different processing for different products#

The settings on the catalog are the default for every product in it. When you want part of a catalog processed differently — the premium model on your best sellers, categorizing only for the rest — add a Process images rule on the catalog's Rules tab. Its dialog has the same two parts as the catalog's section: a Categorize images switch (on for a new rule) and the steps. Together they replace the catalog's settings for the products the rule matches. Everything else keeps the default.

Things worth knowing:

• A rule replaces both parts. The catalog's own Categorize images switch doesn't apply to the products the rule matches; the rule's switch does.
• Categorize images on with no steps is a categorize-only rule: those products' images are categorized, and no background is removed.
• A rule must do something: with Categorize images off every image counts as a Product image, so it needs at least one step that applies to Product images — a rule whose steps are all for Lifestyle or other content types would process no image, and can't be saved.
• If several rules set processing for the same product, the one lowest in the rule list wins — the usual rule order.
• It takes effect when you Publish, and only the products whose processing actually changed are processed again.

The same action is available inside a ruleset, so one decision can cover several catalogs.

Overriding the result manually#

On a specific product, open its image gallery and use Make transparent (v1 / v2 / v3 / v4-medium) on any image to force that version regardless of what the catalog's steps chose. It works on images stored in Renable — the processed images from your feeds, the versions Renable makes, and the images you upload — and refuses an image that is only linked from another website. Each image also shows Aimée's own confidence, for example "Aimée thinks the background removal quality of this image is N%," along with which model produced it — useful for deciding whether to leave the automatic result or override it.

You can also fix up a batch at once from the project's Content page: Make all images transparent (v1 / v2 / v3 / v4-medium) applies a version across every selected image. See Reviewing and approving content.

Image classification#

With Categorize images on, Aimée classifies each image so your templates and channels can target the right kind of shot. Behind the scenes, the classifier only distinguishes three broad buckets:

• Product — the item on a plain or neutral background.
• Lifestyle — the item in a natural setting or on a model (also covers what the classifier internally calls "feature" and "staged" shots).
• Information — badges, infographics, and other non-product graphics.

The manual category picker — in the gallery and in the Content page's bulk Change category action — lists every content category, but for an image the relevant ones are Information, Product, Lifestyle, Staged, and Feature. Use it when Aimée's automatic classification gets a specific image wrong, or when you want finer control than the three automatic buckets provide — for example, marking a specific shot as "Staged" so it's targeted by the Staged image placeholder instead of the general Lifestyle one. See Available placeholders for how each image placeholder resolves.

With Categorize images off, the images a step processes aren't classified: each of them counts as a Product image, except an image whose category you've changed yourself — your correction is that image's category (see "Correcting a category fixes it across the whole project" below). That is a supported way to run a catalog whose feed only has product shots. A step that leaves Product out of Use for content types then runs only on processed images whose category you've changed. The step editor marks such a step instead of removing it, so it applies to every matching image again as soon as you turn the switch back on.

Correcting a category fixes it across the whole project#

Many catalogs reuse the same image on lots of products — a size guide, a brand banner, a shared packshot. When you correct the category of an image, Aimée treats your choice as the right classification for that exact image from then on: every other product in the project showing the same image gets the corrected category, and newly imported products with that image get it right away instead of the automatic classification.

The correction changes more than the label — the image is also processed as if it had been classified that way from the start. Move an image into a category your catalog makes transparent, and its background is removed; move it out, and it returns to the original picture. This happens immediately on the image you corrected, and on the other products carrying the same image as they are brought up to date shortly after.

A correction doesn't decide whether an image is processed at all — that is the catalog's settings (or a rule's), as described above.

Your own decisions always win over the automatic spread:

• A category you set directly on a specific product's image is never changed by a correction made elsewhere.
• An approved image is never touched — approval locks its category. If you want an approved image to change, change its category directly, or un-approve it and then make the correction again (un-approving alone doesn't apply an earlier correction retroactively).
• When you make the correction, a notice tells you how many more products with the same image are getting the new category, and a "Processing image..." indicator stays visible until the corrected image is ready on screen.
• To see every product that uses the same image, open the image's ⋮ menu and choose Show all products with this image. The content view then lists exactly those products, showing only the matching image on each — bulk actions (approve, change category) apply to just these images. The search box shows the image filter as image:...; clear the search text to get back to the normal view. Manually uploaded and AI-generated images can't be searched this way — only images that came from your feed carry the fingerprint the search uses.
• The image you corrected is marked approved for you — you made the call, and the processing that follows from it is applied before the approval is recorded. One exception: if the automatic quality check flags the new result (for example a poor background cutout), the image is left unapproved and flagged so you can look at it first — approving it yourself clears the flag. The copies on other products are not approved automatically; they stay unapproved until you approve them yourself.

If you change your mind, just correct the image's category again — anywhere in the project. The latest correction wins, and every automatically updated copy follows it.

What approving an image locks — and what it doesn't#

Approving ("reviewing") an image locks in exactly two things against Aimée's automatic choices: which processed version is shown (the background-removal result you or Aimée picked) and its category. Aimée never changes either on an approved image on her own.

Approving an image does not freeze it against your catalog's own settings. If you later change the catalog's background-removal steps (for example, switching a step from v1 to v3), every image that step covers is rendered again with the new setting — approved images included. An approved image whose rendering changes this way shows as unapproved again until someone looks at it. Nothing is archived or replaced: it's the same image on the same product, with a new rendering. If you change the setting back, the approval returns on its own.

One exception: an image whose version you picked by hand (with Make transparent (v1 / v2 / v3 / v4-medium)) keeps both the pick and the approval through a change to the steps. You chose what that image shows, so a change to the catalog's steps doesn't touch it. A pick says "this version is good enough to run for this picture", and it stays until you change it. The one thing that sets it aside is a change of the image's category: the automatic result for the new category shows, and the pick returns if the category is changed back.

Rejecting an image is different from un-approving it. A rejection says the picture itself is wrong for the product, for example an information graphic or an icon. It stays through any change to the catalog's Image processing settings, so a new rendering of the same picture arrives still rejected, and it lasts until you change it yourself. It belongs to that picture: if the feed replaces it with a different picture, the new one is not rejected.

Feed-driven attributes — which catalogs an image belongs to and its position in the feed — always stay automatic, whether or not the image has been approved.

When does a change reach my images?#

Changes to the steps, the Categorize images switch, and the other settings on a catalog's Settings tab take effect when you Publish the catalog. Publishing rolls the change out to the catalog's products within minutes — you don't have to wait for the next scheduled import. Images that the change doesn't affect (for example, a category the changed step doesn't cover) are left exactly as they were, approvals included.