DEV Community: Ashish Sikka

Selfie photo search for a 3,000-photo wedding: the pipeline, the cost, and what goes wrong

Ashish Sikka — Sat, 31 Oct 2026 03:11:16 +0000

TL;DR Index every gallery photo into one collection per event, keyed by your own photo id. When a guest uploads a selfie, search that collection and show the returned photo ids, strongest match first. For a 3,000-photo wedding with 120 guest searches, indexing costs about $1.86, searches about $0.11 and a month of storage about $0.05. Most of the work is elsewhere: rejecting bad selfies at upload, choosing a threshold, a "not me" button, and deleting the collection when the gallery closes.

A photographer delivers 3,000 photos from a wedding. Within a day, 120 guests have asked the same question: which ones am I in? Scrolling a public gallery link is how most of them give up, and it also shows every guest's photos to everyone with the link. Selfie search fixes both. The guest takes one selfie and sees only the photos they appear in.

We run this feature on real event galleries, so this guide is the version with the edge cases in it. The code uses our API, SightRadar, but the structure is the same on any face search API that has collections.

The shape of it

Index once. Every gallery photo goes into a collection named for the event. Each face found becomes a stored faceprint tagged with your photo id, so a group shot of eight people produces eight faceprints that all point at one photo.
Search on demand. A guest's selfie is searched against that one collection. Each match carries the photo id and a similarity score. The photo ids are the answer.
Delete when done. When the gallery expires, delete the collection. That one call is the whole retention story for the event's biometric data.

Step 1: index the gallery in one batch

Photos are already in your storage, so send URLs, not bytes. A batch takes up to 1,000 URLs per call and reports each photo through a webhook, which is the right tool for a gallery upload. A 3,000-photo wedding is three calls.

import os, requests

API = "https://api.sightradar.com"
H = {"Authorization": f"Bearer {os.environ['SIGHTRADAR_API_KEY']}"}
EVENT = "wedding-2026-11-14-mehta"   # one collection per event

def index_gallery(photo_keys: list[str]) -> list[str]:
    batch_ids = []
    for i in range(0, len(photo_keys), 1000):
        chunk = photo_keys[i : i + 1000]
        r = requests.post(f"{API}/v1/batches", headers=H, timeout=30, json={
            "collection_id": EVENT,   # created on first write
            "photos": [{"url": f"https://cdn.example.com/{k}", "external_id": k} for k in chunk],
        })
        r.raise_for_status()
        batch_ids.append(r.json()["batch_id"])
    return batch_ids

external_id is echoed back on every webhook and every search match, so use the key you already store the photo under. A photo that succeeds with face_count: 0 is a valid result (a table setting, a venue shot), not an error.

Step 2: reject bad selfies at upload

On our benchmarks page, 96% of 618 real guest selfie searches returned at least one photo. Most of the other 4% were bad selfies: a photo of a screen, heavy coloured party lighting, a face that is barely visible. The fix belongs in the upload screen, not in the search. Run detection on the selfie first, and ask for a retake unless exactly one face passes quality.

def selfie_ok(selfie: bytes) -> tuple[bool, str]:
    r = requests.post(f"{API}/v1/detect", headers=H, files={"file": selfie}, timeout=30)
    r.raise_for_status()
    good = [f for f in r.json()["faces"] if f["quality_passed"]]
    if not good:
        return False, "We couldn't see your face clearly. Try a closer photo in normal light."
    if len(good) > 1:
        return False, "We found more than one face. Take a selfie with just you in it."
    return True, ""

Tip: Tell guests what a good selfie looks like before they take it: face the camera, normal light, no sunglasses. One line of copy above the camera button saves more searches than any threshold tuning.

Step 3: search and rank

def my_photos(selfie: bytes, threshold: float = 0.42) -> list[str]:
    r = requests.post(
        f"{API}/v1/collections/{EVENT}/search",
        headers=H,
        files={"file": selfie},
        data={"threshold": str(threshold), "limit": "500"},
        timeout=30,
    )
    r.raise_for_status()
    body = r.json()
    if not body["matches"]:
        return []   # body.get("reason") says why: no_face, low_quality_selfie
    # Several faces in one photo can match (mirrors, a framed portrait).
    best: dict[str, float] = {}
    for m in body["matches"]:
        best[m["photo_id"]] = max(m["score"], best.get(m["photo_id"], 0))
    return sorted(best, key=best.get, reverse=True)

If you pass limit, set it well above the number of photos one person is likely to be in. The bride appears in hundreds of photos, and a small value like the 10 in our quickstart would cut her results off without any error.

Choosing the threshold

Scores are cosine similarity from 0 to 1. Our default is 0.42, chosen to keep false matches low for event photography. In our 50-gallery study (about 4.06 million faces, 22,070 real selfies), the false-match rate between selfies registered by different accounts was at most 0.13% at a threshold of 0.38, so 0.42 can only be stricter. For a wedding, a wrong photo shown to the wrong guest is worse than a missed one, so start at the default and only lower it if guests report missing photos.

If you want more recall, use two thresholds instead of one: show strong matches straight away, and put weaker ones behind a "Are these you too?" step. Choosing a face-match threshold covers how to sweep for both numbers on your own photos.

What goes wrong in real galleries

Small faces in wide shots. The back rows of a 200-person group photo are a few dozen pixels each. Faces under the quality minimum are skipped at index time, so those guests won't find that photo. That's expected, and it's better than a wrong match.
Children. Children's faces match less reliably than adults', even with good selfies. Our benchmarks page lists this as a known limit. If kids matter to your users, let a parent register a child's selfie separately rather than expecting their own selfie to find the child.
Look-alike relatives. Siblings and parent-child pairs score closer than strangers. A "not me" button on each result lets guests clean up their own view, and it gives you a signal for tuning.
Dark dance-floor photos. Coloured lights and motion blur lower both detection and match scores. Expect fewer matches from the reception than the ceremony.
Mirror and screen shots. A guest photographing their face on another phone's screen is the most common bad selfie we see. The detect pre-check catches many of these, not all.

Consent and deletion

A faceprint is biometric data in most privacy laws (GDPR, Illinois BIPA and others). Get an explicit opt-in before a guest's selfie is processed, say how long it's kept, and delete it when the gallery closes. Because each event has its own collection, deletion is one call. Erasure is asynchronous, though, so don't record the event as erased until the deletion status confirms it.

import time

# When the gallery expires. ?compliance=true skips the grace window and
# records an audited, final erasure.
requests.delete(f"{API}/v1/collections/{EVENT}?compliance=true", headers=H, timeout=30).raise_for_status()

# Erasure runs asynchronously. Only mark the event erased once it is verified.
for _ in range(60):
    st = requests.get(f"{API}/v1/collections/{EVENT}/deletion", headers=H, timeout=30).json()
    if st["phase"] == "completed" and st["verified_zero"]:
        break   # safe to record as erased in your own database
    if st["phase"] == "blocked":
        raise RuntimeError(f"erasure blocked: {st.get('last_error')}")
    time.sleep(30)
else:
    raise RuntimeError("erasure not verified yet; keep polling or wait for the webhook")

What it costs

Billing is per photo processed, never per face, so a group shot costs the same as a portrait. The detect pre-check is another real-time call per selfie.

Item	Volume	Rate	Cost
Index the gallery (batch)	3,000 photos	$0.00062 per photo	$1.86
Guest selfie searches	120 searches	$0.00093 per search	$0.11
Storage	~9,000 faces for a month	$6 per million faces per month	$0.05
Total for one wedding			$2.03

The full API flow, including selfie registration so a returning guest doesn't need to upload again, is in build face search with a selfie. For per-tenant layout when you run hundreds of events, see multi-tenant face search.

Try a search on sample photos first, no sign-up needed. New accounts get free credits, no card. Open the face compare tool

Frequently asked questions

How do guests find their wedding photos with a selfie?

The gallery's photos are indexed into a face search collection ahead of time. When a guest uploads a selfie, the selfie is searched against that collection, and the app shows only the photos that contain a matching face.

How much does selfie photo search cost for one event?

On SightRadar, a 3,000-photo wedding with 120 guest searches costs about $2.03: $1.86 to index the photos at the batch rate, $0.11 for the searches, and $0.05 for a month of storage.

Why can't a guest find photos where they are in the background?

Faces that are very small in the frame fall below the detector's quality minimum and are skipped at indexing, so they cannot be matched later. This affects the back rows of large group photos and distant candid shots.

Do I need consent to run face search on event photos?

In most jurisdictions a faceprint is biometric data. Get an explicit opt-in from each guest before processing their selfie, state how long data is kept, and delete the event's collection when the gallery closes.

I work on SightRadar, the face search API used in the examples. Originally published on the SightRadar blog.

This article was written with AI.

Rekognition ProvisionedThroughputExceededException: TPS limits and backoff that holds up

Ashish Sikka — Sat, 31 Oct 2026 03:10:57 +0000

TL;DR Rekognition's default quota for IndexFaces, SearchFacesByImage and SearchFaces is 5 transactions per second per account in most regions, and 50 in us-east-1, us-west-2 and eu-west-1. A naive parallel backfill blows through that in under a second and gets ProvisionedThroughputExceededException (or ThrottlingException). Retries alone don't fix it. Rate-limit on the client to just under the quota, share one limiter across every worker in the account and region, set the SDK to adaptive retry mode, and request a quota increase before a big job, not during it.

The usual story: a face-search feature works fine in development, then someone kicks off a backfill of 200,000 existing photos with a thread pool of 32 workers. Within seconds the logs fill with this:

botocore.errorfactory.ProvisionedThroughputExceededException: An error occurred
(ProvisionedThroughputExceededException) when calling the IndexFaces operation (reached max retries: 2):
Provisioned rate exceeded

"reached max retries: 2" is the SDK telling you it already retried twice with backoff and gave up. The problem isn't the retry policy. The job is asking for more throughput than the account has.

The default quotas

From the Rekognition service quotas page. These are per account, per region, per operation, so IndexFaces and SearchFacesByImage each have their own budget.

Default TPS quotas as listed by AWS on 2026-10-31. Mumbai, Frankfurt, Tokyo, Sydney, Singapore, London, Ohio and others are in the right-hand column.

Operations	us-east-1, us-west-2, eu-west-1	Most other regions
IndexFaces, SearchFaces, SearchFacesByImage, ListFaces, SearchUsers, SearchUsersByImage	50 TPS	5 TPS
CompareFaces, DetectFaces	100 TPS	25 TPS
AssociateFaces, DisassociateFaces	5 TPS	5 TPS
CreateCollection, DeleteCollection, DeleteFaces, DescribeCollection, ListCollections	5 TPS	5 TPS

Do the arithmetic for that backfill. 200,000 photos at 5 TPS is 40,000 seconds, about 11 hours, and that's at a perfect 5 per second with zero throttles. At 50 TPS it's a bit over an hour. Search has its own quota, so live searches aren't affected by the backfill. Live uploads are: IndexFaces from your upload path and from the backfill share one 5 TPS budget, so new uploads start failing while the backfill runs.

Note: Throttling is per account. Two services, two environments or two developers' scripts in the same AWS account and region all draw on the same quota. A staging backfill can throttle production.

Why more retries make it worse

Each worker that gets throttled backs off and tries again. With 32 workers retrying on similar schedules, the retries arrive in waves that are themselves over quota. Raising max_attempts to 10 just means each photo fails more slowly. In the SDK's default standard mode, failed retries also drain a client-side retry quota (a token bucket), so a sustained overload ends with the SDK refusing to retry at all.

The AWS SDK retry docs say the default is standard mode with max_attempts of 3 (one request plus two retries). adaptive mode adds a client-side rate limiter that slows the initial requests too once it sees throttling, which is what a bulk job needs. AWS's own guidance is that adaptive is for "single-resource, throttling-heavy, latency-tolerant" work. A backfill fits that description. A user-facing search request doesn't.

A backfill that stays under quota

Three pieces: a token bucket set slightly below the quota, shared by all workers; adaptive retries as a safety net; and a dead-letter list for photos that still fail, so the job finishes and you retry the remainder later.

One process, many threads, one shared limiter. For several processes, put the bucket in Redis.

import threading, time
import boto3
from botocore.config import Config
from botocore.exceptions import ClientError
from concurrent.futures import ThreadPoolExecutor

REGION = "ap-south-1"
QUOTA_TPS = 5          # check Service Quotas for your account; it may have been raised
TARGET_TPS = QUOTA_TPS * 0.8   # headroom for live traffic and clock jitter

rek = boto3.client(
    "rekognition",
    region_name=REGION,
    config=Config(retries={"mode": "adaptive", "max_attempts": 6}),
)

class TokenBucket:
    def __init__(self, rate: float, burst: int = 1):
        self.rate, self.capacity = rate, burst
        self.tokens, self.updated = burst, time.monotonic()
        self.lock = threading.Lock()

    def take(self) -> None:
        while True:
            with self.lock:
                now = time.monotonic()
                self.tokens = min(self.capacity, self.tokens + (now - self.updated) * self.rate)
                self.updated = now
                if self.tokens >= 1:
                    self.tokens -= 1
                    return
                wait = (1 - self.tokens) / self.rate
            time.sleep(wait)

bucket = TokenBucket(TARGET_TPS)
failed: list[tuple[str, str]] = []

def index_one(key: str) -> None:
    bucket.take()
    try:
        rek.index_faces(
            CollectionId="gallery-2026",
            Image={"S3Object": {"Bucket": "my-photos", "Name": key}},
            ExternalImageId=key.replace("/", "_"),  # ExternalImageId allows [a-zA-Z0-9_.\-:]+
            MaxFaces=100,
        )
    except ClientError as e:
        failed.append((key, e.response["Error"]["Code"]))

keys = [...]  # your S3 keys
with ThreadPoolExecutor(max_workers=8) as pool:   # more threads than TPS buys nothing
    list(pool.map(index_one, keys))
print(f"done, {len(failed)} to retry later")

A few notes on the numbers. The pool size only needs to cover latency: if an IndexFaces call takes around 400 ms, four threads already sustain 10 calls a second, so eight is plenty for a 5 TPS budget. Burst is 1 on purpose, so the job never sends a spike on startup. And 80% of quota leaves room for whatever else in the account calls the same operation.

Live traffic: different rules

Keep retries short. A user waiting for search results shouldn't sit through six attempts with growing backoff. Use standard mode with the default 3 attempts, and return a "busy, try again" response after that.
Separate the budgets in your head. Live SearchFacesByImage has its own quota, but live IndexFaces (new uploads) shares one with any backfill. Pause or slow the backfill during peak upload hours.
Alarm on throttles, not just errors. CloudWatch publishes a ThrottledCount metric for Rekognition. An alarm on it tells you you're near the ceiling before users notice.

Requesting a quota increase

TPS quotas are adjustable through Service Quotas or the AWS Support Center, per operation and per region. Ask with a specific number and a reason ("IndexFaces to 50 TPS in ap-south-1 for a one-time backfill of 2M photos"), and ask days before you need it, since approval isn't instant. Ask for each operation separately: a raise for IndexFaces does nothing for SearchFacesByImage.

Or send bulk work through a queue

We build SightRadar, a face search API that uses Rekognition's collection model, and we went the other way for bulk work. POST /v1/batches takes up to 1,000 photo URLs in one call, queues them, and sends one signed webhook per photo as results arrive. Your code never meets a per-second ceiling during a backfill, and batch photos are billed at $0.00062 each instead of the $0.00093 real-time rate. See batch and webhooks.

import os, requests

photos = [{"url": f"https://cdn.example.com/{k}", "external_id": k} for k in keys[:1000]]
r = requests.post(
    "https://api.sightradar.com/v1/batches",
    headers={"Authorization": f"Bearer {os.environ['SIGHTRADAR_API_KEY']}"},
    json={"collection_id": "gallery-2026", "photos": photos},
    timeout=30,
)
print(r.json()["batch_id"])  # results arrive per photo via webhook or GET /v1/batches/{id}

Real-time calls do have limits: 50 requests per second per API key and 10 in-flight requests per account by default, returning 429. So the token-bucket advice above still applies to a synchronous loop. The difference is that bulk jobs don't need one. If your existing code is boto3, the Rekognition shim keeps your index_faces calls as they are.

Estimate a backfill at batch rates before you start one. Open the pricing calculator

Frequently asked questions

What is the default TPS limit for AWS Rekognition IndexFaces?

5 transactions per second per account in most regions, and 50 in US East (N. Virginia), US West (Oregon) and Europe (Ireland). SearchFaces and SearchFacesByImage have the same defaults, each as a separate quota. The limits are adjustable through Service Quotas.

What is the difference between ProvisionedThroughputExceededException and ThrottlingException in Rekognition?

Both mean you sent requests faster than the account's quota allows. Handle them the same way: slow down on the client, retry with backoff and jitter, and request a quota increase if the sustained rate you need is above the default.

Should I use adaptive retry mode for Rekognition?

For bulk, latency-tolerant jobs such as backfills, yes. Adaptive mode adds a client-side rate limiter that slows new requests after throttling. For user-facing requests, standard mode with few attempts is better, so a user is not kept waiting.

Do Rekognition TPS limits apply per collection?

No. They apply per AWS account, per region, per operation. Every collection, service and script in the same account and region shares the same quota for a given operation.

I work on SightRadar, the face search API used in the examples. Originally published on the SightRadar blog.

This article was written with AI.

Fixing 'There are no faces in the image' in Rekognition SearchFacesByImage

Ashish Sikka — Sat, 31 Oct 2026 03:10:21 +0000

TL;DR SearchFacesByImage first detects the largest face in your input image. If it finds none, it fails with InvalidParameterException: There are no faces in the image. Should be at least 1. The usual causes are a face that is small relative to the frame, a selfie cropped too tightly, an extreme head pose, or a dark or blurry photo. Call DetectFaces on the same bytes to see which one you hit, crop group shots around the face with a margin, and catch the exception so your user gets "try another photo" instead of a 500.

This is the error every selfie-search feature runs into in its first week of real traffic. Test photos work. Then real users upload a photo of themselves from across the room at a wedding, or a selfie their camera app already cropped to the face, and the call fails before any searching happens.

botocore.errorfactory.InvalidParameterException: An error occurred (InvalidParameterException)
when calling the SearchFacesByImage operation: There are no faces in the image. Should be at least 1.

InvalidParameterException is a generic "input violated a constraint" error with HTTP status 400, so the message text is the only thing that tells you it was face detection that failed and not, say, a bad CollectionId.

What SearchFacesByImage actually does with your image

Per the API reference, the operation runs detection first, takes the single largest face it found, and only then searches the collection with it. Two consequences matter:

It only ever searches one face. In a group photo, it picks the largest face, which may not be the person who uploaded it. To search every face in a photo, AWS suggests IndexFaces and then SearchFaces by face ID.
Detection failure is an exception, not an empty result. A photo where Rekognition sees no face never reaches the search step, so you can't get back an empty FaceMatches list for it.

The six causes, most common first

1. The face is small relative to the image

The quota page says a face must be at least 40×40 pixels in a 1920×1080 image, and that larger images need a proportionally larger face. The input-image recommendations give 50×50 at the same resolution. Either way, the limit is relative. A face that is 60 pixels tall in a 6000×4000 photo behaves like a face of about 16 pixels in a 1080p frame, far below the minimum.

This is why downscaling a large photo doesn't help: the face shrinks with it. Cropping does help, because it makes the face a larger share of the frame.

2. The selfie is cropped too tightly

The opposite mistake. Some upload widgets and camera apps crop to the face before you ever see the image. AWS's recommendation is explicit: the image "should contain the full head and shoulders of the person. It should not be cropped to the face bounding box." If your client code crops, leave a margin of roughly one face-width on every side.

3. Extreme head pose

AWS recommends pitch under 30° looking down and under 45° looking up, and yaw under 45° either way. Roll (head tilt) has no restriction, so a sideways phone photo is rarely the cause on its own. Profile shots and people looking down at a phone are.

4. Dark, blurry or low-contrast photos

Night-time event photos with motion blur, heavy backlight, or a face in deep shadow. IndexFaces reports these as UnindexedFaces with reasons like LOW_BRIGHTNESS and LOW_SHARPNESS, and SearchFacesByImage simply fails to find a face.

5. Occlusion

Sunglasses, masks, a hand over the mouth, or a phone in front of the face during a mirror selfie. AWS asks for both eyes open and visible.

6. A QualityFilter you set yourself

SearchFacesByImage defaults QualityFilter to NONE. If your code sets LOW, MEDIUM or HIGH, a borderline selfie can be filtered out before search. Set it back to NONE while debugging to see whether the filter or detection is what rejects the face.

Info: Not the same error: InvalidImageFormatException means the bytes aren't a PNG or JPEG. Rekognition accepts only those two formats, so iPhone HEIC uploads fail with it, and so does passing a base64 string to Image={"Bytes": ...} in boto3 (boto3 encodes the bytes for you). ImageTooLargeException means raw bytes over 5 MB; S3 objects can be up to 15 MB.

Diagnose with one DetectFaces call

DetectFaces with Attributes=["ALL"] returns every face it sees with its bounding box, pose and quality scores. Run it on the exact bytes that failed. If it returns nothing, the problem is the image. If it returns a face, the numbers tell you which cause above you hit. Note that DetectFaces is a separately billed call, so use it for debugging and sampling, not on every request.

Run on the bytes that failed. Prints size relative to the 1080p minimum, pose and quality.

import boto3
from PIL import Image
import io

rek = boto3.client("rekognition", region_name="us-east-1")

def explain(image_bytes: bytes) -> None:
    w, h = Image.open(io.BytesIO(image_bytes)).size
    faces = rek.detect_faces(Image={"Bytes": image_bytes}, Attributes=["ALL"])["FaceDetails"]
    if not faces:
        print(f"{w}x{h}: no face detected at all")
        return
    for f in faces:
        box = f["BoundingBox"]
        face_px = min(box["Width"] * w, box["Height"] * h)
        # Scale to what this face would measure in a 1920x1080 frame.
        at_1080p = face_px * 1080 / min(w, h)
        p, q = f["Pose"], f["Quality"]
        print(
            f"face ~{face_px:.0f}px ({at_1080p:.0f}px at 1080p, min ~40-50) "
            f"yaw={p['Yaw']:.0f} pitch={p['Pitch']:.0f} "
            f"brightness={q['Brightness']:.0f} sharpness={q['Sharpness']:.0f}"
        )

Handle it in code instead of returning a 500

The error is a user-input problem, so treat it like a validation error. Catch it by code and message, and ask for another photo.

from botocore.exceptions import ClientError

def search_selfie(collection_id: str, image_bytes: bytes):
    try:
        return rek.search_faces_by_image(
            CollectionId=collection_id,
            Image={"Bytes": image_bytes},
            FaceMatchThreshold=90,
            MaxFaces=50,
        )["FaceMatches"]
    except ClientError as e:
        err = e.response["Error"]
        if err["Code"] == "InvalidParameterException" and "no faces" in err["Message"].lower():
            return None  # tell the user: "We couldn't see a face. Try a closer, well-lit photo."
        raise

Prepare images so the error happens less

Apply EXIF rotation and convert to JPEG. Phones store orientation as metadata and often shoot HEIC. ImageOps.exif_transpose plus a JPEG re-encode fixes both, and keeps you under the 5 MB bytes limit.
Crop group shots around the chosen face, with a margin. If your UI lets the user tap their face in a group photo, crop to that region plus about one face-width on each side. The face becomes a larger share of the frame without violating the "head and shoulders" advice.
Validate at upload, not at search. Run detection once when the user uploads the selfie and reject it right away with a clear message. Users accept "retake" at upload time far better than an empty result later.

Rotation, optional crop with margin, JPEG under the 5 MB bytes limit.

import io
from PIL import Image, ImageOps

def prepare(path: str, crop=None, max_side=2048) -> bytes:
    img = ImageOps.exif_transpose(Image.open(path)).convert("RGB")
    if crop:  # (left, top, width, height) as ratios, e.g. from a tap or a detector
        l, t, cw, ch = crop
        W, H = img.size
        mx, my = cw * W, ch * H  # one face-width of margin each side
        img = img.crop((
            max(0, l * W - mx), max(0, t * H - my),
            min(W, (l + cw) * W + mx), min(H, (t + ch) * H + my),
        ))
    img.thumbnail((max_side, max_side))
    buf = io.BytesIO()
    img.save(buf, "JPEG", quality=90)
    return buf.getvalue()

The same flow on SightRadar

We build SightRadar, a face search API that keeps Rekognition's collection model (create a collection, index photos, search by selfie), so this is a problem we handle every day. Two differences are relevant here:

No exception for a missing face. Search returns 200 with an empty matches list and a reason of no_face or low_quality_selfie, so the "ask for another photo" branch is a field check, not an exception handler. Like any processed photo, the call is billed.
More input formats. JPEG, PNG, WebP, HEIC/HEIF, TIFF, GIF and BMP are decoded natively and the limit is 30 MB, so the format and size errors above don't apply. The relative-size and pose advice still does: it's how face detection works, not a vendor quirk.

import os, requests

r = requests.post(
    f"https://api.sightradar.com/v1/collections/{collection_id}/search",
    headers={"Authorization": f"Bearer {os.environ['SIGHTRADAR_API_KEY']}"},
    files={"file": open("selfie.jpg", "rb")},
    data={"limit": "50"},
    timeout=30,
)
body = r.json()
if not body["matches"] and body.get("reason") in ("no_face", "low_quality_selfie"):
    print("Ask for another photo:", body["reason"])
for m in body["matches"]:
    print(m["photo_id"], round(m["score"], 3))

If you already have boto3 code, the Rekognition shim keeps your search_faces_by_image calls and converts the 0 to 100 threshold scale. The migration guide covers re-indexing and cut-over.

Try detection on your own problem photos. New accounts get free credits, no card. Open the face detector

Frequently asked questions

Why does SearchFacesByImage say there are no faces when I can clearly see one?

Rekognition's minimum face size is relative to the image: about 40 to 50 pixels in a 1920x1080 frame, scaled up for larger images. A face that looks fine to you in a 24-megapixel group photo can be far below that. Tight crops, extreme head pose, darkness, blur and occlusion are the other common causes.

Does resizing the image fix the no faces error?

Downscaling does not, because the face shrinks in proportion. Cropping around the face does, because the face becomes a larger share of the frame. Keep a margin so the crop still shows head and shoulders.

How do I search every face in a group photo with Rekognition?

SearchFacesByImage only searches the largest face. To search every face, call IndexFaces on the photo, then call SearchFaces with each returned FaceId.

What is the difference between InvalidParameterException and InvalidImageFormatException here?

InvalidParameterException with the message 'There are no faces in the image' means the image decoded but no face was detected. InvalidImageFormatException means the bytes are not a PNG or JPEG, for example an iPhone HEIC file or a base64 string passed where raw bytes are expected.

I work on SightRadar, the face search API used in the examples. Originally published on the SightRadar blog.

This article was written with AI.