Photo Explorer, Constellations та швидша Mapsake

Випуск нової функції та випуск інженерних змін.

Це оновлення представляє два найамбітніші фотопроекти Mapsake: Перегляд фотографій,, який робить велику картографічну бібліотеку доступною для пошуку, і Сузір'я,, який виявляє візуальні зв'язки між віддаленими місцями.

Він також включає найменш помітну функцію у випуску: постійний набір для оцінки продуктивності. Цей набір негайно виявив найповільніші спільні шляхи, зробив виправлення вимірюваними та надав додатку спосіб виявляти, коли майбутня робота робить їх повільнішими.

Результат – це не просто розширені можливості. Mapsake значно швидше перетворює великі фотоархіви на місця, знаходить навколишні міста та планує зоряне сузір'я.

Photo Explorer шукає записи про подорожі, а не галерею камери.

Photo Explorer починається з компактних метаданих, які Mapsake вже зберігає для зіставлених фотографій. Це включає місцезнаходження, дату, джерело, камеру, нотатки, висоту, швидкість, улюблені, знімки екрана, редагування та організацію, додану в додатку.

Індекс зберігається на пристрої. Пошук може бути прямим (Японія, 2024, iPhone, улюблені) або сформульованим більш природно, наприклад: «улюблені фотографії з Італії минулого року». Шар запитів перетворює підтримувану мову на структурований набір фільтрів, а детермінований словник і виправлення друкарських помилок забезпечують надійний запасний варіант.

Пошук – це лише один із способів доступу до бібліотеки. Колекції дозволяють групувати корисні елементи без введення тексту; область карти обмежує результати географічно; часова шкала групує їх за датою; збережені та нещодавні пошуки дозволяють швидко повторювати запити. Улюблені, оцінки, теги, мітки та нотатки зберігаються в окремому файлі, тому організація фотографії не змінює та не завантажує вихідний файл.

Важливим архітектурним рішенням є те, що кожен інструмент використовує один і той самий індексований знімок. Колекції, часова шкала, карта та пошук за текстом не перестворюють кожен свій власний світ 82,000-фотографій з нуля.

Індекс є похідним, а персональна організація – постійною.

Photo Explorer потребував двох типів сховища з дуже різними термінами життя. Поля пошуку, такі як назви місць, рік зйомки, камера, висота та джерело, можуть бути відновлені з існуючих метаданих Mapsake. Улюблене, особиста нотатка, оцінка, тег або колірний ярлик були створені користувачем і не можуть розглядатися як дані кешу, які можна видалити.

Тому Mapsake зберігає створену користувачем організацію у невеликому файлі, який можна використовувати для резервного копіювання. Більший індекс пошуку знаходиться в кеші, не містить жодних байтів зображень, виключений з резервного копіювання та може бути перегенерований щоразу, коли змінюється його схема. Повторне сканування бібліотеки або очищення похідних даних не видаляє роботу, яку хтось виконав для організації.

Цей поділ також зробив резервні копії більш чесними. Резервні копії у форматі JSON та HTML можуть містити нотатки та організацію, але вони не перетворюються на величезні архіви фотографій. Анотації Apple Photos зберігають стабільний ідентифікатор iCloud, щоб відновлена резервна копія могла підключитися до локальної копії на іншому пристрої Apple; ідентифікатори ресурсів Immich вже є стабільними за замовчуванням.

Перший повний тест навантаження показав, що стиснутий індекс становить близько 12.4 МБ для 82,000 фотографій. Повне географічне збирання займало 2.61 секунди на емуляторі розробки, наступне завантаження з диска займало 1.20 секунди, створення колекцій займало 126 мілісекунд, а модель щоденної часової шкали займала 211 мілісекунд. Ці цифри дозволили встановити бюджет для кожної частини функції, а не приховувати все за одним загальним показником "пошуку".

Photo Explorer також пояснює, чому елемент відповідає запиту. Результат може вказувати на відповідність Кіото, 2024, камері iPhone, особистій нотатці або вибраному фільтру. Цей невеликий рядок важливий, коли запит поєднує природну мову з кількома точними параметрами: користувач ніколи не повинен гадати, що мав на увазі пошуковий двигун.

Мова пошуку – це інтерфейс, а не дозвіл на імпровізацію.

Кожен підтримуваний запит зрештою стає структурою перевіреної фільтрації. Прямий шлях розпізнає місця, дати, джерела, моделі камер, нотатки, улюблене, оцінки, теги, висоту, швидкість, скріншоти та відредаговані фотографії. Обмежений коректор правопису може виправляти слова, що виражають наміри, та відомі слова в індексі, але він не переписує довільні особисті нотатки.

На пристроях, що підтримують локальні моделі Foundation від Apple, введений текст також може бути інтерпретований у ту ж обмежену структуру. У цю систему передається лише запит і поточний рік. Пікселі фотографій, індекси метаданих, примітки про місцезнаходження та особиста організація ніколи не передаються. Недійсні діапазони та невідомі значення відхиляються, а детермінований парсер залишається резервним варіантом.

Інтерфейс показує інтерпретацію та пропонує спосіб повернутися до вихідних слів. Це місце, де кмітливість корисна лише тоді, коли її можна перевірити. «Фотографії вище 3,000 метрів від минулого року» повинні звучати розмовно, але при цьому повинні поводитися як точний набір фільтрів.

Constellations шукає повторення на великих відстанях.

«Then & Now» визначає, чи повернулася людина в те саме місце. «Constellations» ставить майже протилежне питання: які візуальні ідеї вона повторювала в різних місцях?

Вбудований індекс витягує компактний набір візуальних сигналів і мотивів із відповідних фотографій подорожей. Планувальник шукає особливості, які є унікальними для певного зображення, а не просто поширеними всюди, і пов'язує кандидати з різних місць. Двері, берегова лінія, горизонти, форми гір, кольори, пори року та композиція можуть стати словником для створення ланцюжка.

Ці потоки організовані у тривимірному просторі. Користувач може переміщатися в цьому просторі, відкривати сузір'я, зберігати або видаляти зв'язки та відтворювати фільм з переходом, в якому пов'язані фотографії перетікають з одного місця в інше. Карти для обміну та стрічки використовують ті самі збережені дані потоку.

Вилучення та планування виконуються на пристрої. Mapsake не надсилає бібліотеку подорожей на службу аналізу зображень. Фонові пакети можуть з часом поглиблювати індекс, не змушуючи перше відкриття чекати завантаження всієї бібліотеки.

Візуальний індекс був розроблений для швидкої перенастройки.

Для кожного відповідного користувача Mapsake виконує невелике декодування зображення та отримує кілька сигналів: відбиток Vision, необроблені мітки класифікатора, компактну палітру кольорів та клас освітлення, оцінений за місцезнаходженням, часом та висотою сонця. Відбиток – це невеликий числовий опис, який використовується для визначення подібності; це не копія зображення і не може бути відображена як така.

Індекс зберігає необроблені ідентифікатори класифікаторів, а не відразу замінює їх продуктовими мотивами. Цей вибір виявився корисним під час тестування реальної бібліотеки. У перший список мотивів були включені мітки, які звучали розумно, але фактично були відсутні в підтримуваній таксономії Vision. Оскільки необроблені мітки все ще були доступні, відновлення таких груп мотивів, як «Вежі та мости», «Човни та гавані», було швидким процесом, а не повторним скануванням тисяч оригіналів.

Індексація починається з репрезентативних фотографій, а не зі строгого читання бібліотеки від нових до старих. Фотографії групуються у наближені області та дні, з перевагою корисних нерухомих зображень і інтервалів між серіями. Потім планувальник переміщується по місцях послідовно. Це забезпечує широту географічного охоплення на ранніх етапах, а фонові пакети поступово додають глибину.

У першій версії для кожного місця вибиралася одна фотографія за раунд. Дані з реальних пристроїв показали проблему: у більшості місць було менше трьох фотографій, що використовується двигуном потоків, тому тисячі проіндексованих ресурсів все одно могли не давати результатів. Розбиття кожного раунду на три представницькі фотографії зробило індекс корисним швидше, не збільшуючи його загальний бюджет. Це саме те, чому синтетичні тести та реальна, складна бібліотека однаково важливі.

Програма вилучення працює послідовними пакетами, атомарно фіксує прогрес, призупиняється при перегріві та пропускає фонове вилучення в режимі енергозбереження. Спочатку використовуються мініатюри Apple Photos, які вже знаходяться на пристрої; зображення, доступні лише через iCloud, можуть бути оброблені пізніше, коли буде доступне мережеве з'єднання. Immich використовує той самий візуальний ланцюжок через існуючий клієнт мініатюр.

Лише схожість не робить історію.

Функція визначення відстані може знайти дві візуально схожі фотографії, але Constellations призначена для пошуку зв'язку між місцями, а не для виявлення дублікатів. Кандидатські фотографії повинні знаходитися в місцях, розташованих не менше ніж на 150 кілометрів один від одного. Система також враховує характерні мотиви, незвичайне освітлення, сезон та повторювані календарні події, перш ніж встановити зв'язок.

«Визначні» характеристики виявилися найскладнішим аспектом. Рання модель оцінювання надавала перевагу ознакам, присутнім в обох місцях. У бібліотеці розробки це призводило до сотень зв'язків, переважно пов'язаних з нічним часом і звичайними сезонами. Ці ознаки були технічно загальними, але не викликали особливого здивування. Зараз двигун оцінює відмінності: ознака має значення, коли вона незвично сильна в обох місцях порівняно з загальною бібліотекою користувача.

Це змінило питання з «Чи містять обидва місця нічні фотографії?» на «Чи надмірно часто зустрічаються нічні фотографії в цій бібліотеці для обох місць?». Загальні сигнали зникають на фоні, тоді як повторювані кадри в «синій час», дверні отвори, гавані, зимове світло або повторювані святкові тижні можуть набути значення.

Візуальні кандидати використовують кілька представників для кожного місця, а не лише «щасливу пару». Ідентифікатори потоків виводяться на основі їхнього місцезнаходження та сім'ї, тому одне й те саме з'єднання зберігає свій ідентифікатор після повторної оцінки. Стани «збережено», «відхилено» та «переглянуто» зберігаються під час налаштування, і відхилений потік не з'явиться знову просто тому, що двигун був запущений повторно.

Розташування на небі також попередньо обчислюється та є детермінованим. Географічні позиції слугують початковими точками, сила зв'язків тягне пов'язані місця один до одного, а невеликий випадковий зсув запобігає точній відповідності. Живий інтерфейс може плавно переходити між географією, схожою на глобус, і сформованою сузір'ям, використовуючи одне значення переходу; він не виконує ресурсомістке фізичне моделювання щокадру.

Кінематографічний режим «Match Cut» використовує механізм уваги Vision для плавного переміщення камери навколо важливої частини кожного прикладу. Замість простого вирівнювання центрів зображень, двері розчиняються в інші двері. Режим «Reduce Motion» усуває тремтіння та скорочує час переходу, а центральне кадрування залишається елегантним запасним варіантом, коли інформація про увагу недоступна.

Чому зараз важливо створити набір для тестування?

Продуктивність при роботі з великими бібліотеками досягла такого рівня, що інтуїції вже недостатньо. Зміна може прискорити роботу одного екрану, але при цьому може сповільнити імпорт, створення спогадів або роботу з сузір'ями, оскільки все це залежить від однакових географічних та фото-пайплайнів.

Новий набір тестів включає два режими:

• Логічний модуль запускає детерміновані функціональні компоненти на невеликих, середніх і стресових збірках, включаючи рівень фотографій 82,000, заснований на найбільшому звіті з реального світу, доступному під час розробки.
• Інтерфейс відображає типові екрани, в той час як власні інструменти продуктивності Mapsake реєструють час виконання операцій, помилки та використання пам'яті.

Орієнтири використовують оптимізацію для випуску з увімкненим тестуванням. Збірки для налагодження навмисно виключаються, тому що неоптимізований Swift створює числа, які не мають відношення до випущеного додатку. Результати симулятора та фізичного пристрою також мають окремі базові показники, щоб різне обладнання не порівнювалося, як якщо б воно було одним і тим же середовищем.

Цей набір функцій включає довідник, геометрію карти, імпорт, метадані фотографій, досягнення, Passport, Friends, резервні копії, штампи, Constellations, спогади та Photo Explorer. Живі мережі, якість камери, системна перелічення фотографій і CloudKit залишаються інтеграційними тестами, оскільки припущення про детермінованість цих вхідних даних зробило б результати менш достовірними.

Результати бенчмаркінгу можуть бути помилковими.

Розробка цього набору додатків вимагала більше часу, ніж просто вимірювання коду програми за допомогою секундоміра. У першому тестовому середовищі для вибору координат використовувалася звичайна функція хешування; Swift навмисно рандомізує цю хеш-функцію між процесами, що призводить до зміни геометрії роботи приблизно на 30% від одного запуску до іншого. Зараз у тестовому середовищі використовується фіксований генератор, і набір перевіряє згенеровану форму перед прийняттям результату.

У одному з ранніх сценаріїв використовувалося назва import.merge для вимірювання кількості нових записів. Призначеним шляхом було безпечне злиття в існуючу карту. Тест був швидким і відтворюваним, але перевіряв не те. Виправлення тестових даних змінило базовий рівень до початку будь-яких оптимізацій.

У вимірюваннях інтерфейсу була подібна пастка. Лічильники продуктивності накопичувалися з моменту запуску, тому жест перемикання на вкладку міг успадкувати затримки від анімації запуску і здаватися повільнішим, ніж він є. Тепер кожен жест очищає свій попередній знімок, а потім виконує лише роботу в контексті цього сценарію.

Записує середовище виконання, операційну систему, рівень апаратного забезпечення, збірку та тепловий стан. Результати емуляції ніколи не мають пріоритет над базовими показниками пристрою. Нестандартні значення температури все одно корисні для діагностики, але вони позначаються, а не призводять до збою в процесі регресійного тестування. Регресійний тест повинен перевищувати як відносний поріг, так і невеликий абсолютний ліміт, щоб уникнути помилкових спрацювань через шум у наносекундах.

Ці деталі – не бюрократичні процедури, пов'язані з еталоном. Вони визначають цінність цього числа.

Система перевірки точності виявила помилку на карті.

Найважливіший тест у першому проході продуктивності не вимірював швидкість. Він порівнював оптимізоване перетворення фотографій на місцезнаходження з навмисно спрощеною еталонною версією з великою кількістю меж.

Цей захист не спрацював до того, як оптимізація змінила двигун. Фотографії, що знаходяться всередині перекриваючихся адміністративних полігонів (Берлін всередині Бранденбурга, Сеул всередині провінції Кьонгідо та Київ всередині навколишнього регіону), могли бути призначені відповідно до випадкового порядку ітерації словника. Одне й те саме місцезнаходження могло бути розпізнано по-різному після запуску.

І еталонний, і робочий рушій тепер сортують перекривні кандидати за площею полігона, щоб найконкретніший адміністративний об’єкт обирався детерміновано. Просторові оптимізації стали прийнятними лише після того, як 82,000 тестових фотографій дали нуль розбіжностей, а результати прогрітого й холодного шляхів збіглися.

Це прихована перевага інженерної оптимізації з перевірками на еквівалентність: вона може виявити проблему коректності, яку звичайна перевірка часу не виявить.

Які зміни відбулися з початковими одиницями вимірювання.

Початкове стрес-тестування виявило кілька загальних вузьких місць. Перший етап оптимізації додав індексоване тестування перетинів геометрії, постійний кеш географічних комірок, мемоізоване розв'язання місцезнаходження, знімки спільних фотографій і інкрементні оновлення анотацій Atlas.

У симуляторі час визначення місцезнаходження на карті для фотографії 82,000 зменшився з 34.5 секунди до 8.0 секунди.. Типовий шлях після зміни фільтра або відкриття «Місця» залишився незмінним. 2.8 секунди. Планування сузір'їв на рівні фотографій 10,000 знизилося. 3.3 секунди до 0.9 секунди. Час затримки перемикання між вкладками зменшився на 31%, а час затримки пейджера Passport зменшився на 47%.

На наступному етапі повторювані сканування смуг широти в SQLite були замінені лінивим індексом найближчого міста, відсортованим за широтою, та обмеженим кешем записів. У процесі тестування в симуляторі середній розмір пакета найближчих міст зменшився з... 2.11 секунди до 5.2 мілісекунд. На фізичному iPhone та сама загальна функціональність знизилася. 3.06 секунди до 6.35 мілісекунд,, в той час як планування сузір'їв за рівнями стресу знизилося. 5.60 секунди до 65.9 мілісекунд.

Це додаткове оброблення також прискорило процес отримання фотографій 82,000, приблизно з 7.96 секунд. 1.00 секунда у симуляторі є час попереднього завантаження 984 мілісекунд. Підвищення продуктивності відбулося тому, що пошук найближчого міста розташований нижче модулів імпорту, Then & Now, створення карт та Constellations, а не є частиною одного екрану.

Це контрольовані еталонні робочі навантаження, а не обіцянка, що кожне пристрій або бібліотека видаватиме однакову кількість. Їхня цінність полягає в порівнянності: фіксовані параметри, зафіксований тепловий стан, зафіксовані результати та механізми, які можуть вказувати на значне погіршення.

Працює швидше, тому що код став більш багаторазовим.

Найбільші покращення були досягнуті не шляхом видалення функцій або додавання індикатора завантаження. Вони були досягнуті шляхом припинення повторюваної роботи:

• Геометрія регіону тепер звужує кандидати полігони перед дорогими точковими тестами.
• Географічний кеш комірок, прив'язаний до збірки, запам'ятовує вирішені області між запусками.
• Пошук найближчого міста використовує числовий просторовий індекс замість повторного сортування бази даних для кожної координати.
• Інтерфейси, засновані на фотографіях, відображають один незмінний відфільтрований знімок.
• Закладки та прапорці на карті оновлюються за ідентифікатором, а не шляхом видалення та повторного створення всього.

Photo Explorer та Constellations отримують вигоду від того, що побудовані на одних і тих же фундаментальних технологіях. Це також стосується імпорту, функцій «Тоді та зараз», карт даних та історій про місця.

Код для тестування продуктивності виключено з архівів App Store, але він залишається в репозиторії: виконуйте цей набір тестів при кожній зміні критично важливих частин коду, порівнюйте результати з базовими значеннями та зберігайте результати. Тепер продуктивність – це те, що проєкт може тестувати, а не просто сподіватися помітити.

Ці числа також зберігають інформацію про незавершену роботу. На наступному етапі, під час тестування користувацького інтерфейсу на реальному пристрої, були виявлені серйозні проблеми з перегрівом, а також великий пік використання пам'яті при перемиканні між вкладками та майже секунда затримки при відкритті Constellations у реальній бібліотеці. Ці дані є діагностичними, а не результатом чистого порівняння продуктивності, але їх відображення корисніше, ніж оголошення програми «готовою».

Що об'єднує ці три проєкти.

Photo Explorer, Constellations та набір тестів починалися з одного й того ж обмеження: велика бібліотека подорожей повинна бути більш корисною, не покидаючи пристрій і не уповільнюючи роботу решти програми.

Photo Explorer перетворює відомі метадані на запитання та колекції. Constellations перетворює репрезентативні сигнали зображень на візуальну історію. Набір тестів забезпечує відповідність обом компонентам спільним базовим механізмам.

Робота над цією функцією видно в результаті пошуку, зоряному небі та сквозному переході. Інженерна робота видно в основному в тому, чого не відбувається: запуск не чекає завантаження всіх фотографій 82,000, фільтр не створює п'ять копій одного й того ж масиву, а швидкий просторовий індекс не змінює тихо, до якого міста належить фотографія.

Це напрямок, в якому я хочу, щоб розвивалася робота з підвищення продуктивності в Mapsake. Швидкість – це не етап очищення після амбітних ідей. Це один із інструментів, який робить ці ідеї безпечними для збереження.

• Дослідіть переглядач фотографій
• Дізнайтеся, як працює Constellations
• Створіть карту подорожей з Apple Photos.