Photo Explorer, Constellations et un Mapsake plus rapide.

Une version de nouvelles fonctionnalités et une version d'ingénierie.

Cette mise à jour introduit deux des expériences photographiques les plus ambitieuses de Mapsake : Explorateur de photos, qui rend une vaste bibliothèque cartographique facile à rechercher, et Constellations, qui découvre des liens visuels entre des lieux éloignés.

Il comprend également la fonctionnalité la moins visible de la version : une suite de référence de performance permanente. Cette suite a immédiatement trouvé les chemins partagés les plus lents, a rendu les corrections mesurables et a donné à l'application un moyen de détecter quand les travaux futurs les ralentiraient à nouveau.

Le résultat offre plus que de simples fonctionnalités. Mapsake est nettement plus rapide pour convertir de grandes bibliothèques de photos en lieux, pour trouver des villes à proximité et pour planifier une constellation.

Photo Explorer recherche dans l'historique des voyages, et non dans la galerie de photos.

Photo Explorer commence avec les métadonnées compactes que Mapsake gère déjà pour les photos cartographiées. Cela comprend l'emplacement, la date, la source, l'appareil photo, les notes, l'altitude, la vitesse, les favoris, les captures d'écran, les modifications et l'organisation ajoutée dans l'application.

L'index reste sur l'appareil. Une recherche peut être directe (Japon, 2024, iPhone, favoris) ou formulée de manière plus naturelle, comme "photos préférées d'Italie l'année dernière". La couche de requête convertit le langage pris en charge en un ensemble structuré de filtres, tandis que le vocabulaire déterministe et la correction des erreurs fournissent une solution de repli fiable.

La recherche n'est qu'un moyen d'accéder à la bibliothèque. Les collections affichent des groupes utiles sans avoir à taper ; la zone de la carte limite les résultats géographiquement ; la chronologie les regroupe par date ; les recherches enregistrées et récentes facilitent la répétition des questions. Les favoris, les évaluations, les balises, les étiquettes et les notes se trouvent dans un complément local, de sorte que l'organisation d'une photo ne modifie ni ne télécharge le fichier original.

Le choix architectural important est que chaque outil partage la même instantané indexée. Les collections, la chronologie, la carte et la recherche de texte ne reconstruisent pas à chaque fois un monde de photos 82,000 à partir de zéro.

L'index est dérivé, tandis que l'organisation personnelle est durable.

Photo Explorer avait besoin de deux types de stockage avec des durées de vie très différentes. Les champs de recherche tels que les noms de lieux, l'année de capture, l'appareil photo, l'altitude et la source peuvent être reconstitués à partir des métadonnées existantes de Mapsake. Un favori, une note privée, une note, une étiquette ou une couleur ont été écrits par une personne et ne peuvent pas être traités comme des données de cache temporaires.

Mapsake conserve l'organisation rédigée par l'utilisateur dans un fichier secondaire de petite taille, éligible à la sauvegarde. L'index de recherche plus important se trouve dans le cache, ne contient pas d'octets d'image, est exclu de la sauvegarde et peut être régénéré chaque fois que son schéma change. Le balayage d'une bibliothèque ou la suppression des données dérivées n'efface pas le travail que quelqu'un a consacré à l'organisation.

Cette division a également rendu les sauvegardes plus honnêtes. Les sauvegardes sans perte au format JSON et HTML peuvent contenir des notes et une organisation, mais elles ne se transforment pas silencieusement en archives de photos. Les annotations d'Apple Photos conservent un identifiant iCloud stable afin qu'une sauvegarde restaurée puisse reconnecter la copie locale à un autre appareil Apple ; les identifiants d'actifs Immich sont déjà stables par leur origine.

L'environnement de test complet a produit un index compressé d'environ 12.4 Mo pour 82,000 photos. Une construction géographique complète a pris 2.61 secondes sur le simulateur de développement, une restauration ultérieure à partir du disque a pris 1.20 secondes, la génération de collections a pris 126 millisecondes et le modèle de chronologie quotidien a pris 211 millisecondes. Ces chiffres ont attribué un budget propre à chaque partie de la fonctionnalité plutôt que de masquer tout derrière une mesure générique de "recherche".

Photo Explorer explique également pourquoi un élément a correspondu. Un résultat peut indiquer qu'il a correspondu à Kyoto, 2024, un appareil photo iPhone, une note privée ou un filtre sélectionné. Cette petite ligne est importante lorsque une requête combine le langage naturel avec plusieurs contrôles exacts : l'utilisateur ne doit jamais avoir à deviner ce que le moteur de recherche a voulu dire.

Le langage de recherche est une interface, pas une licence pour improviser.

Chaque requête prise en charge devient finalement une structure de filtre validée. Le chemin direct reconnaît les lieux, les dates, les sources, les modèles de caméra, les notes, les favoris, les évaluations, les balises, l'altitude, la vitesse, les captures d'écran et les photos modifiées. Un correcteur orthographique limité peut corriger les mots d'intention et le vocabulaire indexé connu, mais il ne réécrit pas les notes privées arbitraires.

Sur les appareils qui prennent en charge les modèles de base sur l'appareil d'Apple, le texte soumis peut également être interprété dans la même structure contrainte. Seule la requête et l'année actuelle sont fournies à ce modèle système. Les pixels de la photo, les index de métadonnées, les notes de localisation et l'organisation personnelle ne sont jamais fournis. Les plages non valides et les valeurs inconnues sont rejetées, et l'analyseur déterministe reste la solution de secours.

L'interface affiche l'interprétation et offre un moyen de revenir aux mots d'origine. C'est un endroit où l'ingéniosité n'est utile que si elle reste vérifiable. "Photos à 3,000 mètres de l'année dernière" doivent sembler conversationnelles, mais doivent toujours se comporter comme un ensemble précis de filtres.

Constellations recherche des répétitions sur de longues distances.

"Then & Now" demande si quelqu'un est retourné au même endroit. "Constellations" pose presque la question inverse : quelles idées visuelles a-t-il répétées dans des endroits éloignés ?

L'index local extrait un ensemble compact de signaux visuels et de motifs à partir des photos de voyage éligibles. Le planificateur recherche des caractéristiques qui sont distinctives d'une image plutôt que simplement communes partout, puis connecte les candidats de différentes destinations. Les portes, les côtes, les silhouettes, les formes de montagnes, les couleurs, les saisons et la composition peuvent devenir le vocabulaire d'un fil.

Ces fils sont organisés en un ciel tridimensionnel. L'utilisateur peut naviguer dans celui-ci, ouvrir une constellation, conserver ou supprimer une connexion et lire un film de coupe en correspondance dans lequel les photos connexes se fondent d'un endroit à l'autre. Les cartes de partage et la bobine utilisent les mêmes données de fil enregistrées.

L'extraction et la planification se font sur l'appareil. Mapsake n'envoie pas de bibliothèque de voyages à un service d'analyse d'images. Les lots en arrière-plan peuvent approfondir l'index au fil du temps sans que le premier lancement ne doive attendre que toute la bibliothèque soit chargée.

L'index visuel a été conçu pour être réajusté à moindre coût.

Pour chaque entrée éligible, Mapsake effectue un petit décodage d'image et dérive plusieurs signaux : une empreinte de fonctionnalité Vision, des étiquettes de classification brutes, une palette de couleurs compacte et une classe de lumière estimée à partir de la localisation, de l'heure et de l'altitude solaire. L'empreinte de fonctionnalité est une description numérique utilisée pour la similarité ; ce n'est pas une copie de la photo et ne peut pas être affichée comme telle.

L'index stocke des identificateurs de classificateurs bruts plutôt que de les remplacer immédiatement par des motifs orientés vers le produit. Ce choix a porté ses fruits lors des tests avec des bibliothèques réelles. La première liste de motifs comprenait des étiquettes qui semblaient raisonnables, mais qui n'étaient pas réellement présentes dans la taxonomie prise en charge de Vision. Étant donné que les étiquettes brutes étaient toujours disponibles, la reconstruction de "Tours et ponts", "Bateaux et ports" et de groupes de motifs ultérieurs a été une évaluation rapide plutôt qu'un autre balayage de milliers d'éléments originaux.

L'indexation commence avec des photos représentatives plutôt que de lire strictement la bibliothèque du plus récent au plus ancien. Les photos sont regroupées en cellules de lieu approximatives et en jours de lieu, avec une préférence pour les images fixes utiles et l'espacement entre les rafales. Le planificateur parcourt ensuite les lieux par étapes. Cela permet une large couverture géographique au début, tandis que les lots d'arrière-plan ajoutent progressivement de la profondeur.

La première version choisissait une photo par lieu à chaque tour. Les données réelles des appareils ont révélé le défaut : la plupart des lieux restaient en dessous du minimum de trois photos utilisé par le moteur de threads, de sorte que des milliers d'actifs indexés pouvaient toujours ne produire aucun candidat. La division de chaque tour en trois représentants a rendu l'index utile plus tôt sans augmenter son budget total. C'est précisément pourquoi les environnements de test synthétiques et une bibliothèque réelle et désordonnée sont tous les deux importants.

L'extracteur fonctionne par lots séquentiels, effectue les modifications de manière atomique, met en pause en cas de contrainte thermique et ignore l'extraction en arrière-plan en mode basse consommation. Les miniatures Apple Photos qui se trouvent déjà sur l'appareil sont essayées en premier ; les images qui ne sont disponibles que sur iCloud peuvent attendre un passage ultérieur avec une connexion réseau. Immich utilise la même canalisation visuelle que son client de miniatures existant.

La similitude seule ne suffit pas à raconter une histoire.

Une distance de fonctionnalité peut trouver deux photographies visuellement similaires, mais Constellations est conçu pour trouver une connexion entre les lieux plutôt qu'un détecteur de doublons. Les photos candidates doivent appartenir à des destinations situées à au moins 150 kilomètres de distance. Le moteur prend également en compte des motifs distinctifs, une lumière inhabituelle, la saison et des rituels de calendrier récurrents avant d'admettre une connexion.

“Distinctif” est devenu la partie difficile. Un ancien modèle de notation récompensait les signaux présents dans les deux endroits. Dans la bibliothèque de développement, cela a généré des centaines de connexions dominées par la nuit et les saisons communes. Ces signaux étaient techniquement partagés, mais pas du tout surprenants. Le moteur évalue désormais la pertinence : un signal est important lorsqu'il est inhabituellement fort dans les deux endroits par rapport à la bibliothèque de la personne dans son ensemble.

Cela a changé la question de "Les deux lieux contiennent-ils des photos de nuit ?" à "Les deux lieux ont-ils une quantité inhabituellement élevée de photos de nuit pour cette bibliothèque ?" Les signaux courants disparaissent en arrière-plan, tandis que les prises répétées pendant la "blue hour", les vues de portes, les ports, la lumière hivernale ou une semaine de vacances récurrente peuvent devenir significatives.

Les candidats visuels utilisent plusieurs représentants par lieu plutôt qu'une seule paire aléatoire. Les identifiants de fil sont dérivés de leur emplacement et de leur famille, de sorte que la même connexion conserve son identité après un réévalué. L'état « enregistré », « rejeté » et « vu » est donc conservé, et un fil rejeté ne réapparaît pas simplement parce que le moteur a été relancé.

La disposition du ciel est également précalculée et déterministe. Les positions géographiques définissent les nœuds, la force de la connexion attire les lieux connectés les uns vers les autres, et un petit jitter aléatoire évite les chevauchements exacts. L'interface en direct peut animer entre une géographie de type globe et la constellation terminée avec une seule valeur de transition ; elle n'exécute pas de simulation physique gourmande en batterie à chaque image.

Le montage utilise l'attention de saliency de Vision pour placer le mouvement doux de la caméra autour de la partie importante de chaque exemple. Une porte se fond dans une autre porte au lieu d'aligner aveuglément deux centres d'image. "Réduire le mouvement" supprime le mouvement de dérive et raccourcit la transition, tandis qu'un recadrage central est la méthode de repli élégante lorsque la saliency n'est pas disponible.

Pourquoi créer une suite de tests maintenant ?

Les performances d'une bibliothèque importante avaient atteint un point où l'intuition ne suffisait plus. Un changement pouvait rendre un écran plus rapide, tout en ralentissant silencieusement les importations, les souvenirs ou les constellations, car ils dépendent tous des mêmes pipelines géographiques et photo.

La nouvelle suite comporte deux voies :

• Un moteur de logique exécute des tests de fonctionnalités déterministes sur des ensembles de données petits, moyens et de stress, y compris un niveau de photo 82,000 basé sur le rapport du monde réel le plus important disponible lors du développement.
• Une couche de l'interface utilisateur affiche des captures d'écran représentatives, tandis que l'instrumentation de performance propre à Mapsake enregistre le temps d'exécution, les problèmes et la mémoire.

Les références utilisent l'optimisation de la version de publication avec la possibilité de tester activée. Les builds de débogage sont délibérément exclus car Swift non optimisé produit des nombres qui ne sont pas pertinents pour l'application publiée. Les résultats du simulateur et de l'appareil physique maintiennent également des références distinctes afin que le matériel différent ne soit pas comparé comme s'il s'agissait du même environnement.

Le package couvre le gazetteer, la géométrie de la carte, les importations, les métadonnées des photos, les réalisations, Passport, les amis, les sauvegardes, les timbres, les constellations, les souvenirs et l'explorateur de photos. Les réseaux en direct, la qualité de l'appareil photo, l'énumération du système de photos et CloudKit restent des tests d'intégration, car prétendre que ces entrées sont déterministes rendrait les résultats moins honnêtes.

Un point de référence peut être dangereusement faux

La création de la suite a nécessité plus d'efforts que de simplement intégrer un chronomètre dans le code de l'application. L'environnement de test initial utilisait une fonction de hachage simple pour sélectionner les coordonnées. Swift randomise délibérément ce hachage entre les processus, ce qui modifie la géométrie d'environ 30 pour cent d'une exécution à l'autre. Les environnements de test utilisent maintenant un générateur fixe, et la suite valide la forme générée avant d'accepter un résultat.

Un scénario initial appelé import.merge mesurait les nouvelles insertions. Le chemin de production qu'il était censé représenter était une fusion idempotente dans un atlas existant. Le benchmark était rapide et reproductible, mais il testait la mauvaise chose. La correction de la configuration a modifié la ligne de base avant toute tentative d'optimisation.

Les mesures de l'interface utilisateur présentaient un piège similaire. Les compteurs de performance étaient cumulés depuis le lancement, de sorte qu'un geste de onglet pouvait hériter de ralentissements de l'animation de lancement et sembler plus lent qu'il ne l'était. Chaque interaction efface maintenant son instantané précédent et traite ensuite uniquement le travail dans le contexte de ce scénario.

L'environnement d'exécution enregistre le système d'exploitation, le niveau de matériel, la version, l'état thermique et l'état thermique. Le résultat d'une simulation n'est jamais privilégié par rapport à une ligne de base de l'appareil. Les exécutions thermiques non nominales restent des diagnostics utiles, mais elles sont annotées au lieu de provoquer un échec de la régression. Une régression doit dépasser à la fois un seuil relatif et un seuil absolu faible afin que le bruit de quelques millisecondes ne devienne pas une fausse urgence.

Ces détails ne sont pas une bureaucratie liée à la référence. C'est ce qui rend ce nombre pertinent.

Les mécanismes de correction ont détecté un bug réel dans la carte

Le test le plus utile dans le premier passage de performance n'a pas mesuré la vitesse. Il a comparé la dérivation de photos vers des lieux optimisée à une référence simple et figée sur des coordonnées riches en limites.

Cette protection a échoué avant même que l'optimisation n'ait modifié le moteur. Les photos à l'intérieur de polygones administratifs qui se chevauchent (Berlin dans le Brandebourg, Séoul dans le Gyeonggi et Kyiv dans son oblast environnant) pourraient être attribuées en fonction de l'ordre d'itération aléatoire d'un dictionnaire. La même coordonnée pourrait être résolue différemment après un lancement.

Le moteur de référence et le moteur de production trient désormais les candidats qui se chevauchent par superficie du polygone, ce qui permet à la caractéristique administrative la plus spécifique de gagner de manière déterministe. Ce n'est qu'après que les photos de référence 82,000 n'ont produit aucune différence, les chemins chauds et froids étant d'accord, que les raccourcis spatiaux sont devenus acceptables.

C'est l'avantage silencieux de l'ingénierie des performances avec les vérifications d'équivalence : cela peut révéler un problème de correction qu'un travail de temporisation normal ne verrait jamais.

Ce qui a changé dans les premières mesures.

Le test de charge initial a révélé plusieurs goulots d'étranglement partagés. La première passe d'optimisation a ajouté la détection de géométrie indexée, un cache géographique persistant, la résolution de lieux mémorisée, des instantanés partagés de photos et des mises à jour incrémentielles de l'annotation Atlas.

Sur le simulateur, la création initiale d'une carte photo 82,000 a été réduite de 34.5 secondes à 8.0 secondes. Une répétition courante après un changement de filtre ou lors de l'ouverture de "Lieux" est 2.8 secondes. La planification des constellations au niveau de la photo de 10,000 a échoué. 3.3 secondes à 0.9 secondes. Le temps de basculement des onglets a diminué de 31 %, et les erreurs du paginador Passport ont diminué de 47 %.

Le passage suivant a remplacé les analyses répétées de bandes de latitude SQLite par un index de ville la plus proche paresseux et trié par latitude et un cache d'enregistrements limité. Dans la simulation de la référence, un lot de ville la plus proche de taille moyenne est passé de 2.11 secondes à 5.2 millisecondes. Sur un iPhone physique, le même moteur partagé a échoué. 3.06 secondes à 6.35 millisecondes, tandis que la planification de constellations avec niveaux de stress a diminué de 5.60 secondes à 65.9 millisecondes.

Cette deuxième itération a également amélioré la dérivation de photos 82,000 de 7.96 secondes à environ 1.00 secondes. sur le simulateur, avec un démarrage à chaud de 984 millisecondes. Les gains ont été réalisés car la recherche de la ville la plus proche se trouve sous les imports, Then & Now, la dérivation de la carte et les constellations plutôt que d'appartenir à un seul écran.

Il s'agit de charges de travail de référence contrôlées, et non d'une promesse que chaque appareil ou bibliothèque produira le même nombre. Leur valeur réside dans la comparabilité : configurations fixes, état thermique enregistré, résultats établis et mécanismes qui peuvent détecter une régression significative.

Plus rapide car le travail est devenu plus réutilisable.

Les améliorations les plus importantes n'ont pas résulté de la suppression de fonctionnalités ou de l'ajout d'un indicateur de chargement. Elles ont résulté de l'arrêt du travail répétitif :

• La géométrie de la région réduit désormais les polygones candidats avant de procéder à des tests de points coûteux.
• Une cache géographique de cellules, liée à la compilation, mémorise les zones résolues à travers les exécutions.
• La recherche de la ville la plus proche utilise un index spatial numérique au lieu de reconstruire un tri de la base de données pour chaque coordonnée.
• Les interfaces basées sur des photos partagent une capture instantanée filtrée et immuable.
• Les épingles et les drapeaux de l'atlas sont mis à jour par identifiant plutôt que d'être supprimés et recréés.

Photo Explorer et Constellations bénéficient tous deux de cette même base. Cela s'applique également aux importations, Then & Now, aux cartes de données et aux histoires de lieux.

Le code de référence est exclu des archives de l'App Store, mais la pratique reste dans le dépôt : exécutez la suite autour des modifications apportées à un chemin critique, comparez-la à la ligne de base correcte et conservez le résultat. La performance est désormais quelque chose que le projet peut tester, et non seulement quelque chose qu'il peut espérer remarquer.

Les chiffres préservent également le travail inachevé. Une implémentation ultérieure de l'interface utilisateur pour les appareils physiques a atteint un état thermique critique et a tout de même enregistré un pic de mémoire important lors du changement d'onglet et presque une seconde de délai lors de l'ouverture de Constellations par rapport à la bibliothèque réelle. Ces lectures sont diagnostiques plutôt qu'une comparaison de régression propre, mais les conserver visibles est plus utile que de déclarer que l'application est « terminée ».

Ce que ces trois projets ont en commun.

Photo Explorer, Constellations et la suite de tests ont tous commencé avec la même contrainte : une vaste bibliothèque de photos devait devenir plus utile sans quitter l'appareil ni rendre le reste de l'application plus lente.

Photo Explorer transforme les métadonnées connues en questions et collections. Constellations transforme les signaux d'image représentatifs en un récit visuel. La suite de tests garantit que les deux fonctionnent avec les mêmes moteurs sous-jacents.

La fonctionnalité est visible dans un résultat de recherche, un ciel étoilé et un effet de coupe. Le travail d'ingénierie est principalement visible dans ce qui ne se produit pas : un chargement n'attend pas que toutes les photos de 82,000 soient chargées, un filtre ne recrée pas cinq copies du même tableau, et un index spatial rapide ne modifie pas silencieusement la ville à laquelle appartient une photo.

C'est la direction que je souhaite donner aux travaux de performance dans Mapsake. La vitesse n'est pas une phase de nettoyage après des idées ambitieuses. C'est l'un des outils qui rendent ces idées sûres à conserver.

• Explorez l'explorateur de photos.
• Voir comment Constellations fonctionne.
• Créez une carte de voyage à partir des photos Apple.