Why Does Face Recognition Ignore Photos From a Shared Album?

Face recognition can ignore shared-album photos when sharing makes the asset visible without placing it inside the ownership or processing scope used by the People index.

The useful distinction is not simply shared versus private. Compare an owned photo with a similar shared photo, verify whether face-processing jobs ran for both, and determine which account or library owns each asset. Rebuild face data only after the affected photos belong to a scope the application is designed to index.

Separate Album Visibility From Face Index Visibility

Open one affected shared photo and confirm the viewer can see the asset, then check whether the People or face-search view contains the same photo. Treat those as two separate permissions and processing questions.

Shared-album workflows such as shared Immich albums demonstrate that making an asset visible to another user does not necessarily transfer every derived organizational feature with it.

If the photo is visible but never appears in People, stop troubleshooting album sharing alone. The next tests should identify which account owns the asset and which assets the face pipeline indexes.

Compare an Owned Control Photo

Use two visually similar photos: one uploaded by the account whose People view works and one visible only through the shared album. Confirm both contain a clear face and were added during the same period.

A self-hosted Immich deployment has distinct Immich processing architecture, storage, job, and client layers, so the control test should hold image quality constant while changing ownership or library scope.

If only the owned asset receives face metadata, the symptom follows scope rather than image quality. Avoid changing recognition thresholds until that ownership boundary is understood.

Check Whether Face Jobs Actually Ran

Inspect job queues and asset metadata for face detection and recognition on the affected record. Compare timestamps and job completion with the owned control photo.

Independent Immich operations coverage describes Immich machine-learning jobs as background work, which means an uploaded or shared asset can be visible before every machine-learning derivative is complete.

If the job never ran for the shared asset, reprocessing only makes sense after confirming that asset is eligible. Repeatedly retrying an ineligible scope wastes compute and hides the real boundary.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Choose the Sharing Model That Matches the Goal

Decide whether the household needs only shared viewing or expects one unified people index across all photos. Those are different product behaviors and may require shared ownership, partner-style sharing, or a common managed library.

A practical shared photo library design is useful because it shows how shared-library organization choices affect what becomes common versus what stays attached to individual users.

Do not copy every photo into another user’s library solely to force face recognition unless duplicate storage and deletion semantics are acceptable. Prefer the application’s supported sharing model.

Reprocess Only After Scope Is Correct

Once the asset belongs to a scope that should receive face processing, run the smallest supported face-detection or recognition job for a test subset and compare the result.

The related ZimaSpace guide to Immich family photo library keeps the change inside a backup-aware photo-library workflow, where derived face data can be rebuilt without risking originals.

The fix is proven when newly eligible shared photos enter the expected People view after normal processing. If eligible owned controls still fail, then investigate model, worker, or resource faults.