Photo Explorer, Constellations y un Mapsake más rápido.

Una versión de nuevas funciones y una versión de ingeniería.

Esta actualización introduce dos de las experiencias de fotos más ambiciosas de Mapsake: Explorador de fotos, que hace que una gran biblioteca de mapas sea fácil de buscar, y Constelaciones, que descubre hilos visuales entre lugares distantes.

También incluye la función menos visible de la versión: un conjunto de referencia de rendimiento permanente. Este conjunto encontró inmediatamente las rutas compartidas más lentas, hizo que las correcciones fueran medibles y le dio a la aplicación una forma de detectar cuándo trabajos futuros las vuelven a ralentizar.

El resultado no es solo más funcionalidad. Mapsake es significativamente más rápido para convertir grandes bibliotecas de fotos en lugares, encontrar ciudades cercanas y planificar una constelación.

Photo Explorer busca en el registro de viajes, no en la galería de fotos.

Photo Explorer comienza con los metadatos compactos que Mapsake ya mantiene para las fotos cartografiadas. Esto incluye la ubicación, la fecha, la fuente, la cámara, las notas, la altitud, la velocidad, los favoritos, las capturas de pantalla, las ediciones y la organización agregada dentro de la aplicación.

El índice permanece en el dispositivo. Una búsqueda puede ser directa (Japón, 2024, iPhone, favoritos) o expresada de manera más natural, como "fotos favoritas de Italia el año pasado". La capa de consulta convierte el lenguaje admitido en un conjunto estructurado de filtros, mientras que el vocabulario determinista y la corrección de errores proporcionan una opción de respaldo confiable.

La búsqueda es solo una forma de acceder a la biblioteca. Las colecciones muestran grupos útiles sin necesidad de escribir; el área del mapa limita los resultados geográficamente; la línea de tiempo los agrupa por fecha; las búsquedas guardadas y recientes facilitan la repetición de preguntas. Los favoritos, las calificaciones, las etiquetas, las etiquetas y las notas se encuentran en un complemento local, por lo que organizar una foto no altera ni carga el archivo original.

La elección arquitectónica importante es que cada herramienta comparte la misma instantánea indexada. Las colecciones, la línea de tiempo, el mapa y la búsqueda de texto no reconstruyen cada vez un mundo de fotos 82,000 desde cero.

El índice se deriva, mientras que la organización personal es duradera.

Photo Explorer necesitaba dos tipos de almacenamiento con vidas útiles muy diferentes. Los campos de búsqueda como los nombres de los lugares, el año de captura, la cámara, la altitud y la fuente se pueden reconstruir a partir de los metadatos existentes de Mapsake. Un favorito, una nota privada, una calificación, una etiqueta o una etiqueta de color fueron escritos por una persona y no se pueden tratar como datos de caché desechables.

Mapsake guarda la organización creada por el usuario en un archivo secundario pequeño que se puede incluir en la copia de seguridad. El índice de búsqueda más grande se encuentra en la caché, no contiene bytes de imagen, se excluye de la copia de seguridad y se puede regenerar cada vez que cambia su esquema. Volver a escanear una biblioteca o borrar datos derivados no borra el trabajo que alguien ha dedicado a organizarla.

Esa división también hizo que las copias de seguridad fueran más honestas. Las copias de seguridad sin pérdidas en formato JSON y HTML pueden contener notas y organización, pero no se convierten silenciosamente en archivos de fotos. Las anotaciones de Apple Photos conservan un identificador de iCloud estable y tentativo para que una copia de seguridad restaurada pueda volver a conectar la copia local en otro dispositivo de Apple; los identificadores de activos de Immich ya son estables en su origen.

El primer entorno de pruebas completo produjo un índice comprimido de aproximadamente 12.4 MB para 82,000 fotos. Una compilación geográfica completa tardó 2.61 segundos en el simulador de desarrollo, una restauración posterior desde el disco tardó 1.20 segundos, la generación de colecciones tardó 126 milisegundos y el modelo de línea de tiempo diario tardó 211 milisegundos. Estos números asignaron un presupuesto propio a cada parte de la función en lugar de ocultar todo detrás de una medición genérica de "búsqueda".

Photo Explorer también explica por qué un elemento coincidió. Un resultado puede indicar que coincidió con Kioto, 2024, una cámara de iPhone, una nota privada o un filtro seleccionado. Esa pequeña línea es importante cuando una consulta combina lenguaje natural con varios controles exactos: el usuario nunca debe tener que adivinar lo que el motor de búsqueda quiso decir.

El lenguaje de búsqueda es una interfaz, no una licencia para improvisar.

Cada consulta admitida se convierte en última instancia en una estructura de filtro validada. La ruta directa reconoce lugares, fechas, fuentes, modelos de cámara, notas, favoritos, calificaciones, etiquetas, elevación, velocidad, capturas de pantalla y fotos editadas. Un corrector ortográfico limitado puede corregir palabras de intención y vocabulario indexado conocido, pero no reescribe notas privadas arbitrarias.

En los dispositivos que admiten los modelos de Foundation de Apple, el texto enviado también se puede interpretar en la misma estructura restringida. Solo la consulta y el año actual se proporcionan a ese modelo del sistema. Los píxeles de la foto, los índices de metadatos, las notas de ubicación y la organización personal nunca se proporcionan. Los rangos no válidos y los valores desconocidos se rechazan, y el analizador determinista sigue siendo la opción de respaldo.

La interfaz muestra la interpretación y ofrece un camino de regreso a las palabras originales. Este es un lugar donde la inteligencia solo es útil cuando permanece verificable. "Fotos a 3,000 metros del año pasado" deben sentirse conversacionales, pero aún así deben comportarse como un conjunto preciso de filtros.

Constellations busca repeticiones a través de la distancia.

"Then & Now" pregunta si alguien regresó al mismo lugar. "Constellations" pregunta casi lo contrario: ¿qué ideas visuales repitió en lugares distantes?

El índice local extrae un conjunto compacto de señales visuales y motivos de las fotos de viaje elegibles. El planificador busca características que sean distintivas de una imagen en lugar de simplemente comunes en todas partes, y luego conecta candidatos de diferentes destinos. Puertas, costas, siluetas, formas de montañas, colores, estaciones y composición pueden convertirse en el vocabulario de un hilo.

Estos hilos están organizados en un cielo tridimensional. El usuario puede orbitar a través de él, abrir una constelación, mantener o descartar una conexión y reproducir una película de corte de coincidencia en la que las fotos relacionadas se desvanecen de un lugar a otro. Las tarjetas de compartir y el reel utilizan los mismos datos de hilo guardados.

La extracción y la planificación se realizan en el dispositivo. Mapsake no envía una biblioteca de viajes a un servicio de análisis de imágenes. Los lotes en segundo plano pueden profundizar el índice con el tiempo sin que la primera ejecución espere a que se cargue toda la biblioteca.

El índice visual se diseñó para ser reajustado de forma económica.

Para cada entrada elegible, Mapsake realiza una pequeña decodificación de imagen y deriva varias señales: una huella de características de Vision, etiquetas de clasificación brutas, una paleta de colores compacta y una clase de luz estimada a partir de la ubicación, la hora y la elevación solar. La huella de características es una descripción numérica pequeña que se utiliza para la similitud; no es una copia de la imagen y no se puede mostrar como tal.

El índice almacena identificadores de clasificadores sin procesar en lugar de reemplazarlos de inmediato con motivos orientados al producto. Esta elección dio sus frutos durante las pruebas con bibliotecas reales. La primera lista de motivos incluía etiquetas que sonaban razonables, pero que en realidad no estaban presentes en la taxonomía admitida de Vision. Debido a que las etiquetas sin procesar aún estaban disponibles, la reconstrucción de "Torres y puentes", "Barcos y puertos" y grupos de motivos posteriores fue una evaluación rápida en lugar de otro escaneo de miles de elementos originales.

La indexación comienza con fotos representativas en lugar de leer estrictamente la biblioteca de las más nuevas a las más antiguas. Las fotos se agrupan en celdas de ubicación aproximadas y días de ubicación, con preferencia por imágenes estáticas útiles y espaciamiento entre ráfagas. El planificador luego recorre los lugares en rondas. Esto proporciona un amplio alcance geográfico en las primeras etapas, mientras que los procesos en segundo plano agregan gradualmente profundidad.

La primera versión eligió una foto por lugar en cada ronda. Los datos reales de los dispositivos revelaron la falla: la mayoría de los lugares permanecieron por debajo del mínimo de tres fotos utilizado por el motor de hilos, por lo que miles de activos indexados aún podrían no generar candidatos. La división de cada ronda en tres representantes hizo que el índice fuera útil antes sin aumentar su presupuesto total. Esto es precisamente por lo que tanto los entornos de prueba sintéticos como una biblioteca real y desordenada son importantes.

El extractor funciona en lotes seriales, realiza cambios de forma atómica, se pausa por presión térmica y omite la extracción en segundo plano en el modo de bajo consumo. Las miniaturas de Apple Fotos que ya están en el dispositivo se intentan primero; las imágenes que solo están en iCloud pueden esperar una pasada posterior con conexión de red. Immich utiliza la misma canalización visual que su cliente de miniaturas existente.

La similitud por sí sola no cuenta una historia.

Una distancia de función puede encontrar dos fotografías visualmente similares, pero Constellations está diseñado para encontrar una conexión entre lugares en lugar de un detector de duplicados. Las fotos candidatas deben pertenecer a destinos que estén a al menos 150 kilómetros de distancia. El motor también considera motivos distintivos, luz inusual, estación y rituales de calendario recurrentes antes de admitir una conexión.

“Distintivo” se convirtió en la parte difícil. Un modelo de puntuación temprano recompensaba las señales que existían en ambos lugares. En la biblioteca de desarrollo, esto produjo cientos de conexiones dominadas por la noche y las estaciones comunes. Esas señales eran técnicamente compartidas, pero no remotamente sorprendentes. El motor ahora evalúa la relevancia: una señal es importante cuando es inusualmente fuerte en ambos lugares en comparación con la biblioteca de la persona en su conjunto.

Eso cambió la pregunta de "¿Ambos lugares contienen fotos nocturnas?" a "¿Ambos lugares tienen una cantidad inusualmente alta de fotos nocturnas para esta biblioteca?" Las señales comunes se desvanecen en el fondo, mientras que las tomas repetidas durante la "hora azul", las vistas de puertas, los puertos, la luz de invierno o una semana festiva recurrente pueden volverse significativas.

Los candidatos visuales utilizan varios representantes por lugar en lugar de un único par aleatorio. Los identificadores de hilo se derivan de su ubicación y familia, por lo que la misma conexión conserva su identidad después de una reevaluación. El estado 'guardado', 'rechazado' y 'visto' se mantiene, y un hilo rechazado no reaparece simplemente porque el motor se ejecutó nuevamente.

El diseño del cielo también se precalcula y es determinista. Las posiciones geográficas definen los nodos, la fuerza de la conexión atrae los lugares conectados entre sí, y un pequeño jitter aleatorio evita las superposiciones exactas. La interfaz en vivo puede animar entre una geografía tipo globo y la constelación terminada con un solo valor de transición; no ejecuta una simulación de física que consume mucha batería cada fotograma.

El corte de película utiliza la atención de saliencia de Vision para colocar el movimiento suave de la cámara alrededor de la parte importante de cada ejemplo. Una puerta se desvanece hacia otra puerta en lugar de alinear ciegamente dos centros de imagen. "Reduce Motion" elimina el movimiento de deriva y acorta la transición, mientras que un recorte central es el método de respaldo elegante cuando la saliencia no está disponible.

¿Por qué crear un conjunto de pruebas ahora?

El rendimiento de una biblioteca grande había llegado a un punto en el que la intuición ya no era suficiente. Un cambio podría hacer que una pantalla se sienta más rápida, mientras que silenciosamente ralentiza las importaciones, los recuerdos o las constelaciones, porque todos dependen de los mismos procesos geográficos y de fotos.

El nuevo conjunto tiene dos carriles:

• Un motor de lógica ejecuta pruebas de funciones deterministas en arreglos pequeños, medianos y de estrés, incluido un nivel de foto 82,000 basado en el informe del mundo real más grande disponible durante el desarrollo.
• Una capa de la interfaz de usuario muestra pantallas representativas, mientras que la instrumentación de rendimiento propia de Mapsake registra el tiempo de ejecución, los problemas y la memoria.

Los puntos de referencia utilizan la optimización de la versión de lanzamiento con la capacidad de prueba habilitada. Las compilaciones de depuración se excluyen intencionalmente porque Swift no optimizado produce números que no son relevantes para la aplicación publicada. Los resultados del simulador y del dispositivo físico también mantienen líneas de base separadas para que el hardware diferente no se compare como si fuera el mismo entorno.

El paquete cubre el gazetario, la geometría del mapa, las importaciones, los metadatos de las fotos, los logros, Passport, Amigos, copias de seguridad, sellos, constelaciones, recuerdos y el Explorador de fotos. Las redes en vivo, la calidad de la cámara, la enumeración del sistema de fotos y CloudKit siguen siendo pruebas de integración porque pretender que estas entradas son deterministas haría que los resultados fueran menos honestos.

Un punto de referencia puede estar equivocadamente seguro

La creación del conjunto requirió más esfuerzo que simplemente integrar un cronómetro en el código de la aplicación. El primer entorno de pruebas utilizó una función hash simple para seleccionar las coordenadas; Swift aleatoriza deliberadamente esta función hash entre los procesos, lo que cambia la geometría de aproximadamente 30 por ciento de una ejecución a otra. Los entornos de pruebas ahora utilizan un generador fijo, y la suite valida la forma generada antes de aceptar un resultado.

Un escenario temprano llamado import.merge midió nuevas inserciones. La ruta de producción que se suponía que debía representar era una fusión idempotente en un atlas existente. El punto de referencia fue rápido y repetible, pero estaba probando lo incorrecto. Corregir la configuración cambió la línea de base antes de intentar cualquier optimización.

Las mediciones de la interfaz de usuario tenían una trampa similar. Los contadores de rendimiento se acumulaban desde el inicio, por lo que un gesto de pestaña podía heredar retrasos de la animación de inicio y parecer más lento de lo que era. Ahora, cada interacción borra su instantánea previa al gesto y luego procesa solo el trabajo dentro del contexto de ese escenario.

El entorno de ejecución registra el sistema operativo, el nivel de hardware, la versión, el estado térmico y el estado térmico. El resultado de una simulación nunca se prioriza sobre una línea de base del dispositivo. Las ejecuciones térmicas no nominales siguen siendo diagnósticos útiles, pero se anotan en lugar de fallar en una puerta de regresión. Una regresión debe exceder tanto un umbral relativo como un valor absoluto pequeño para que el ruido de milisegundos no se convierta en una emergencia falsa.

Estos detalles no son burocracia relacionada con la referencia. Son lo que hace que ese número sea valioso.

Los controles de corrección encontraron un error real en el mapa

La prueba más valiosa en la primera fase de rendimiento no midió la velocidad. Comparó la derivación de fotos a lugares optimizada con una referencia simple y congelada sobre coordenadas con muchos límites.

Esa protección falló antes de que la optimización hubiera cambiado ni siquiera el motor. Las fotos dentro de polígonos administrativos superpuestos (Berlín dentro de Brandeburgo, Seúl dentro de Gyeonggi y Kyiv dentro de su oblast circundante) podrían asignarse según el orden de iteración aleatorio de un diccionario. La misma coordenada podría resolverse de manera diferente después de un inicio.

Tanto el motor de referencia como el de producción ahora ordenan los candidatos superpuestos por área de polígono, lo que permite que la característica administrativa más específica gane de forma determinista. Solo después de que las fotos de referencia 82,000 produjeron cero diferencias, con rutas cálidas y frías de acuerdo, los atajos espaciales se volvieron aceptables.

Esta es la ventaja silenciosa de la ingeniería de rendimiento con verificaciones de equivalencia: puede descubrir un problema de corrección que un trabajo de temporización normal nunca vería.

¿Qué cambió en las primeras mediciones?

La prueba de estrés inicial reveló varios cuellos de botella compartidos. La primera optimización agregó la detección de geometría indexada, un caché persistente de celdas geográficas, la resolución de lugares memorizada, instantáneas compartidas de fotos y actualizaciones incrementales de Atlas.

En el simulador, la creación inicial de un mapa de foto de 82,000 se redujo de 34.5 segundos a 8.0 segundos. Una repetición común después de un cambio de filtro o al abrir "Lugares" es 2.8 segundos. La planificación de constelaciones en el nivel de foto de 10,000 falló. 3.3 segundos a 0.9 segundos. El tiempo de cambio de pestaña disminuyó en un 31 por ciento, y los errores del paginador de Passport disminuyeron en un 47 por ciento.

El siguiente paso reemplazó los escaneos repetidos de bandas de latitud de SQLite con un índice de ciudad más cercana perezoso y ordenado por latitud y un caché de registros limitado. En la simulación de la prueba de rendimiento, un lote de ciudad más cercana de tamaño medio pasó de 2.11 segundos a 5.2 milisegundos. En un iPhone físico, el mismo motor compartido falló. 3.06 segundos a 6.35 milisegundos, mientras que la planificación de constelaciones con niveles de estrés disminuyó de 5.60 segundos a 65.9 milisegundos.

Esa segunda iteración también impulsó la derivación de fotos 82,000 desde 7.96 segundos hasta aproximadamente 1.00 segundos. en el simulador, con un inicio en caliente de 984 milisegundos. Las mejoras se lograron porque la búsqueda de la ciudad más cercana se encuentra debajo de imports, Then & Now, la derivación de mapas y las constelaciones, en lugar de pertenecer a una sola pantalla.

Estas son cargas de trabajo de referencia controladas, no una promesa de que cada dispositivo o biblioteca producirá el mismo número. Su valor radica en la comparabilidad: configuraciones fijas, estado térmico registrado, resultados comprometidos y mecanismos que pueden detectar una regresión significativa.

Más rápido porque el trabajo se volvió más reutilizable.

Las mayores mejoras no surgieron de eliminar funciones o agregar un indicador de carga. Surgieron de detener el trabajo repetido:

• La geometría de la región ahora reduce los polígonos candidatos antes de realizar pruebas de puntos costosas.
• Una caché geográfica de celdas, vinculada a la compilación, recuerda las áreas resueltas a través de ejecuciones.
• La búsqueda de la ciudad más cercana utiliza un índice espacial numérico en lugar de reconstruir una clasificación de la base de datos para cada coordenada.
• Las interfaces impulsadas por fotos comparten una instantánea filtrada e inmutable.
• Los pines y banderas del atlas se actualizan por identificador en lugar de eliminar y recrear todo.

Photo Explorer y Constellations se benefician porque se basan en las mismas bases. Esto también se aplica a las importaciones, Then & Now, los mapas de datos y las historias de lugares.

El código de referencia se excluye de los archivos de la App Store, pero la práctica permanece en el repositorio: ejecute la suite alrededor de los cambios en una ruta crítica, compare con la línea de base correcta y mantenga el resultado. El rendimiento es ahora algo que el proyecto puede probar, no solo algo que puede esperar notar.

Los números también preservan el trabajo incompleto. Una posterior implementación de la interfaz de usuario para dispositivos físicos alcanzó un estado térmico crítico y aún registró un pico de memoria significativo al cambiar de pestaña y casi un segundo de retraso al abrir Constellations en comparación con la biblioteca real. Estas lecturas son diagnósticas, no una comparación de regresión limpia, pero mantenerlas visibles es más útil que declarar que la aplicación está "terminada".

¿Qué tienen en común estos tres proyectos?

Photo Explorer, Constellations y el conjunto de pruebas comenzaron con la misma restricción: una gran biblioteca de fotos debe ser más útil sin dejar el dispositivo ni hacer que el resto de la aplicación se sienta más lenta.

Photo Explorer convierte los metadatos conocidos en preguntas y colecciones. Constellations transforma señales de imagen representativas en una historia visual. El conjunto de pruebas garantiza que ambos funcionen con los mismos motores subyacentes.

La funcionalidad es visible en un resultado de búsqueda, un cielo estrellado y un corte de transición. El trabajo de ingeniería es visible principalmente en lo que no sucede: una carga no espera a que se carguen todas las fotos de 82,000, un filtro no vuelve a crear cinco copias del mismo array, y un índice espacial rápido no cambia silenciosamente la ciudad a la que pertenece una foto.

Esa es la dirección en la que quiero que se dirija el trabajo de rendimiento en Mapsake. La velocidad no es una fase de limpieza después de ideas ambiciosas. Es una de las herramientas que hacen que esas ideas sean seguras para mantenerse.

• Explore el Explorador de Fotos.
• Ver cómo funciona Constellations.
• Crea un mapa de viajes a partir de fotos de Apple.