Immich 3.0
(github.com/immich-app)- Immich v3.0.0 は、数か月にわたる作業を経て公開された次のメジャーリリースで、モバイルでの非破壊編集、ワークフローのプレビュー、バックグラウンドバックアップの改善、整合性チェック、リアルタイム動画トランスコーディングのプレビューなどを含む
- 今回のリリースには Breaking changes があるが、その多くは Immich API エンドポイントの変更であり、主に Immich API と統合するサードパーティツールに影響する。ほとんどのユーザーは従来どおり更新できる
- アップグレードは
.envの IMMICH_VERSION をv2からv3に変更したうえでdocker compose pull && docker compose up -dを実行する。v3.0.0 は pgvecto.rs のサポートを終了したため、v1.133.0 以前の環境では VectorChord への移行が必要 - モバイルアプリは Web と同じ非破壊編集モデルを導入し、Android のバックグラウンドバックアップを周期的なジョブスケジューラで改善した。iOS では短いバックグラウンド実行時間の中で同期とアップロードを並列実行する
- リアルタイム動画トランスコーディングはまだ 実験的機能で、現在は Web アプリにのみ実装されている。モバイルアプリは実装中のため、既存のオフライントランスコードファイルを手動削除することは推奨されない
アップデートと互換性の変更
- Immich v3.0.0 は次のメジャーバージョンとして発表され、複数の Breaking changes を含む
- Breaking changes の多くは API エンドポイントの更新であり、主に Immich API と統合するサードパーティツールに影響する
- ほとんどのユーザーは従来と同じ方法で更新できる
- 完全な移行ガイドはリリース案内内で別リンクとして提供される
- v3.0.0 は pgvecto.rs のサポートを終了する
- v1.133.0 以前の Immich を実行しており、まだ移行していない場合は、先に VectorChord 移行を確認する必要がある
- 案内リンク: https://docs.immich.app/install/upgrading/#migrating-to-vectorchord
- 更新手順:
.envファイルでIMMICH_VERSION=v2をIMMICH_VERSION=v3に変更docker compose pull && docker compose up -dを実行
リリース候補と通知チャネル
- v3.0.0 は Immich が release candidate を初めて使用したリリース
- リリース候補はテスト済みだが正式リリースではないプレリリースで、最終リリース前に残ったバグを見つけて修正するために使われる
- Immich 内でリリース候補の通知を受け取りたい場合は、
Admin settings > Version checkでリリースチャネルをStableからRelease candidateに変更できる
モバイル編集とバックアップ改善
- モバイル非破壊編集は、v2.5.0 で Web に先に追加された画像編集機能の後続作業
- 従来のモバイル編集機能は、写真をその場で変更せず新しい asset を作成する別システムを使用していた
- v3.0.0 のモバイル編集機能は Web 版と同じ機能を提供し、元ファイルに手を加えずにトリミング、回転、画像調整ができる
- 編集は非破壊方式のため、後から再編集したり元に戻したりでき、モバイルで編集した後に Web で続けて調整できる
- 以前のモバイル編集実装で提供されていた一部機能は削除された
- 写真の色変更
- Live Photo 編集
- ローカル asset 編集
- 一部機能は今後のリリースで再提供する予定
- Android のバックグラウンドバックアップは 周期的なジョブスケジューラを使用し、より安定して動作する
- 以前は新しく撮影した写真に限定されていた
- 現在はライブラリ全体をバックグラウンドでアップロードできる
- Android のバックグラウンド実行制限により適合し、ジョブの整理やバッテリー最適化・通知設定の警告を扱う
- iOS のバックグラウンド更新ジョブは同期とアップロードを並列実行し、iOS が許可する短い時間内にアップロードが開始されるよう変更された
ワークフローのプレビュー
- Workflows は、ライブラリの動作を自動化する最初のプレビュー機能
- トリガー、フィルター、アクションをドラッグ＆ドロップビルダーでつなげて自動化を作成できる
- Web の
Utilities > Workflowsからアクセス可能 - 新しい空のワークフローを作成したり、事前に用意されたテンプレートを確認したりできる
- エディターは Visual editor と JSON editor を提供する
- Visual editor はワークフロー構成に適している
- JSON editor はワークフロー内容を他の人と共有したり受け取ったりするのに適している
- 各ワークフローは
triggerと一連のstepsで構成される- Trigger はワークフローのエントリーポイントで、トリガーが発生するとステップが評価される
- Steps は条件に相当する Filters と、効果に相当する Actions を含む
- 共有方式はテキストと JSON の2種類
- テキストはフォーラム共有やデモに適している
- JSON はワークフロー設定を正確に複製するのに適している
- 新しいトリガーやアクションのアイデアは、別の discussion thread でフィードバックを受け付けている
ライブラリ探索と整合性チェック
- Web とモバイルに Recently Added ページが追加された
- asset の撮影時点ではなく、Immich に追加された時点を基準にライブラリを表示できる
- 新しく取り込んだまとまりを探索するとき、何が新しく入ったのか見つけやすい
- Web では
Exploreタブ、モバイルではSearchタブで見つけられる
- メンテナンスページには integrity reports が追加された
- Immich がファイルシステム上のディレクトリをスキャンし、データベースに保存された情報と比較する
- Immich が把握していないファイルがディレクトリにある場合は
untrackedと表示される - データベースには参照があるが該当場所にファイルがない場合は
missingと表示される - ディスク上のファイルチェックサムが Immich が保存したチェックサムと異なる場合は
checksum mismatchと表示される
- チェックサム不一致は一般にファイル破損で発生することがあり、不適切な名前変更の結果である可能性もある
- 整合性チェックジョブは、毎晩いつ、どれくらいの時間実行するかを設定できる
動画とメディア再生
- モバイルアプリに Slideshow 機能が追加され、Web と同様に写真と動画を画面上で自動再生できる
- HLS とリアルタイム動画トランスコーディングがプレビュー機能として追加された
- オフライントランスコードを事前作成せず、動画の再生中に変換できる
- 手動・自動の品質切り替えをサポートする
- クライアントがサポートする最適なコーデックにトランスコードできる
- オフライントランスコーディングを無効にすると、ストレージ容量の負担を減らせる
- まだ実装されていない項目も明示されている
- 対応クライアント向け HDR
- 帯域幅が許す場合に、元ファイルをトランスコードせず remuxing すること
- リアルタイムトランスコーディングは 実験的で、バージョンごとに動作が変わる可能性がある
- 現在は Web アプリにのみ実装されており、モバイルアプリの実装は進行中
- 有効化は video transcoding settings で行える
- リアルタイムトランスコーディングを有効にしてもオフライントランスコーディングには直接影響しないため、オフライントランスコーディングをオフにするには transcode policy も調整する必要がある
- v3 以前に取り込んだ asset は、ジョブパネルで Metadata Extraction を再実行する必要がある
- サーバーはリアルタイムトランスコーディングを処理できるだけ十分に強力である必要があり、ハードウェアアクセラレーションは推奨されるが必須ではない
- Web アプリには Immich のデザインに合わせた新しいカスタム動画プレイヤーが追加された
- すべてのデバイスで同じコントロールとレイアウトを提供する
- 再生速度の変更など基本機能を提供する
- iOS で OS のコントロールが Immich のナビゲーションバーの背後に隠れる問題も解決できる
Android、OCR、共有とアルバムの流れ
- Android で Immich を ギャラリー/画像ビューアアプリのように使える
- 他のアプリで写真や動画をタップして Immich を選択すると、asset viewer で直接開く
- ファイル共有またはライブラリアップロードのオプションを提供する
- すでにライブラリ内にあるファイルを認識する方式は今後改善される予定
- モバイルの asset viewer には、写真内で認識されたテキストを強調表示する OCR トグルが追加された
- 画像内のテキストを選択してコピーできる
- モバイルアプリでローカル写真をアルバムに直接アップロードできる
- asset bottom sheet からもアルバムに直接追加できる
- 先にアップロードして後から整理する流れの摩擦を減らす
- モバイル共有時に、送信前に画像サイズを選択できる
- メッセージアプリ向けにファイルを小さく保てる
- 必要ならフル品質で共有することもできる
- デフォルト動作は
App Settings > Preferencesで変更可能 - 共有ボタンを長押しして、その場でオプションを選べる
- 1か月内に asset が多い場合のタイムライン探索性能が改善され、ブラウザタブが固まる状況を減らす
主な変更のまとまり
- Breaking changes には、
class-validatorから zod への移行、replace asset の削除、古い timeline sync エンドポイントの削除、pgvecto.rsサポート終了、エラーレスポンス構造の変更などが含まれる - Deprecated changes には、PUT ルートを PATCH に置き換える方向の deprecation が含まれる
- セキュリティ項目には、プロフィール写真を thumbnail pipeline に通す修正が含まれる
- 機能追加には、モバイル編集、Android periodic work manager task、カスタム Web 動画プレイヤー、recently added assets page、workflows & plugins、HLS リアルタイムトランスコーディング、モバイル OCR、整合性チェックジョブなどが含まれる
- バグ修正には、OAuth メールアドレスの正規化、zip に追加する前のファイル名整理、ロックされた asset のパートナーへの露出防止、不正な face 作成の修正、CLI アップロード時のメモリ不足防止などが含まれる
議論で確認された制約と回答
- v2.0.1 から v3.0.0 に上げる場合、別途特別な指示はなく、リリースノートの更新手順に従えばよいとの回答があった
- モバイル更新後にアルバムが見えない事例はモバイル側の移行バグと思われ、ログアウト後の再ログイン、またはサーバーを v3 に更新することで解決する可能性がある
- iPhone のバックアップ復元後、モバイルアプリでサーバー上の写真を再びローカルに受け取る流れについて、モバイルアプリにはまだ bulk download オプションがなく、個別写真のダウンロードのみ可能
- リアルタイムトランスコーディングを有効にした後に既存のトランスコード済み動画を削除する質問には、モバイルアプリがまだリアルタイムトランスコーディングをサポートしていないため既存のトランスコード済み動画が必要で、手動削除は推奨されないとの回答があった
- HEIC 写真をその場で JPG に変換する機能の計画はなく、現在生成されるサムネイルは JPEG/WEBP なので、すべてのブラウザとクライアントに対応しているとの回答があった
- Android バックグラウンドバックアップ改善は、100MB 以上の大型画像や Cloudflare 制限の問題を解決する変更ではなく、バックグラウンドジョブがより頻繁に周期実行されるようにする改善
- リアルタイムトランスコーディングでコーデックを選ぶのはサーバーではなくクライアントであり、サーバーが AV1 バリアントを広告すると、AV1 をデコード可能なクライアントがそちらを選ぶ可能性がある
- サーバーが広告するコーデックと解像度を選択する設定を追加する計画がある
- キャスティング改善は ToDo リストにあり、cast 全体を書き直してリアルタイムトランスコーディングも追加する必要があるとの回答があった
- アップグレード後に
No vector extension found. Available extensions: vchord, vectorエラーを投稿したユーザーは、その後解決したと残している - 新しいチェックサム不一致検査について、過去に Immich 外部でアップロード済み画像を編集したユーザーは数百件の checksum mismatch が発生する可能性があるため、チェックサム再計算で解決する機能が有用だという意見があった
- VectorChord 移行に関連し、v1.102 以前のユーザーは
DB_DATA_LOCATIONの opt-in 変更を見落としている可能性があるため、警告があるとよいという意見があった
支援とグッズ
- v3.0.0 リリースとあわせて新しい Immich グッズも案内された
- 子ども用衣類
- フルカラー刺繍の Immich ロゴ入り衣類
- グッズページ: https://immich.store
- プロジェクト支援は product key の購入またはグッズ購入で可能
- product key: https://buy.immich.app
- merchandise: https://immich.store
1件のコメント
Hacker Newsの意見
学部生に無料のソフトウェア開発授業を教えているのですが、授業課題として作ったものが実際のプロジェクトで見つかって本当に興奮しています。
最初に挙げられているバグ修正は、その学生が授業中にImmichへマージした3つのプルリクエストの最後のものなので、誇らしく思います。
コメントで暗号化の話が多いので、自分の構成を共有します。約1年半、Hetznerのオークションサーバーで家族と友人向けにImmichを運用してきました。
Hetznerコミュニティには公式のフルディスク暗号化ドキュメントがあります: https://community.hetzner.com/tutorials/install-debian-with-...
Letsencryptで無料SSLを使い、ImmichはSSLを処理するNginxプロキシの背後に簡単に隠せます。
cronベースの自動バックアップでImmichの全データをローカルの暗号化NASに保存すれば、信頼性があり、転送中と保存時の両方が暗号化された構成になります。これまでメンテナンスは正確に0回でした。
IPレベルで3つの地域以外のトラフィックを破棄しているのでより安全で、NginxプロキシにWAFを追加することもできます。
Google/iCloudよりも安全だと考える理由は、「会社の従業員」という攻撃ベクトルがずっと小さいからです。Googleが写真をのぞき見し、虚偽の警察通報まで進んで行う事例も文書化されています: https://www.eff.org/deeplinks/2022/08/googles-scans-private-...
もちろん理論上は、Hetznerの従業員がサーバーに物理アクセスしてRAMから暗号化キーを抽出したり、偽のSSHサーバーでキーを盗んだりすることは可能ですが、はるかに複雑で、まだ文書化されたことのない攻撃であり、検知されるリスクもあります。
この構成は転送中の暗号化と保存時の暗号化です。大手クラウドプロバイダーにとって保存時暗号化は相対的に重要度が低いかもしれません。彼らは大半の企業や個人よりもディスクのライフサイクル管理をうまく行っている可能性が高いからです。
誰かがデータセンターを物理的に襲ったり、適切に処理・消去されていないリファービッシュドライブを手に入れたりする可能性は低いでしょう。
マネージドプロバイダーより必ず安全だとも言いにくいです。あなたがセキュリティエンジニアではない可能性が高く、サーバーを保護するリソースもずっと少ないからです。
Google/iCloudがデータをスクレイピングすることは防げますが、Hetznerがデータにアクセスできないという意味ではありません。Hetznerはサーバー/VMを管理する上位のハイパーバイザーと制御プレーンを支配しているため、どんな機能が実装されているかは分かりません。
情報機関ができることの大半は、流出も公開文書化もされていません。
本物のエンドツーエンド暗号化なら、家族が使うクライアント側でディスク上の全データを暗号化しなければならず、ディスクボリュームを調べても暗号文だけが見えるはずです。
本当に素晴らしいソフトウェアで、Google Photosと同等です。ホームラボを始めてから数か月間、Tailscaleの背後に置いて使ってきましたが、まったく問題ありませんでした。
実はGoogle Photosの100GBストレージ制限に引っかかった後、Immichへ移行したことがセルフホスティングを始めるきっかけで、その過程は本当に楽しかったです。
この完成度のセルフホスティング製品が無料だなんて信じられません。同じ理由でHomeAssistant、PiHole、paperless-ngx、Dawarich、そして数多くのプロジェクトにも大きな拍手を送ります。
個人的な思い出を整理する手助けをしてくれたチームに、お祝いと感謝を送ります。
ここではエンドツーエンド暗号化がないというコメントが多いけど、正直なところ、なぜ必要なのか分からない
泥棒が入ってホームラボを盗んでいったとしよう。エンドツーエンド暗号化がないせいで、亡くなった祖母の写真を見られてしまうなんて、大変だ！
もっと起こりそうなのは、スマホに問題が起きるケースのほう。エンドツーエンド暗号化がなければ、鍵を失くしても祖母との最後の思い出まで失うわけではなく、
.jpgファイルを新しい端末にコピーすればいいただし、一般ユーザーにとってエンドツーエンド暗号化がもたらすアクセシビリティ上のトレードオフは悩ましい。この場合、鍵やパスワードを失くしたり忘れたりすると、非常に大切な写真を丸ごと失うことになり、かなり致命的
Google PhotosやiPhotosは、人々に写真が安全だという感覚を与えている
また、リモートサーバー/VPSのファイルシステムを暗号化しなくても、Immich用のクラウドインスタンスをホストしやすくなる。特に小規模な販売業者からサーバーを借りるときは、従業員のアクセス制御をどこまで信用できるのか常に慎重になる
物理アクセスがあればある程度の信頼は避けられないのは分かるが、メンテナンス中にディスクをどう扱うかも重要
そうなると、意味ベース検索、顔認識、動画のトランスコード、サムネイル生成といった機能はクライアント側に移す必要がある
Immichは、サーバーが写真にアクセスできると信頼する前提に立っている。セルフホスティングでは常にそういう構造になる
ほとんどのユーザーがGoogleやAppleにもそうした信頼を置いているのだから、合理的だと思う
本当のエンドツーエンド暗号化アーキテクチャなら、クラウドストレージ、マネージドホスティング、オフサイトバックアップをもっと柔軟に使えるようになる気がする
セルフホスティングなら、運用者がファイルにアクセスできないように防ぐ必要はない
今はデジタルで保管し、外部にバックアップできる。Immichに必要な変化はその程度で十分
すべてを完全に暗号化すると、むしろより多くの問題を招くことになる
iOSからGrapheneOSへ移行するにあたり写真をセルフホストすることにし、Immichも検討したが、暗号化の理由でEnteを選んだ
Ente Photosは非常に洗練されていて、Apple Photosに匹敵する品質
多くのエンドツーエンド暗号化プロジェクトのようにクライアントだけを公開するのではなく、サーバーも公開し、セルフホスティング可能な状態を保っている点が良い
アカウントなしでも誰でもアルバムに投稿できるよう共有でき、スマホを他人に渡すときに選択した写真だけが見えるようロックできる機能も気に入っている
セルフホスティング前提では、写真のアップロードすら安定してできない。何日も何もアップロードできなかったことがあり、診断情報もないので自分でビルドしてデバッグする必要があった
アプリを前面に出し、充電器につないだまま何時間も維持し、動画アップロードと機械学習機能をすべてオフにして写真だけに集中させてもそうだった
サーバー側は問題なく、Webアップロードも問題なく動くのに、アプリだけが駄目。まだ原因は分かっていない
つまり両方の形態が可能
https://github.com/ente/ente
もしかすると二要素認証の目的を弱めているのかもしれないが、時にはあまり気にしない
アプリは不要で、とても単純で、非常に安い。その後は写真のバックアップ/アーカイブサービスも使うようになった
見た目どおりのサービスなのでファンになった
ImmichはApple PhotosやGoogle Photosの代替としてあまりに自然な選択肢。TailscaleのようなVPNと併用すれば、ほぼそのまま置き換えられる
https://github.com/immich-app/immich/discussions/14365
定期的にアップデートし、簡単なルールに従い、CrowdSecのようなものを設定すればいい
Tailscaleのようなツールを使うほうが単純なのは分かるが、最近はそれ以外の選択肢をそもそも検討しない流れが見える
私の写真は
events -> year/month - holiday -> (album_1, ...)、home town -> year -> (album_1, ...)のように整理している写真は複数のアルバムに入ることができ、編集版もあり、採用/却下状態も追跡してフィルタリングする必要がある
まだImmichに移行できていない唯一の理由は、自分の写真整理のやり方をImmichの方式にきれいにマッピングするのに苦労しているから。これまでの試みは扱いづらかった
エンドツーエンド暗号化がないことよりも、もっと不満な点がある。Google PhotosやiCloudのような他サービスからのインポートを簡単にしていないが、これは優先事項であるべきだと思う
Immichはimmich-goプロジェクトに依存しているが、バグが多く、事実上放置されている状態
独自のiOSアプリもiCloudギャラリー同期に使えるが、約2年前から未解決のバグのせいでLive Motion写真のアップロードに失敗する
Immichにエクスポートした写真のうち約9000個が壊れているか、半分だけ取り込まれたLive Photosで、これを直す時間がない
これが優先事項ではないという事実が理解できない。最も徹底的にA/Bテストされるべき機能なのに
取り込んだ思い出を壊していないと信じられないなら、OCRに何の意味があるのかわからない
Google Photosの半分壊れたエクスポートを扱う作業が誰にとっても面白いとは思えないし、インポートの苦痛は一度経験してしまえば、もう掻くべきかゆみも消えてしまう
CephをバックエンドにしたImmichを設定し、immich-goですべてのメタデータとアルバムまで全部移した
並列化オプションを少し変える必要はあったが、それ以外はとても簡単だった
設定にものすごく時間をかけて一度使ったきり二度と使わないものも多いし、設定は簡単で毎日少しずつ恩恵をくれるものも多い
Immichは設定に時間がかかり、ごくまれにしか使わないが、年に一度使うたびにインストールしておいて本当に良かったと思うソフトウェアだ
毎週使っていて、ただ普通に動くので素晴らしい
記憶ではメジャーバージョン移行に関係していたかもしれない。その後、このスタックへの熱が冷めた
アップグレードは望むほど手軽な方式ではなく、今も大きくは変わっていないと思う
ただ馬鹿げたライブラリシステムの外でフォルダを整理したいだけなのに、当時のImmichはそのやり方ともあまり相性が良くなかった
iOSの写真同期が改善されたのか気になる。スマホに写真が2万枚あるが、最後に試したときはオリジナルでスマホのストレージがいっぱいになり、数日間同じローカルネットワーク上でスマホを開いてロック解除したままImmichアプリを前面で動かしても終わらなかった
作業中だというのは知っているが、追いかけてはいなかった。今はもっと良く動いて、再挑戦する価値があるのか知りたい
「iOSでバックグラウンド更新タスクが同期とアップロードを並列に実行するようになったため、iOSが許可する短い時間枠の中で実際にアップロードが開始される」
ただし、これがその問題を直すのかはわからない
オリジナルがダウンロードされたのか、その後自動的に削除されたのかは覚えていないが、全体の流れはスムーズに感じた
iOSはバックグラウンドアップロードでこれを簡単にはしてくれない。アプリを一晩中開きっぱなしにして、全部アップロードした
「モバイルアプリでアセットをアルバムに直接アップロード」がこの問題を直すものなのか気になる: https://github.com/immich-app/immich/discussions/12748
複数のデバイスと複数人で猫の写真を1つのアルバムに集めたいので、自分にとってはかなり大きな問題
現在はこのように構成する必要がある。Syncthingで写真をImmichをホストしているホームラボサーバーの
/mnt/Syncthing/a1/cats/、/mnt/Syncthing/a2/cats/、/mnt/Syncthing/b/cats/に同期するcronジョブで、写真を読み取り専用の外部ライブラリボリュームとしてマウントされた
/mnt/immich/ext-lib/cats/フォルダにハードリンクコピーするさらに別のcronジョブで、外部ライブラリのフォルダ構造からアルバムを自動生成するスクリプト https://github.com/Salvoxia/immich-folder-album-creator を実行する
最後に、スマホの空き容量確保のため、Syncthingフォルダから1年以上前の写真を整理するcronジョブを走らせる。全体で約1TBなので、問題はある
それでも3.0リリースはおめでとう。ただ、このプログラムを見つけたのが1か月前で、セルフホスティング構成を安定させたのが1週間前だったので、少し残念ではある