Photo Explorer、Constellations、および高速化されたMapsake

機能リリースとエンジニアリングリリース。

このアップデートでは、Mapsakeの最も野心的な写真体験の2つが導入されます。 写真閲覧, は、大規模な地図ライブラリを検索可能にし、 星座, は、遠く離れた場所との間の視覚的なつながりを検出します。

また、リリースで最も目立たない機能である、パフォーマンスベンチマークスイートが含まれています。そのスイートは、最も遅い共有パスをすばやく特定し、修正を測定可能にし、将来の作業がそれらを再び遅くするかどうかをアプリが検出する方法を提供しました。

結果は、単に機能を追加するだけではありません。 Mapsake は、大規模な写真ライブラリを場所に変換したり、近くの都市を見つけたり、星座の空を計画したりするのに、大幅に高速です。

Photo Explorerは、カメラロールではなく、旅行記録を検索します。

Photo Explorerは、Mapsakeがすでにマッピングされた写真に対して保持しているコンパクトなメタデータから開始されます。これには、場所、日付、ソース、カメラ、メモ、標高、速度、お気に入り、スクリーンショット、編集、およびアプリ内で追加された整理が含まれます。

インデックスはデバイス上に保存されます。検索は、直接的（日本、2024、iPhone、お気に入り）なものと、「昨年からのイタリアのお気に入りの写真」のように、より自然な表現のいずれかで行うことができます。クエリレイヤーは、サポートされている言語を構造化されたフィルターのセットに変換し、決定論的な語彙とタイプミス修正により、信頼性の高い代替手段が提供されます。

検索は、ライブラリへのアクセス方法の一つです。コレクションは便利なグループを提供し、地図エリアは結果を地理的に絞り込み、タイムラインは日付でグループ化し、保存された検索や最近の検索は、同じ質問を繰り返す手間を省きます。お気に入り、評価、タグ、ラベル、メモは、ローカルの補助データとして保存されるため、写真の整理は、元のファイルを変更したりアップロードしたりすることなく行えます。

重要なアーキテクチャ上の選択は、すべてのツールが同じインデックス化されたスナップショットを共有することです。コレクション、タイムライン、地図、およびテキスト検索は、それぞれ82,000の写真の世界を最初から再構築するわけではありません。

インデックスは派生型であり、パーソナルな整理は永続的です。

Photo Explorerには、寿命が大きく異なる2種類のストレージが必要でした。場所の名前、キャプチャ年、カメラ、標高、およびソースなどの検索フィールドは、Mapsakeの既存のメタデータから再構築できます。お気に入り、プライベートノート、評価、タグ、またはカラーラベルは、ユーザーによって記述されたものであり、使い捨てのキャッシュデータとして扱うことはできません。

したがって、Mapsake は、ユーザーが作成した組織を小さなバックアップ対象のサイドカーに保持します。より大きな検索インデックスは、キャッシュに保存され、画像バイトは含まれておらず、バックアップから除外され、スキーマが変更されるたびに再生成できます。ライブラリを再スキャンするか、派生データをクリアしても、誰かが整理に費やした作業は消えません。

その区別により、バックアップがより正確になりました。非圧縮のJSONとHTMLのバックアップは、メモと整理を保持できますが、写真アーカイブに静かに膨らむことはありません。Apple Photosのアノテーションは、iCloudの識別子を可能な限り保持するため、復元されたバックアップは、別のAppleデバイス上のローカルコピーに再接続できます。Immichのアセット識別子は、ソースで既に安定しています。

最初のフルストレステストでは、約12.4 MBの圧縮されたインデックスが82,000枚の写真に対して生成されました。開発シミュレーターでの最初の地理的ビルドには2.61秒、ディスクからの後の復元には1.20秒、コレクションの生成には126ミリ秒、そして日次のタイムラインモデルには211ミリ秒かかりました。これらの数値は、機能の各部分に独自の予算を与え、すべてを1つの一般的な「検索」測定値に隠すのではなく、個別に管理できるようにしました。

Photo Explorerは、一致した理由を説明します。結果は、京都、2024、iPhoneカメラ、プライベートノート、または選択されたフィルターに一致したことを示す場合があります。この小さな情報は、自然言語といくつかの正確なコントロールを組み合わせたクエリを使用する場合に重要です。ユーザーは、検索エンジンが何を意味していたかを推測する必要はありません。

検索言語は、インターフェースであり、自由に操作できるライセンスではありません。

すべてのサポートされているクエリは、最終的に検証されたフィルター構造になります。直接的なパスは、場所、日付、ソース、カメラモデル、メモ、お気に入り、評価、タグ、標高、速度、スクリーンショット、および編集された写真などを認識します。境界付きのスペルチェッカーは、意図された単語や既知のインデックス化された語彙を修正できますが、任意のプライベートメモを書き換えることはありません。

AppleのオンデバイスFoundationモデルをサポートするデバイスでは、送信されたテキストも、同様の制約された構造で解釈できます。提供されるのは、クエリと現在の年のみです。写真のピクセル、メタデータインデックス、場所に関するメモ、および個人的な整理は一切提供されません。無効な範囲と不明な値は拒否され、決定論的なパーサーが代替手段として使用されます。

インターフェースは、解釈を表示し、元の単語に戻る方法を提供します。この場所では、賢さがあるのは、検査可能である場合にのみ役立ちます。「昨年から3,000メートル以上の写真」は、会話的に感じられるべきですが、正確なフィルターのセットとして機能する必要があります。

Constellationsは、距離を越えた繰り返しを検出します。

「Then & Now」は、ある人が同じ場所に戻ったかどうかを調べます。一方、「Constellations」は、ほぼ逆の質問をします。それは、遠く離れた場所で、どのような視覚的なアイデアが繰り返されたか、ということです。

オンデバイスのインデックスは、対象となる旅行写真から、コンパクトな視覚信号とモチーフを抽出します。プランナーは、単にどこにでも共通する特徴ではなく、特定の画像に特有の特徴を探し、異なる目的地間で候補を結びつけます。ドア、海岸線、スカイライン、山脈の形、色、季節、構図などが、スレッドの語彙になる可能性があります。

そのスレッドは、三次元の空に配置されています。ユーザーは、その中を周回したり、星座を開いたり、接続を維持または破棄したり、関連する写真が場所から場所へと溶けていくマッチカットフィルムを再生したりできます。共有カードとリールは、同じ保存されたスレッドデータを使用します。

抽出と計画の作業は、デバイス上で行われます。 Mapsakeは、旅行ライブラリを画像分析サービスに送信しません。 バックグラウンドバッチは、最初の起動時にライブラリ全体を待たずに、時間の経過とともにインデックスを深めることができます。

視覚的なインデックスは、安価に再調整できるように設計されています。

各対象ユーザーに対して、Mapsakeは小さな画像デコードを実行し、いくつかの情報を取得します。これには、Vision特徴量、生の分類器ラベル、コンパクトなカラーパレット、および場所、時間、太陽高度から推定される光の種類が含まれます。 特徴量は、類似性を判断するための小さな数値データであり、画像のコピーではありません。表示することはできません。

インデックスは、製品向けのモチーフにすぐに置き換えるのではなく、生の分類器識別子を保存します。この選択は、実際のライブラリのテスト中に効果を発揮しました。最初のモチーフリストには、妥当に聞こえるラベルが含まれていましたが、実際にはVisionのサポートされている分類体系には存在しませんでした。生のラベルがまだ利用可能であったため、「タワーと橋」、「ボートと港」などのモチーフグループを再構築するには、数千ものオリジナルファイルを再度スキャンするよりも、高速なスコアリング処理で十分でした。

インデックス作成は、最新から順にライブラリ全体を読み込むのではなく、代表的な写真から開始されます。写真は、おおよその場所セルと場所ごとの日付にグループ化され、有用な静止画を優先し、バースト間の間隔を空けます。プランナーは、場所をラウンドで移動します。これにより、若いインデックスは地理的な広がりを持ち、バックグラウンドのバッチ処理によって徐々に深みを加えます。

最初のバージョンでは、各場所につき1枚の写真を選択していました。実際のデバイスデータから、ほとんどの場所がスレッドエンジンで使用する3枚の最小写真数よりも少ないことがわかりました。そのため、インデックスされたアセットが数千枚あっても、候補が見つからないことがありました。各ラウンドを3つの代表的な写真に分割することで、インデックスがより早く役立つようになり、その総予算は増加しませんでした。これは、合成のテストと、実際の、複雑なライブラリの両方が重要であることの明確な理由です。

エクストラクターは、シリアルバッチで動作し、進捗状況をアトミックにコミットし、サーマル圧力のために一時停止し、低電力モードではバックグラウンド抽出をスキップします。 デバイスにすでに存在するApple Photosのサムネイルが最初に試され、iCloudでのみ利用可能な画像は、後でネットワーク接続が許可されたときに処理されます。 Immichは、既存のサムネイルクライアントを介して、同じ視覚パイプラインを使用します。

類似性だけでは物語は語れません。

機能による距離の測定は、視覚的に類似した写真を2枚見つけることができますが、Constellationsは、場所間のつながりを見つけることを目的としており、重複検出ツールではありません。候補となる写真は、少なくとも150キロメートル離れた場所にある必要があります。エンジンは、特徴的なモチーフ、異常な光、季節、および繰り返されるカレンダーの儀式も考慮してから、関連性を認めます。

「特徴的」であることが最も難しい部分になりました。初期の評価モデルでは、両方の場所で存在する要素が重視されました。開発ライブラリでは、これにより数百の関連性が生まれましたが、そのほとんどは夜間や一般的な季節に関連していました。これらの要素は技術的には共有されていましたが、驚くほどではありませんでした。エンジンは現在、相違点に着目します。要素は、個人のライブラリ全体と比較して、両方の場所で異常に強い場合に重要であると判断されます。

それにより、質問は「両方の場所に夜の写真が含まれているか？」から「両方の場所がこのライブラリにとって異常に夜が多いか？」へと変わりました。一般的な信号は背景に溶け込みますが、繰り返しのブルーアワー、ドアの形、港、冬の光、または特定の祝日の週は、意味を持つ可能性があります。

視覚的な候補は、各場所に複数の代表的な場所を使用し、単一の「幸運なペア」を使用するものではありません。スレッド識別子は、場所と家族から派生するため、再評価後も同じ接続は識別子を維持します。保持、却下、および閲覧状態は、調整後も維持されるため、エンジンが再実行されたとしても、却下されたスレッドは再表示されません。

天空のレイアウトも、事前に計算され、決定論的です。地理的な位置がノードを生成し、関連する場所が互いに引き寄せられ、小さなランダムなジッターにより、正確な重複が防止されます。ライブインターフェースは、球体のような地理と完成した星座の間で、1つのトランジション値でアニメーションできます。バッテリーを消費する物理シミュレーションを、すべてのフレームで実行するわけではありません。

マッチカットシネマは、Visionの注意サリエンシーを使用して、各例の重要な部分の周りのカメラの動きを調整します。ドアウェイが別のドアウェイに溶け込むため、画像中心を単純に一致させるわけではありません。Reduce Motionは、ドリフトする動きをなくし、トランジションを短縮します。サリエンシーが利用できない場合は、画面中央のクロップがエレガントな代替手段となります。

なぜ、今こそベンチマークスイートを構築するのか?

大規模なライブラリのパフォーマンスは、直感だけでは対応できないレベルに達しました。変更によって、ある画面の表示速度が向上する一方で、インポート、思い出、コンステレーションの処理速度が低下する可能性があります。なぜなら、これらはすべて同じ地理情報および写真処理パイプラインに依存しているからです。

新しいスイートには、2つのレーンがあります。

• ロジックレーンは、開発中に利用可能な最大の実世界レポートに基づいて、82,000の写真を含む、小規模、中規模、およびストレステストの環境で、機能エンジンを厳密にテストします。
• ユーザーインターフェースのレイアウトは、代表的な画面を表示し、Mapsake 独自のパフォーマンス測定ツールは、操作時間、問題点、およびメモリ使用量を記録します。

ベンチマークは、テスト機能を有効にしたリリース最適化を使用します。デバッグビルドは、最適化されていないSwiftが、出荷されたアプリに関連性のない数値を生み出すため、意図的に除外されています。シミュレーターと物理デバイスの結果も、異なるハードウェアを同じ環境として比較しないように、個別のベースラインを保持します。

このスイートには、地理情報、地図の形状、インポート、写真のメタデータ、実績、Passport、Friends、バックアップ、スタンプ、Constellations、思い出、およびPhoto Explorerが含まれます。ライブネットワーク、カメラの品質、システムの写真の列挙、およびCloudKitは、これらの入力が決定論的であると仮定すると結果が不正確になるため、統合テストとして残っています。

ベンチマークは、誤っている可能性が高いです。

このアプリケーションスイートの開発には、ストップウォッチでアプリのコードを計測するよりも多くの時間が必要でした。最初のテスト環境では、座標を選択するために通常のハッシュ関数が使用されていましたが、Swiftはプロセス間でそのハッシュを意図的にランダム化し、実行ごとに幾何学的な処理が約30%変化します。現在、テスト環境では固定ジェネレーターを使用しており、スイートは結果を受け入れる前に生成された形状を検証します。

以前のシナリオでは、import.mergeという名前で、新しいデータの追加を測定していました。これは、既存の地図への変更を安全に行うという目的で設計されました。ベンチマークは高速で再現可能でしたが、テストしていたものが間違っていました。この問題を修正したことで、最適化を試みる前に、基準値が変更されました。

UIの測定には同様の落とし穴がありました。パフォーマンスカウンターは起動時から累積されるため、タブジェスチャーは起動アニメーションの遅延を継承し、実際よりも遅く見えることがあります。各操作は、ジェスチャー前のスナップショットをフラッシュし、次に、そのシナリオ自身のコンテキスト内でのみ処理を行います。

動作環境、オペレーティングシステム、ハードウェア構成、ビルド、およびサーマル状態を記録します。シミュレーションの結果は、デバイスの基準値よりも優先されません。非標準のサーマル状態での実行は、依然として有用な診断情報を提供しますが、回帰テストの失敗とは見なされず、代わりに注釈が追加されます。回帰テストは、相対的な閾値と小さな絶対的な下限の両方を満たす必要があります。これにより、亜ミリ秒単位のノイズが誤ったエラーとして検出されるのを防ぎます。

これらの詳細情報は、基準となる数値の価値を理解するための官僚的な手続きではありません。これらは、行動を起こす価値のある数値を作り出すものです。

正確性のチェック機能が、実際の地図のバグを発見しました。

最初のパフォーマンスパスで最も重要なテストは、速度を測定するものではありませんでした。最適化された写真から場所への導出を、境界線が密集した座標で意図的に単純化された参照と比較しました。

その保護機能は、最適化がエンジンを変更する前に失敗しました。重なり合う行政区分内の写真（ベルリンがブランデンブルク内、ソウルが京畿道内、キーウ市が周辺のオブラスト内）は、辞書のランダムな反復順序に従って割り当てられる可能性があります。同じ座標が、起動ごとに異なる結果になる可能性があります。

参照エンジンと本番エンジンはどちらも、重なり合う候補をポリゴン面積順に並べ、最も具体的な行政地物が決定論的に選ばれるようにしています。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 ミリ秒.

その2回目の処理により、82,000の写真のコールドデリベレーションが、7.96秒から約～秒に短縮されました。 1.00 秒 シミュレーターでは、984ミリ秒のウォームアップ時間があります。利点が発生したのは、最寄りの都市の検索が、インポート、Then & Now、地図作成、およびConstellationsの下に配置されているためで、単一の画面に属していないからです。

これらは、制御されたベンチマークワークロードであり、すべてのデバイスまたはライブラリが同じ数値を生成することを約束するものではありません。その価値は、固定された構成、記録された熱状態、コミットされた結果、および意味のある回帰をフラグを設定できるゲートです。

作業の再利用性が向上したため、高速化されました。

最も大きな改善点は、機能の削除やローディングスピナーの追加ではなく、繰り返しの作業を停止することから得られました。

• 地域ジオメトリは、高価なポイントテストの前に、候補となるポリゴンを絞り込みます。
• ビルドキーで識別される地理的なセルキャッシュは、解決された領域を複数回の実行間で記憶します。
• 最寄りの都市の検索では、データベースのソートを毎回再構築する代わりに、数値空間インデックスを使用します。
• 写真ベースのインターフェースは、常に同じ、変更不可能な、フィルタリングされたスナップショットを共有します。
• アトラスのピンとフラグは、識別子に基づいて更新され、すべてを削除して再作成するわけではありません。

Photo ExplorerとConstellationsは、どちらもこれらの共通の基盤の上に構築されているため、恩恵を受けています。インポート、Then & Now、データマップ、およびプレイスストーリーも同様です。

ベンチマークコードは、App Store アーカイブから除外されていますが、リポジトリにはそのコードが残っています。ホットパスの変更時に、このテストスイートを実行し、正しいベースラインと比較し、結果を維持してください。パフォーマンスは、プロジェクトが期待できるものではなく、テストできるものになりました。

これらの数値は、未完成の作業も保持しています。物理デバイスのUIの次のパスでは、深刻な熱状態になり、まだ大きなタブサイクルによるメモリのピークと、実際のライブラリに対するConstellationsの開く際の約1秒の遅延が発生しました。これらの測定値は、診断的なものであり、クリーンな回帰比較ではありませんが、アプリが「完了」と宣言するよりも、これらの測定値を表示する方が役立ちます。

これらの3つのプロジェクトに共通する点。

Photo Explorer、Constellations、およびベンチマークスイートは、すべて同じ制約から始まりました。大規模な旅行ライブラリが、デバイスから離れることなく、アプリの他の部分が重くならないように、より便利になるべきです。

Photo Explorerは、既知のメタデータを質問とコレクションに変換します。Constellationsは、代表的な画像シグナルを視覚的なストーリーに変換します。ベンチマークスイートは、両方を共通の基盤エンジンに準拠させます。

この機能の作業は、検索結果、星空、およびカットマッチで確認できます。 エンジニアリングの作業は、主に何が起こらないかによって確認できます。起動はすべての82,000の写真のダウンロードを待機せず、フィルターは同じ配列の5つのコピーを再構築せず、高速な空間インデックスは、写真がどの都市に属するかを静かに変更しません。

それが、Mapsakeでパフォーマンスの作業を進めたい方向です。スピードは、野心的なアイデアの後に行われるクリーンアップ段階ではありません。それは、それらのアイデアを安全に維持するためのツールの一つです。

• 写真エクスプローラーを探索
• Constellations の仕組みを見る
• Apple Photosから旅行地図を作成します。