How it works

Three moving parts, what each one does, and how a photo becomes searchable.

Three moving parts: the app on your phone, the Opensolr platform, and the phone's own Opensolr Index. The app talks to each of them over HTTPS and to nothing else.

HOW A PHOTO BECOMES SEARCHABLE On the phone the app Photo in a folder EXIF read here 640 px copy made image_clip api.opensolr.com CLIP reads the copy Returns 12 labels Copy not stored batch_embed api.opensolr.com Labels to a vector 1024 numbers Plans with vectors Your index Solr, direct POST /update Labels and vector Date, camera, place Search the app Words, meaning Filters Opens in gallery Paid for once per photo Labels and vectors are cached on the phone. An emptied or recreated index is refilled without a single AI request. The copy carries nothing else It is re-encoded from pixels: no EXIF block, no GPS, no camera data travels with it. EXIF goes only into your own index, as fields.

Figure 1 — how a photo becomes searchable.

01 · The app
  • Finds photos through Android's MediaStore, in the folders you chose.
  • Reads each photo's camera details itself: date, camera, lens, exposure, place.
  • Makes a small upright JPEG copy, 640 px on its long edge, for the reader. The copy is re-encoded from pixels and carries no metadata.
  • Writes the documents into the index, and searches the index directly.
  • Runs sync in the background, one at a time, and keeps a cache of what it already learned.
  • Watches the photo library and syncs on its own when photos are added, changed or deleted.
02 · Opensolr

opensolr.com

The sign-in and approval pages, and the account API: creating the index, uploading its configuration, reading its address and password, reading plan limits and usage, and nearby_places, which turns a GPS position into the nearest place: city, region, country.

api.opensolr.com

image_clip reads a picture into words with CLIP, the same model and vocabulary as Opensolr's image search, and stores nothing. batch_embed and embed turn words into search vectors.

03 · The phone's index

A regular Opensolr Index named photos_<ANDROID_ID>__dense, created in your account on a server that runs vector search, with the app's own schema. The app reads and writes it directly with its credentials: /select to search and list, /update to add and delete. See the phone's index.

YOUR PHONE Original photos, full size EXIF and GPS read here API key, Keystore-encrypted Label and vector cache Thumbnails, from the phone excluded from phone backups OPENSOLR.COM Sign-in and approval Create index, upload config Plan limits and usage API.OPENSOLR.COM CLIP on a 640 px copy Vectors of the labels Nothing stored YOUR OPENSOLR INDEX Labels (the meaning) Search vector Date, camera, place Path, folder, size Removed with the photo one per phone, in your account direct to Solr: HTTPS + index password Every arrow is HTTPS. The app sends nothing to any other host: no analytics, no ads, no crash reporting.

Figure 2 — where each piece of data lives. Every arrow is HTTPS.

04 · The life of one photo
  1. You take a photo; the camera saves it in DCIM/Camera/.
  2. At the next sync the app finds it, gives it its id and sees it is not in the index.
  3. The app reads its date, camera and GPS position, and makes the 640 px copy.
  4. image_clip answers twelve words, for example dog, beach, sand, sea, ….
  5. nearby_places turns the position into Constanţa, Constanţa, Romania.
  6. batch_embed turns those words into a 1024-number vector.
  7. The document — words, vector, date, camera, place, path — is written to the index, and the photo appears in search.
  8. You edit the photo in your gallery; a minute later a sync notices the changed file and reads it again.
  9. You delete the photo from your gallery; a minute later its id is missing from the phone, and its document is deleted from the index.

Opensolr Photos is open source and MIT licensed. Questions about your Opensolr account, index or plan go to opensolr.com/contact; questions about the app itself belong on GitHub.

Opensolr Photos Documentation