GIMP、Photoshop、MS Paintなどのアプリケーションを使用して画像ファイルを編集すると、保存中に必要なファイル形式を選択するよう求められます。利用可能なさまざまな形式がありますが、一般的な形式はJPEG、PNG およびBMP、GIFおよびTIFFです。一部のプログラムでは、JP2のようなさらに多くの形式があります。
それでは、どのオプションを選択する必要がありますか?特定のファイル形式を使用するメリットとデメリットは何ですか?
GIMP、Photoshop、MS Paintなどのアプリケーションを使用して画像ファイルを編集すると、保存中に必要なファイル形式を選択するよう求められます。利用可能なさまざまな形式がありますが、一般的な形式はJPEG、PNG およびBMP、GIFおよびTIFFです。一部のプログラムでは、JP2のようなさらに多くの形式があります。
それでは、どのオプションを選択する必要がありますか?特定のファイル形式を使用するメリットとデメリットは何ですか?
回答:
JPEGは非可逆です。つまり、JPEGはデータを破棄することで画像を部分的に圧縮します。破棄するデータは、(通常)画像の品質への影響を最小限に抑えるように選択されますが、(実質的に)常に少なくとも少しは品質が低下します。選択した品質レベルによっては、かなり失われる可能性があります。ほとんどの写真では、表示専用の形式と見なす必要があります。いったん何かをJPEGに変換したら、それ以上編集する必要はありません。変更を加える必要がある場合は、他の形式からやり直して、変更を加え、別のJPEG変換を行います。
JPEG仕様の新しいバージョンがあります。それらは一般に、ファイルサイズと画質の間のより良いトレードオフを与えることができる新しい形式の画像圧縮を定義します-小さいファイルで同じ品質を選択するか、ほぼ同じファイルサイズでより良い品質を選択します。また、より高い色解像度をサポートします(たとえば、チャネルあたり16ビットおよび高ダイナミックレンジをサポートする浮動小数点形式)。技術的な観点から、それらは非常に魅力的です。大きな欠点は、多くのプログラムがそれらの読み取り、表示、操作、または書き込みの方法を認識していないことです。
TIFFと同様に、HEIFは実際にはコンテナー形式であり、さまざまな方法(主にh.265だけでなく、h.264およびJPEG)でエンコードされた画像を含めることができます。元のJPEGよりもファイルサイズに対する品質の比率が高くなります。TIFF(またはGIF)と同様に、一連の画像全体を1つのファイルにパッケージ化できます。2014年にHEIFが導入されたときはかなりのファンファーレがありましたが、最終的にどのようにJPEGを無効にするフォーマットになるかについて多くの声明がありましたが、興奮のほとんどは、JPEGを大幅に置き換えることなく消えていったようです。
BPGは、多作なプログラマであるFabrice Bellardによって設計されたフォーマットです。これは基本的にh.265でエンコードされた画像のコンテナである点でHEIFに似ています。ただし、ラッパーは少し異なるため、この2つは互いに互換性がありません。ただし、写真の観点から見ると、BPGにはかなり重要な利点があります。BPGは、EXIFデータの画像ファイルへの埋め込みを直接サポートします。
私たちが通常JPEGと考えるものは不可逆ですが、JPEG仕様は、可逆圧縮を使用するファイル形式も定義しています。圧縮はロスレスであるため、通常、通常のJPEG圧縮ほど小さなファイルは生成されませんが、実際にはロスレス圧縮には非常に優れています。写真に。JPEG 2000やJPEG XRと同様に、これらはうまく機能しますが、サポートが不足しています。
GIFはロスレス圧縮のみを使用しますが、8ビット(256)色に制限されているため、写真にはかなり制限があります。
PNGはGIFの代わりとして設計され、ほとんどが成功しています。24ビットカラー(赤、緑、青にそれぞれ8ビット)をサポートし、ロスレス圧縮を使用します。それは写真に必要な色解像度を持っていますが、それが使用する圧縮はほとんどの写真にとって非常に効果がない傾向があるので、ファイルは結局かなり大きくなります。PNGのもう1つの大きな欠点は、EXIF(または同様の)データを保存する方法が定義されていないことです。そのため、PNGを使用して写真を保存する場合は、メタデータを個別に保存する必要があります。これはあなた自身の使用には問題ないかもしれませんが、Webページやそのようなものでそれを使用すると、一般的に失われることを意味します。
TIFFは、実際にはさまざまな種類のデータをコンテナーに挿入できるコンテナー形式です。主に画像に使用されますが、実際にはほとんどファイルシステムに似ているため、理論的にはほとんどすべての種類のデータに使用できます。これにはいくつかの影響があります。1つは、プログラムがTIFFファイルをサポートしていても、すべての TIFFファイルをサポートしているとは限らないことです。たとえば、多くはLZW圧縮された画像をサポートしていません。実際、すべての可能なTIFFファイルをサポートするプログラムはほとんどありません。別の結果として、TIFFはかなりの量のオーバーヘッドを持つ傾向があり、TIFFをサポートするコードを(まったく)書くのは面倒です(そのため、非常に多くのプログラムがTIFFを不完全にしかサポートしていません)。
BMPは基本的に、ディスクに書き出されたWindowsデバイスに依存しないビットマップです。それだけであり、非常に圧縮のための限定的なサポートを(そしてほとんどの BMPはまったく圧縮されません)。Windows用に作成されたプログラムは、BMPを非常に簡単に読み書きできますが、他に推奨することはあまりありません(特に、BMPファイルは、格納されるデータの量に対して非常に大きくなる傾向があります)。BMPには、EXIF(または同様の)メタデータを格納する方法がありません。BMPは一種のPNGに似ていますが、Windowsに固有です。
JPEGは出力形式として便利です(たとえば、Webページに表示する場合、コンパクトであり、事実上誰もがそれを読むことができるため、JPEGは優れています)。
TIFFは、後で編集される可能性のあるファイルを(たとえば)保存するための中間形式として頻繁に使用されます。
256色の制限により、GIFは写真にはほとんど役に立ちません。BMPとPNGは基本的に写真自体には無害ですが、メタデータを保存できません。また、それらが使用する圧縮が写真に対して非常に効果的であることはめったにありません(ただし、ストレージの価格は十分に低く、多くの人はそれほど気にしないかもしれません)。
一般的に、やむを得ない理由がない限り、メタデータをサポートする形式で保存することをお勧めします。その点で、jpegとtiffは、RAW + XMPまたはDNG以外の写真で最も一般的な2つの形式です。
私は自分のオンラインポートフォリオの一部でPNGを使用しました。縮小した画像の角を丸くして、より優れた展示を行い、他の人とは一線を画すために何かをしているからです。この欠点は、PNGがメタデータをサポートしないことです。優れたオンライン写真サイトのほとんどが自動メタデータ抽出と表示をサポートしているため(Flickrなど)、これは多くの点で私を制限しました。
より明確にするために... Flickr、DeviantArt、1x、RedBubbleなど、オンラインでアートの縮小版を展示する場合、最終出力形式としてJPEGを使用するのがおそらく最善です。これらのファイルは高品質ですが非常にコンパクトで、メタデータをサポートしています。オリジナルの長期保存には、RAW + XMP、DNG、またはTIFFをお勧めします。これらの形式はすべてロスレス圧縮を行い、メタデータも保持するためです。Gimpを使用している場合は、TIFFが最良の選択かもしれません。私はRAW + XMPを自分で使用しました。これは、元のRAWファイルが好きなので...すべてをDNGに変換してファイル管理を簡略化することも検討しました。
巨大なポストの準備-はい、これは手に負えなくなった...
残念ながら、単純な「最適な」形式はありません。非常によくサポートされているもの、極端な汎用性を提供しているもの、ロスレス圧縮を提供しているもの、...
この回答の最初の部分(「機能」および「フォーマットの簡単な概要」)は技術について説明しますが、2番目の部分(「(その他)考慮すべき事項」)は、フォーマットの選択の実際的な側面に重点を置いています。 。
すべてのハックをすべての形式に含めることはほぼ不可能であることに注意してください。たとえば、GIFはLZWテーブルを無視することで圧縮せずに保存できます。以下でこれについて触れないのはなぜですか?私が今まで遭遇したすべてのGIFの99%がLZWを使用したため、LZWは計算能力が非常に簡単であり、この投稿はILMのR&D部門ではなく、一般的な状況の状況を明確にすることを目的としているためです。写真家はそれらのファイルをアーカイブ、出版、印刷に使用するので、ここでこれらを検討します。
それぞれのWikipediaの記事、仕様、Wikiの比較、exiftoolのmetadata-support-listの間でクロスチェックされた情報。
| Bits per | | Supported by
Codec | Lossy | Channel | Metadata | Channels | Programs | Good for (IMHO)
-------------------------------------------------------------------------------------------------
BMP | n | <= 8 | - | RGBA | Most propr. & free | Archival
BPG | y | <= 14 | EXIF+XMP | RGBA | |
EXR | o | <= 32 | y(?) | RGBAD | | VFX workflow
FLIF | o* | <= 16 | EXIF+XMP | RGBA | | To be seen
GIF | n | <= 8* | XMP | RGB | Most propr. & free | GIFs ;-)
HEIF | o* | <= 16 | EXIF+XMP | RGB(A/D) | | To be seen
JPEG | y* | <= 8 | EXIF+IPTC+XMP | RGB | ~ all propr. & free | Online; Easy access
JP2K | o | <= 32 | EXIF+IPTC+XMP | RGBA | |
JXR | o | <= 32 | EXIF+IPTC+XMP | RGBA | |
PNG | n | <= 16 | EXIF+IPTC+XMP*| RGBA | Most propr. & free | CAD-drawings; Online
TGA | n | <= 8 | y(?) | RGBA | |
TIFF | o | <= 32 | EXIF+XMP | RGBA | Most propr. & free | Archival; Editing
WebP | o | <= 8 | EXIF+XMP | RGBA | |
凡例:o
...オプション。n
... 利用不可; y
...利用可能; D
...奥行き; *
...以下のテキストを見てください。
Feature |
-----------------------------------------------------------------
Introduced | 1990
Open + Free | Both per Microsoft's Open Specification Promise
Colorspace | R:G:B[:A] (4:4:4[:4])
b/c/p | 1:0:0[:0], 5:6:5, 8:8:8[:8]
Compression | None [RLE in 5:6:4] (so: lossless)
Maximum Size | 4 GiB
Metadata | [ICC]
OS support | Virtually all OSs with a graphical interface
凡例:b/c/p
...ピクセルあたりのチャネルあたりのビット(R、G、Bなど)。のもの[ ]
はオプションです。?
...教育的推測/手がかりなし。
「ビットマップ」ファイルはラインでエンコードされ、通常は圧縮されないため、単一のビットフリップは画像の1行のみを破壊しますが、ヘッダーをフリップしない限り、デコードが難しくなります-HEXで試してください編集者!。各ピクセルの完全な情報を保存する必要があるため、(適切な)圧縮が提供されないため、ファイルサイズが大きくなります。その剛性のため、長期間のアーカイブに適しています。
Feature |
---------------------------------------------------------------------
Introduced | 2014
Open + Free | Yes (but HEVC patents might be problematic)
Colorspace | R:G:B[:A] (4:4:4[:4]); Y:Cb:CR[:A] (4:2:0[:4] - 4:4:4[:4]);
| Y:Cg:Co[:A] (4:2:0[:4] - 4:4:4[:4]); C:M:Y:K (4:4:4:4)
b/c/p | 8 - 14
Compression | HEVC (lossy / lossless)
Maximum Size | ?
Metadata | [EXIF]; [ICC]; [XMP]
OS support | Linux, Mac, Windows (at least through browser decoding)
凡例:b/c/p
...ピクセルあたりのチャネルあたりのビット(R、G、Bなど)。のもの[ ]
はオプションです。?
...教育的推測/手がかりなし。
'Better Portable Graphics'(BPG)はHEVCを使用します。これは、h.265ビデオコーデックから知ることができます。JPEGの後継となることを意図していたが、十分な人気を得ることはできなかった。いくつかの点で非常によく似ていますが、より一般的なHEIFの台頭により、HEIFが好まれるようになります。HEVCは、JPEGのDCTと比較して圧縮の点ではるかに優れていますが、ぼやけている傾向があるため、低いビットレートを除いてすべての点でよく比較されていません。
Feature |
---------------------------------------------------------------------
Introduced | 1999
Open + Free | Yes
Colorspace | R:G:B[:A][:D] (4:4:4[:4][:4])
b/c/p | <= 32
Compression | [RLE]; [ZIP]; [PIZ]; ... [lossless (usual) / lossy]
Maximum Size | > 4 GiB
Metadata | [Yes (XMP-style)]
OS support | Linux, Mac, Windows (through library)
凡例:b/c/p
...ピクセルあたりのチャネルあたりのビット(R、G、Bなど)。のもの[ ]
はオプションです。?
...教育的推測/手がかりなし。
OpenEXRは、VFXワークフローの中間形式として、Industrial Lights and Magic(ILM)によって設計されました。非常に高いビット深度で複数のチャネル、複数の画像、メタデータを1つのファイルに保持できます。異なる圧縮アルゴリズムを提供します-またはまったく圧縮しません。EXRはTIFFと比較できます-TIFFははるかに人気がありますが、EXRはより多くのオプションを提供します。
Feature |
---------------------------------------------------------------------
Introduced | 2015
Open + Free | Yes
Colorspace | R:G:B[:A] (4:4:4[:4]) (CMYK and YCbCr in ToDo-List)
b/c/p | <= 16
Compression | MANIAC (variant of CABAC, used in AVC/HEVC) (lossless / lossy (1st generation))
Maximum Size | > 4 GiB
Metadata | [EXIF]; [ICC]; [XMP]
OS support | Linux, Mac, Windows (through provided viewer)
凡例:b/c/p
...ピクセルあたりのチャネルあたりのビット(R、G、Bなど)。のもの[ ]
はオプションです。?
...教育的推測/手がかりなし。
「Free Lossless Image Format」(FLIF)は、ロスレスであるHEVC圧縮の派生物を使用します。FLIFは他のすべての形式と比較して極端な圧縮率を持っていると主張しています-私自身のテストでこれを信じるようになりましたが、それを使用するには本当に計算能力が必要です(ハイパースレッドを使用する単一の24 MP画像には数分のエンコード時間が必要です) 4,3 GHzヘキサコアはそれほど良くありません:D)。しかし、それは若いコーデックなので、改善が出てくるかもしれません。アニメーション、アルファチャネル、プログレッシブデコード、さらには非可逆エンコーディング(最初のエンコーディング後の世代損失はありません)もサポートします。それが成功するかどうかを示すのは時間だけであり、正直なところ、複数の問題に対する単一の解決策を提供するように思われるので、そうすることを強く望みます。
Feature |
---------------------------------------------------------------------
Introduced | 1987
Open + Free | Yes
Colorspace | R:G:B[:A] (4:4:4[:4])
b/c/p | 2 (palette of 256 colors in total)
Compression | LZW (lossless)
Maximum Size | < 4 GiB
Metadata | [XMP]
OS support | Virtually all OSs with a graphical interface
凡例:b/c/p
...ピクセルあたりのチャネルあたりのビット(R、G、Bなど)。のもの[ ]
はオプションです。?
...教育的推測/手がかりなし。
ながら「グラフィックスインターチェンジ形式」(GIF)申し出ピクセル当たりチャンネルあたり8ビット、それは(「背景色」を含むことができる)256色のカラーパレットにそれらを減少させます。これは主にアニメーションに使用されます。PNG自体はアニメーションのサポートを提供しないため、PNGがこれ以上うまくできない唯一のものです。
Feature |
----------------------------------------------------------------------
Introduced | 2015
Open + Free | No (patents)
Colorspace | ? Y:Cb:Cr[:A/:D] (4:2:0[:4]) ?
b/c/p | <= 16
Compression | HEVC (lossy)
Maximum Size | < 4 GiB
Metadata | [EXIF]; [XMP]
OS support | Linux, Mac, Windows
凡例:b/c/p
...ピクセルあたりのチャネルあたりのビット(R、G、Bなど)。のもの[ ]
はオプションです。?
...教育的推測/手がかりなし。
'High Efficiency Image Format'(HEIF)もHEVCを圧縮に使用します。カラーチャネルに加えて、アルファチャネルまたは深度マップ(後のソフトウェアの被写界深度効果に使用される)も保持できます。また、初歩的な編集はロスレスで行われる可能性があります。仕様に応じて、ロスレス圧縮モードも備えています。すべての主要なOSがサポートしているため、JPEGの連続(存在する場合)の可能性が最も高いようです。
Feature |
----------------------------------------------------------------------
Introduced | 1991
Open + Free | Sort of (free library, but patent might apply)
Colorspace | Y:Cb:Cr (4:2:0 (typical) - 4:4:4)
b/c/p | 8
Compression | DCT (lossy)
Maximum Size | < 2 GiB
Metadata | [EXIF]; [ICC]; [IPTC]; [XMP]
OS support | Virtually all OSs with a graphical interface
凡例:b/c/p
...ピクセルあたりのチャネルあたりのビット(R、G、Bなど)。のもの[ ]
はオプションです。?
...教育的推測/手がかりなし。
'Joint Photographic Experts Group'(JPEG)は、おそらく今日最も使用されている画像フォーマットです。損失の多い種類の離散コサイン変換(DCT)を使用します。ロスレス仕様がありますが、あまり使われていません。特定のプログラムは特定の基本的なアクション(回転など)をロスレスで実行できますが、これには画像の幅と高さを8(JPEGのブロックサイズ)で割り切れる必要があります。たとえば、800x640は機能し、804x643は機能しません。JPEGには画像をRGBで保存するオプションがありません-画像をYCbCr色空間に変換し、ピクセル情報を4:4:4(すべてのピクセルにすべてのチャネルがある)から4:2:0(すべてのチャネルに輝度がある)に削減しますが、 4 番目ごとのピクセルのみがCb / Cr値を取得します)。ほとんどの色空間変換と同様に、これは特に極端な色で知覚可能な違いをもたらす可能性があります。JPEGはエンコードが高速で、高品質の設定ではそれほど悪くありませんが、私にとって、上記のことは、消えてしまったとしても涙を流さないでしょう-それは私たちによく役立ちましたが、使用された画像フォーマットはもう少し...最近。結局のところ、コンピューターは1991年以来よく進化しました。
Feature |
----------------------------------------------------------------------
Introduced | 2000 (duh...)
Open + Free | No (patents)
Colorspace | ? Y:Cb:Cr[:A] (4:4:4[:4]) ?
b/c/p | 8 - 32
Compression | Wavelet (lossy / lossless)
Maximum Size | ?
Metadata | [EXIF]; [ICC]; [IPTC]; [XMP]
OS support | Linux, Mac, Windows (at least through viewer programs)
凡例:b/c/p
...ピクセルあたりのチャネルあたりのビット(R、G、Bなど)。のもの[ ]
はオプションです。?
...教育的推測/手がかりなし。
「JPEG 2000」(JP2kまたはJP2)は、JPEGの公式の後継です。DCTの代わりにウェーブレットを使用します。ウェーブレットは、ブロック状のアーティファクトが少なく、JPEGよりも汎用性が高くなります。これらすべてにもかかわらず、JPEGに追いつくことはありませんでした。
Feature |
----------------------------------------------------------------------
Introduced | 2009
Open + Free | Yes (Microsoft Open Specification Promise)
Colorspace | Y:Cb:Cr[:A] (4:2:0[:4] - 4:4:4[:4]); Y:Cg:Co[:A] (? 4:2:0[:4] - 4:4:4[:4] ?);
| C:M:Y:K [4:4:4:4]
b/c/p | 8 - 32 (16 for CMYK)
Compression | DCT (lossy / lossless)
Maximum Size | ?
Metadata | [EXIF]; [ICC]; [IPTC]; [XMP]
OS support | Linux, Mac, Windows (at least through viewer programs)
凡例:b/c/p
...ピクセルあたりのチャネルあたりのビット(R、G、Bなど)。のもの[ ]
はオプションです。?
...教育的推測/手がかりなし。
「JPEG拡張範囲」(JPEG XR、JXR)は、 JPEGを成功させるもう1つの試みです。YCgCoカラースペースは完全にリバーシブルであるため、YCbCrより優れています。一部のソフトウェアはそれをサポートしていますが、他のフォーマットの名声に近づくことはありません。
Feature |
----------------------------------------------------------------------
Introduced | 1996
Open + Free | Yes
Colorspace | R:G:B[:A] (4:4:4[:4])
b/c/p | 8 - 16
Compression | DEFLATE (lossless)
Maximum Size | ?
Metadata | [EXIF]; [ICC]; [IPTC]; [XMP]
OS support | Virtually all OSs with a graphical interface
凡例:b/c/p
...ピクセルあたりのチャネルあたりのビット(R、G、Bなど)。のもの[ ]
はオプションです。?
...教育的推測/手がかりなし。
'Portable Network Graphics'(PNG)は、GIFの後継として導入されました。設計上はロスレスですが、PNGファイルはいくつかのツールで最適化できます。その一部はファイルを非可逆的に圧縮します。PNGはDEFLATE圧縮を使用するため、グラフィックス(CAD図面、スクリーンショットなど)には非常に効率的ですが、写真にはあまり効率的ではありません。メタデータのサポートを提供していますが、一部のプログラムはそれらを読み取ることができません。ヘッドアップ、@ mattdmをありがとう!
Feature |
----------------------------------------------------------------------
Introduced | 1984
Open + Free | ? Yes
Colorspace | R:G:B[:A] (4:4:4[:4])
b/c/p | <= 8
Compression | RLE (lossless)
Maximum Size | ? < 2 GiB
Metadata | Rudimentary
OS support | ? Virtually all OSs with a graphical interface
凡例:b/c/p
...ピクセルあたりのチャネルあたりのビット(R、G、Bなど)。のもの[ ]
はオプションです。?
...教育的推測/手がかりなし。
'Truevision TGA' / 'TARGA'(TGA)は、誰もが知っているように見えるため、私が含めたファイル形式です。それは1984年に導入されました。それはグラフィックスでは大丈夫ですが写真ではそれほどうまく機能しないロスレス圧縮(RLE)をサポートします。
Feature |
----------------------------------------------------------------------
Introduced | 1986
Open + Free | ? Yes
Colorspace | R:G:B[:A] (4:4:4[:4]); Y:Cb:Cr[:A] (? 4:2:0[:4] - 4:4:4[:4] ?);
| C:M:Y:K (? 4:4:4:4 ?); L:a:b[:A] (? 4:4:4:[A] ?)
b/c/p | 8 - 32
Compression | [LZW (lossless)]; [ZIP (lossless)]; [JPEG (lossy)]
Maximum Size | ?
Metadata | [EXIF]; [ICC]; [XMP]
OS support | Virtually all OSs with a GUI support >= 1 of the compression types
凡例:b/c/p
...ピクセルあたりのチャネルあたりのビット(R、G、Bなど)。のもの[ ]
はオプションです。?
...教育的推測/手がかりなし。
「タグ付き画像ファイル形式」(TIFまたはTIF)も長い間使用されてきました。レイヤーサポートを提供します(つまり、複数のRGBA画像を積み重ねます)。TIFFは広くサポートされており、機能面で非常に柔軟であるため、中間ファイルとしてよく使用されます。
Feature |
----------------------------------------------------------------------
Introduced | 2010
Open + Free | Yes
Colorspace | R:G:B:A (4:4:4[:4]) lossless; Y:Cb:Cr[:A] (4:2:0[:4]) lossy
b/c/p | 8
Compression | VP8 (lossless / lossy)
Maximum Size | ?
Metadata | [EXIF]; [ICC]; [XMP]
OS support | Linux, Mac, Windows (at least through browser decoding)
凡例:b/c/p
...ピクセルあたりのチャネルあたりのビット(R、G、Bなど)。のもの[ ]
はオプションです。?
...教育的推測/手がかりなし。
「WebP」はVP8(AVCへのオープンソースのライバルフォーマット)を使用します。BPGと同様に、多くのインターネットサービスで使用されているように見えますが、コンシューマデバイスに飛躍することはありませんでした。
損失のないファイルを再エンコードしても何も変更されません-損失のあるファイルを再エンコードするとほぼ確実にアーティファクトが発生します。JPEGはかなりよく、これを扱うことができるならば、あなたはそれが前に保存されたことと同じ品質設定でファイルを保存します。
このビデオは世代損失をかなりよく示しています-最初のフレームは元のファイルを示していますが、他のすべてのフレームは異なる品質設定での再圧縮を示しています。(FLIFは非可逆モードであるため、最初のフレームは異なって見えることに注意してください。)
アーティファクトは必ずしも死刑判決ではありません。たとえば、モバイルデバイスでの迅速なWeb公開やプレビューの場合、それほど悪くはないかもしれません。
この答えを書いているとき、私は「とにかく今日、誰がTARGAを使うのか」と考えていました。80年代に作られた車を運転するのをためらうことはありませんでした。80年代に撮った写真を見るのをためらわない。その時に作ったカメラなら何でも使います。しかし、私は古いコーデックを使用しませんでした。どうして?
結局のところ、どちらのコーデックが特定の期間存続するかどうかを判断する確実な方法はありません。HEIFが明日すべてのコンシューマデバイスのJPEGを置き換えるとしたら、プログラムがJPEGサポートを停止するのにどのくらいの時間がかかりますか?何世代のコンピューター-そしてもっと重要なこと:OS-は、それらを開くことができなくなる前に存在しますか?
一方、TARGAのような比較的単純なコーデックは、比較的単純なプログラムがそれらを読み取ることだけを要求しますが、最新のコーデックとそのデコーダーには複数の依存関係があります。したがって、単純化は圧縮には不向きですが、終末論的なシナリオでのアーカイブには適している可能性があります。これを指摘してくれた@lijatに感謝!
私の意見では、これを検討するにはいくつかの角度が必要です。サポートがすぐに低下しないように、どのコーデックが十分に人気がありますか?オープンソースコミュニティでサポートされているコーデックはどれですか(破産した会社の専有フォーマットを誰も維持しないため)。また、少なくとも10年ごとに、サポートされている新しいコーデックにジャンプする必要があるかどうかを確認する必要があるようです(「再エンコード(生成損失)」を参照)。たとえば、あなたのTARGAコレクションは明日読めなくなりますよね?
ちなみに、これはRAWファイルについて考えるときに特に気になります。
最も人気のある最高のコーデックは、使用できない場合は十分ではありません。また、特定のプログラムがサポートしていないという理由だけで劣ったコーデックを使用することはありませんが、1つのプログラムだけが適切にサポートするコーデックを使用するのは悪いことかもしれません。
個人的には、依然としてほとんどのファイルをJPEGでエンコードしています。どのデバイスでも読み取ることができ、アーティファクトをほとんど(またはまったく)見ることができます。ほとんどのデバイスでは8ビットで十分です。写真を表示するだけの場合は、アルファチャネルは実際には必要ありません。
「一度編集する」スタイルではないすべてのファイルについて、RAWを保持するか、少なくとも16ビットTIFFを保持して、将来も引き続き使用できるようにします。
「Photoshop Document」(PSD)は、PhotoshopのTIFFスタイルの形式です。技術的には、TIFとよく似ています。PSBもあります。これは、4 GiBを超えるファイルサイズの場合と同じです。それを使用することに問題はありませんが、個人的には、可能な限りTIFFを好みます。
「Digital Negative」(DNG)は、オープンなRAW標準を作成する試みです。私はこのアイデアを気に入っていますが、かなりうまくいきますが、一部のRAWエディターには問題があることに注意してください。たとえば、Capture Oneは通常、カメラのホワイトバランスを忘れるため、実際の値に関係なくスライダーを5000Kに設定します。過去の他のプログラムは、それらを白またはピンクの無地の画像として表示したり、マゼンタ色を与えたりしました。ファイルサイズが問題にならない場合は、元のRAWをDNGに含めることができます。これが再び必要になった場合は、再度抽出するだけです。私の2セント?お気に入りのソフトウェアで試してみてください。うまくいく場合は、それを使用してください。
これはすでに手に負えなくなったので、これ以上の画像フォーマットには対応したくありませんでした。ただし、これはリストされていないものを検討する価値がないことを意味するものではありません。
編集した画像をLZW圧縮したTIFFとして保存します。私はGimpを使用して編集し、ImageMagickに基づくスクリプトを使用して、TIFFをさまざまなサイズや品質レベルのJPGに変換し、Webでの使用や印刷などを行います。PNGも機能すると思います。数年前に私はそれらの中から選択し、TIFFを選んだ理由を忘れました。(おそらく、他のレスポンダが言及したメタデータの問題か、おそらくufrawのPNG出力が遅すぎたのでしょう。)
将来の編集のためにレイヤーを保持したい場合は、.xcf.gz(gzip圧縮を使用したGimpのネイティブ形式)として保存します。もちろん、Gimp以外のプログラムを使用している場合は、役に立ちません。