JPEG画像圧縮FAQ その1

この文書は JPEG image compression FAQ, part 1 を私自身の勉強のために和訳したものです。間違いを見つけた際にはご指摘頂けたら幸いです。また利用はご自由に。 

Newsgroups: comp.graphics.misc, comp.infosystems.www.authoring.images
From: tgl@netcom.com (Tom Lane)
Subject: JPEG image compression FAQ, part 1/2
Message-ID: <jpeg-faq-p1_922674260@netcom.com>
Summary: General questions and answers about JPEG
Keywords: JPEG, image compression, FAQ, JPG, JFIF
Reply-To: jpeg-info@uunet.uu.net
Date: Mon, 29 Mar 1999 02:24:27 GMT
Sender: tgl@netcom17.netcom.com

Archive-name: jpeg-faq/part1
Posting-Frequency: every 14 days
Last-modified: 28 March 1999

この文書では、JPEG画像圧縮についてよく尋ねられる質問に答えます。 第1部で、JPEGについて一般的な質問とその答えを、 第2部で、WindowsやMacなどのシステム毎のヒントとプログラムについて触れます。 いつものように、このFAQの改良のための提案を歓迎します。

この第1部では、次の項目について述べます。

基本的な質問
高度な質問
その他

1. JPEGって何?

JPEG(ジェイペグと発音します)は、規格化された画像圧縮の仕組みです。 (訳注: ここで言う「圧縮」とは「ファイルサイズを小さくすること」です。) JPEGとは、規格を作った委員会、Joint Photographic Experts Group の略称です。

JPEGは、自然や現実の風景の、フルカラーあるいはグレイスケール画像を圧縮するために設計されています。 写真や写実的絵画などに適していて、文字や単純なイラスト、線画にはあまり適していません。 JPEGで扱うのは静止画像だけですが、動画のためには MPEG という関連の規格があります。

JPEGには画像情報の「損失」があります。 (訳注: 「損失」は「画質の劣化」と考えてかまいません。) これは、JPEGで圧縮した画像は、もともとの画像と決して同じではないことを意味します (損失のない圧縮手法は存在しますが、JPEGはそれよりも大幅な圧縮を達成しています)。 JPEGは、人間の目の既知の限界、明るさのわずかな変化より色のわずかな変化のほうが判別しにくいという事実を利用しています。 このように JPEG は人間が見るための画像を圧縮するのが目的です。 もし画像を機械的に解析する場合、たとえ人間の目ではわからなくても、JPEGで圧縮することによっておこる小さい情報の損失が問題になるかもしれません。

JPEGの便利なところは、「損失」の程度を圧縮パラメータの調節で変えられることです。 これは画像制作者がファイルサイズと出力画質を天秤にかけられることを意味しています。 低画質を気にしないなら極めて小さいファイルを作れます。 これは、多数の画像に一覧用の画像を付けるようなアプリケーションで威力を発揮します。 標準の圧縮設定での出力画質に満足できないなら、圧縮を弱めて満足できるまで画質を上げることができます。

JPEGのもう一つの重要な点は、必要とされる計算に、速いけれどあまり正確でない近似値を使うことで、画質を落とす代わりに画像展開速度を上げられることです。 一部の画像ビュアーはこのようにして驚くべきスピードアップをはかっています。 (エンコーダ(訳注: JPEGフォーマットで保存するためのソフトウェア)もまた、精度を犠牲にして速度を上げることができます。)

2. どうしてJPEGを使うの?

正当な理由が2つあります。画像のファイルサイズをより小さくできることと、8ビットカラー(256色)ではなく24ビットカラー(フルカラー)データを扱えることです。

画像のファイルサイズを小さくすると、ネットワーク上でのやり取りや、大量に保管する際に便利です。まあ、2メガバイトのフルカラー画像を100キロバイトまで圧縮できるってことは、ディスク容量と転送時間に大きな違いがでますからね。で、JPEGはフルカラーデータを簡単に20分の1に圧縮できるのです。 GIFとJPEGを比較するなら、サイズの比率は通常ほぼ 4:1 です。(参照:[4] JPEGは画像をどれくらい圧縮できるの?)

さて、JPEG画像の表示は、GIFのような単純なフォーマットの場合より計算に時間がかかります。 そういうわけで JPEGを使うことは、より安く保存したり転送したりするために JPEGの処理で少々時間がかかるというように、ファイルサイズを小さくするかわりに時間が必要になります。 でもネットワークが混雑している場合、ファイルを小さくすることで転送にかかる時間を節約できる分のほうが、JPEGの表示処理にかかる時間よりも大きくなって、トータルの時間が短くて済む点は注目する価値があります。(訳注: パソコンの性能が向上しているので、JPEGの保存や表示処理で待たされると感じることは現在ではほとんどないと思います。一方、ネットワークは混んでる時はどうしても転送速度が落ちるので内容が同じならファイルサイズは小さい方がありがたいですね。)

JPEGの第二の基本的な利点は、フルカラー、1ピクセルあたり24ビット(1600万色)の情報をあつかえることです。 ネットで広く使われている他の画像フォーマットである GIF は 1ピクセルあたり8ビット(256色かそれ以下)しかあつかえません。 GIFは安価なコンピュータの表示にほどよく適しています。 ― 一般的なパソコンは256色以上の色を表示できません。 (訳注: Web資料館-Access Reportによると、2003/08/01現在の8ビットカラー(256色)モードの割合はわずか1.3%。24ビットカラー以上は50.7%となっています。現在では256色以下しか表示できないパソコンはほんのわずかと考えていいようです。) しかし、フルカラーのハードウェアはどんどん安くなってますし、そんなハードウェアではJPEGの写真はGIFよりとってもきれいに見えます。 2年以内におそらくGIFは、現在の白黒のマックペイント・フォーマットのように廃れるでしょう。 さらに、JPEG は何色使用するべきかを事前にチェックしないので、さまざまな表示機器で人々が画像を交換するには GIF よりもはるかに便利です (参照: [8] 色量子化って何?)。 そういうわけで、JPEGは Usenet(訳注: 「ニュースグループ」の集まり) と WWW の標準写真フォーマットとして使うのに GIFよりかなり適しています。

多くの人は「損失のある圧縮(非可逆圧縮)」という言葉に怯えます。 しかし実際の風景を扱う場合、人間の眼に映るすべての情報を保存できるデジタル画像フォーマットは存在しません。 実際の風景で比較すると、JPEGはGIFより失う情報がはるかに少ないのです。 非可逆圧縮の本当に不都合な点は、画像の圧縮と解凍を繰り返すとそのたびに少しずつ画質が劣化していくということです (参照: [10] 圧縮・解凍を繰り返すと画質の劣化は大きくなるの?)。 これはある種のアプリケーションソフトにとっては重大な欠点ですが、多くの他のソフトではまったく問題ありません。

3. どんな時にJPEGを使ったらいいの? GIFでないとダメな時って?

ある種の画像ではGIFは画質とファイルサイズの両方とも優っているので、JPEGは完全にGIFを置き換えるに至っていません。 JPEGについて最初に学ぶことは、どんな種類の画像に使うべきかということです。

一般的に言うと、JPEGはフルカラーやグレイスケールの「写実的な」風景の画像− スキャンした写真や連続したトーンの作品、それに似たもの − を保存するのにGIFより優れています。 どんななめらかな色の変化でも、例えば明るくなった部分や暗くなった部分で生じる色の変化でも、JPEGの方がGIFよりも少ないディスクスペース(ファイルサイズ)で忠実に表現できます。

GIFは色数が少なく色の違いがはっきりした画像、例えば線画や単純なイラストにたいへん適しています。 GIFはそんな画像では損失なしに圧縮できるだけではなく、たいていJPEGよりもファイルサイズが小さくなります。 たとえば、広い部分がまったく同じ色だと、GIFでは本当にとっても小さく圧縮されます。 このような画像では JPEG はかなり画質を落とさないと GIF のようには圧縮することができません。 （これの一例として、太い単色の枠線がJPEGは苦手なのに対してGIFはとっても得意ということが挙げられます。)

コンピュータが作り出した画像、たとえばレイトレーシングCG画像は、複雑さでは写真と単純なイラストの中間ぐらいです。 そういう画像や、もっと複雑で精密にレンダリングされた画像は JPEGに適しています。 半現実的な絵画(ファンタジー絵など)も同様です。 しかし、色数がほんのちょっとだけのアイコンは GIF の方が適しています。

JPEGは非常にシャープなエッジが苦手です。 たとえば真っ白と真っ黒が隣り合ってるような場合です。 非常に高い画質で保存しない限り、シャープなエッジ(色や明るさのくっきりとした境界)はボケる(にじむ)傾向があります。 こんなにシャープなエッジは写真では珍しいのですが、GIFファイルでは枠線で囲んだり文字を乗せるなどの加工が施されていることが結構よくあります。 小さい文字がにじんで汚れるのはとっても困ります。 小さいサイズの文字がいっぱいのGIF画像は、JPEGに変換してはいけません。 (説明文をJPEG画像に付けたいなら、画像にかぶせるよりも、むしろコメントとして画像データに内蔵したほうがいいでしょう。 古い画像ビュアーはコメントを無視するかもしれませんが、最新のJPEGソフトウェアはJPEGファイル中のコメントを扱えます。) (訳注: 今これを読んでる人にとって一番よく使うJPEG表示ソフトはWEBブラウザだろうと思うのですが、残念ながら最新バージョンであってもJPEGコメントを表示できる WEBブラウザは存在しないようです。)

白黒2値の画像は決してJPEGに変換してはいけません。 白黒2値画像は上で言った状況全てにひっかかります。 JPEGで白黒(グレイスケール)画像をきれいに扱うには、白黒の階調が少なくとも16段階必要です。 JPEGにはそんな弱点がありますが、グレイスケールは最大256階調なので、GIFでも損失なしで扱えてしまいます。

GIF画像をたくさん持ってるなら、GIFをJPEGに変換することでディスクスペースを節約したくなるかもしれません。 これは思ったよりもうまくいきません。 というのもGIF画像に写真画像が含まれていてもそれはすでに減色されているので、JPEGにとってはすごくまずい素材なのです。 写真でない画像はたいがいの場合GIFのままにしておくべきです。 上質の写真のGIFを、画質を劣化させずに変換することは可能です。ただしそれは、どうすべきか知っていて、さらに個々の画像処理に時間をかけられる場合に限られます。 そうでなければ、画質劣化しまくりかファイルサイズ爆発しまくりか、ひょっとすると両方の事態に陥るかもしれません。 GIFをJPEGに変換したいなら、第8章と第9章を読んでください。

4. JPEGは画像をどれくらい圧縮できるの?

写真などのもともと想定している種類の画像を扱う場合、とってもよく圧縮できます。 フルカラー画像は圧縮してない状態で通常1ピクセルあたり24ビットのデータです。 よく知られた損失がない圧縮方法は、そのようなデータを平均しておよそ2分の1に圧縮することができます。 JPEGは保存に必要なディスク容量を1ピクセルあたり1〜2ビットまで効果的に引き下げるので、目に見える損失なしに10分の1から20分の1という圧縮をなしとげます。 30分の1から50分の1の圧縮は、少し画質を落とせば可能ですし、プレビュー画像や書庫のインデックス画像のような非常に低い画質であれば100分の1にもちゃんと圧縮できます。 JPEGで100分の1に圧縮した画像は、画像サイズが10分の1のフルカラー(無圧縮)サムネイル画像と同じディスクスペースしか使いませんし、そんなサムネイル画像よりも細部(ディテール)を残しているのです。

比較のために同じ画像をGIFで圧縮することを考えてみましょう。 まず、大部分の色情報を犠牲にして256色(1ピクセルあたり8ビット)に減らします。 これで3分の1に圧縮できます。 GIFはさらにLZW圧縮を組み込んでいます。でも、LZWは典型的な写真のデータにあまりうまく作用しません。全体で最高5分の1に圧縮できるかもしれませんが、LZWが逆にファイルサイズを増やしてしまう(つまり全体の圧縮が3分の1を下回ってしまう)ことはまったく珍しくありません。 LZWは線画のような単純な画像でうまく作用します。それがGIFでその種の画像をうまくあつかえる理由なのです。 目に見える画質の劣化が出ないよう十分に高い画質設定でフルカラーの写真データからJPEGファイルを作った場合、同じデータから作ったGIFファイルよりもだいたい4分の1から5分の1小さくなります。

グレイスケール画像ではそんなに圧縮できません。 人間の目が色彩の変化よりも輝度の変化に非常に敏感なので、JPEGは輝度(グレイスケール)データよりも色データを重点的に圧縮しています。 グレイスケールJPEGファイルは、似た画質のフルカラーJPEGファイルよりだいたい10%から25%小さいだけです。 でも、圧縮してないグレイスケールデータは1ピクセルあたり8ビットで、フルカラーデータの3分の1のサイズしかありません。それで圧縮比率を計算してみると全然高くないのです。 グレイスケール画像では5分の1の圧縮あたりで画質の劣化が目につくようになることがしばしばあります。

劣化が見えないギリギリの圧縮はどれくらいかというと、これは閲覧環境によって変わってきます。 個々のピクセルが小さければ小さいほど劣化を見極めるのが難しくなります。 それで、高品質のカラープリントアウト(300dpi以上)よりもコンピュータディスプレイ(70dpiほど)上での方が劣化は目につきます。 このように高解像度の画像は、もともと大きいことを考えると幸いにも、きつい圧縮が許されます。 上で述べた圧縮比は、コンピュータディスプレイで見る場合の典型的な値です。 さらに、劣化が見えない限界は画像によってかなり変化する点にも注意が必要です。

5. JPEG保存の時のよい「品質設定値」って?

大部分のJPEG圧縮ソフトは、品質の設定でファイルサイズを重視するか画質を重視するか選べるようになっています。 この設定値の意味について誤った解釈が広まってるようです。 「品質95」は、一部の人が主張している「情報の95%を保つ」という意味では決してありません。 品質の設定値は何かに対するパーセンテージではなく、独立した数値です。

実際、品質の設定値の範囲はJPEGソフトウェア全体で標準化されてはいません。 この文書で議論している品質設定値の幅は、IJGの自由(フリー)な JPEGソフトウェア(参照: 第2部 第15章)と、それに基づく多くのソフトウェアにあてはまります。 JPEGを扱う他のソフトウェアでは、品質設定値の幅はまったく違っています。 たとえば…

幸いにもこの混乱は、異なるソフトウェア同士でのJPEGファイルのやりとりを妨げることはありません。 しかし、JPEGを作成するソフトウェアが変われば品質の範囲が相当に変わると心に留めておく必要があります。そして、どのソフトウェアを使ったか言わなければ、「Q75で保存した」というような発言は全く意味がありません。

ほとんどの場合、ユーザーの目標は、オリジナルと見分けがつかない画質で小さいファイルサイズになるように、できるだけ低い品質設定値を決めることです。 この設定値は、画像によって、そして人によって変わってくるでしょうが、ここにいくつか経験則があります。

上質のフルカラー画像には、IJGの初期品質設定値(Q75)がたいへんおすすめです。 この設定値は、代表的な画像で欠点を見出さずに済む、一番低いものです。 まず最初にQ75を試してください。それで画質の劣化が気になるなら設定値を上げてください。

画像が初めから決して完全な品質でないなら、これはだめだというほど劣化させずにQ50まで落とせるかもしれません。 逆に更なる劣化を避けるため、もっと高い品質設定にする必要があるかもしれません。 画像がディザリングやモアレパターンを含んでいる場合、これはよくあることです。(参照: [9] GIF画像をJPEGに変換するコツは?)

実験的な目的を除いて、Q95より上にしてはいけません。 Q100にすると、画質がQ95とほとんど変わらないにもかかわらず、2〜3倍も大きいファイルができあがります。 Q100は使える設定値というより数学的な限界です。 Q100で作られたJPEGファイルを見たとしたら、それは制作者が自分のしたことをわかっていないというかなり確かな印です。

たいへん小さいファイル(プレビューや一覧用の画像)が欲しくて、低い画質でもかまわないなら、5〜10の品質設定値にするのがいいでしょう。 Q2くらいは「オップ・アート(光学芸術)」として面白いかもしれません。(それは、現在のIJGソフトウェアがそのような低い品質向けに最適化されていないと言うべきでしょう。将来のバージョンは低い品質設定値、小さいファイルサイズで、よりよい画質を達成するかもしれません。)

画像にはっきりした色の境界があるなら、品質設定値をどんなに高くしても、そのような境界の部分にわずかなにじみやギザギザができるかもしれません。 これは、JPEG圧縮ソフトで色のダウンサンプリングをオフにすれば、ファイルサイズを犠牲にして抑制することができます。 IJGエンコーダでは、品質設定とは関係なく独立したオプションとしてダウンサンプリングをオン・オフすることができます。 cjpegプログラム(訳注: IJGのJPEGエンコーダ)では、コマンドラインスイッチ "-sample 1x1" でダウンサンプリングをオフにできますし、 IJGライブラリに基づく他のソフトウェアでは、ダウンサンプリングを制御するためにチェックボックスなどを用意しているかもしれません。 IJGライブラリを使っていないソフトウェアでは、利用者がダウンサンプリングを制御する手段を用意しているかもしれないし、していないかもしれません。 たとえばアドビPhotoshopでは、高い品質設定にすると自動的にダウンサンプリングがオフになります。 たいがいの写真画像では、ほとんど視覚的な影響がなくディスクスペースをたっぷり節約できるので、ダウンサンプリングをオンのままにしておくのがおすすめです。

ダウンロード時間を減らすために、インターネットで使う画像の画質をちょびっと落とすというのはたいていの場合よいことです。 品質設定がおよそ50の場合、ウェブ上ではまず問題ありません。 実際、256色環境のブラウザでそんな画像を見る人には、ブラウザが表示のために減色加工してJPEG画像自体の欠点を隠してしまうので、もっと高画質の画像との違いはわからないでしょう。 また、現在のプログレッシブJPEGを作るソフトウェアは、品質設定が50から75あたりであることを前提にした作りになっています。 (訳注: プログレッシブJPEGは、最初は全体をおおまかに、データが読み込まれるにつれ細部がはっきりしてくるような表示のされ方をするJPEGデータです。くわしくは「[11] プログレッシブJPEGって何?」を見てください。ただし、表示するソフトの中には途中の状態を表示しないものもあります。) 50よりかなり低い場合は、最初のおおまかに表示される部分がすごく汚く見えますし、逆に75よりかなり高い場合、後で細かく表示されるはずのところがデータが読み込まれても全く変化がないように見えてしまいます。

6. どこでJPEGソフトウェアを手に入れられるの?

略。

7. どうすればJPEG画像を見られるの?

見られなくて困ってる人はいないと思うのでこれも略。

8. 色量子化って何?

多くの人々は、フルカラー(1ピクセルあたり24ビット、1600万色)を表示できるハードウェアを持っていません。 安いパソコンでは1ピクセルあたり8ビットの情報を扱うので、同時発色数が最大256となります。 フルカラー画像を表示するために、コンピュータはよく使われている色を選び出して、画像をこれらの色にあてはめなければなりません。 この過程は「色量子化」と呼ばれています。 (これは、少し不適切な名称です。 「色選択」や「色削減」のほうが適切な用語でしょう。 でも規格の用語に従うとしましょう) (訳注: ここでは「減色処理」という訳を使っていきます。)

減色処理は明らかに損失のあるプロセスです。 たいがいの画像では、JPEG自身の画質の劣化の度合い(非常に低い品質設定値の場合をのぞく)よりも、減色処理方式の優劣の方が、最終的な画質に及ぼす影響はかなり大きいのです。 よい減色処理の方式を編み出すのはむずかしいことです。そして、一つの方式でどんなタイプの画像でも最高にきれいに処理できるというわけにはいきません。

JPEGはフルカラーのフォーマットなので、256色やそれ以下の表示環境でカラーJPEG画像を表示するには減色処理をする必要があります。 そのような環境で動くJPEGビュアーの速度と画質は、主にその減色方式によって決まります。 早いけど汚い方式か奇麗だけど遅い方式のどっちが使われるかによって、256色環境のビュアーではフルカラー環境のときよりもずっと大きな画質の違いを見ることができるでしょう。

一方、GIF画像は256色以下に減色済です (GIFは常にそれぞれの画像に固有のパレット(色の組み合わせ)を持っています。またフォーマット上パレットの色数が256以上になることを許していません)。 GIFは、画像を表示する時ではなく、画像を作成する時に前もって減色処理の計算を済ませておくという長所を持っています。 これがGIF画像ビュアーはJPEGビュアーよりも表示が早い理由のひとつです。 しかし、これはまたGIFの欠点でもあるのです。GIFで保存する時は減色処理で頭を悩ませることになります。 もし表示できる色数と違う色数で減色した場合、このGIFデータを表示させるとすると、表示能力を無駄に余らせるか、表示できるようさらに減色する(フルカラー画像から一回だけ減色処理したものよりたいがい非常に低い画質に終わります)ことになります。 さらに、作成ソフトウェアが高品質の減色処理方式を使用していなければ、残念なことに画像はダメになってしまいます。

この理由のため、画像を作成した表示環境とはちがう機械を持つすべてのユーザーにとってJPEGはGIFより大変よい画質を約束します。 JPEGのフルカラー画像は、閲覧者の表示環境にきちんと合うよう減色することが可能です。 さらにすでに持っているJPEG画像をもっときれいに表示するために、減色処理方式の将来の改良を利用することができるし、よりよい表示のハードウェアを購入することもできます。 GIFは、永久にそのままです。

これに大変関わりのある問題が現在の多くのWEBブラウザで見られます。 256色環境で動作するとき、ブラウザはどの画像にも前もって決めておいたパレット(色の組み合わせ)を無理矢理使うのです (これはブラウザがWebページのいろいろな項目について、使える色数が限られた中、色の割り当て方法で悩まないようにするためです)。 事実上2回目の減色処理が強制されているので、写真から作成したGIF画像はこの状況ではたいがい非常に画質が落ちます。 写真から作成したJPEG画像は(256色環境では)きれいに見えないかもしれません。でも、一度だけの減色なので、同じ写真から作成したGIF画像より悪くは見えないでしょう。

256色(8ビット/ピクセル)以上を表示できるハードウェアを持っている人が増えています。 ハイカラー(15または16ビット/ピクセル)環境は今ではすっかり普通ですし、本当のフルカラー(24ビット/ピクセル)環境も珍しくありません。 そういう人たちにとっては、性能をフルに利用した表示ができないので、GIFはすでに時代遅れです。 JPEG画像はもっと有効に表示能力を使えます。

要するに、ハードウェアの種類に関わらず写真画像を表示するには、JPEGはGIFよりも全ての面でよい選択になります。

時々、GIFから変換したJPEGの表示には減色処理は全く必要ないと考える人がいます。 それは間違いです。 256色以下のGIFからJPEGを作っても、JPEG圧縮を解凍した時に出てくるのは256種類の色でなく何千もの色なのです。 JPEGでの劣化が各ピクセルに少しずつ違う影響を及ぼして、初めは同じ色だった2つのピクセルはたいてい少し違う色になるため、こういうことになります。 画像全体について見てみると、それぞれ本来の色は近くにある色で「汚され」ます。 したがって、カラーJPEGを256色環境で表示するには画像の元が何であれ常に減色処理が必要になります。

同様に、JPEG画像に何色使われているかを語ることにはほとんど意味がありません。 たとえ色の違うピクセルの数を数えようとしても、違うJPEGデコーダーを使えば計算誤差のため違った結果が出てしまいます。 ネットニュースで時折「256色のJPEG」と記述された投稿画像を見かけます。 これは投稿者が(a)このFAQを読まずに(b)おそらくGIFからJPEGに変換したということを物語っています。 JPEGはカラーまたはグレイスケールとして分類することができます。しかし、色数を数えるということは、普通の写真ではそんなことはしないのと同じように、JPEGにとっても意味がありません。

9. GIF画像をJPEGに変換するコツは?

GIFファイルをJPEGに変換することは、やっかいな仕事です。 ――限界いっぱいのデータを全く違うところへ押し込むわけで、その結果はひどいものになります。 確かにGIFから作ったJPEGは、本当の24ビットカラーデータから作ったものみたいに高品質なことはありえません。 しかし手に入れた画像がGIFで、ディスクスペースを節約したいなら、最高の結果を得るためのヒントがいくつかあります。

用心ときれいな元画像があれば、GIFと同等の質のJPEGを作ることはたいてい可能です。 これはJPEGとGIFのピクセル1つ1つがまるっきり同じに見えるということではありません。 特に256色環境以外で、JPEGの表示に使われる減色処理は、元データからGIFを作るのに使われた減色処理とはおそらく全く違うからです。(参照: [8] 色量子化って何?) しかし個々のピクセルを見てみると、GIFはフルカラー元データにそんなに忠実でないのを思い出してください。 画像全体を見た場合、変換したJPEGは元のGIFと同じくらいきれいに見えるようにできます。 一部の人々はフルカラー環境では慎重に変換したJPEGはディザパターンが除去されているので、元のGIFより本当にきれいに見えると主張します。 (ディザリングについては後述します)

一方、適していない画像の変換やいい加減なやり方でのJPEGへの変換は確実に質の低下を招くことになります。 もし下に示すやっかいな分量の苦労が受け入れられないのなら、GIF画像はそのままにしておく方がよいでしょう。 単純に、JPEG品質を非常に高くセットしはじめるとディスクスペースをどんどん浪費します(GIFのファイルサイズを突破するでしょう)。 また、いくつかの画像はどうしても画質が落ちるでしょう。

コツその1は、JPEGに適していない画像は決して変換してはいけないということです (参照: [3] どんな時にJPEGを使ったらいいの? GIFでないとダメな時って?)。 でかくて高画質の写真画像はたいてい元データとして最高です。 そして、そういう画像はGIF形式ではファイルサイズが大きいので、変換すれば大幅にディスクスペースを節約できます。 (100Kバイトよりずっと小さいGIFは変換しようかと悩まないことです。そんな小さいファイルではディスクスペース節約に役立ちません)

コツその2は画像の出所を知ることです。 GIF-JPEG間の変換の繰り返しは画像をぐちゃぐちゃにしてしまうこと請け合いです。 変換済みの画像を再変換してはいけません。

コツその3は枠線を取り除くことです。 多くの人がGIF画像のまわりに太い単色の枠線をつける変な習慣を身につけてしまいました。 役に立たない一方、これはGIFファイルではファイルサイズにほとんど関係しません。 でもJPEGファイルの場合、これはファイルサイズや展開速度に関係してきます。 更に悪いことにくっきりとしたフチの枠線は、目に見えるニセモノ(ゴーストエッジ)を作ってしまいます。 さらに256色環境で枠線のあるJPEGを見るとき、枠線はかなり面積が広いので減色処理アルゴリズムは枠線の色を重要だと考えてしまいます。そして枠線のためにパレットを浪費してしまいます。その結果、画像本体に使うパレットが減って画質が低下するのです。 だからJPEG変換する前に自分で愛情込めて枠線を切り取ってください。

最後のコツは、変換元のGIFを捨てる前に、満足できる変換ができたか確認するためにひとつひとつJPEG画像を見ることです。 これで必要があればもっと高い品質設定で変換をやり直すことができます。 また、ファイルサイズを比較して ― もし画像がJPEGに適したものでないなら、GIFより大きい、ほどよい画質のJPEGファイルが出てくるかもしれません。

グレイスケールの写真(白黒写真)はたいがいそんなに問題なく変換できます。 cjpegを使うときには、"-gray"スイッチを必ず使うようにしてください (そうしないとcjpegはGIFをカラーデータとみなしてしまいますので本当に白黒写真だったとしてもディスクスペースと時間を無駄にしてしまいます)。 デフォルト値(75)あたりの品質設定でたいがいきれいに変換できます。

カラー画像の場合はかなりやっかいです。 写真画像のカラーGIFはたいがい「ディザリング」されているので目がだまされてGIFが実際にあつかえる256色よりも色数が多く見えます。 画像を拡大してみると、隣り合ったピクセルの色はたいていかなり違うことがわかるでしょう。 普通のサイズでは、目の錯覚でこれらのピクセルの色が混じりあって一つの色に見えるのです。 JPEGにとってディザリングの問題点は、それが空間周波数の高いカラーノイズのように見えるということです。 そしてJPEGはノイズをあまりよく圧縮することができません。 その結果できあがるJPEGファイルは、もともとのフルカラー画像(もし持ってたら、ですが)から直接JPEG化したものより大きくて低画質になります。 これをなんとかするには、GIF画像を圧縮の前に「なめらかにする(スムージング)」必要があります。 スムージングは見たとおりの色に近くなるよう隣り合ったピクセルの色をならし、JPEGで問題になる急激な色の変化を取り除きます。 スムージングによる効果は、圧縮ファイルのサイズを減らして、スムージングを使わない時よりもきれいに見える画像ができることなのです。

IJG JPEGソフトウェア(cjpegやそれに由来しているプログラム)にはシンプルなスムージング機能が組み込まれています。 GIF画像から変換するときは "-smooth 10" などを試してください。 この設定値を10から25にすると高画質GIFにいいようです。 かなりきついディザリングのかかったGIFだともっとスムージングの値を大きくしてやる必要があるかもしれません (拡大しなくてもGIF画像に規則的なうろこ状のパターンが見えるなら強力なスムージングが明らかに必要です)。 ただ、スムージングの値を大きくしすぎるとイヤになるくらい画像がボケます。 画像処理の達人であれば別のフィルタリングプログラムでスムージングをすることもできますが、そのようなツールの解説はこのFAQの範囲を越えますのでここでは触れません。

カラーGIFから変換する際に、よいスムージング設定値を選択したなら、品質設定値85あたり(デフォルトより少し高い)が通常よいでしょう。 適度なスムージングをかけてもディザパターンを隠せないなら、品質設定値をもっと高くしなければいけないかもしれません。 本当にひどいディザリングがされたGIFは、GIFのままにしておくのが一番です。

GIFから変換したJPEGファイルがフルカラーのオリジナルから直接つくったJPEGよりも小さいことを期待してはいけません。 ディザリングによるノイズはファイルサイズを肥大させますが、画像をボケさせずにノイズを取っ払うことはできません。 概して、GIFから変換したJPEGでよい画質のものは、GIFのサイズの2分の1から3分の1程度です([4] JPEGは画像をどれくらい圧縮できるの?で示した4分の1にまでは小さくなりません)。 JPEGがGIFのサイズの半分よりかなり大きくなるなら、これは画像をまったく変換すべきでないというしるしです。

この結論は、"cjpeg -quality 85 -smooth 10" が多分カラーGIFを変換するためのよい出発点であるだろうということです。 しかし画像を気にするなら、結果をチェックして、他のいくつかの設定をいじってみるようにしましょう。 この設定や他のどんな設定でも、大量のGIF画像を機械的に一括して変換することは大失敗の元です。

10. 圧縮・解凍を繰り返すと画質の劣化は大きくなるの?

JPEGで画像を圧縮して、解凍し何らかの加工をして(枠線を切り取る、など)、最初にJPEG化した時の画像の劣化からさらに劣化させないでふたたびJPEGで圧縮できたらすばらしいでしょう。 残念なことにそれはありえません。 一般に加工修正をした画像をJPEGで再圧縮するとさらに多くの情報を失うことになります。 ですから何度も再圧縮しないで済むようにすることが大切です。

JPEGファイルを解凍せずにあつかえて、通常の画像処理ソフトで読込み・再圧縮した場合のさらなる劣化をさせずにすむ専門的なオプションがいくつかあります。 特に、画像寸法がファイルのブロックサイズ(一般的にカラーJPEGでは16ピクセルx16ピクセルか、16x8、8x8のいずれか)の整数倍なら、劣化させずに90度回転と反転が可能です。 この事実はまさに学術的な好奇心をくすぐりますが、デジタルカメラの多くのユーザーが画質を劣化させずに画像を横長から縦長に回転させたいと思っているため、最近では実用的な重要性を帯びてきました。 ― そして実際、JPEGで記録できる全てのデジカメはこの機能が使えるよう適切な寸法の画像を出力するようになってます。 それでJPEGを劣化させずに変形できるソフトウェアが現れはじめました。 しかし通常の画像処理ソフトで画像を回転させてJPEGで再圧縮すると画質の劣化があるので特別なソフトウェアが必要となります。

画像を解凍して、最初に使ったのと同じ品質設定で再圧縮するなら、比較的ほんのわずかの画質の劣化で済みます。 これはJPEG画像の他の部分を劣化させずに、局部的な修正ができることを意味します (しかし修正を加えた部分はどうしても劣化してしまいます)。 直感に反して、これには低めの画質設定の方がよいのです。 しかし正確に同じ設定値を使う必要があります。そうでなければ全てがパーです。 また解凍された画像は、フルカラーのフォーマットで保存しないといけませんし、 JPEG→GIF→JPEGのようなことをするなら、減色処理の段階でたくさんの情報を失うことになります。

残念なことに、「切り抜き」は局部的な変更とは見なされません! JPEGは画像を小さいブロックに分割して処理しています。「切り抜き」をするとブロックの境界をたいがい動かすことになります。そのためJPEGからすると画像が完全に違うように見えてしまいます。 残っているブロックが同じ場所で始まるように、ブロックサイズ(たいがい16ピクセル)の倍数だけ上と左の余白を切り取るよう気をつければ、画質の劣化を低く抑えることができます。 (正真正銘の劣化のない切り抜きは、切り抜く部分の制限が同じですが可能です。しかし、これにはまた専門のソフトウェアが必要です)。

JPEGは画像を小さく保存して伝送するのに役立つフォーマットですが、画像処理の途中の段階を保存しておくのには使わない方がいいです。 画像処理作業中は画質の劣化のない24ビットのフォーマット(PNG、TIFF、PPM、その他)を使い (訳注: フォトショップならPSD、GIMPならXCFと、そのソフトウェア専用のフォーマットがある場合はそれを使いましょう)、保管したりネットに上げたりする時にJPEGを使います。 将来もう一度画像を編集するつもりなら、もとの劣化のないデータを保存しておきましょう。 ウェブサイトに置いたJPEGは派生コピーであるべきで、編集用マスターであってはいけません。

11. プログレッシブJPEGって何?

通常のJPEG(ベースラインJPEG)ファイルでは、上から下へ順に1回で画像が表示されます。 プログレッシブJPEGでは、何回かに分けて画像が表示されます。 1回目は、ほんの少しの量のデータで、非常に低品質設定相当の画質で画像の全体を表示します。 あとはだんだんとデータが読み込まれていくにつれ画質が上がっていきます。 そしてファイルサイズは同じ画質のベースラインJPEGとだいたい同じになります。 (基本的にプログレッシブJPEGは同じデータをもっと複雑な並びに組み替えたものです)

プログレッシブJPEGの利点は、転送中に画像を見る場合、おおまかな全体像をすばやく見てとることができ、少し待てばだんだん画質が上がっていくことです。 これは上から下へ画像がゆっくり表示されるよりもたいへんすばらしいことです。 欠点は、何回かに分けての表示で、各回の表示ごとにベースラインJPEGまるまる1枚分の計算量が必要になるということです。 したがって通信速度よりも速いデコーダーを持っている場合にのみプログレッシブJPEGは意味があります。 (データが速く到着するなら、プログレッシブJPEGデコーダーは途中経過の表示をとばすことで対応できます。 つまり幸運にもT1(速度が1.5Mbpsの回線)やもっと高速の回線を利用している人にはプログレッシブJPEGと普通のJPEGの違いはまったくわからないでしょう。 ですが、低速回線ではプログレッシブJPEGは威力を発揮します。)

最近までプログレッシブJPEGが魅力的に見えるアプリケーションが少なかったので、プログレッシブJPEGはあまり利用されていませんでした。 しかし、低速回線でWebブラウザを利用する人が増え、そしてパソコンがどんどん高速化したことでプログレッシブJPEGはWWWでの利用で勝利を収めました。 IJGの自由(フリー)なJPEGソフトウェア(参照: 第2部 第15章)は現在プログレッシブJPEGに対応しています。そしてその機能はWebブラウザやほかのソフトウェアに速い速度で広まっています。

徐々に表示する機能を除けばプログレッシブJPEGとベースラインJPEGは基本的にまったく同じもので、同様の種類の画像に適しています。 まったく画質を劣化させずにベースラインとプログレッシブの形式の変換が可能です。 (でもこれには専門のソフトウェアが必要です。 解凍して再圧縮という方法での変換は、計算誤差が発生するので画質劣化なしではありません)

プログレッシブJPEGファイルはベースラインJPEG専用のデコーダーでは読めません。 それで、プログレッシブJPEGが広く使われる前に、既存のソフトウェアはアップグレードされることになるでしょう。 プログレッシブJPEG対応ソフトウェアの最新情報は第2部第16章を見てください。

12. 透過JPEGって作れるの?

いいえ。 JPEGは透明度に対応してませんし、近々そうなる見込みもありません。 透明度をJPEGに加えることは単純な作業でないことが判明しました。 もしむごい詳細が知りたいならお読みください。

GIFや他のいくつかのファイル形式で見られるような従来の透明度を実現する方法は、透明なピクセルを示すために他で使っていない色を一つ選ぶというやり方です。 JPEGは画質の劣化がある(もともとの色と正確に同じ色のピクセルが必ずしも出てくるわけではありません)ので、その方法はJPEGでは使えません。 通常は小さなエラー(画質の劣化)はほんの少し画像に影響を及ぼすだけなのでかまいません。 でも、そのことがピクセルを透明な状態から通常へ、あるいはその逆に変えてしまうなら、特に実際の背景が透明な色とは全く異なっていれば、エラーは非常に目について困るでしょう。

もっと合理的な解決策は、JPEG画像に独立した色成分としてアルファチャンネル(透明の割合)を保存することです。 これはアルファチャンネルでのエラーが小さく、結果にあまり影響しない場合のみうまくいきます。 問題は、よくあるアルファチャネルがJPEGにとってまさに非常に不得意な種類の画像(広く平坦な部分が多く、それが急に変わる)だということです。 アルファチャンネルのためには非常に高い品質設定にしないといけないでしょう。 それをしなくても、ファイルサイズでの罰則は大きいのです。 このような透過JPEGは非透過JPEGのサイズの倍に簡単になってしまいます。 透明度の利用の代償としてはあまりに高すぎます。

唯一の本当の解決策は、画像本体に劣化のあるJPEGを使い、透明度のマスクに他のアルゴリズムを利用した劣化のない方式を使うというように組み合わせることです。 その機能があるファイル形式を開発して、標準化して、広めることは、小さい仕事ではありません。 私が知る限り、そんな重大な作業は行われていません。 透明度の対応には、そんなかなりの苦労をするだけの値打ちがあるとは思えません。

13. 画質の劣化がないJPEGはないの?

いくつかの違う圧縮方式が「JPEG」としてよく知られているので、この話題で大きな混乱があっても驚きません。 一般に使用されている方式は「ベースラインJPEG」(あるいはそれが変化した「プログレッシブJPEG」)です。 同じISO規格でも「ロスレス(損失なし)JPEG」と呼ばれるまったく違う方式が定義されています。 そしてさらに混乱に輪をかけるように「JPEG-LS」と呼ばれる新しい損失がない規格が世に出ようとしています。

ここで「損失がない」というのは、数学的に損失がないということを意味します。 損失がない圧縮方式では、解凍された出力データが最初の入力データと1ビットの違いもなくまったく同じことが保証されています。 これは「視覚的に元絵と見分けがつかない」よりも非常に厳しい要求です。 ベースラインJPEGはほとんどの写真のような画像を視覚的に区別がつかないよう圧縮することができますが、それには必ず損失があります。

ロスレスJPEGは、本当に損失がない、まったく異なる方式です。 しかしそれはベースラインJPEGほど圧縮率がよくありません。 だいたいフルカラーデータの2分の1ぐらいの圧縮率です。 そしてロスレスJPEGは連続した階調の画像でのみうまく動作します。 パレットカラー(インデックスカラー)画像や色の階調が少ない画像では圧縮が効きません。

ロスレスJPEGはいまだに一般的ではありません。 ― 実際のところ、一般のアプリケーションでは対応していないし、現在すでに廃れてしまっています (たとえば大部分の画像ではロスレスJPEGにかわって新しいPNGが標準となっています)。 これを認めて、ISO JPEG委員会は最近JPEG-LS(すでにLOCOという名前でそのことを耳にしたかもしれません)と呼ばれるまったく新しい損失のない圧縮規格を仕上げました。 JPEG-LSはロスレスJPEGよりもよく圧縮できますが、まだ損失のある方式には及びません。 この新しい規格が広く受け入れられるかどうかはまだわかりません。

最大の品質設定になるまで通常のJPEGの実行を繰り返しても損失のない保存をすることはできません。 最も高い品質設定値でも、様々な計算における誤差の影響があるのでベースラインJPEGには損失があります。 誤差は単独ではいつでもかなり小さいように見えるのですが、何回も圧縮を繰り返すと誤差は積み上がっていくでしょう(参照: [10] 圧縮・解凍を繰り返すと画質の劣化は大きくなるの?)。

通常のJPEGを使うにはたいそう効率が悪いので、多くの実装では初めから設定可能な最大値にはなっていません。 たとえば、IJG JPEGソフトウェアでは「品質100」を選ぶ必要があるだけでなく、情報の損失を最小にするために色のダウンサンプリングもオフにしなければいけません。 その結果できるファイルは、合理的な設定で作ったファイルよりはるかに大きくてほんのちょっと品質がよいだけです。 それでもまだわずかに損失があるのです! 本当に損失がない保存が必要なら、通常のJPEGを使ってはいけません。

14. どうしてファイル形式について議論するの?

厳密に言うと、JPEGとは圧縮方式を指し、 特定の画像ファイル形式のことではありません。 JPEG委員会は、国際標準組織内での縄張り争いによってファイル形式の定義を妨害されました。

一般に使うファイル形式であると認められない限り、私たちは実際に画像を他の誰とも交換することができないので、これは問題があります。 公式の規格がない場合、多くのJPEGプログラム作者は自分勝手にプログラムを作りはじめてしまい、その結果、プログラムは他の誰のものとも互換性を持たないことになります。

私たちが使っている標準のJPEGフォーマットに最も近いものは、C-Cube Microsystemsの人々によって作られたものです。 彼らはJPEGに基づく2つのファイル形式を定義しました。

JFIF (JPEG File Interchange Format)
ピクセルを伝送する「ローエンド」フォーマットで、ファイル内に他のものはほとんどありません。
TIFF/JPEG 別名TIFF 6.0
アルダスTIFFフォーマットの拡張です。 TIFFは画像に関する知りたかったことやたくさんのもっと他のことをあなたに記録させてしまう「ハイエンド」フォーマットです(^_^)。

JFIFはインターネットの上の事実上の標準として現れ、「JPEGファイル」といえば一般にこれを意味します。 大部分のJFIF表示ソフトは、まっとうなJFIFではないいくつかのフォーマットを取り扱えます。

JPEGを組み込んだTIFF 6.0は、重大な設計上の欠点があるため、対応しているソフトは多くありません。 修正されたTIFF/JPEG設計は、現在TIFFテクニカルノート#2に記載されています。 この設計はTIFF 7.0で使われるものです。 TIFFの新しい実装は、TIFF 6.0 の設計ではなく、JPEGの埋め込みのためのテクニカルノートの設計を使わなければなりません (私が知る限り、NeXTStepシステムだけが TIFF 6.0スタイルのTIFF/JPEGを本格的に使用しています)。 TIFF/JPEGが安定していても、JFIFほど広く使われることはありません。 さまざまなベンダーがわずかに違う共通部分のないTIFFをたびたび作り出すので、TIFFはJFIFよりはるかに複雑で、一般には使いにくいのです。 JPEGを組み込んでも何の助けにもなりませんでした。

アップルのマック用QuickTimeソフトウェアは、マック独自のPICTフォーマットの中に包まれるJFIF互換のデータストリームを使います。 JFIFとPICT/JPEGの変換は見事に率直で、いくつかのマック用ソフトウェアはそれができます(参照: 第2部 第8章)。 バイナリファイルをあつかえるエディタがあれば、手作業でPICT/JPEGファイルからJFIFを取り出すことができます。 くわしくは次のセクションを見てください。

ニュース速報: ISO JPEG委員会は縄張り争いに勝ったようです。 彼らは、JPEG規格の新しい「パート3」拡張で SPIFF と呼ばれる完全なファイル形式の仕様を定義しました。 それは勝負にかなり遅れたので、実在のファイルにどれだけ影響を与えるかわかりません。 SPIFF は JFIF と上位互換性を持つので、それが広く採用されたとしても、大部分のユーザーは多分気づかないでしょう。

15. どうやってファイル形式を見分けて、どう扱えばいいの?

手元のソフトウェアで読めないあやしげなJPEGファイルがあったら、 それはJPEGをベースにした独自形式のファイルかもしれません。 ファイルの最初の数バイトを調べればそれが何かわかります。

  1. JFIFスタンダードファイルは4バイトのFF D8 FF E0(16進数)から始まります。そして2バイトの不定数(たいがい16進で 00 10)が続き、そのあと 'JFIF' が続きます。
  2. 最初に FF D8 FF があって 'JFIF'マーカー がなければ、多分それは全く JFIFではない JPEGファイルでしょう。 大部分のJFIFソフトウェアは文句を言わずにそれを読むはずです。 もしJFIFマーカーがないと文句を言うようなものを使っているなら、別のデコーダーを試してみましょう。 (とても古いJPEGファイルととても新しいものにはJFIFマーカーがありません。 ― 新しいSPIFF規格では JFIFマーカーを使わないと言ってます。 問題があるなら、ソフトウェアベンダーに文句を言いましょう。)
  3. マックのPICTファイルは、 JPEG圧縮されているなら数百バイトのヘッダ(たいてい726バイトですが必ずしもそうとは限りません)があり、JPEGデータがあとに続きます。 3バイトの並び FF D8 FF(16進)を探しましょう。 文字列 'Photo - JPEG' はこのヘッダの前に通常すぐ現れ、'AppleMark' あるいは 'JFIF' はたいがいその後すぐ現れます。 FF D8 FF の前にあるすべてを取り去れば、たいていファイルを解凍(デコード)できます。 (PICTイメージが複数の「バンド」に分割されているなら、これは失敗するでしょう。 幸いそんなPICTはあまり一般的ではありません。 複数のバンドに分割されたPICTは、高さの合計が画像の高さになる複数のJPEGデータストリームを含んでいます。 一つの画像を表示するには、これらをつなぎあわせる必要があります。 ベイリー・ブラウンはウェブページ上でこの目的のための単純なツールをいくつか公開しています。
  4. ファイルがマックでつくられたものなら、マックバイナリヘッダがついたスタンダードJFIFファイルかもしれません。 この場合JFIFヘッダはファイル先頭から128バイト後に現れるでしょう。 最初の128バイトを取り除けば準備完了です。
  5. その他−独自形式か、まったくJPEGでないかです。 運がよければ、ファイルはヘッダと生のJPEGデータストリームという構成かもしれません。 JPEGデータストリームの始まり(FF D8 を探しましょう)が確認できれば、その前にあるすべてを取りさって見ましょう。

HiJaak Pro(訳注: 画像フォーマット変換ユーティリティのようです)のリリースのうち少なくとも1つは、バージョン2.01というJFIFファイルを書き出します。 そんな仕様は存在しません。 JFIFの最新のバージョンは1.02です。 どうやらHiJaakはバージョンの数字を逆にしてしまっているようです。 残念ながら大部分のJFIF画像を読むソフトウェアは、そんなファイルに出会うともうお手上げです。 というのも、JFIFの仕様では、メジャーバージョンナンバー(訳注: 整数部分+小数部分となってるバージョン番号の整数部分のこと)の変更は、フォーマットが互換性のないものへ変わることを意味すると定義されているからです。 もしこれまでにバージョン2.01が存在していたら、それはそんなに数が出ていなかったでしょう。現在のソフトウェアはそれを読めないし、試してみることすらしないのですから。 (HiJaakが他のソフトウェアとの相互試験をしたかどうか疑問です) もしこのような番号を付けまちがったファイルに出くわしたら、ファイルの12バイト目をバイナリエディタで2から1に書き変えることで修正できます。

16. 他にどんな互換性の問題があるの?

前のセクションで触れたファイル形式の問題点以外に、JPEGをやりとりする際、トラブルの原因となるものがいくつかあります。

プログレッシブJPEGを扱えない古いデコーダーにプログレッシブJPEGを食わせてみると、たびたびわけのわからないエラーメッセージを吐き出します。 「サポートされていないマーカー 0xC2 です」というようなエラーが出たら、それは明らかにプログレッシブJPEG非対応のデコーダーにプログレッシブJPEGを食わせたってことです (最新のソフトウェアについて詳しくはこのFAQの第2部を見てください)。 あるいは、「ファイルが壊れています」とか「JPEGファイルではありません」というありがちなエラーメッセージが出るかもしれません。

アドビPhotoshopや他の印刷用途向けのアプリケーションソフトウェアは、CMYKモードの画像をJPEGで保存すると4チャンネルCMYK JPEGを作ります。 印刷に関する知識がないソフトにはCMYK JPEGは(あるいは他のどんなCMYK形式のものも)決して対処できないでしょう。 ウェブ用にJPEGを作るときには、必ずRGBかグレイスケールモードで保存するようにしてください。

Photoshopも、かなり大きいサムネイル(プレビュー画像)をJPEGファイルのアプリケーション・セグメントに詰め込む習慣を持っています。 他のいくつかのアプリケーション(SunのJavaライブラリの特に早期のリリース)は、このデータで詰まらせると知られています。 これは明確にそのアプリケーションのバグですが、最も役立つ回避方法は今までどおりPhotoshopにサムネイルを保存しないよう指定することです。 ウェブ上に画像を置いているなら、サムネイルを埋め込むことはダウンロード時間の浪費にしかなりません。

異なるOSのマシン間で画像をやりとりする時には、まっとうに「バイナリ」転送するように気をつける必要があります。 テキストモードで転送すると、どんな種類のテキストフォーマット変換であれ、JPEGファイルを壊してしまうでしょう。 実際、JPEGだけでなく全ての画像形式にあてはまります。

17. JPEGはどう動作するの?

技術的な詳細はこのFAQの範囲外ですが、comp.compression FAQにある紹介や参考文献で探せるでしょう(参照: [24] FAQリストはどこでアーカイブされるの?)。

comp.compression FAQ は他の最高水準の画像圧縮方法(ウェーブレットやフラクタルなど)に関する情報のためのよい足がかりでもあります。 手っ取り早く比較してみると、 ウェーブレットは損失のある画像圧縮規格の次世代の基礎となりそうですが、標準化の流れの中でたぶんJPEGに10年遅れを取っています。 フラクタルは主要な商用の提案者によってひどく誇大宣伝されました。 人々がその本当の能力と限界を知るにつれ、支持を失っているようです。

18. 算術符号化って?

JPEGの仕様では、圧縮データの最終出力のために2つの異なる「最終段階」モジュール(ハフマン符号化と算術符号化)を定義しています。 どちらを選んでも画質には影響しませんが、算術符号化を使うとファイルをたいがいもっと小さく圧縮できます。 典型的画像では算術符号化の方がハフマン符号化よりも5〜10%小さいファイルを作ります。 (これまでに示したファイルサイズの数字はすべてハフマン符号化によるものです)

残念なことにJPEGの仕様に定められている算術符号化の手法は、IBMとAT&T、三菱が特許を持っています。 つまり、これらの会社から許可を得ない限り合法的に算術符号化JPEGを使うことはできません。 (例外もあります。合衆国特許法では、特許を受けた方法を科学的調査の目的でテストする場合に「試験的使用」として許可していますが、商用利用や個人が日常で使う場合はすべて違反となります。)

算術符号化JPEGはおすすめできません。 法律的ないざこざが起きる可能性を無視できるほどすごい圧縮率なわけではありません。 特にインターネットで画像をやりとりするのに算術符号化は絶対に使うべきではありません。 たとえあなたが合衆国特許法を気にしなくても他の人は気にします。

19. FPUを使うとJPEGの速度を上げることができるの? DSPチップは?

JPEGは非常に大量の計算を必要としているので、多くの人がFPUチップ(数値演算コプロセッサ)を使えば速度があがるはずだと言ってます。 これはそうではありません。 大部分の製品品質のJPEGソフトウェアは整数演算だけを使うので、浮動小数点を計算するハードウェアがあるかないかは関係ありません。

FPUチップは、DCT(訳注: Discrete Cosine Transform = 離散コサイン変換)の段階で浮動小数点演算を使う場合にほんの2、3の演算を助けることができます。 たいがいのパソコンクラスのマシンでは浮動小数点演算は整数演算よりもずいぶん遅く、全体的な速度は浮動小数点演算の使用でさらにもっと悪くなります。 いくつかの高価格ワークステーションやスーパーコンピュータは浮動小数点DCT法でやっていけるほど速い浮動小数点演算装置を備えています。

DSP(デジタル信号処理)チップは速い繰り返しの整数演算に適しているので、DSPでJPEG用にプログラムを組むと本質的にスピードアップすることができます。 DSPはいくつかのパソコンとワークステーションで追加装置(アドオン)として利用できます。 そのようなハードウェアを持っているなら、それを利用できるJPEGプログラムを探しましょう。

20. 動画用にM-JPEG規格ってあるの?

第1章で説明したように、JPEGであつかうのは静止画像だけです。 それでもビデオ用の「モーションJPEG」や「M-JPEG」の参考文献を求める人が後を断ちません。 そんな規格は存在しません。 いろいろなベンダーは一連の映像のひとコマひとコマに JPEG を適用して、その結果を「M-JPEG」と呼んでいます。 残念なことに、どれも認定された規格ではなく、それぞれ違うものになってしまってます。 できたファイルはたいがいベンダー間で互換性がありません。

MPEGは動画圧縮の認定規格です。 それはJPEGと同じ技術を多く使いますが、連続したコマ(フレーム)の間に通常存在する類似を利用してフレーム間圧縮を加えます。 このためMPEGは、類似した品質の「M-JPEG」方法より動画をだいたい3倍ほどよく圧縮できます。 MPEGの不利な点は、 (1)圧縮するのにはるかに多くの計算を必要とする(視覚的に似た部分を見つけることはコンピュータにとってむずかしい)ことと、 (2)1フレーム単位で編集をするのがむずかしい(各フレームが隣のフレームと緊密に結びついている)ことです。 (2)の問題のためビデオ編集製品では「M-JPEG」方式の方がかなり人気があります。

認定されたM-JPEG規格がないことは恥ずかしいことです。 でも実際には存在しないので、「M-JPEG」と呼ばれている製品を買ってしまうと、そのベンダーに囲い込まれてしまうことに気づきましょう。

最近、マイクロソフトとアップルは「標準」M-JPEG方式(困ったことにそれぞれ違う方式)を推進しはじめました。 その努力のどちらが現在の混乱の状況を変えるかはわかりません。 両社は静止画JPEGファイル形式で自分たちの案を全く誰にも採用してもらえなかったので、 今度も期待しない方がいいでしょう…。

MPEGの詳細についてはMPEG FAQを見てください。

21. 8ビット以上の精度が要る時は?

ベースラインJPEGは色標本当たり8ビット、言いかえればRGBモード画像のピクセル当たり24ビット(訳注: Red, Green, Blue 各8ビットで合計24ビット)、グレイスケールでピクセル当たり8ビット、CMYKだと32ビット(訳注: 同様にCyan, Magenta, Yellow, blacK 各8ビットで合計32ビット)…を画像に保存します。 もっと高い精度を必要とするアプリケーションのために1標本あたり12ビットの拡張があります。 たとえば、医療用画像にはしばしば12ビットのグレイスケールが使われています。 でも、12ビット拡張はあまり広く使われていません。 それをサポートするパッケージのひとつが自由(フリー)な IJG ソースコードです(参照: 第2部 第15章)。

ロスレスJPEGの規格では、1標本あたり2ビットから16ビットまでどのデータ精度も許しています。 しかし、高精度のロスレスJPEGは高精度の損失のあるJPEGよりもサポートされていません。 スタンフォードPVRGコーデック(参照: 第2部 第15章)は、話によると1標本あたり最高16ビットのロスレスJPEGに対応しているとのことです。

22. 自作プログラムでJPEGファイルから画像のサイズを得るにはどうしたらいい?

JPEGファイルのヘッダは「マーカー」と呼ばれる一連のブロックから構成されています。 画像の高さと幅は、SOFn(Start Of Frame, type N)マーカーに保存されます。 SOFnを見つけるには先行するマーカーを読み飛ばさなければなりません。 他のマーカーの中に何が入っているかを知る必要はなく、読み飛ばすためだけにその長さを利用します。 必要とされる最小限の論理は、おそらくCコードのページです (一部の人々は、マーカーブロックの構造がどうであれ、単純に SOFn を表しているバイトのペアを探す方法を推薦しています。 先行するマーカーがSOFnというパターンを含むかもしれないし、あるいはJPEG圧縮のサムネイル画像を含むかもしれないので、これは安全ではありません。 マーカーの構造を無視すると画像本体のサイズではなくサムネイルのサイズを得ることになるかもしれません)。 たっぷりコメントされたCの例は、IJG が配布している rdjpgcom.c (参照: 第2部 第15章) の中で見つけられます。 perlだと wwwis です。

23. WWW上で画像利用についてどこで学べるの?

WEB上で静止画像を表示したいとき、ほとんどのWEBブラウザで扱える画像フォーマットである JPEG か GIF のどちらかを選ぶことになります (PNGがWEB上でGIFに取って代わるぐらい普及するのは間もなくだろうと我々は期待しています。参照: PNGについての情報)。 たいがいの画像の場合、どちらのフォーマットを選べばいいのかはっきりしています(参照: [3] どんな時に使ったらいいの?)。 画質を下げればファイルサイズを小さくできるという JPEG の能力は、WEB上で写真表示にかかる時間を調整するのに特に役に立ちます。

しかし、WEBデザイン特有でかつ、現在一番使われているブラウザに特有として知られる多くのことがらがあります。 このFAQでは、WEBグラフィックスデザインについては触れません。基礎的なよい情報は次のサイトで見つけられます。

また、さらに高度な情報があるサイトもあります。

24. FAQリストはどこでアーカイブされるの?

前略。 Internet FAQ Archives。後略。

2004.06.18. https://mimi.moe.in/nmp/ もうパンツはかない