Having migrated to immich, I decided to aim for a more integrated experience, where a lot more of the workflow was driven from immich itself. I also decided to try to keep the facts (persons, places) more in one place, immich.

Immich reads the GPS coordinates, but although it will in the UI show an approximate reverse geocoding of an image, it doesn’t inherently log that anywhere. Thus, I decided to keep doing reverse geocoding and a POI registry in my classifier, with some changes:

• I wanted control of it to be done from immich as much as possible.
• I wanted the results written back to immich, as tags.

Earlier, I have made a cli and a GUI to control the classifier.I ended up creating immich-sync as sort of a third inteface, though it ended up changing a bit on how the classifier itself works. The old methods should ideally stll work, but the reverse geocoding and faces now mostly is supplied as inputs in the classifying calls, with immich being the source of truth. Reverse geocoding happens on the outside, in immich-sync, with tags written back to immich in an hierarchy. The same data is supplied in the prompt to the classifier.

The POI registry no longer lives in the classifier, it lives in immich-sync, which I initally filled with the registry I had before. I also created a web gui for immich-sync, because some manual updating in it was unavoidable.

So, how do I interact with it now?

• To learn a place from an image that has a GPS coordinate, I add a tag sync/learn-place/<Kind>/<Name>. Earlier, I would use the GUI app to pick an image, then add the kind and name manually. In the web interface, I can manage it, if I for example want to manually adjust «has view», radius or other things that could also earlier be customized. But the idea was always that a kind should have a default radius, and has a view if that kind of place usually has a view. Some manual overriding, I guess, will always be needed, which is why there’s a web ui to the registry.
• Faces/Persons, I’ve stopped doing in the classifier. Here, I rely completely on immich face recognition and/or manual tagging.
• To do a classification, I will add a tag sync/classify
• The immich-sync service will periodically (every 30 seconds in my case) poll immich for images with these tags, and will do its tasks and then remove the tags to mark the task done.

All of the above makes the classifier feels more like an integral part of my library, now, with all facts (description, tags and places) back-filled into immich.

Core changes and key results

Earlier, the facts (POIs, faces) lived in the classifier itself. Now, immich-sync instead supplies these facts, which it reads from immich metadata through the API. That means it needs to supply the face and place in the call to the media classifier. If there are faces or places supplied in the classification call, the internal resolving of faces or places is skipped, and the externally supplied facts is instead applied to the prompt.

The whole internal batch system is also more or less bypassed, by immich-sync itself controlling what classification requests are pending, periodically polling the classifier for the state of that classification.

The classifier no longer relies on XMP files, the results are written back into immich directly, via the API.

The sum of this is that the workflow is now more streamlined, I can rely on immich-sync itself writing the metadata back where it belongs, instead of having to remmber to re-read the XMPs, so immich-sync becomes more or less just a plugin to immich.