クラウド写真のサイドカーによって撮影日が変更されるのを防ぐ方法

クラウド写真のサイドカーによって撮影日時が変更されるのを防ぐには、元画像に埋め込まれた撮影日時を正しい基準として扱い、サイドカーをメインアーカイブに適用する前に必ず統合テストを行います。

家庭用NASの写真ライブラリでは、クラウドからのエクスポート、モバイル同期、Lightroomによるサイドカーの書き込み、またはメタデータの一括修復の後に問題が発生しがちです。画像自体は正しく表示されていても、タイムライン、フォルダーの並び順、バックアップの比較が、写真を撮影した瞬間ではなく、エクスポート日時、編集日時、またはJSONサイドカーの日時に従うよう突然変わることがあります。

写真ライブラリが実際に使用している日時を確認する

最初に安全な手順として、3種類の日時を分けて考えます。画像に埋め込まれたカメラの撮影日時、ファイルシステムの更新日時または作成日時、そしてサイドカーファイルに保存された日時です。これらはすべて同じ写真について説明できますが、写真アプリが常に同じ優先順位で参照するとは限りません。

通常のJPEGや多くのRAWワークフローでは、DateTimeOriginal、CreateDate、ModifyDateなどの埋め込みタグが、画像の撮影日時を判断する際に多くのツールが確認するフィールドです。ExifToolには、これらの一般的な日時フィールドの説明に加え、これらのメタデータ日時をまとめて編集できるAllDatesショートカットも用意されています。

クラウドからエクスポートしたデータをメインギャラリーに取り込む前に、メタデータリーダーで数個のファイルを確認し、実際の撮影時刻と一致する値を記録します。ファイルシステムの日時がエクスポート日を示していても、埋め込みの撮影日時が正しい場合は、整理アプリにファイルシステムの日時を基準としてフォルダーを再構成させないでください。

サイドカーを写真の横に保持しつつ、自動的な上書きを防ぐ

サイドカーは、元の画像を書き換えずに編集内容、クラウドによる補正、評価、ラベル、欠落したメタデータなどを保存できるため便利です。危険なのはサイドカーが存在することではなく、インポーターにすべての日時フィールドへ無条件に適用させることです。

たとえばAdobe Lightroom Classicでは、変更内容をXMPに自動的に書き込むことができます。つまり、作業中にサイドカーが継続的に更新される可能性があります。これはデータの持ち運びには便利ですが、サイドカーの更新日時と写真の撮影日時を同じものとして扱ってはいけないということでもあります。

写真とサイドカーは常にペアで移動またはバックアップします。ただし、サイドカーに含まれる修正済みの撮影日時フィールドが本当に必要なものだと確認できるまでは、サイドカーの編集内容が撮影日時を上書きしないようインポートルールを設定してください。アプリにドライラン機能がある場合は、確定する前に日時のマッピングをプレビューします。

日時を統合する前に、クラウドのJSONサイドカーをコピーでテストする

クラウドからのエクスポートでは、写真ファイル名に似た名前のJSONファイルが追加されることがあります。これらのファイルには便利なメタデータが含まれている場合がありますが、意味の異なる複数の日時が入っていることもあります。そのため、フォルダー全体を直接統合するのではなく、コピーを使ってテストするのが正しい手順です。

Google Photos Takeoutの修復ガイドでは、写真を撮影した日時のフィールドと、アップロード日時または作成日時のフィールドを区別することがよくあります。Google TakeoutのJSONファイルに関する説明では、photoTakenTimeは写真の撮影時刻を表す一方、creationTimeはアイテムがGoogle Photosに登録された時刻を表す場合があるとされています。この違いがあるため、無条件に統合するとアーカイブ全体が誤った年に移動する可能性があります。

代表的なファイルを10個、テストフォルダーにコピーします。意図した撮影日時フィールドだけを統合し、その後、メタデータリーダーと、NASで実際に使用しているギャラリーアプリの2か所で結果を確認します。両方が期待どおりの撮影日時を示し、サイドカーの編集内容も表示される場合にのみ、次へ進んでください。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

メタデータを書き換える際はファイルの更新日時を保持する

多くのメタデータツールは、埋め込みフィールドを更新するときにファイルを書き換えます。この書き換えによって、埋め込まれた撮影日時が正しいままでも、ファイルシステムの更新日時が変わることがあります。バックアップソフトやギャラリーの並び順がファイルの更新日時を使用している場合、これは重要な問題になります。

ExifToolには、メタデータを変更しながらファイルシステムのタイムスタンプを移動させたくないワークフロー向けに、ファイルの更新日時を保持するオプションがあります。すべてのアプリが同じように動作することを保証するものではありませんが、管理された修復を行うためのより安全な方法になります。

修正した日時をファイルに書き戻す必要がある場合は、まずコピーに対してコマンドを実行します。後続のツールがファイルの更新日時に依存している場合は、その日時を保持し、実行前後のレポートを出力してください。画像の撮影日時フィールドは正しいのに、ギャラリーが別の日時を基準に並べ替える場合は停止します。それはアプリの設定の問題であり、元画像を書き換え続ける理由にはなりません。

フォルダー、ギャラリー、バックアップの比較でアーカイブを検証する

コマンドの実行が終わっただけでは、日時の修復は完了しません。NASのギャラリー、ファイルブラウザー、バックアップの比較画面で、同じ代表的な写真が正しい順序で表示されたときに初めて完了です。

クラウドのサイドカーに関するコミュニティ事例では、同じ失敗パターンがよく見られます。ユーザーがJSONまたはXMPのデータを統合した後、インポート先のライブラリが誤ったフィールドを使用していることに気付くというものです。Google Takeoutのサイドカー日時の混乱に関するPhotoStructureのサポートスレッドは、名前と日時の意味をエクスポートフォルダーだけでなく、移行先のアプリで確認する必要があることを示すよい例です。

テストバッチに問題がなければ、本番の共有フォルダーを変更する前に、より大きなコピーでも同じ確認を行います。ツールによって結果が異なる場合は、ワークフローを停止し、変更していないバックアップを保持します。そのうえで、各アプリがどの日時フィールドを読み取っているのかを記録してから先に進んでください。

よくある質問

写真をインポートした後、JSONまたはXMPのサイドカーを削除してもよいですか？

いいえ。編集内容や修正済みのメタデータが安全に埋め込まれた、またはインポートされたことを確認するまでは削除しないでください。バックアップとギャラリーの確認によって不要になったことが証明されるまで、サイドカーは元画像と一緒に保持します。

ファイルの日時とEXIFの日時が一致しない場合、どちらを信頼すべきですか？

カメラで撮影した元画像の場合、カメラ側で誤っていたと分かっていない限り、まず埋め込まれた撮影日時を信頼します。ファイルの日時は、ダウンロード、エクスポート、同期、コピー、復元の操作によって簡単に変わるためです。

この修復が大規模なホームアーカイブ整理の一部である場合は、変更していない元画像を編集済みまたは修復済みのコピーから分離して保管するストレージポリシーと組み合わせてください。同じ分離の考え方は、NASの写真共有フォルダーでスナップショットレプリケーションの保持期間を計画する場合にも役立ちます。