私はソフトウェア開発者であり、取引において、開発ツールに多くの時間を費やしています...より便利な開発ツールの種類の1つはバージョン管理です。
とにかく、写真に似たようなものが使用されているのではないかと思っていますか？本質的に、私は次の方向に沿って何かを考えていました：
上記のフローを使用すると、さらに多くの変更を追跡できるはずです...そして、何らかのバックアップ戦略を提供できます...
回答:
Adobe LightroomやAppleのApertureなどの写真ワークフローアプリケーションは、機能の一部として組み込まれたこの種の履歴を提供します。
これらのRAWファイルを編集する場合、元の画像は変更されません。代わりに、「命令」として個別に保存されます。したがって、行われたすべての変更の履歴を表示し、マウスをクリックするだけで、以前の時点に非破壊的に戻ることができます。
Photoshopを使用している場合、これは発生せず、毎回作業する前に異なるバージョンの写真を手動で保存する必要があります。
（私はあなたが写真にSVNリポジトリを使用できない理由がないと推測していますか??。すなわち、バイナリファイル？）
仮想変更
Lightroom v3を使用していますが、この製品には非破壊的なワークフローがあります。これにより、仮想的な意味で画像に変更を加えることができます。
バージョン管理
次に、SVNを使用してLightroomカタログ（単なるSQLite DB）の制御を維持します。これにより、基本的に仮想変更のバージョン管理が可能になります。
冗長性
冗長性のためにメディアを保持するRAID 6セットアップと、回転バックアップシステムとしてのUSBドライブのサイクルがあります。
これはすべての人に効果があるわけではありませんが、私には効果があります。さらに、複数のマシンを使用し、同じLRカタログを持つことができます（svnコミット/更新サイクルを使用）。
ここのブログ投稿からの抜粋：
RAID 6ベースのサーバーを搭載した2台のコンピューターにLightroomがあり、すべてを同期してマシン間での生活を楽にする方法に苦労しています。
いくつかの決定の後、写真を\ server \ shareに移動しました。カタログはSubversionで追跡されます！これにより、マシン間ですべてが非常に簡単になります。
私がやったことは、Lightroomカタログを保持するリポジトリを作成することです。Subversionにはいくつかの問題があるため、プレビューファイルを含めないように例外を追加しました。
今、私の手順は次のとおりです。
Update subversion Run Lightroom Import pictures Move images between local drive import and the media file share Make any required changes Exit lightroom Commit catalog That's it!
git-annex（写真とバックアップを管理するため）をbupリモート（バージョン管理用）とともに使用したいと思うかもしれません。私は現在、実際に自分で調べています。
git-annexは、ファイルへのシンボリックリンクをコミットすることにより、gitを使用してファイルを追跡します。ファイル自体はリポジトリに追加されません。写真が「添付」された後、リポジトリをクローンする場合（たとえば、外部ハードドライブ上）、クローンにハードドライブ上のリポジトリに関連付けられているファイル（またはその一部）を取得するように依頼できます。git-annexは、どのリポジトリにすべてのファイルのコピーがあるかを追跡します。これにより、バックアップを2台の小さなハードドライブに分割し、写真を忘れていないことを確認できます。
旅行中だとしましょう。ラップトップにコピーされた写真を撮影しました。自宅のsshサーバーにあるgitリポジトリーのクローンを作成して同期し、ローカル写真をgit-annexにコレクションに追加し、変更をサーバーにプッシュバックできます。次に、ファイル自体をプッシュします。
git-annexはコレクションの変更を追跡しますが、写真の最新バージョンのみを保持します。ファイルのバージョン管理では、git-annexリポジトリに特別なbupリモートを追加できます。私はそれが必要かどうか確信がないので、まだ調べていませんが、あなたが望むことをするべきです。こちらまたはこちらをご覧ください。
Lightroomを使用して画像編集を行い、バージョン履歴を保持します。Photoshopを使用する場合は、Adobe DriveとVersion Cueというバージョン管理機能がほとんど組み込まれています。Version CueはCreative Suite、FYIの一部に過ぎないと思います。
Pixel NovelはPhoto Shopに接続し、すでにお持ちのSubversionサーバーと連携するか、それらからリポジトリを購入できると思います。
彼らはそれを「デザイナーのバージョン管理」と呼んでいます
Lightroomの代わりにPhotoshopとAdobe Camera Rawを使用しているため、XMPファイルのバージョン管理を使用して、変更を追跡するために生の変換設定を保存します。XMPファイルは単なるXMLであるため、これは非常にうまく機能します。最初にすべての色補正を行い、XMPファイルをチェックインしてから、非標準のアスペクト比にトリミングするのが便利です。そうすれば、元の3x2アスペクトで画像を印刷する必要がある場合に、トリミングされていないバージョンにすばやく戻すことができます。
Photoshopには独自のリビジョン追跡システムが組み込まれていますが、よく知っているツールを使用する場合です。ビルドスクリプト/ビルドの自動化など、便利な他のコーディングツールがあります。たとえば、単一のコマンドを発行して、プロセスの名前を変更し、セットからすべての画像を出力する、印刷用の未トリミングXMPファイルを使用して写真のセットを「構築」できます。ソフトウェアのためにそれを行う方法をすでに知っているなら、それは本当に簡単です！
リポジトリにバイナリファイルを追加できますが、これには大量のストレージが必要であり、異なるバージョンを比較するときに有用なdiff情報を取得できません。
これは、通常の生の変換、露出の設定、カラーバランスなどのためです。Photoshopのより複雑な作業のために、調整レイヤーとスマートフィルターで非破壊的にできる限りのことを行いますが、まだすべてを行うことはできません非破壊的であるため、当面は.PSDファイルのいくつかのバージョンを保存するだけです。
私はソフトウェア開発者でもあり、リムーバブルドライブとXMPのバージョン間で写真を同期するためだけに、大容量のRAWとXMPにGitとSVNを使用しようとしました。それは耐えられないほど遅く、ファイルを追加するにつれて時間がたつにつれて遅くなりました。歴史にもLightroomを使用しているため、rsyncに戻りました。
現在、私はgit-annexも検討していますが、これまでのところ素晴らしく高速です。また、各RAWファイルをチェックサムするという追加の利点もあるため、インポート後に不良HDが画像を台無しにしているかどうかを確認できます。これは、バックアップをテストしてコピー/ビットの腐敗によって劣化していないことを確認できるため、私にとって大きなメリットです。XMPのみのバージョン管理とRAWの併合を計画しています。git-annexは、物事がどこにあるのかを知ることができます。また、必要に応じてラップトップに作業コピーを置くだけでなく、サーバー上のすべてのものがバックアップされていることを確認できます。
Amazon Glacierのリモートを使用することもできますので、読みましたが、まだ試していません。
ダミニオンをご覧ください。これは、アーカイブされた写真やその他のメディア形式のバージョン管理をサポートする写真管理ソフトウェア（マルチユーザーフレンドリー）です。
シングルユーザーDaminionバージョンは無料なので、今すぐダウンロードして確認できます。
関係するファイルのサイズが大きいため、GitやSVNのようなソースバージョン管理は使用しません。各生ファイルは20〜30 MBであり、変更は多くの場合、画像全体のすべてのピクセルに影響を与え、「変更の追跡」の効果を減らします。
元の画像と最終画像のコピーを保存するだけであれば、単一の画像の場合、おそらく60MBではなく200MBのSVNリポジトリを簡単に見ることができます。
これについては、https：//www.impulseadventure.com/photo/flow-catalog-versions.htmlを参照してください。
コードリポジトリとイメージDAMには大きな違いがあります。
マスター
---トリミングおよびシャープ化。
--- --- Facebookの解像度を下げる
--- ---ギャラリーの大きなサムネイル
--- ---ギャラリーのミディアムサムネイル
--- ---ギャラリーの小さなサムネイル。
--- ---ギャラリー用のウォーターマーク付きの大きなバージョン
--- --- ---透かし入りの白黒バージョン
--- --- ---白黒バージョン
--- ---クライアントのための特別な作物。
--- ---さまざまなクライアント向けに調整された色かぶり
（各画像が18の異なる解像度を持つ1つのWebページを作成しました。）
コードにはバージョン間でわずかな違いがある傾向があります。通常のチェックインでは、コードが変更されるのはわずか数パーセントです。画像では、ほとんどのピクセルが一部を変更し、変更のみを保存することによるスペース節約はわずかです。
コードリポジトリでは、ビットレベルの変更に関心があります。ここのコード行、そこの定数の値。画像操作では、実行した手順の履歴がより重要です。
画像作業は、コードよりも共同作業がはるかに少ない傾向があります。グラフィックアーティストは既存の画像を取得し、その上にグラフィックアートワークを重ねることができますが、ほとんどの画像は1人のユーザーが一生管理します。（これはビデオ/フィルムで異なります。）
ソフトウェアでは、基本レベルはプロジェクトです 。単一のクラスファイルは、プロジェクトの残りがなければ意味がありません。画像処理では、画像が基本単位です。一生を単一のソフトウェアプロジェクトに費やすことができます（Microsoft Word ...）写真では、画像に数分以上かかることはめったにありません。
ソフトウェアにおいて重要なタスクは、変更を追跡し、以前のバージョンに戻すことができるようにすることです。画像処理において重要なタスクは、後日その画像とその派生物を見つけることができるようにすることです。