特定の画像ファイル形式を使用するメリットは何ですか?


11

GIMP、PhotoshopMS Paintなどのアプリケーションを使用して画像ファイルを編集すると、保存中に必要なファイル形式を選択するよう求められます。利用可能なさまざまな形式がありますが、一般的な形式はJPEGPNG およびBMPGIFおよびTIFFです。一部のプログラムでは、JP2のようなさらに多くの形式があります

それでは、どのオプションを選択する必要がありますか?特定のファイル形式を使用するメリットとデメリットは何ですか?


私の編集が、「あなたが回答した質問を編集するためにシステムを賭けているのですか?」で述べられたいかなる内容にも違反しないことを願っています-ある場合は、自由にロールバックしてください。編集の意図:特にHEIFやその他の形式が広く普及し始めているため、タイトルが具体的すぎる(IMHO)のは良い質問です。
flolilo

@floliloliloここでは問題だとは思いません。オーガニック検索のトラフィックが少なくなり、重複を手動で閉じる必要があることを少し心配していますが、ええと。
プロフィールを読んでください

@mattdm申し訳ありませんが、ここでさらに労力を導入するつもりはありませんでした!「JPEG、BMP、PNGのどちらを使うべきか」というのは、他のすべてのコーデックのために扉を開いたままにしておくことだと思っていました。それが私だけの場合は、この方法で維持する必要はありません。
flolilo

回答:


12

JPEG

JPEGは非可逆です。つまり、JPEGはデータを破棄することで画像を部分的に圧縮します。破棄するデータは、(通常)画像の品質への影響を最小限に抑えるように選択されますが、(実質的に)常に少なくとも少しは品質が低下します。選択した品質レベルによっては、かなり失われる可能性があります。ほとんどの写真では、表示専用の形式と見なす必要があります。いったん何かをJPEGに変換したら、それ以上編集する必要はありません。変更を加える必要がある場合は、他の形式からやり直して、変更を加え、別のJPEG変換を行います。

JPEG 2000、JPEG XR

JPEG仕様の新しいバージョンがあります。それらは一般に、ファイルサイズと画質の間のより良いトレードオフを与えることができる新しい形式の画像圧縮を定義します-小さいファイルで同じ品質を選択するか、ほぼ同じファイルサイズでより良い品質を選択します。また、より高い色解像度をサポートします(たとえば、チャネルあたり16ビットおよび高ダイナミックレンジをサポートする浮動小数点形式)。技術的な観点から、それらは非常に魅力的です。大きな欠点は、多くのプログラムがそれらの読み取り、表示、操作、または書き込みの方法を認識していないことです。

HEIF

TIFFと同様に、HEIFは実際にはコンテナー形式であり、さまざまな方法(主にh.265だけでなく、h.264およびJPEG)でエンコードされた画像を含めることができます。元のJPEGよりもファイルサイズに対する品質の比率が高くなります。TIFF(またはGIF)と同様に、一連の画像全体を1つのファイルにパッケージ化できます。2014年にHEIFが導入されたときはかなりのファンファーレがありましたが、最終的にどのようにJPEGを無効にするフォーマットになるかについて多くの声明がありましたが、興奮のほとんどは、JPEGを大幅に置き換えることなく消えていったようです。

BPG

BPGは、多作なプログラマであるFabrice Bellardによって設計されたフォーマットです。これは基本的にh.265でエンコードされた画像のコンテナである点でHEIFに似ています。ただし、ラッパーは少し異なるため、この2つは互いに互換性がありません。ただし、写真の観点から見ると、BPGにはかなり重要な利点があります。BPGは、EXIFデータの画像ファイルへの埋め込みを直接サポートします。

ロスレスJPEG

私たちが通常JPEGと考えるものは不可逆ですが、JPEG仕様は、可逆圧縮を使用するファイル形式も定義しています。圧縮はロスレスであるため、通常、通常のJPEG圧縮ほど小さなファイルは生成されませんが、実際にはロスレス圧縮には非常に優れています。写真に。JPEG 2000やJPEG XRと同様に、これらはうまく機能しますが、サポートが不足しています。

GIF

GIFはロスレス圧縮のみを使用しますが、8ビット(256)色に制限されているため、写真にはかなり制限があります。

PNG

PNGはGIFの代わりとして設計され、ほとんどが成功しています。24ビットカラー(赤、緑、青にそれぞれ8ビット)をサポートし、ロスレス圧縮を使用します。それは写真に必要な色解像度を持っていますが、それが使用する圧縮はほとんどの写真にとって非常に効果がない傾向があるので、ファイルは結局かなり大きくなります。PNGのもう1つの大きな欠点は、EXIF(または同様の)データを保存する方法が定義されていないことです。そのため、PNGを使用して写真を保存する場合は、メタデータを個別に保存する必要があります。これはあなた自身の使用には問題ないかもしれませんが、Webページやそのようなものでそれを使用すると、一般的に失われることを意味します。

TIFF

TIFFは、実際にはさまざまな種類のデータをコンテナーに挿入できるコンテナー形式です。主に画像に使用されますが、実際にはほとんどファイルシステムに似ているため、理論的にはほとんどすべての種類のデータに使用できます。これにはいくつかの影響があります。1つは、プログラムがTIFFファイルをサポートしていても、すべての TIFFファイルをサポートしているとは限らないことです。たとえば、多くはLZW圧縮された画像をサポートしていません。実際、すべての可能なTIFFファイルをサポートするプログラムはほとんどありません。別の結果として、TIFFはかなりの量のオーバーヘッドを持つ傾向があり、TIFFをサポートするコードを(まったく)書くのは面倒です(そのため、非常に多くのプログラムがTIFFを不完全にしかサポートしていません)。

BMP

BMPは基本的に、ディスクに書き出されたWindowsデバイスに依存しないビットマップです。それだけであり、非常に圧縮のための限定的なサポートを(そしてほとんどの BMPはまったく圧縮されません)。Windows用に作成されたプログラムは、BMPを非常に簡単に読み書きできますが、他に推奨することはあまりありません(特に、BMPファイルは、格納されるデータの量に対して非常に大きくなる傾向があります)。BMPには、EXIF(または同様の)メタデータを格納する方法がありません。BMPは一種のPNGに似ていますが、Windowsに固有です。

結論

JPEGは出力形式として便利です(たとえば、Webページに表示する場合、コンパクトであり、事実上誰もがそれを読むことができるため、JPEGは優れています)。

TIFFは、後で編集される可能性のあるファイルを(たとえば)保存するための中間形式として頻繁に使用されます。

256色の制限により、GIFは写真にはほとんど役に立ちません。BMPとPNGは基本的に写真自体には無害ですが、メタデータを保存できません。また、それらが使用する圧縮が写真に対して非常に効果的であることはめったにありません(ただし、ストレージの価格は十分に低く、多くの人はそれほど気にしないかもしれません)。


4
PNGは8ビットのアルファチャネルもサポートするため、実際には32ビットをサポートしています。完全な写真を保存する場合はそれほど重要ではありませんが、たとえばWebページで使用する画像を生成する場合、8ビットのアルファチャネルは非常に重要です。
ピート

写真にPNGが役に立たないのはなぜですか?
Clicketyリケット

1
@ClicketyRicket:私は状況をよりよく説明できると思うもう少し情報を追加するように編集しました。
Jerry Coffin

@JerryCoffin JPEG XR、そしておそらくHEIFについて何か追加できると思いますか?
プロフィールを読んでください

@mattdm:妥当なようです。
Jerry Coffin

5

一般的に、やむを得ない理由がない限り、メタデータをサポートする形式で保存することをお勧めします。その点で、jpegとtiffは、RAW + XMPまたはDNG以外の写真で最も一般的な2つの形式です。

私は自分のオンラインポートフォリオの一部でPNGを使用しました。縮小した画像の角を丸くして、より優れた展示を行い、他の人とは一線を画すために何かをしているからです。この欠点は、PNGがメタデータをサポートしないことです。優れたオンライン写真サイトのほとんどが自動メタデータ抽出と表示をサポートしているため(Flickrなど)、これは多くの点で私を制限しました。

より明確にするために... Flickr、DeviantArt、1x、RedBubbleなど、オンラインでアートの縮小版を展示する場合、最終出力形式としてJPEGを使用するのがおそらく最善です。これらのファイルは高品質ですが非常にコンパクトで、メタデータをサポートしています。オリジナルの長期保存には、RAW + XMP、DNG、またはTIFFをお勧めします。これらの形式はすべてロスレス圧縮を行い、メタデータも保持するためです。Gimpを使用している場合は、TIFFが最良の選択かもしれません。私はRAW + XMPを自分で使用しました。これは、元のRAWファイルが好きなので...すべてをDNGに変換してファイル管理を簡略化することも検討しました。


5

巨大なポストの準備-はい、これは手に負えなくなった...

必須のxkcd:

xkcd#927「規格」

残念ながら、単純な「最適な」形式はありません。非常によくサポートされているもの、極端な汎用性を提供しているもの、ロスレス圧縮を提供しているもの、...

この回答の最初の部分(「機能」および「フォーマットの簡単な概要」)は技術について説明しますが、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...奥行き; *...以下のテキストを見てください。


フォーマットの概要:

BMP

 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で試してください編集者!。各ピクセルの完全な情報を保存する必要があるため、(適切な)圧縮が提供されないため、ファイルサイズが大きくなります。その剛性のため、長期間のアーカイブに適しています。


BPG

 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と比較して圧縮の点ではるかに優れていますが、ぼやけている傾向があるため、低いビットレートを除いてすべての点でよく比較されていません。


EXR

 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はより多くのオプションを提供します。


FLIF

 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)。しかし、それは若いコーデックなので、改善が出てくるかもしれません。アニメーション、アルファチャネル、プログレッシブデコード、さらには非可逆エンコーディング(最初のエンコーディング後の世代損失はありません)もサポートします。それが成功するかどうかを示すのは時間だけであり、正直なところ、複数の問題に対する単一の解決策を提供するように思われるので、そうすることを強く望みます。


GIF

 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がこれ以上うまくできない唯一のものです。


HEIF

 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の連続(存在する場合)の可能性が最も高いようです。


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年以来よく進化しました。


JP2k

 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に追いつくことはありませんでした。


JXR

 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より優れています。一部のソフトウェアはそれをサポートしていますが、他のフォーマットの名声に近づくことはありません。


PNG

 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をありがとう


TGA

 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)をサポートします。


TIFF

 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は広くサポートされており、機能面で非常に柔軟であるため、中間ファイルとしてよく使用されます。


WebP

 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ファイルについて考えるときに特に気になります

プログラムのサポート(長寿#2)

最も人気のある最高のコーデックは、使用できない場合は十分ではありません。また、特定のプログラムがサポートしていないという理由だけで劣ったコーデックを使用することはありませんが、1つのプログラムだけが適切にサポートするコーデックを使用するのは悪いことかもしれません。

どのような機能が必要ですか?

個人的には、依然としてほとんどのファイルをJPEGでエンコードしています。どのデバイスでも読み取ることができ、アーティファクトをほとんど(またはまったく)見ることができます。ほとんどのデバイスでは8ビットで十分です。写真を表示するだけの場合は、アルファチャネルは実際には必要ありません。

「一度編集する」スタイルではないすべてのファイルについて、RAWを保持するか、少なくとも16ビットTIFFを保持して、将来も引き続き使用できるようにします。

PSD?DNG?

「Photoshop Document」(PSD)は、PhotoshopのTIFFスタイルの形式です。技術的には、TIFとよく似ています。PSBもあります。これは、4 GiBを超えるファイルサイズの場合と同じです。それを使用することに問題はありませんが、個人的には、可能な限りTIFFを好みます。

「Digital Negative」(DNG)は、オープンなRAW標準を作成する試みです。私はこのアイデアを気に入っていますが、かなりうまくいきますが、一部のRAWエディターには問題があることに注意してください。たとえば、Capture Oneは通常、カメラのホワイトバランスを忘れるため、実際の値に関係なくスライダーを5000Kに設定します。過去の他のプログラムは、それらを白またはピンクの無地の画像として表示したり、マゼンタ色を与えたりしました。ファイルサイズが問題にならない場合は、元のRAWをDNGに含めることができます。これが再び必要になった場合は、再度抽出するだけです。私の2セント?お気に入りのソフトウェアで試してみてください。うまくいく場合は、それを使用してください。

他のフォーマット?

これはすでに手に負えなくなったので、これ以上の画像フォーマットには対応したくありませんでした。ただし、これはリストされていないものを検討する価値がないことを意味するものではありません。


雑学:「私たちのDSPはJPEG以外のコーデック用に最適化されていない」というのは、今日の怠惰な言い訳であることに気づきました。
flolilo

1
フォーマットのサポートについて書いたように、フォーマットがシンプルであるほど、サポートを維持しやすくなることは言及する価値があると思います。これは、プログラミングの学生が午後にデコーダーを作成するのに十分なほど単純な非圧縮targaなどの大きなプラスです(つまり、すべてのサポートソフトウェアが失われたとしても、安価で簡単に再作成できます)。
lijat

2

編集した画像をLZW圧縮したTIFFとして保存します。私はGimpを使用して編集し、ImageMagickに基づくスクリプトを使用して、TIFFをさまざまなサイズや品質レベルのJPGに変換し、Webでの使用や印刷などを行います。PNGも機能すると思います。数年前に私はそれらの中から選択し、TIFFを選んだ理由を忘れました。(おそらく、他のレスポンダが言及したメタデータの問題か、おそらくufrawのPNG出力が遅すぎたのでしょう。)

将来の編集のためにレイヤーを保持したい場合は、.xcf.gz(gzip圧縮を使用したGimpのネイティブ形式)として保存します。もちろん、Gimp以外のプログラムを使用している場合は、役に立ちません。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.