クラウドライブラリから移行した後に写真の重複を防ぐ方法

まず正規のエクスポートを1つだけインポートして重複写真を防ぎ、その後、完全一致するコピーと編集済みのバリエーションを分類してからスマートフォンのバックアップを有効にします。

クラウドライブラリの移行には、オリジナル、編集済みコピー、サイズ変更されたダウンロード、共有アルバム版、Live Photoの構成ファイル、メタデータのサイドカー、繰り返し作成されたエクスポートフォルダーが含まれていることがよくあります。セルフホスト型ギャラリーは、バイト単位で完全に一致する重複ファイルを拒否できても、圧縮率、寸法、メタデータ、ファイル名が異なる、見た目が同一のファイルを受け入れる場合があります。安全な手順では、稼働中のライブラリの外で移行を準備し、ハッシュと保存元フォルダーを記録して、管理された1つのバッチをインポートします。そのうえで、ギャラリーがバリエーションをどのように扱うかを確認してから、スマートフォンの自動バックアップを開始します。

同じ写真を含む可能性のあるすべての保存元を確認する

クラウドのエクスポートアーカイブ、スマートフォンのカメラロール、デスクトップの写真ライブラリ、共有アルバム、ダウンロードフォルダー、パートナーのライブラリ、古いNASフォルダー、ギャラリーにマウントされている外部ライブラリを一覧にします。各保存元の対象期間とファイル数を記録してください。

重複は、クラウド上のコピーをインポートした後、スマートフォンがローカルのオリジナルをアップロードすることで発生しがちです。Immichのディスカッションでは、Googleフォトとモバイルバックアップによって見かけ上の重複が生じた事例が説明されています。クラウド版が圧縮されていた一方で、スマートフォンからは異なるフル解像度のファイルが提供されたためです。

オリジナルの正規の保存元を決めます。最初のインポート中は、他の保存元をオフラインにしておき、重複で埋め尽くされたタイムラインを削除対象の判断環境にしないようにします。

完全一致する重複と見た目の似たバリエーションを分ける

インポート前にファイルの暗号学的ハッシュを生成します。ハッシュが一致すればバイト単位で同一であることを示します。一方、ハッシュが異なる場合は、編集、再圧縮、メタデータの変更、サイズ変更されたエクスポート、モーションフォトの構成ファイル、または実際に異なる撮影データである可能性があります。

Immichの移行ユーザーは、外部ライブラリからの転送では、APIアップロードと同じ重複チェックが行われない場合があるため、インポート前のハッシュ確認を実施しています。報告された方法は、コピー前にハッシュを比較するというものです。

サムネイルで似て見えるという理由だけで、ファイルを自動的に削除しないでください。高解像度のオリジナル、意図した編集版、モーション構成ファイル、メタデータのサイドカーは、ギャラリーの外で比較するまで保持します。

オリジナルを書き換えずにエクスポートフォルダーの構成を整理する

すべてのクラウドアーカイブをステージングディレクトリに展開し、繰り返されたアーカイブの分割、「original」や「edited」のサフィックス、JSONサイドカー、アルバム内の重複、複数のエクスポートパッケージに分割されたファイルを確認します。

最初のインベントリ作成中は、ファイル名とタイムスタンプを変更しないでください。ハッシュを生成する前に名前変更、再エンコード、メタデータの書き換えを行うと、完全一致する重複が異なるバイトのファイルに変わり、ギャラリーが自動的に識別できなくなる可能性があります。

保存元アーカイブ、元の相対パス、ファイル名、ハッシュ、サイズ、寸法、撮影時刻、サイドカーのパスを含むマニフェストを作成します。これにより、その後の削除をすべて元に戻せるようになり、似た2つのアセットがライブラリに入った理由も説明できます。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

まず少量の代表的なバッチをインポートする

通常のJPEG、HEIC写真、編集済み画像、Live Photo、動画、連写、共有アルバムのコピー、完全一致する重複2つを含むバッチを選びます。ライブラリ全体で使用する予定の方法と同じ方法でインポートしてください。

モバイルのタイムラインでは、片方がサーバー上のコピーを表し、もう片方がスマートフォンにだけ残っている場合でも、クラウドとローカルのアセットが2つ表示されることがあります。Immichの報告では、写真がクラウド状態とクラウドオフ状態の両方で表示されています。

ギャラリーが同一ハッシュを拒否するか、モーション構成ファイルをグループ化するか、編集内容を保持するか、サイドカーを読み込むか、ローカルのみのアセットとアップロード済みアセットを区別するかを確認します。エクスポート全体に拡大する前に、インポート経路を調整してください。

過去のインポートが安定するまでモバイルバックアップを有効にしない

移行するクラウドライブラリの一部を含むすべてのスマートフォンで、自動バックアップを一時停止します。そうしないと、サーバーがエクスポートファイルから同じ履歴を取り込んでいる間に、モバイルクライアントが数千件のアセットをアップロードする可能性があります。

ユーザーが外部ライブラリのコピーを残したままアップロードを削除すると、異なる保存元間での重複が再発することがあります。その後、モバイルクライアントが同じアセットを再びアップロードする可能性があるためです。Immichのディスカッションでは、モバイルと外部ライブラリの重複ループが繰り返される事例が説明されています。

過去のインポートが完了したら、スマートフォンの保留件数とサーバーのマニフェストを比較します。まず最近の小さなアルバムでバックアップを有効にし、既知の過去のアセットがスキップされるか、バックアップ済みとして扱われることを確認してください。

外部ライブラリとアップロード済みライブラリを意図的に扱う

移行したファイルをギャラリーが管理するアップロードとして保存するのか、外部の読み取り専用ライブラリとして保存するのかを決めます。同じ物理ファイルを両方の経路で表示しないようにしてください。

管理対象ライブラリから外部ライブラリへアセットを移動すると、古いデータベースのレコードが残ったまま新しい外部スキャンによって別のアセットが追加され、タイムラインに重複項目が表示されることがあります。報告された結果は、孤立したレコードと新しい重複でした。

ファイルセットごとに1つの所有モデルを使用します。モデルを切り替える場合は、データベースをバックアップし、古いパスのサポートされた削除またはクリーンアップを完了させます。その後、新しい場所をスキャンする前に、古いレコードが消えていることを確認してください。

メタデータと復元の観点を踏まえて重複を確認する

ギャラリーが重複を検出したら、保持するアセットを選ぶ前に、解像度、ファイルサイズ、コーデック、撮影時刻、編集履歴、Live Photoのペアリング、アルバムへの登録状況、お気に入り、顔の割り当て、バックアップ元を比較します。

近似重複の検出では、同じシーンを異なる解像度やエンコードで保存したファイルを見つけられます。しかし、どのバージョンがユーザーの好みの編集内容や最高品質のオリジナルを保持しているかまでは判断できません。自動検出は削除指示ではなく、確認待ちのキューとして扱ってください。

ZimaSpaceのNASデータ移行ガイドでは、関連する原則として、ファイル数、メタデータ、アルバム、代表的な復元結果を確認するまで、クラウドのエクスポートと元のライブラリを保持することを示しています。

再現可能な監査で移行を完了する

保存元のマニフェスト、インポートされたファイル数、拒否された完全一致の重複、保持したバリエーション、失敗したファイル、スマートフォンの保留件数を比較します。数年分のデータ、アルバム、編集済み写真、動画、Live Photoを抜き取り確認してください。

元のクラウドエクスポートを変更せずに保持し、サブスクリプションを解約したりクラウド上のアセットを削除したりする前に、セルフホスト型ライブラリの2つ目のバックアップを作成します。重複の整理はバックアップではなく、コピーを変更する唯一の操作にしてはいけません。

各オリジナルに意図した正規コピーが1つだけあり、編集済みのバリエーションを区別でき、スマートフォンが新しいアセットだけをアップロードし、外部ライブラリと管理対象ライブラリが重複せず、除外または保持したすべての重複をマニフェストで説明できれば、移行は完了です。