DEV Community: AI Engine

Marketplace Product Image Pipeline: Moderate, Clean, Tag (Python)

AI Engine — Sun, 21 Jun 2026 13:38:29 +0000

A marketplace lives or dies on its catalog, and the catalog is built from images other people upload. Every seller photo needs three things before it belongs on your storefront: a safety check so prohibited products never go live, a consistent look so the catalog does not resemble a flea market, and tags so the item is findable. Doing that by hand does not scale. Three APIs, chained into one Python pipeline, do it automatically for every upload.

This guide builds that pipeline: screen the image for prohibited content, remove the background and place the product on white, and auto-tag it for search. Each step is one API call, and all code runs against live endpoints.

Building this for your store? Each API used below has a free tier, starting with the Background Removal API.

The Three Stages

Each stage is a focused job handled by its own API, so you can tune or swap any one without disturbing the others:

Moderate: the content moderation API screens for nudity, violence, drugs, weapons, and hate symbols. It runs first, so a prohibited image never gets cleaned, tagged, or stored.
Clean: the Background Removal API puts every approved product on a uniform white background.
Tag: the Image Labeling API returns product labels for search, filtering, and auto-categorization.

A small shared helper keeps the credentials in one place:

import requests

API_KEY = "YOUR_API_KEY"

def api(host):
    return {"x-rapidapi-key": API_KEY, "x-rapidapi-host": host}

Stage 1: Moderate the Image

Screen the upload before spending any other work on it. The endpoint returns labels across risk categories, each with a confidence score and a parent category; the top-level categories are the ones with an empty ParentName:

def moderate(image_path):
    """Return the moderation labels for an image (empty list means clean)."""
    with open(image_path, "rb") as f:
        r = requests.post(
            "https://nsfw-detect3.p.rapidapi.com/nsfw-detect",
            headers=api("nsfw-detect3.p.rapidapi.com"),
            files={"image": f},
        )
    return r.json()["body"]["ModerationLabels"]

# Categories that should keep a listing off the marketplace
PROHIBITED = {
    "Explicit",
    "Non-Explicit Nudity of Intimate parts and Kissing",
    "Violence",
    "Hate Symbols",
    "Drugs & Tobacco",
}

Tune PROHIBITED to your marketplace. An apparel store keeps Swimwear or Underwear off this list because it is a legitimate product. For the full policy engine with per-category thresholds and a review queue, see content moderation for marketplace listings. You can grab a key on the content moderation API page.

Stage 2: Clean the Image

Once an image passes moderation, standardize it. Marketplaces like Amazon expect a pure white background on the main image, and a consistent backdrop makes any catalog look professional. The /color-background endpoint removes the original background and composites the product onto solid white in one call:

def clean_image(image_path):
    """Remove the background and place the product on solid white."""
    with open(image_path, "rb") as f:
        r = requests.post(
            "https://background-removal-ai.p.rapidapi.com/color-background",
            headers=api("background-removal-ai.p.rapidapi.com"),
            files={"image": f},
            data={"bg_color": "255,255,255,255"},
        )
    return r.json()["image_url"]   # URL to the white-background image

The bg_color is R,G,B,A, so 255,255,255,255 is opaque white. The response also carries width, height, and size_bytes. For the full batch and concurrency patterns of this step on its own, see background removal at scale.

Stage 3: Tag the Image

Tags power search, filters, and auto-categorization, so sellers do not have to label everything by hand and buyers can actually find the item. The /detect-label endpoint returns labels with a confidence score from 0 to 1:

def tag(image_path, min_score=0.7):
    """Return product tags above a confidence threshold."""
    with open(image_path, "rb") as f:
        r = requests.post(
            "https://label-image.p.rapidapi.com/detect-label",
            headers=api("label-image.p.rapidapi.com"),
            files={"image": f},
        )
    labels = r.json()["body"]["labels"]
    return [l["description"] for l in labels if l["score"] >= min_score]

print(tag("leather_shoe.jpg"))
# ['Walking Shoe', 'Cross Training Shoe', 'Running Shoe']

The min_score filter drops low-confidence guesses so you store tags you can trust. Map the returned labels to your own category taxonomy with the Image Labeling API, or keep them as free-text search tags.

The Pipeline: One Function per Listing

Now chain the three stages. Moderate first, because there is no point cleaning and tagging an image you are going to reject, and a prohibited image should never land in your processed bucket:

def process_listing(image_path):
    """Screen, then clean and tag one seller image. Returns a result dict."""
    # 1. Screen the original upload first
    flagged = [
        label["Name"]
        for label in moderate(image_path)
        if label["ParentName"] == "" and label["Name"] in PROHIBITED
    ]
    if flagged:
        return {"status": "rejected", "reasons": flagged}

    # 2. Clean for the catalog, 3. tag for search
    return {
        "status": "approved",
        "image_url": clean_image(image_path),
        "tags": tag(image_path),
    }

print(process_listing("leather_shoe.jpg"))
# {'status': 'approved',
#  'image_url': 'https://images.ai-engine.net/background-removal-ai/....png',
#  'tags': ['Walking Shoe', 'Cross Training Shoe', 'Running Shoe']}

# An image that trips a prohibited category comes back rejected,
# with no wasted background-removal or tagging calls:
# {'status': 'rejected', 'reasons': ['Drugs & Tobacco']}

One call into process_listing and a seller upload comes back either rejected with a reason or approved with a clean catalog image and a set of tags, ready to write to your database.

Run It Across the Whole Catalog

The same function runs event-driven on new listings and as a batch over an existing catalog. Process concurrently so a backfill of thousands of images finishes in minutes, not hours:

from concurrent.futures import ThreadPoolExecutor, as_completed

def process_catalog(listings, max_workers=8):
    """listings: list of dicts with id and image path."""
    approved, rejected = [], []
    with ThreadPoolExecutor(max_workers=max_workers) as pool:
        futures = {pool.submit(process_listing, l["image"]): l for l in listings}
        for fut in as_completed(futures):
            listing = futures[fut]
            try:
                result = fut.result()
            except Exception as e:
                result = {"status": "rejected", "reasons": [f"pipeline error: {e}"]}
            (approved if result["status"] == "approved" else rejected).append(
                {"id": listing["id"], **result}
            )
    return approved, rejected

approved, rejected = process_catalog(all_listings)
print(f"{len(approved)} approved, {len(rejected)} held")

Write the approved images and tags back to your catalog and route the rejected list to your seller-support flow. New uploads call process_listing from your listing-creation webhook, so every product gets the same treatment automatically.

Honest Limits

Tags need a taxonomy. The labeling API returns generic descriptions; mapping them to your category tree is your work. Treat low-confidence tags as suggestions, not truth.
Moderation is visual, not legal. It catches offensive imagery, not counterfeits, brand misuse, or whether a product is restricted in a given country. Those need seller verification and category rules.
Cleaning has a tail of hard cases. Reflective or transparent products cut out imperfectly, so keep a quality check on the background-removal output for the few percent that need it.

Getting Started

Grab keys from the Background Removal, content moderation, and Image Labeling APIs, drop them into the helper, and run process_listing on a sample of your real listings. Tune PROHIBITED and the tag threshold to your catalog, wire the function into listing creation, backfill once, and your marketplace images clean, screen, and tag themselves. A free tier is available on each API to test the full pipeline first.

Read the full tutorial on ai-engine.net.

Content Moderation for Marketplace Seller Listings (Python)

AI Engine — Thu, 18 Jun 2026 17:52:16 +0000

On a marketplace, your catalog is built from images other people upload, whether from third-party sellers on a structured e-commerce site or from individuals posting ads on a classifieds platform. At any real volume you cannot review them by hand, and you cannot afford not to. Prohibited or offensive images do show up: weapons, drugs, explicit material, a hate symbol printed on a t-shirt. One of them reaching the storefront is a brand problem, a payment-processor problem, and sometimes a legal one. The risk runs higher on classifieds, where uploads come from individuals rather than vetted sellers.

A content moderation API screens every upload automatically and sends only the ambiguous ones to a human. This guide builds that for an e-commerce catalog in Python: scoring a listing image, a policy that passes legitimate product categories while blocking prohibited ones, a gate at listing creation, and a bulk backfill. All code runs against a live API.

Want to try it first? Screen an image with the content moderation API on your own listings.

Why a Generic Nudity Filter Hurts a Marketplace

The instinct is to bolt on a nudity detector and block anything it flags. On a marketplace that backfires. An apparel seller listing a bikini, a lingerie brand, a swimwear store: a blanket nudity filter rejects all of them and you lose real sellers and real sales. The same photo that is a violation on a social feed is a legitimate product on a fashion marketplace.

So marketplace moderation is not "block flagged images." It is "apply a policy that knows your catalog": reject genuinely prohibited content, let category-relevant product imagery through, and send the in-between to a fast human review. That needs a moderation API that returns which category fired and how confidently, not a single score.

Step 1: Score a Listing Image

Send the seller's image and get back the labels the API is confident about. A clean product photo returns an empty list:

import requests

HEADERS = {
    "x-rapidapi-key": "YOUR_API_KEY",
    "x-rapidapi-host": "nsfw-detect3.p.rapidapi.com",
}

def moderate(image_path):
    """Return the moderation labels for an image (empty list means clean)."""
    with open(image_path, "rb") as f:
        r = requests.post(
            "https://nsfw-detect3.p.rapidapi.com/nsfw-detect",
            headers=HEADERS,
            files={"image": f},
        )
    return r.json()["body"]["ModerationLabels"]

Each label has a Name, a Confidence (0 to 100), and a ParentName. Labels are hierarchical, so the top-level categories are the ones with an empty ParentName. Print them on a sample of your real listings to see the exact names you need:

labels = moderate("seller_photo.jpg")
categories = [l["Name"] for l in labels if l["ParentName"] == ""]
print(categories)
# ['Swimwear or Underwear']   on a bikini listing (legit for apparel)
# ['Drugs & Tobacco']         on a prohibited listing
# []                          on a clean product photo

Step 2: A Policy That Knows Your Catalog

Map each category to a listing action, and make the category-relevant ones review or approve instead of a hard reject. An apparel marketplace reviews swimwear rather than blocking it; a wine marketplace allows alcohol:

# Tune per marketplace. A category absent from the table is approved.
LISTING_POLICY = {
    "Explicit":                                          {"action": "reject", "threshold": 50},
    "Non-Explicit Nudity of Intimate parts and Kissing": {"action": "reject", "threshold": 60},
    "Violence":                                          {"action": "reject", "threshold": 60},
    "Hate Symbols":                                      {"action": "reject", "threshold": 40},
    "Drugs & Tobacco":                                   {"action": "reject", "threshold": 60},
    # Category-relevant for apparel -> review, do not auto-reject
    "Swimwear or Underwear":                             {"action": "review", "threshold": 60},
    "Gambling":                                          {"action": "review", "threshold": 70},
    # Alcohol absent -> approved (wine and spirits sellers)
}

def screen_listing(labels):
    """Map moderation labels to a verdict: approve, review, or reject."""
    verdict, reasons = "approve", []
    for label in labels:
        if label["ParentName"]:          # top-level categories only
            continue
        rule = LISTING_POLICY.get(label["Name"])
        if not rule or label["Confidence"] < rule["threshold"]:
            continue
        reasons.append(f"{label['Name']} ({label['Confidence']:.0f}%)")
        if rule["action"] == "reject":
            verdict = "reject"
        elif verdict != "reject":
            verdict = "review"
    return verdict, reasons

print(screen_listing(moderate("leather_shoe.jpg")))   # ('approve', [])
print(screen_listing(moderate("bikini.jpg")))         # ('review', ['Swimwear or Underwear (97%)'])
print(screen_listing(moderate("prohibited.jpg")))     # ('reject', ['Drugs & Tobacco (100%)'])

The bikini listing lands in review, not the bin, so a human confirms a legitimate apparel product in seconds instead of the system silently killing the sale. One table, edited per marketplace, serves a fashion store, a wine merchant, or a general bazaar.

Building a trust-and-safety layer? The content moderation API has a free tier to test on your catalog.

Step 3: Gate at Listing Creation

A listing usually has several images, and it should be gated by its worst one. Screen them all on submit, strictest verdict wins:

RANK = {"approve": 0, "review": 1, "reject": 2}

def on_new_listing(listing_id, image_paths):
    """Screen every image on a new listing; the strictest verdict wins."""
    verdict, reasons = "approve", []
    for path in image_paths:
        v, r = screen_listing(moderate(path))
        reasons += r
        if RANK[v] > RANK[verdict]:
            verdict = v

    if verdict == "approve":
        publish_listing(listing_id)            # goes live
    elif verdict == "review":
        queue_for_review(listing_id, reasons)  # human checks
    else:
        reject_listing(listing_id, reasons)    # seller is notified why
    return verdict

Returning a clear reason on a reject matters: the seller sees why and can fix the photo instead of opening a support ticket.

Step 4: Backfill the Existing Catalog

Listings created before you added the check still need screening. Run a one-time batch concurrently, and act on each result as it lands:

from concurrent.futures import ThreadPoolExecutor, as_completed

def screen_one(listing):
    try:
        verdict, reasons = screen_listing(moderate(listing["image"]))
    except Exception as e:
        verdict, reasons = "review", [f"moderation error: {e}"]
    return {"id": listing["id"], "verdict": verdict, "reasons": reasons}

def backfill(catalog, max_workers=10):
    flagged = []
    with ThreadPoolExecutor(max_workers=max_workers) as pool:
        futures = [pool.submit(screen_one, l) for l in catalog]
        for fut in as_completed(futures):
            res = fut.result()
            if res["verdict"] != "approve":
                flagged.append(res)        # pull or review these
    return flagged

flagged = backfill(all_listings)
print(f"{len(flagged)} listings need attention")

Failing safe to review on error keeps a failed call from quietly approving a listing.

Honest Limits

It does not catch counterfeits or IP misuse. A fake handbag looks like a real one. Brand rights and authenticity need seller verification and brand registries, not a pixel score.
Restricted does not equal unsafe. Whether a legal product can be sold in a given country is a category-and-jurisdiction rule, separate from whether the image is offensive.
Thresholds are yours to tune. Too strict and you bury reviewers in legitimate apparel; too loose and prohibited items slip through. Tune against your own catalog.

For moderating non-commerce user uploads (profile photos, chat images, review photos), see the content moderation guide for user uploads, and for a provider comparison, the best content moderation APIs comparison.

Getting Started

Grab a key from the content moderation API page, run moderate over a sample of your real listings to see which categories fire, and set LISTING_POLICY so legitimate product categories review or pass while prohibited ones reject. Wire it into listing creation, backfill once, and prohibited products stop reaching your storefront. A free tier is available to test first.

Read the full tutorial on ai-engine.net.

Face Recognition Attendance System with REST API (Python)

AI Engine — Wed, 17 Jun 2026 06:24:13 +0000

Punch cards get shared. Fingerprint scanners spread germs and fail on worn fingertips. A face recognition attendance system fixes both: an employee looks at a camera, the system matches the face against a registered repository, and the check-in is logged. No hardware beyond a webcam or phone.

This builds one in Python with a face analysis REST API, no OpenCV, dlib, or local model required.

Want to see the matching in action? Try the Face Analyzer API with two photos.

Why a REST API instead of OpenCV

Rolling your own means dlib or a deep model, a GPU for reasonable latency, and ongoing maintenance of the recognition pipeline. A REST API handles detection, embedding, and matching server-side. You manage a face repository and call two endpoints.

Setting up the face repository

import requests

BASE = "https://faceanalyzer-ai.p.rapidapi.com"
HEADERS = {
    "x-rapidapi-host": "faceanalyzer-ai.p.rapidapi.com",
    "x-rapidapi-key": "YOUR_API_KEY",
}

requests.post(
    f"{BASE}/create-facial-repository",
    headers={**HEADERS, "Content-Type": "application/x-www-form-urlencoded"},
    data={"repository_id": "office-hq"},
)

Registering employees

def register_employee(photo_path, employee_id):
    with open(photo_path, "rb") as f:
        r = requests.post(
            f"{BASE}/save-face-in-repository",
            headers=HEADERS,
            files={"image": (photo_path, f, "image/jpeg")},
            data={"repository_id": "office-hq", "external_id": employee_id, "max_faces": "1"},
        )
    return r.json()

register_employee("alice.jpg", "EMP-001")
register_employee("bob.jpg", "EMP-002")

See the repository-management details in the complete tutorial.

The check-in endpoint

At check-in, search the repository for the captured face:

def check_in(photo_path):
    with open(photo_path, "rb") as f:
        r = requests.post(
            f"{BASE}/search-face-in-repository",
            headers=HEADERS,
            files={"image": (photo_path, f, "image/jpeg")},
            data={"repository_id": "office-hq"},
        )
    matches = r.json()["body"].get("FaceMatches", [])
    return matches[0]["ExternalImageId"] if matches else None

employee = check_in("checkin_capture.jpg")
print(f"Checked in: {employee}" if employee else "No match, try again")

Wrapping it in Flask

from flask import Flask, request, jsonify
from datetime import datetime

app = Flask(__name__)

@app.route("/checkin", methods=["POST"])
def checkin():
    file = request.files["image"]
    file.save("/tmp/capture.jpg")
    emp = check_in("/tmp/capture.jpg")
    if emp:
        return jsonify({"employee_id": emp, "time": str(datetime.now())})
    return jsonify({"error": "no match"}), 404

Anti-spoofing and privacy

Pair the check-in with a liveness step (ask for a blink or head turn) to block photo-of-a-photo buddy punching. For GDPR compliance, store only the repository's face identifiers, get explicit employee consent, and provide a delete path with the delete-face-from-repository endpoint.

Face recognition vs fingerprint

Face recognition is contactless, works on any phone or webcam, and is hard to share. Fingerprint hardware is cheap but fails on worn fingertips and raises hygiene concerns. For distributed or remote teams, the camera-based approach wins on reach.

Read the full tutorial with the complete Flask app, cURL tests, and JavaScript examples on ai-engine.net.

Content Moderation API: Screen User Uploads Beyond Nudity

AI Engine — Fri, 12 Jun 2026 06:25:10 +0000

The moment your product lets users upload images, profile photos, listing pictures, chat attachments, review photos, you inherit a Trust and Safety problem. Someone will upload something that breaks your policy, and if it reaches other users before you catch it, that is a brand and sometimes a legal incident. Manual review does not scale past a trickle of uploads. A content moderation API screens every image automatically and lets a human handle only the genuinely ambiguous ones.

This builds that flow: one call to score an image across the risk categories, a per-category policy engine that turns scores into an allow / review / block decision, and a concurrent batch pattern for real platform volume. All code is Python and runs against a live API.

Want to test it on your own uploads? Try the content moderation API on a sample image.

Moderation is more than a nudity filter

A lot of "NSFW detection" content treats moderation as one yes/no question about nudity. Real platform policy is broader. Weapons and gore, drug paraphernalia, hate symbols, and gambling promotions all break the rules on most platforms, and none of them are nudity. The API returns labels across a broad set of categories (nudity, suggestive content, violence, visually disturbing imagery, drugs and tobacco, alcohol, gambling, hate symbols, rude gestures), each with a confidence score.

That breadth lets your policy distinguish a weapon from a wine bottle instead of lumping everything into "bad."

Step 1: Score an image

Send an image (file or public URL) and get back the labels the model is confident about. A clean image returns an empty list:

import requests

HEADERS = {
    "x-rapidapi-key": "YOUR_API_KEY",
    "x-rapidapi-host": "nsfw-detect3.p.rapidapi.com",
}

def moderate(image_path):
    """Return the moderation labels for an image (empty list means clean)."""
    with open(image_path, "rb") as f:
        r = requests.post(
            "https://nsfw-detect3.p.rapidapi.com/nsfw-detect",
            headers=HEADERS,
            files={"image": f},
        )
    return r.json()["body"]["ModerationLabels"]

Each label has a Name, a Confidence (0 to 100), and a ParentName. Labels are hierarchical and can be a few levels deep (a specific drug label sits under a broader Drugs & Tobacco category). Top-level categories are the ones with an empty ParentName. The reliable way to build a policy is to first see which top-level categories the API actually returns on your content:

labels = moderate("sample_upload.jpg")
categories = [l["Name"] for l in labels if l["ParentName"] == ""]
print(categories)
# ['Gambling']          on a poker photo
# ['Drugs & Tobacco']   on a pills photo
# []                    on a clean photo

Step 2: Turn scores into a policy decision

The labels are not a decision. A wine marketplace allows alcohol; a kids' app blocks it. Your policy lives in a small table that maps each top-level category to an action and a threshold:

# Use the exact Names the API returns for your content (see Step 1).
# A category absent from the table is allowed.
POLICY = {
    "Explicit":                                          {"action": "block",  "threshold": 60},
    "Non-Explicit Nudity of Intimate parts and Kissing": {"action": "block",  "threshold": 60},
    "Violence":                                          {"action": "block",  "threshold": 70},
    "Hate Symbols":                                      {"action": "block",  "threshold": 50},
    "Drugs & Tobacco":                                   {"action": "block",  "threshold": 70},
    "Swimwear or Underwear":                             {"action": "review", "threshold": 60},
    "Gambling":                                          {"action": "review", "threshold": 80},
    # Alcohol is not listed, so it is allowed (e.g. a wine marketplace)
}

def decide(labels):
    """Map moderation labels to a verdict: allow, review, or block."""
    verdict, reasons = "allow", []
    for label in labels:
        if label["ParentName"]:          # match on top-level categories only
            continue
        rule = POLICY.get(label["Name"])
        if not rule or label["Confidence"] < rule["threshold"]:
            continue
        reasons.append(f"{label['Name']} ({label['Confidence']:.0f}%)")
        if rule["action"] == "block":
            verdict = "block"
        elif verdict != "block":
            verdict = "review"
    return verdict, reasons


print(decide(moderate("clean_photo.jpg")))    # ('allow', [])
print(decide(moderate("wine_listing.jpg")))   # ('allow', [])  Alcohol is not in the policy
print(decide(moderate("poker_table.jpg")))    # ('review', ['Gambling (99%)'])

Three ideas make this work at scale. Match on the top-level category (empty ParentName) so a deeply nested label still maps to the right rule. Set thresholds per category. And use three outcomes, not two: block clear violations, allow clean images, and route the uncertain middle to a human.

Curious which categories fire on your content? Run the API on a sample and print the top-level labels.

Step 3: Screen uploads at scale

A live platform does not moderate one image at a time. Screen a batch concurrently and act on each verdict as it lands:

from concurrent.futures import ThreadPoolExecutor, as_completed

def screen(upload):
    """upload: dict with id and local path. Returns the moderation verdict."""
    try:
        verdict, reasons = decide(moderate(upload["path"]))
    except Exception as e:
        # On error, fail safe to review rather than letting content through
        verdict, reasons = "review", [f"moderation error: {e}"]
    return {"id": upload["id"], "verdict": verdict, "reasons": reasons}

def screen_batch(uploads, max_workers=10):
    blocked, review, allowed = [], [], []
    with ThreadPoolExecutor(max_workers=max_workers) as pool:
        futures = [pool.submit(screen, u) for u in uploads]
        for fut in as_completed(futures):
            r = fut.result()
            {"block": blocked, "review": review, "allow": allowed}[r["verdict"]].append(r)
    return blocked, review, allowed

Publish the allowed bucket, hold the blocked bucket, and push the review bucket to your moderation queue. The fail-safe to review on error matters: when the API call fails, you want the image held for a human, not published unchecked.

Honest limits

A moderation API is a strong first line, not the whole system. It scores pixels, not intent, so the same image can be a violation or legitimate news depending on context the model cannot see (that is what the review queue is for). Thresholds are a product decision: strict catches more but annoys real users with false positives. Policy is regional, and images are one surface (text, video, and audio need their own moderation).

Read the full guide with the review-queue pattern and the honest limits on ai-engine.net.

Background Removal at Scale: A High-Volume Pipeline for Ecommerce

AI Engine — Sun, 07 Jun 2026 05:49:56 +0000

You run an online store, a marketplace integration, or a product-data pipeline, and you have thousands of product photos shot against inconsistent backgrounds: vendor warehouses, kitchen tables, studio sweeps, phone snaps. Marketplaces want clean, uniform images. Doing this by hand in Photoshop does not scale past a few dozen SKUs. A background removal API turns it into a batch job you run once and forget.

This walkthrough covers the scaling patterns that matter when you are processing a whole catalog: single calls, concurrent batches, white-background output for marketplace listings, and a retry-safe pipeline. All code is Python and runs against a live API.

Want to see the cutout quality on your own products? Try the Background Removal API on a sample image.

Why backgrounds matter for conversion

Product image quality is not cosmetic. Amazon requires a pure white background (RGB 255, 255, 255) for main listing images. Shopify themes look broken when one product floats on white and the next sits on a gray kitchen counter. Consistent backgrounds make a catalog look professional, and that consistency is part of how shoppers judge whether a store is trustworthy. The problem is that source images almost never arrive consistent, especially when vendors or drop-shippers supply them.

So the real job is not "remove one background." It is "normalize thousands of inconsistent images into one clean look, repeatably, as new products arrive."

The single call

Start with one image to confirm the shape. Install the two packages first (pip install requests tqdm), then:

import requests

HEADERS = {
    "x-rapidapi-key": "YOUR_API_KEY",
    "x-rapidapi-host": "background-removal-ai.p.rapidapi.com",
}

resp = requests.post(
    "https://background-removal-ai.p.rapidapi.com/remove-background",
    headers={**HEADERS, "Content-Type": "application/json"},
    json={"image_url": "https://example.com/product.jpg"},
)
result = resp.json()
print(result["image_url"])  # URL to the transparent PNG

The response includes the output image_url plus width, height, and size_bytes, which you can store alongside your product records.

White background for marketplace listings

Transparency is great for your own site, but marketplaces usually want a solid white backdrop. Instead of removing the background and then compositing onto white in a second step, use the color-background endpoint to do both at once:

def on_white(image_url):
    """Remove background and composite the product onto solid white."""
    resp = requests.post(
        "https://background-removal-ai.p.rapidapi.com/color-background",
        headers={**HEADERS, "Content-Type": "application/json"},
        json={"image_url": image_url, "bg_color": "255,255,255,255"},
    )
    return resp.json()["image_url"]

The bg_color value is R,G,B,A (each 0 to 255), so 255,255,255,255 is opaque white. Swap it if a channel needs a brand color behind the product.

Run the white-background call on a product photo and check the result before wiring up a batch.

Batch a whole catalog concurrently

A catalog migration is the moment scaling matters. Processing sequentially, 10,000 images at 1.5 seconds each is over 4 hours of wall-clock time. With a concurrency pool, the same job finishes in a fraction of that. Here is a retry-safe batch processor:

import csv
import requests
from concurrent.futures import ThreadPoolExecutor, as_completed
from tqdm import tqdm

HEADERS = {
    "x-rapidapi-key": "YOUR_API_KEY",
    "x-rapidapi-host": "background-removal-ai.p.rapidapi.com",
}
URL = "https://background-removal-ai.p.rapidapi.com/color-background"

def process(sku, image_url, retries=3):
    """Process one product image, retrying on transient errors."""
    for attempt in range(retries):
        try:
            r = requests.post(
                URL,
                headers={**HEADERS, "Content-Type": "application/json"},
                json={"image_url": image_url, "bg_color": "255,255,255,255"},
                timeout=30,
            )
            r.raise_for_status()
            return sku, r.json()["image_url"], None
        except Exception as e:
            if attempt == retries - 1:
                return sku, None, str(e)

# products.csv has columns: sku, image_url
with open("products.csv") as f:
    products = list(csv.DictReader(f))

results, failures = [], []
with ThreadPoolExecutor(max_workers=10) as pool:
    futures = [pool.submit(process, p["sku"], p["image_url"]) for p in products]
    for fut in tqdm(as_completed(futures), total=len(futures), desc="Removing backgrounds"):
        sku, out_url, err = fut.result()
        (failures if err else results).append((sku, err or out_url))

print(f"Processed {len(results)} images, {len(failures)} failed")

The max_workers=10 setting controls concurrency. Tune it to your plan's rate limit: higher means faster but risks throttling. The retry loop absorbs transient network blips so a single failure does not abort a 10,000-image run, and failed SKUs land in a list you can re-run.

Quality control at scale

Most product photos cut out cleanly, but a catalog always has a tail of hard cases: reflective bottles, transparent or glossy packaging, white products on near-white surfaces. Publishing a bad cutout looks worse than the original photo, so a high-volume pipeline needs a QA step. You cannot eyeball 10,000 images, so flag the suspicious ones automatically and send only those to a human:

import statistics

def flag_for_review(results_with_meta):
    """results_with_meta: list of (sku, width, height, size_bytes, category)"""
    sizes = [m[3] for m in results_with_meta]
    median = statistics.median(sizes)
    tricky = {"glassware", "jewelry", "transparent-packaging"}

    review = []
    for sku, w, h, size_bytes, category in results_with_meta:
        too_small = size_bytes < median * 0.3  # over-cropped subject
        if too_small or category in tricky:
            review.append(sku)
    return review

Two cheap signals catch most failures: an output whose file size is far from the batch norm, and products in categories you already know are tricky. Route the flagged SKUs to a review queue and auto-publish the rest, keeping human effort on the few percent that need it.

When a cloud API beats self-hosting

Open-source models like rembg are free and fine for low volume. At catalog scale the calculus changes: a managed API holds quality across hair, fur, and transparent packaging where lighter models struggle, there is no GPU fleet to operate, and you monitor one pipeline with retries and a single output format instead of a model deployment you maintain. The trade-off is a per-call cost and a network dependency, usually worth it when image quality directly affects conversion.

Read the full guide with the new-product ingest worker and the gradient and blur options on ai-engine.net.

Build eKYC for Your SaaS: Match a Selfie to an ID with an API

AI Engine — Sun, 07 Jun 2026 05:49:50 +0000

Your SaaS needs to confirm new users are who they claim to be: a fintech opening accounts, a marketplace onboarding sellers, a gig app vetting workers. The standard step is eKYC. The user uploads a government ID and takes a selfie, and your backend checks that the selfie matches the photo on the ID. Building that from scratch means face-recognition models and document parsing. Two APIs handle both halves, and you can wire the onboarding step together in an afternoon.

This walkthrough builds the two layers you can ship quickly: extracting the ID data with an OCR API, and matching the selfie to the ID photo with a face comparison API, then combining them into an approve / review / reject decision. Every snippet runs against live endpoints.

Want to test the match step now? Try the Face Analyzer API on a selfie and an ID photo.

What eKYC actually requires

It helps to be precise about the layers, because no single API does all of them and overclaiming here is how teams ship insecure onboarding:

Document data extraction - read the name, date of birth, document number, and expiry off the ID. This uses an OCR API.
Face match - confirm the selfie is the same person as the ID photo. This uses a face comparison API.
Liveness - confirm the selfie is a live person, not a photo of a photo or a screen replay. A separate concern.
Document authenticity - confirm the ID itself is genuine and unaltered. Also separate, and the hardest to automate.

The first two are the layers you can build today with a couple of API calls, and they catch the most common case: a user submitting someone else's ID.

Step 1: Extract the ID data with OCR

Send the ID image to the OCR endpoint and get the text back. For a national ID, license, or passport, it returns every printed field:

import requests

OCR_HEADERS = {
    "x-rapidapi-key": "YOUR_API_KEY",
    "x-rapidapi-host": "ocr-wizard.p.rapidapi.com",
}

def read_id_document(id_image_path):
    """OCR an ID document, return the raw extracted text."""
    with open(id_image_path, "rb") as f:
        r = requests.post(
            "https://ocr-wizard.p.rapidapi.com/ocr",
            headers=OCR_HEADERS,
            files={"image": f},
        )
    return r.json()["body"]["fullText"]

Labels and values come back on separate lines, exact order varying by document. To turn that into structured fields, pipe it through an LLM, the same pattern as an invoice or receipt parser.

Reading IDs, invoices, or receipts? Try the OCR Wizard API on your own document.

Step 2: Match the selfie to the ID photo

Now the core of identity verification: does the selfie belong to the same person as the photo on the ID. The compare-faces endpoint takes two images and returns the faces that matched. A useful detail: you can pass the full ID image as the target without cropping the photo first, and the API locates the face on the document for you.

FACE_HEADERS = {
    "x-rapidapi-key": "YOUR_API_KEY",
    "x-rapidapi-host": "faceanalyzer-ai.p.rapidapi.com",
}

def faces_match(selfie_path, id_image_path):
    """Return True if the selfie matches the face on the ID document."""
    with open(selfie_path, "rb") as selfie, open(id_image_path, "rb") as id_img:
        r = requests.post(
            "https://faceanalyzer-ai.p.rapidapi.com/compare-faces",
            headers=FACE_HEADERS,
            files={
                "source_image": ("selfie.jpg", selfie, "image/jpeg"),
                "target_image": ("id.jpg", id_img, "image/jpeg"),
            },
        )
    body = r.json()["body"]
    return len(body.get("matchedFaces", [])) > 0

A non-empty matchedFaces means the selfie and the ID photo are the same person. An empty match with a populated unmatchedFaces means a mismatch.

Curious how it scores your own pair of images? Run it on a selfie and an ID and read the matched faces back.

Step 3: Quality-gate the inputs with face detection

The compare call finds the face on the ID for you, so you do not need detection to make the match. Where detection earns its place is as a quality gate before the comparison: confirm the selfie shows exactly one clear face, and confirm the ID actually has a detectable photo. That turns a useless empty match into a clear reason like "no face found on the document":

def count_faces(image_path):
    """Return how many faces the detector finds in an image."""
    with open(image_path, "rb") as f:
        r = requests.post(
            "https://faceanalyzer-ai.p.rapidapi.com/faceanalysis",
            headers=FACE_HEADERS,
            files={"image": f},
        )
    return len(r.json()["body"]["faces"])

Zero faces on the selfie means a bad capture, two or more means someone else is in frame, and zero on the ID means the photo region was not readable. Each is a reason to route to review rather than guess.

Step 4: Turn it into a decision

No single call is a decision. Combine the detection gate, the document data, the expiry check, and the face match into one verdict your flow can act on:

import re
from datetime import date

def verify_identity(selfie_path, id_image_path):
    if count_faces(selfie_path) != 1:
        return "review", "selfie must show exactly one clear face"
    if count_faces(id_image_path) != 1:
        return "review", "could not find a single face on the ID document"

    text = read_id_document(id_image_path)
    m = re.search(r"EXPIRES\s+(\d{4}-\d{2}-\d{2})", text)
    expiry = date.fromisoformat(m.group(1)) if m else None
    if expiry is not None and expiry < date.today():
        return "reject", "ID is expired"

    if not faces_match(selfie_path, id_image_path):
        return "review", "selfie did not match the ID photo"
    if expiry is None:
        return "review", "could not read the expiry date"
    return "approve", "identity verified"

Auto-approve when everything lines up, auto-reject on a clear failure, and send the ambiguous middle to a human queue rather than guessing.

Honest limits

These two layers catch the common failure modes, but they are not a complete eKYC stack on their own. There is no liveness here, so a face match alone cannot tell a live selfie from a held-up photo of the ID owner; add a liveness step for anything high-risk. And OCR reads what is printed, it does not verify the ID is genuine; forged documents need a separate authenticity layer. Treat this as the face-match and data-extraction core of your eKYC, not the whole thing.

Read the full guide with the Flask endpoint, the response shapes, and the decision logic on ai-engine.net.

PDF OCR in Python: Extract Text from Scanned PDFs in 5 Lines

AI Engine — Sat, 06 Jun 2026 05:55:14 +0000

You have a folder of scanned PDFs. Invoices, contracts, old reports, bank statements your accountant emailed you. None of them are searchable. PyPDF2 returns empty strings because the text is locked inside pixel data, not actual characters.

The classic Python answer is Tesseract: install the binary, install pytesseract, install pdf2image and Poppler, convert each page to an image, run OCR per page, stitch the text back together. Forty lines of code, three system dependencies, and accuracy that varies with scan quality.

A cloud OCR API skips all of that. Here are the five lines of Python that replace the entire pipeline.

Want to run it now? Grab a key from the OCR Wizard API and paste it in.

The 5-line solution

import requests

with open("scanned.pdf", "rb") as f:
    r = requests.post(
        "https://ocr-wizard.p.rapidapi.com/ocr-pdf",
        headers={"x-rapidapi-key": "YOUR_API_KEY", "x-rapidapi-host": "ocr-wizard.p.rapidapi.com"},
        files={"pdf_file": f},
        data={"first_page": 1, "last_page": 10},
    )

print("\n\n".join(p["fullText"] for p in r.json()["body"]["pages"]))

No Tesseract install, no pdf2image, no Poppler, no per-page image conversion. Open the PDF, post it, join the pages.

One detail worth knowing: the API caps each request at a 10-page range (the difference between first_page and last_page cannot exceed 10). The snippet covers any PDF from 1 to 10 pages in a single call.

Process PDFs longer than 10 pages

Slide a 10-page window across the document:

import requests

HEADERS = {"x-rapidapi-key": "YOUR_API_KEY", "x-rapidapi-host": "ocr-wizard.p.rapidapi.com"}
URL = "https://ocr-wizard.p.rapidapi.com/ocr-pdf"
BATCH = 10

def ocr_pdf(pdf_path, total_pages):
    all_pages = []
    for start in range(1, total_pages + 1, BATCH):
        end = min(start + BATCH - 1, total_pages)
        with open(pdf_path, "rb") as f:
            r = requests.post(URL, headers=HEADERS, files={"pdf_file": f},
                              data={"first_page": start, "last_page": end})
        all_pages.extend(r.json()["body"]["pages"])
    return all_pages

pages = ocr_pdf("annual-report.pdf", total_pages=120)
print(f"{len(pages)} pages, {sum(len(p['fullText']) for p in pages)} characters")

See the folder-batch and citation variations in the complete guide.

Track page numbers for citations

The API does not return a pageNumber field, so use the list index plus your first_page offset when you need to cite specific pages:

pages = r.json()["body"]["pages"]
first_page = 1
for offset, p in enumerate(pages):
    print(f"[Page {first_page + offset}] ({p['detectedLanguage']})")
    print(p["fullText"][:200], "...\n")

Why skip Tesseract locally

Tesseract is a fine engine and still the go-to for offline, privacy-sensitive workloads. For most other use cases, the cloud approach wins on three concrete points: no system dependencies (no binary, no Poppler), no per-page image conversion (the API accepts the PDF directly), and better accuracy on noisy scans like faxes and skewed pages.

Read the full PDF OCR developer guide on ai-engine.net, or see how to pipe OCR into GPT-4 in the ID Card to JSON tutorial.

Free PDF OCR API: Extract Text from Scanned PDFs (No Setup)

AI Engine — Tue, 02 Jun 2026 19:01:10 +0000

"Free PDF OCR" usually means one of three things, each with strings attached. Tesseract is free but needs the binary, Poppler, pdf2image, and per-page rasterization, a forty-minute setup the first time. Online tools like Smallpdf cap file size, drop pages, or watermark output. Free trial APIs from the big clouds require a credit card and an account setup that takes longer than the OCR itself.

A free-tier cloud OCR API on the RapidAPI marketplace skips all three compromises. You sign up once, grab a key, and call the endpoint from any language that can send an HTTP POST.

Want to skip the setup? Try the OCR Wizard API on a scanned PDF.

The 30-second quickstart

Three steps, no install beyond the Python requests library.

Sign up at OCR Wizard on RapidAPI, subscribe to the free plan, copy your key.
Paste the key into the script below.
Run it against any scanned PDF, up to 10 pages per call.

import requests

with open("scanned.pdf", "rb") as f:
    r = requests.post(
        "https://ocr-wizard.p.rapidapi.com/ocr-pdf",
        headers={"x-rapidapi-key": "YOUR_API_KEY", "x-rapidapi-host": "ocr-wizard.p.rapidapi.com"},
        files={"pdf_file": f},
        data={"first_page": 1, "last_page": 10},
    )

print("\n\n".join(p["fullText"] for p in r.json()["body"]["pages"]))

That is the whole client. No model weights, no native binary, no per-page image conversion. The response comes back as JSON with one entry per page.

What you get on the free tier

Scanned PDF text extraction via the /ocr-pdf endpoint, with per-page text and language detection.
Image OCR on the sibling /ocr endpoint, which takes JPEG and PNG instead of PDF.
Automatic language detection per page, returned as a two-letter code.
HTTPS everywhere, multipart upload, no base64 string gymnastics.

See the full response format in the complete guide.

Why a cloud API beats "free" alternatives

Option	Setup	Catch
Tesseract + Poppler	30 to 60 min	accuracy drops on noisy scans, manual page rasterization
Browser tools (Smallpdf, PDF24)	none	file-size limits, watermarks, no API
AWS Textract / Google DocAI free tier	30 to 60 min	credit card required, SDK lock-in
Free RapidAPI OCR endpoint	2 min	10-page range cap per call

The decision comes down to two factors: can you stomach the Tesseract install for the offline guarantee, or do you want to ship something tonight? If the answer is the second, the free tier gets you to working OCR faster than any alternative here.

Pair it with an LLM for structured output

Raw OCR text is rarely the final deliverable. The common next step is feeding it to a model that pulls out the fields you care about:

from openai import OpenAI

client = OpenAI(api_key="YOUR_OPENAI_KEY")
text = "\n\n".join(p["fullText"] for p in r.json()["body"]["pages"])

resp = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": f"Extract invoice_number, date, vendor, total as JSON:\n{text}"}],
    response_format={"type": "json_object"},
)
print(resp.choices[0].message.content)

When the free tier stops being enough

You hit the monthly quota mid-week, you have a PDF longer than 10 pages that you need processed in a single call, or you need priority processing inside an SLA. Bump up to a higher tier on the same API page; the code does not change.

Read the full guide with cURL, JavaScript, and folder-batch examples, or the focused 5-line Python tutorial.

Extract PDF Tables in 2026: Hybrid OCR + LLM Beats GPT-4o Vision

AI Engine — Sat, 30 May 2026 17:32:30 +0000

Your invoicing system needs to ingest scanned purchase orders. Your accounting platform handles contracts with cross-page tables. The text inside these PDFs has to come out as structured data, not just a wall of text, or your downstream code has nothing to act on.

In April 2026, LlamaIndex published their ParseBench benchmark showing vision LLMs with specific prompts outperform traditional OCR on layout-heavy documents. The buzz suggests we should all switch to Gemini 3 Flash or GPT-4o with HTML colspan/rowspan prompts. So I ran the comparison live on a messy 2-page purchase order. The results were not what the headlines suggest.

Want to test it on your own documents? Try the OCR Wizard API with a scanned PDF.

Quick comparison

Same 2-page purchase order, 7 line items, repeated shipping-address sub-headers, item 030 split across the page break. Mat.No identifiers (like ALRD00882) are the codes that matter: get one wrong and you ship the wrong product.

Approach	Latency	Cost	Codes accurate	Layout
OCR API alone	1.14s	~$0.001	7 of 7	lost
GPT-4o-mini + prompts	22s	$0.0087	1 of 7	preserved
GPT-4o full + prompts	20s	$0.0228	1 of 7	preserved
Hybrid (OCR + GPT-4o-mini)	23s	$0.002	7 of 7	preserved

What ParseBench got right

The benchmark tested 14 parsing methods and found prompt design matters more than model size. LlamaParse Agentic scored 84.9, Gemini 3 Flash 71, beating dedicated parsers like AWS Textract (47.9), Google DocAI (50.4), and Azure Document Intelligence (59.6).

The trick: ask the model to emit HTML tables with colspan and rowspan attributes. Here is the approach as runnable code:

import base64
from openai import OpenAI

client = OpenAI(api_key="YOUR_OPENAI_API_KEY")

SYSTEM_PROMPT = """You are a document parser. Convert PDFs into clean Markdown.
- Convert tables to HTML using <table>, <tr>, <th>, <td>.
- Use colspan and rowspan to preserve merged cells and hierarchical headers.
- Maintain reading order. Output only the parsed content."""

def encode(path):
    with open(path, "rb") as f:
        return base64.b64encode(f.read()).decode()

resp = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {"role": "system", "content": SYSTEM_PROMPT},
        {"role": "user", "content": [
            {"type": "text", "text": "Parse this document. Merge tables split across pages."},
            {"type": "image_url", "image_url": {"url": f"data:image/png;base64,{encode('page1.png')}"}},
            {"type": "image_url", "image_url": {"url": f"data:image/png;base64,{encode('page2.png')}"}},
        ]},
    ],
)
print(resp.choices[0].message.content)

On my test, both GPT-4o-mini and GPT-4o full produced a correctly structured table. The layout claim holds up.

What ParseBench did not stress-test

Per-character fidelity on identifiers. Both vision LLM runs invented Mat.No codes that look plausible but do not match the source:

Source	GPT-4o-mini	GPT-4o full
ALRD00882	ALU000892	ALUM0088
ALRD00913	ALU000913	ALUM00913
ALSQ00716	ALU050716	(dropped)
ALPL00534	ALPL005034	ALPL05034

GPT-4o-mini also rewrote 12.700 (a tolerance in mm) as 12,700, three orders of magnitude off. It misread 3658 mm as 356 mm. GPT-4o full fixed those numeric mistakes but still hallucinated the identifiers.

This is not a flaw in the prompts. It is what happens when a language model generates text from pixels: alphanumeric codes have no linguistic regularity, so the model substitutes characters from codes it has seen in similar layouts. Bigger models hallucinate less, but they still hallucinate.

See the full item-by-item output comparison in the complete guide.

The hybrid pipeline

Pure OCR reads every character literally with no language prior, which is why it preserved all 7 codes. But it emits text in a broken reading order on messy layouts. Hybrid splits the work: OCR for fidelity, LLM for layout reconstruction.

Step 1, OCR extracts exact text:

import requests

def ocr_pdf(pdf_path):
    with open(pdf_path, "rb") as f:
        r = requests.post(
            "https://ocr-wizard.p.rapidapi.com/ocr-pdf",
            headers={"x-rapidapi-key": "YOUR_KEY", "x-rapidapi-host": "ocr-wizard.p.rapidapi.com"},
            files={"pdf_file": f},
            data={"first_page": 1, "last_page": 10},
        )
    pages = r.json()["body"]["pages"]
    return "\n\n".join(p["fullText"] for p in pages)

Step 2, the LLM reconstructs structure under a prompt that forbids changing values:

from openai import OpenAI

client = OpenAI(api_key="YOUR_OPENAI_KEY")

SYSTEM_PROMPT = """You receive raw OCR text. The OCR is accurate at the character
level but the reading order is broken. Reconstruct the document as clean HTML.
CRITICAL: Every code, number, identifier, email, and date in your output MUST
appear verbatim in the input. Do NOT invent, modify, or correct any value.
Convert tables to HTML with <table>, <tr>, <th>, <td>, colspan and rowspan.
Merge tables split across pages."""

def reconstruct(ocr_text):
    resp = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": SYSTEM_PROMPT},
            {"role": "user", "content": f"OCR TEXT:\n{ocr_text}\n\nOutput ONLY the HTML."},
        ],
    )
    return resp.choices[0].message.content

# Full pipeline
text = ocr_pdf("purchase_order.pdf")
html = reconstruct(text)

On the same purchase order, this preserved all 7 Mat.No codes, fixed the page-break fragmentation, separated the shipping-address blocks, and produced one well-formed HTML table.

Why hybrid costs less than direct vision LLM

Vision LLM input is dominated by image tokens. Two pages plus prompts run about 51,000 tokens. The hybrid sends only the OCR text, about 1,300 tokens. Input cost drops by a factor of 39. At 10,000 documents per month: $20 hybrid, $87 GPT-4o-mini direct, $228 GPT-4o full.

When to use what

Searchable text only (RAG, archive): OCR alone.
Structured tables, values must be exact (invoices, contracts): hybrid.
Charts, graphs, signatures, hand-drawn marks: vision LLM direct, since OCR cannot see what is not text.
Sub-second latency at high volume: OCR alone.

Sources

Read the full guide with the annotated test document and complete pipeline code on ai-engine.net.

Photo to Anime: API vs AnimeGAN v2/v3 (Open Source)

AI Engine — Sun, 17 May 2026 09:42:08 +0000

You want to add an anime or cartoon filter to your application. The open-source route is tempting: AnimeGAN has been the go-to model since 2020, with v2 (2021) and v3 (2022) available as pretrained weights on GitHub. It is free, runs locally, and generates decent anime portraits. But once you look at what it actually outputs and what it takes to run in production, the picture changes. This guide compares AnimeGAN v2 and v3 against the cloud Photo to Anime API on the same portrait.

Want to see the results on your own photos? Try the Photo to Anime API on a portrait.

Quick Comparison

	Photo to Anime API	AnimeGAN v2/v3
Styles available	14 (6 premium + 7 classic + Ghibli)	5 total (face_paint, celeba_distill, paprika, Hayao, Shinkai)
Style variety	Cartoon, Pixar, Arcane, Comic, Caricature, Illustration, Anime, Sketch, Ghibli	Japanese anime only
Setup	API key	PyTorch (~2GB) or ONNX Runtime
First-run latency	1-2s (network only)	60s (PyTorch import + model download)
Steady-state latency	1-2s per image	2-3s (v2 CPU) / 700ms (v3 CPU)
Output resolution	Up to 1600x1344	512x512 fixed (v2 face_paint)
Style intensity control	Yes (0.0-1.0)	No (fixed per model)
License	Commercial	Open source

What AnimeGAN Does

AnimeGAN is a GAN trained to transform photos into anime-style images. Each version ships with a handful of pretrained weights:

AnimeGANv2 (PyTorch):

face_paint_512_v2: portrait-focused, clean lines
celeba_distill: distilled from CelebA, softer colors
paprika: trained on Paprika aesthetic

AnimeGANv3 (ONNX):

AnimeGANv3_Hayao_36: Hayao Miyazaki style
AnimeGANv3_Shinkai_37: Makoto Shinkai style

All variants produce similar results on the same input: a stylized version with anime-like shading. They are trained for the same target domain (Japanese anime).

What the Photo to Anime API Does

The API provides 3 endpoints with 14 total styles:

/cartoonize-pro: 6 premium styles (Cartoon Pro, Caricature, Arcane, Comic, Pixar, Illustration)
/cartoonize: 7 classic styles (Anime, 3D, Hand-drawn, Sketch, Art Style, Design, Illustration)
/ghibli: Studio Ghibli style with face enhancement

The premium styles produce distinct artistic aesthetics that AnimeGAN cannot reach. Same portrait, 6 different looks. None of these can be produced by AnimeGAN.

See side-by-side image comparison, code for all 3 tools, and the install pain in the complete guide.

The Style Coverage Gap

This is the fundamental difference. AnimeGAN was trained on anime datasets for a single target aesthetic per model. The API supports a broader set of style domains:

Japanese anime: both
Studio Ghibli: both (API has dedicated endpoint, AnimeGAN has v3 Hayao)
Arcane / dark fantasy: API only
Pixar / 3D animation: API only
Comic book: API only
Caricature: API only
Sketch / line drawing: API only
Style intensity control: API only (0.0 to 1.0)

Running AnimeGAN Locally

Here is how to install and run AnimeGANv2 on your machine. You will need Python 3.8+ and about 2.5GB of free disk space for dependencies.

AnimeGANv2 with PyTorch

import torch
from PIL import Image

model = torch.hub.load(
    "bryandlee/animegan2-pytorch:main",
    "generator",
    pretrained="face_paint_512_v2",
    trust_repo=True,
)
face2paint = torch.hub.load(
    "bryandlee/animegan2-pytorch:main",
    "face2paint",
    size=512,
    trust_repo=True,
)

img = Image.open("portrait.jpg").convert("RGB")
with torch.no_grad():
    output = face2paint(model, img)
output.save("result.jpg", quality=90)

First run takes about 60 seconds: PyTorch imports, repo clone from GitHub, model weight download, initial inference. Subsequent runs take 2-3 seconds per image on CPU. Output is fixed at 512x512.

AnimeGANv3 with ONNX Runtime

import numpy as np
import onnxruntime as ort
from PIL import Image

# Download model from https://github.com/TachibanaYoshino/AnimeGANv3/releases
session = ort.InferenceSession("AnimeGANv3_Hayao_36.onnx")
img = Image.open("portrait.jpg").convert("RGB")

w, h = img.size
scale = 512 / max(w, h)
new_w = int((w * scale) // 8) * 8
new_h = int((h * scale) // 8) * 8
img_resized = img.resize((new_w, new_h), Image.LANCZOS)
arr = np.array(img_resized).astype(np.float32) / 127.5 - 1.0
arr = arr[np.newaxis, :, :, :]

output = session.run(None, {session.get_inputs()[0].name: arr})
result_arr = (output[0][0] + 1.0) * 127.5
result_arr = np.clip(result_arr, 0, 255).astype(np.uint8)
Image.fromarray(result_arr).save("result.jpg", quality=90)

v3 is faster than v2 on CPU (~700ms per image) thanks to ONNX Runtime, but you manage preprocessing manually.

Calling the Photo to Anime API

import requests

url = "https://phototoanime1.p.rapidapi.com/cartoonize-pro"
headers = {
    "x-rapidapi-host": "phototoanime1.p.rapidapi.com",
    "x-rapidapi-key": "YOUR_API_KEY",
}

for style in ["arcane", "pixar", "comic", "caricature"]:
    with open("portrait.jpg", "rb") as f:
        response = requests.post(
            url,
            headers=headers,
            files={"image": f},
            data={"style": style, "style_degree": "0.7"},
        )
    result = response.json()
    print(f"{style}: {result['image_url']}")

Performance Benchmark

We ran both tools on the same portrait. Test environment: Intel Core i7-7700HQ @ 2.80GHz, 4 cores, no GPU.

Tool	First call	Steady state	Output size	Notes
AnimeGANv2 (face_paint)	~60s	2-3s	512x512	PyTorch import + repo clone + 8MB weight download on first run
AnimeGANv3 (Hayao ONNX)	~3s	700ms	matches input	4MB ONNX model, no PyTorch needed
Photo to Anime API	1-2s	1-2s	up to 1600x1344	No local setup, includes network

The API wins on cold start (no model to load), consistency (same latency every call), and output resolution. AnimeGANv3 wins on per-call latency once warm if you stay in the anime style. AnimeGANv2 is the slowest of the three on every metric except cost.

When to Choose AnimeGAN

Japanese anime style is enough. If you only need anime portraits, AnimeGAN handles that.
Offline processing. No network dependency.
Custom training. Fine-tune AnimeGAN on your own dataset with GPU time.
Zero per-call cost. Self-hosting wins on cost at high volume with existing GPU hardware.

When to Choose the API

Multiple artistic styles. Arcane, Pixar, Comic, Caricature, Illustration, Ghibli. AnimeGAN cannot produce any of these.
Higher output resolution. Up to 1600x1344 vs AnimeGAN's fixed 512x512.
Style intensity control. style_degree parameter (0.0-1.0) for subtle to strong effects.
No dependency management. No PyTorch (~2GB), no onnxruntime, no model weights to download.
Face-aware processing. Detects faces and applies stylization with smooth blending.

Sources

AnimeGANv2 PyTorch (bryandlee) - PyTorch port, 3 pretrained weights, torch.hub integration
AnimeGANv3 official repository - Hayao and Shinkai ONNX models, v1.1.0 release
AnimeGANv2 paper and TensorFlow implementation - architecture details

Read the full guide with side-by-side image comparison, all 6 premium styles demo, and JavaScript examples on ai-engine.net.

Emotion Detection: Face Analyzer API vs DeepFace

AI Engine — Sat, 16 May 2026 06:00:18 +0000

You want to detect emotions from facial expressions. Customer feedback kiosks, driver monitoring, telehealth, HR mood tracking. Two approaches: install DeepFace, the most popular open-source face analysis library (22,000+ GitHub stars), or call a cloud face analysis API. This guide tests both on the same images and compares what they get right, what they get wrong, and what it takes to run each in production.

Want to see how it performs on your photos? Try the Face Analyzer API on your own images.

Quick Comparison

	Face Analyzer API	DeepFace
Emotions detected	8 (happy, sad, angry, surprised, disgusted, calm, confused, fear)	7 (angry, disgust, fear, happy, sad, surprise, neutral)
Output format	Dominant emotion(s), can return multiple	Percentage scores for all 7
Extra features	Age, gender, smile, glasses, sunglasses, landmarks, face comparison	Age, gender, race
Setup	API key (2 min)	TensorFlow + tf-keras + ~1GB model weights
Latency (CPU)	600-700ms	500-5,000ms (depends on cold/warm)
License	Commercial	MIT

What DeepFace Does

DeepFace is a Python library that wraps multiple face analysis models. It uses TensorFlow under the hood and downloads model weights (~500MB) on first run.

from deepface import DeepFace

result = DeepFace.analyze(
    "photo.jpg",
    actions=["emotion", "age", "gender"],
    silent=True,
)

r = result[0]
print(f"Emotion: {r['dominant_emotion']}")
for emo, score in sorted(r["emotion"].items(), key=lambda x: -x[1]):
    print(f"  {emo}: {score:.1f}%")

The first call is slow (5-10 seconds) because it downloads model weights from GitHub. Subsequent calls take 500-800ms on CPU.

What the Face Analyzer API Does

import requests

url = "https://faceanalyzer-ai.p.rapidapi.com/faceanalysis"
headers = {
    "x-rapidapi-host": "faceanalyzer-ai.p.rapidapi.com",
    "x-rapidapi-key": "YOUR_API_KEY",
}

with open("photo.jpg", "rb") as f:
    response = requests.post(url, headers=headers, files={"image": f})

for face in response.json()["body"]["faces"]:
    ff = face["facialFeatures"]
    print(f"Emotions: {ff['Emotions']}")
    print(f"Gender: {ff['Gender']}, Age: {ff['AgeRange']['Low']}-{ff['AgeRange']['High']}")
    print(f"Smile: {ff['Smile']}, Glasses: {ff['Eyeglasses']}")

One API call returns emotion + age + gender + smile + glasses + sunglasses + landmarks. DeepFace requires separate analysis passes and does not detect smile, glasses, or landmarks.

See real benchmarks side by side, full code for both tools, and the install gotchas in the complete guide.

Testing Both on the Same Images

Test environment: Intel Core i7-7700HQ @ 2.80GHz, 4 cores, no GPU.

Test 1: Surprised expression

API: SURPRISED. Female, 31-39. Latency: ~600ms.
DeepFace: surprise 95.9%, happy 2.9%, fear 1.1%. Woman, 32. Latency: ~500ms (warm).
Verdict: both correct.

Test 2: Fear expression

API: SURPRISED + FEAR (two emotions). Male, 27-35. Latency: 665ms.
DeepFace: FaceNotDetected crash. With enforce_detection=False: sad 99.7%. Wrong emotion.
Verdict: API wins.

Test 3: Angry expression

API: ANGRY. Male, 47-55. Latency: 633ms.
DeepFace: FaceNotDetected crash. With fallback: neutral 77.5%. Wrong emotion, wrong gender (Woman 52.1%), age 31 vs API 47-55. Latency: 5,672ms.
Verdict: API wins. DeepFace got emotion, gender, and age all wrong.

Summary: API correct on 3/3 images. DeepFace crashed on 2/3, wrong emotion on 2/3, wrong gender on 2/3.

The Installation Problem

DeepFace's biggest friction point is setup. Here's what we encountered:

pip install deepface installs TensorFlow (~500MB of dependencies)
First run crashes with ValueError: You have tensorflow 2.21.0 and this requires tf-keras package. Fix: pip install tf-keras
First analysis call downloads 3 model files from GitHub (emotion 6MB, age 539MB, gender 537MB). Total: over 1GB of model weights
File paths with non-ASCII characters (e.g., French "Téléchargements") throw ValueError: Input image must not have non-english characters
Without a GPU, TensorFlow prints warnings about missing CUDA drivers on every single run

The API requires pip install requests and an API key. That's it.

When to Choose DeepFace

You need emotion score distributions. DeepFace returns percentage scores for all 7 emotions.
Offline processing. No network dependency.
You need race estimation. DeepFace detects race. The API does not.

When to Choose the API

Reliable face detection. The API detected all 3 test images. DeepFace crashed on 2 of 3.
Multi-feature analysis. One API call returns emotion + age + gender + smile + glasses + landmarks.
Face comparison and repositories for identity verification workflows.
No dependency headaches. No TensorFlow, no tf-keras, no 1GB model downloads.
Consistent latency. 600-700ms regardless of input vs DeepFace ranging from 500ms (warm) to 5,000ms+ (cold start).

Sources

DeepFace GitHub Repository - 22K+ stars, MIT license, TensorFlow-based
Facial Expression Recognition with Keras (Serengil, 2018) - FER2013 benchmark: human accuracy ~65%, top models ~75%
DeepFace on PyPI - current version, dependencies

Read the full guide with image-by-image breakdown, install gotchas explained, and JavaScript examples on ai-engine.net.

NSFW Detection: API vs NudeNet for Content Moderation

AI Engine — Thu, 14 May 2026 19:24:42 +0000

Your platform accepts user-uploaded images. You need to filter out inappropriate content before it reaches other users. Two options: install NudeNet, the most popular open-source NSFW detection library (2,300+ GitHub stars), or call a cloud NSFW detection API that handles everything server-side. This guide tests both on the same images and compares what they catch, what they miss, and what it costs to run each in production.

Want to test on your own images? Try the NSFW Detect API on a few uploads.

Quick Comparison

	NSFW Detect API	NudeNet
Categories	10 (nudity, violence, drugs, alcohol, tobacco, gambling, hate symbols, etc.)	1 (nudity only)
Label structure	Hierarchical (3 levels)	Flat (body parts)
Setup	API key	`pip install nudenet` + ONNX model download
GPU	Not needed	Optional (faster)
Accuracy	93-98% across categories	~90% on nudity
License	Commercial	AGPL-3.0

What NudeNet Does

NudeNet is a Python library that detects nudity in images. Version 3 uses ONNX Runtime instead of TensorFlow, which makes it lighter and faster to install.

from nudenet import NudeDetector

detector = NudeDetector()
results = detector.detect("photo.jpg")

for detection in results:
    print(f"{detection['class']}: {detection['score']:.3f}")
    # FEMALE_BREAST_EXPOSED: 0.787
    # FACE_FEMALE: 0.736

The detection classes are all body-part based: exposed/covered variants of breasts, buttocks, genitalia, belly, feet, armpits, and face. There are no classes for violence, drugs, alcohol, gambling, or any non-nudity content.

What the NSFW Detection API Does

The NSFW Detect API classifies images across 10 categories with hierarchical sub-labels.

import requests

url = "https://nsfw-detect3.p.rapidapi.com/nsfw-detect"
headers = {
    "x-rapidapi-host": "nsfw-detect3.p.rapidapi.com",
    "x-rapidapi-key": "YOUR_API_KEY",
}

with open("photo.jpg", "rb") as f:
    response = requests.post(url, headers=headers, files={"image": f})

labels = response.json()["body"]["ModerationLabels"]
for label in labels:
    print(f"{label['Name']}: {label['Confidence']:.1f}% (parent: {label['ParentName']})")
    # Drugs & Tobacco: 99.4% (parent: )
    # Smoking: 99.4% (parent: Drugs & Tobacco)

The response uses a 3-level taxonomy. Here is the actual JSON for a smoking photo:

{
  "statusCode": 200,
  "body": {
    "ModerationLabels": [
      {
        "Name": "Drugs & Tobacco",
        "ParentName": "",
        "TaxonomyLevel": 1,
        "Confidence": 99.4
      },
      {
        "Name": "Drugs & Tobacco Paraphernalia & Use",
        "ParentName": "Drugs & Tobacco",
        "TaxonomyLevel": 2,
        "Confidence": 99.4
      },
      {
        "Name": "Smoking",
        "ParentName": "Drugs & Tobacco Paraphernalia & Use",
        "TaxonomyLevel": 3,
        "Confidence": 99.4
      }
    ]
  }
}

You walk down the tree to get more specific. Top-level "Drugs & Tobacco" tells you the broad category, "Smoking" tells you the exact behavior. Set different thresholds per category: strict on nudity, lenient on suggestive content.

See the full comparison with side-by-side test results, accuracy benchmarks, and code for both tools in the complete guide.

Testing Both on the Same Images

We tested both tools on three Pexels images (no explicit content).

Test 1: Male shirtless photo

API: Non-Explicit Nudity (99.9%), Exposed Male Nipple (99.9%). Correct category, correct gender.
NudeNet: FEMALE_BREAST_EXPOSED (78.7%), FACE_FEMALE (73.6%). Wrong gender on both detections. The image shows a man.

Test 2: Smoking photo

API: Drugs & Tobacco (99.4%), Smoking (99.4%). Correctly identifies smoking.
NudeNet: FACE_FEMALE (67.4%). No smoking detection. Also misclassifies the male face as female.

Test 3: Alcohol photo

API: Alcohol (98.6%), Alcoholic Beverages (98.6%). Identifies the beer glasses.
NudeNet: No detections. Alcohol is not in NudeNet's scope.

The Category Gap

The test results illustrate the fundamental difference. NudeNet is a nudity detector. The API is a content moderator covering 10 categories:

Explicit Nudity
Non-Explicit Nudity (swimwear, partial exposure)
Suggestive content
Violence
Visually Disturbing
Drugs & Tobacco
Alcohol
Gambling
Hate Symbols
Rude Gestures

For platforms with advertising revenue, brand safety requires all 10. An advertiser will not care that your filter catches nudity if their ad appears next to a photo of someone smoking or holding a weapon.

When to Choose NudeNet

Nudity-only filtering. If explicit nudity is your only concern, NudeNet covers it.
Offline or air-gapped environments. No network dependency.
Privacy-critical workloads. Images never leave your server.

When to Choose the API

Multi-category moderation. Drugs, alcohol, violence, hate symbols, gambling. NudeNet cannot help.
Brand safety. Advertising platforms need all 10 categories.
Scale without infrastructure. No GPU servers, no model updates.
Hierarchical filtering. Set different thresholds per category.

Running NudeNet in Production

Tutorials make NudeNet look simple: pip install nudenet, call detect(), done. In production:

AGPL-3.0 license. Requires you to open-source your application if you distribute it. For SaaS platforms, this is a legal grey area.
No model updates. NudeNet's model was last updated in 2023.
Gender accuracy. Our tests showed NudeNet misclassifying male subjects as female on 2 out of 3 images.

Sources

NudeNet GitHub Repository - AGPL-3.0 license, 2.3K stars
A Comparative Study of Tools for Explicit Content Detection in Images (2023) - academic benchmark: NudeNet ~90% accuracy
NudeNet on PyPI - v3.4.2, ONNX runtime

Read the full guide with side-by-side demos, all 10 category details, and JavaScript examples on ai-engine.net.