[JPEG方式の功罪]の変更点 - 極道な唄／ハンティングメモ

「JPEG方式の功罪」(2009/02/15 (日) 16:44:41) の最新版変更点

追加された行は緑色になります。

削除された行は赤色になります。

JPEG方式の功罪　　09/02/13 創始 　　筆者が、手探りで（コンピュータ内実験しながら）、書いています。 　　また、小学高学年／中学生に言って聴かせるスタイルで表現しています。 　　その意味で「嘘（？善意の？）／たとえ話」も混じっています。 ＜JPEGとは？＞ 　　情報処理の教科書ではありませんから、歴史や細かい技術を書く予定はありません。　良いところと悪いところを浮かび上がらせるように書きます。 　　今ではメモリーの大きさや情報伝達速度の速さが進化しましたが、文字だけを扱っていた時代に画像を送ろうと発想したときは、大変なことでした。　見かけ上、同じ情報を記憶し送るために色々な工夫がなされます。 　　その一つが、JPEG方式です。　どんな情報も、しょせんは、０と１との連なりです。　それを真面目に順番通り全部伝送するとき最大の情報量になります。　「００００１１１１」の情報の塊があったとき、「０が４つ／１が４つ」と送るのも一つの考えですが、節約になるとは限りません。　ところが、「００００１１１１」が３つ～５つと並んだときには、『「０が４つ／１が４つ」の繰り返し３回』と送るとすると、表現法次第で節約が始まります。 　　画像では、隣の「画素」同士に同じ色（ごく近い色）が並ぶ可能性が強く、更に、４ｘ４程度の画素に関して同じ傾向があり得ます。　それならば、「４Ｘ４個まとめて処理すれば良い」という発想が現れます。　ただし、４Ｘ４を単純にひと塊に置き換えると、情報量は「縮減」されるが、画像寸法を１／４（面積で１／１６）に縮めたことと同じか、更に悪いことになってしまいます。　新たに出来た「ひと塊」の隣に極端に異なる色が来たとき、「ざらつき」が生じるからです。　情報量節約の代償です。　正確ではないが、感覚的に書くならば、デジタル画像を１５０％拡大しただけで生じる「不快感＝ザラツキ感」を思い起こしてください。　実用に適しませんね。 　　「隣の画素同士で『滲み』を生じさせる」ことで、人間の視覚との折り合いをつける幾つかの方式が考え出されました。　『滲み』は、他方で、画像サイズを縮小したときの、隣接画素同士の処理（折り合いづけ）にも関わってきます。　JPEG方式内部では、この『滲み』の程度を調節できます（利用者からの調節はムツカシイ）。　その想定外の効果（知らないで利用するときには弊害）が、この稿の議論の副主題です。 　　もう暫らく続けます；－ 『滲み付け』の他に、もう一つの操作があります。　ここでも誤解を恐れずに例え話で書きますが、「大海原の写真」を想像して下さい。　僅かに「アミ（小型の海老？）」が浮遊していても、一部の生物学者以外には「アミ」には『情報』の値打ちはありません。　そこで、情報処理世界の「あみ（網）」を用意して「アミ」を漉し取ります。　画像は気が付かないところで単調になり、上で述べた効果で、明らかに情報サイズは小さくできます。　場合によっては、漉し取られるのは、誰にとっても「情報世界のゴミ」である場合もあり、これはとりあえず総ての人にハッピーなことです。 　　ただし、「網の目」のサイズが画像処理ソフトごとに一定でなく、問題です。　この稿で議論する主題です。　たとえ話に戻ります。　Ａ君が「細かい網目」で漉し取った後に、Ｂさんが「粗めの網」で漉し取り作業をしたとき、Ｂさんの第二の操作は効果も少ないし実害も少ない。 　　逆に、「粗めの網」 ⇒ 「細かい網」の連用は、第二の操作で効果も実害も強く発生する。　別人が、それぞれの意図で、２つの操作をするときは致し方ないが、少なくとも連絡が取り合える操作人の間では、また前人の操作が予想できるときには、第二の操作は強い意図の下に行われる必要があります。 　　「適切な処理ソフトで適切な処理をする」ことが重要です。 ここで、一旦項目を替えます。 ＜実地実験結果＞　　 　　幾つかのカメラと幾つかの処理ソフトに関して、実験的に調べた結果を示します。　「幾つかのカメラ」と述べたのには理由があります。　通常、プロフェッショナル仕様でない限り、ディジタルカメラの出力にはJPEG方式が選ばれ、その内部には固有のJPEG処理機能が隠れているからです。　これ自体は、カメラ機種やメーカーを替えない限り、恐らくユーザー側に選択肢はありません。　つまり、カメラのJPEGで言うところの特性を知って、以後の処理ソフトを用いるのが大切なのです。 　［テストの準備］　　 　　カメラから取り出したばかりの、「原画」を用意します。　比較のために、色調や明度・彩度が余り入り組まない「単調な」画像と、逆の「複雑な」画像が良いでしょう。　余裕があれば、３枚目に「白地に黒文字」のような、極端な画像を持ち込むのも良いかもしれません。 　［テスト内容］ 　　テスト操作とテスト評価はいくらでも複雑に出来ますが、操作はある程度のシナリオに沿って行うのが有効です。　　評価には、出来上がった画像の質の判定が重要ですが、多くの場合、質の数量化は難しいので、とりあえず『画像縮減比率』で見比べます。 　　『画像縮減率』について述べるには、また、話を元に戻す必要があります。　画像表現の初源的な方法はBMP方式でありましょう。　語源としてはビットマップの意味で、画素の並びに対応したバイトごとの（ビットごとの）情報値を、事実上加工なしに、記憶／伝送するもので、三色・各８ビットの２４ビット式を標準とすれば、100X100画素のフルカラー画像は、30,000バイト＝３０kBに相当します。 　　後に解かるように、多くのカメラが採用しているJPEG処理方式では、100X100 の画像は５～１０kB程度に縮減されるように設定されています。　縮減比率は、１７～３３％ということです。 　　これに対し、処理ソフトでは、ユーザーが縮減率を設定できるものと、お任せのものがあります。　お任せのものが特に要注意です。 　［最初のテスト］ 　　使い慣れている処理ソフトで、次の２つのことを試みて下さい；－ 最初のテストは、どちらでも宜しいが、「９９％画像縮小」と「約１度の傾斜補正」の二つのメニューを用意します。　これは、主に、カメラに搭載されたJPEGエンジンと手持ちのソフトのJPEGエンジンの相性を調べるものです。 　　先ず最初の、カメラから得られたばかりの「原画」の縮減率は１５～２５％程度の値を示していることを確認して下さい。　例えば、4000X3000画素＝１２MegPix　⇒　３６MBの最大ファイルサイズに対して、５～７MBのJPEG（１４～１９％）。 　　さて、この原画に 「９９％画像縮小」 を施します。　原理的には面積で９８％になりますから、最大ファイルサイズはそれだけしか小さくならないはずですが、加工後のJPEG画のサイズは元のJPEGサイズよりかなり小さくなることが普通です。 　　「1度程度の傾斜補正」 を施しても、実質縮小は数パーセントでも、同様の大きな縮減が現れます。　（大角度の補正を行うと、「隣の」画素が様変わりするので、話が変ります） 　　上の二つのテストで大きい差異が出る場合は、カメラと処理ソフトのJPEGエンジンの仕様が違うせいだと理解できます。 　　ごく希に、この程度の「画像面積の縮小」ではJPEG値が変化しない場合があるかもしれません。　その場合は、カメラ搭載のJPEGエンジンと手持ちのソフトのエンジンの特性が限りなく近いのだと理解しておきましょう。　（カメラメーカー提供の専用ソフトがあれば、適切なのかもしれません） 　　これまでも、これからも、「JPEG操作で縮減が大きくなることは悪いこと／JPEGエンジンが低級なこと」と言うものではありません。　ただ言えることは、「追加操作でJPEGサイズが大きくなることは殆んどなく、失われた情報が戻ることは決してない（非可逆性）」と言うことです。　つまり、無意識のJPEG操作でファイルが小さくなることを望むのも、小さくならないのを喜ぶのも、いずれも、本末転倒だということです。 　［１／２縮小テスト］　　 　　第二に提案するテストは、画像の「１／２縮小」テストです。　ここで１／２とは寸法で半分にしますから、面積では１／４です。 　　２つのことに興味があります。　 　　第一は、手持ちの、ある特定ソフトで、一旦１／２縮小して、更に「別のテスト」をしたらどうなるかと言うことです。　「別のテスト」には、更に二つモデルを用意します。　（総てを試みる必要はありません）　テストの趣意も含めて、理解し易い／イメージし易いものを確かめたら多分充分です。　二つのモデルとは、同じソフトを使った「更に１／２縮小」と「９９％に縮小」です。　結果を示す前に、もう一つの提案に進みます。 　　第二のテストは、手元に２つ以上のソフトがある場合です。　大体提案の趣意が読めてきたと思います。　「ソフトＡとソフトＢを組み合わせた」テストです。　判り易いモデルでは「Ａで１／２縮小した後、再びＢで１／２縮小」と「Ｂで１／２縮小した後、再びＡで１／２縮小」を行うことです。　一方で「Ａを使った１／２縮小、１／２縮小の連続２段技」。　同じことをＢで行って、更に「Ａによる直接１／４」、「Ｂによる同じ操作」の６つの結果を互いに比較するのです。

JPEG方式の功罪　　09/02/13 創始　09/02/15加筆 　　筆者が、手探りで（コンピュータ内実験しながら）、書いています。 　　また、小学高学年／中学生に言って聴かせるスタイルで表現しています。 　　その意味で「嘘（？善意の？）／たとえ話」も混じっています。 ＜JPEGとは？＞ 　　情報処理の教科書ではありませんから、歴史や細かい技術を書く予定はありません。　良いところと悪いところを浮かび上がらせるように書きます。 　　今ではメモリーの大きさや情報伝達速度の速さが進化しましたが、文字だけを扱っていた時代に画像を送ろうと発想したときは、大変なことでした。　見かけ上、同じ情報を記憶し送るために色々な工夫がなされます。 　　その一つが、JPEG方式です。　どんな情報も、しょせんは、０と１との連なりです。　それを真面目に順番通り全部伝送するとき最大の情報量になります。　「００００１１１１」の情報の塊があったとき、「０が４つ／１が４つ」と送るのも一つの考えですが、節約になるとは限りません。　ところが、「００００１１１１」が３つ～５つと並んだときには、『「０が４つ／１が４つ」の繰り返し３回』と送るとすると、表現法次第で節約が始まります。 　　画像では、隣の「画素」同士に同じ色（ごく近い色）が並ぶ可能性が強く、更に、４ｘ４程度の画素に関して同じ傾向があり得ます。　それならば、「４Ｘ４個まとめて処理すれば良い」という発想が現れます。　ただし、４Ｘ４を単純にひと塊に置き換えると、情報量は「縮減」されるが、画像寸法を１／４（面積で１／１６）に縮めたことと同じか、更に悪いことになってしまいます。　新たに出来た「ひと塊」の隣に極端に異なる色が来たとき、「ざらつき」が生じるからです。　情報量節約の代償です。　正確ではないが、感覚的に書くならば、デジタル画像を１５０％拡大しただけで生じる「不快感＝ザラツキ感」を思い起こしてください。　実用に適しませんね。 　　「隣の画素同士で『滲み』を生じさせる」ことで、人間の視覚との折り合いをつける幾つかの方式が考え出されました。　『滲み』は、他方で、画像サイズを縮小したときの、隣接画素同士の処理（折り合いづけ）にも関わってきます。　JPEG方式内部では、この『滲み』の程度を調節できます（利用者からの調節はムツカシイ）。　その想定外の効果（知らないで利用するときには弊害）が、この稿の議論の副主題です。 　　もう暫らく続けます；－ 『滲み付け』の他に、もう一つの操作があります。　ここでも誤解を恐れずに例え話で書きますが、「大海原の写真」を想像して下さい。　僅かに「アミ（小型の海老？）」が浮遊していても、一部の生物学者以外には「アミ」には『情報』の値打ちはありません。　そこで、情報処理世界の「あみ（網）」を用意して「アミ」を漉し取ります。　画像は気が付かないところで単調になり、上で述べた効果で、明らかに情報サイズは小さくできます。　場合によっては、漉し取られるのは、誰にとっても「情報世界のゴミ」である場合もあり、これはとりあえず総ての人にハッピーなことです。 　　ただし、「網の目」のサイズが画像処理ソフトごとに一定でなく、問題です。　この稿で議論する主題です。　たとえ話に戻ります。　Ａ君が「細かい網目」で漉し取った後に、Ｂさんが「粗めの網」で漉し取り作業をしたとき、Ｂさんの第二の操作は効果も少ないし実害も少ない。 　　逆に、「粗めの網」 ⇒ 「細かい網」の連用は、第二の操作で効果も実害も強く発生する。　別人が、それぞれの意図で、２つの操作をするときは致し方ないが、少なくとも連絡が取り合える操作人の間では、また前人の操作が予想できるときには、第二の操作は強い意図の下に行われる必要があります。 　　「適切な処理ソフトで適切な処理をする」ことが重要です。 ここで、一旦項目を替えます。 ＜実地実験結果＞　　 　　幾つかのカメラと幾つかの処理ソフトに関して、実験的に調べた結果を示します。　「幾つかのカメラ」と述べたのには理由があります。　通常、プロフェッショナル仕様でない限り、ディジタルカメラの出力にはJPEG方式が選ばれ、その内部には固有のJPEG処理機能が隠れているからです。　これ自体は、カメラ機種やメーカーを替えない限り、恐らくユーザー側に選択肢はありません。　つまり、カメラのJPEGで言うところの特性を知って、以後の処理ソフトを用いるのが大切なのです。 　［テストの準備］　　 　　カメラから取り出したばかりの、「原画」を用意します。　比較のために、色調や明度・彩度が余り入り組まない「単調な」画像と、逆の「複雑な」画像が良いでしょう。　余裕があれば、３枚目に「白地に黒文字」のような、極端な画像を持ち込むのも良いかもしれません。 　［テスト内容］ 　　テスト操作とテスト評価はいくらでも複雑に出来ますが、操作はある程度のシナリオに沿って行うのが有効です。　　評価には、出来上がった画像の質の判定が重要ですが、多くの場合、質の数量化は難しいので、とりあえず『画像縮減比率』で見比べます。 　　『画像縮減率』について述べるには、また、話を元に戻す必要があります。　画像表現の初源的な方法はBMP方式でありましょう。　語源としてはビットマップの意味で、画素の並びに対応したバイトごとの（ビットごとの）情報値を、事実上加工なしに、記憶／伝送するもので、三色・各８ビットの２４ビット式を標準とすれば、100X100画素のフルカラー画像は、30,000バイト＝３０kBに相当します。 　　後に解かるように、多くのカメラが採用しているJPEG処理方式では、100X100 の画像は５～１０kB程度に縮減されるように設定されています。　縮減比率は、１７～３３％ということです。 　　これに対し、処理ソフトでは、ユーザーが縮減率を設定できるものと、お任せのものがあります。　お任せのものが特に要注意です。 　［最初のテスト］ 　　使い慣れている処理ソフトで、次の２つのことを試みて下さい；－ 最初のテストは、どちらでも宜しいが、「９９％画像縮小」と「約１度の傾斜補正」の二つのメニューを用意します。　これは、主に、カメラに搭載されたJPEGエンジンと手持ちのソフトのJPEGエンジンの相性を調べるものです。 　　先ず最初の、カメラから得られたばかりの「原画」の縮減率は１５～２５％程度の値を示していることを確認して下さい。　例えば、4000X3000画素＝１２MegPix　⇒　３６MBの最大ファイルサイズに対して、５～７MBのJPEG（１４～１９％）。 　　さて、この原画に「９９％画像縮小」を施します。　原理的には面積で９８％になりますから、最大ファイルサイズはそれだけしか小さくならないはずですが、加工後のJPEG画のサイズは元のJPEGサイズよりかなり小さくなることが普通です。 　　「1度程度の傾斜補正」を施しても、実質縮小は数パーセントでも、同様の大きな縮減が現れます。　（大角度の補正を行うと、「隣の」画素が様変わりするので、話が変ります） 　　上の二つのテストで大きい差異が出る場合は、カメラと処理ソフトのJPEGエンジンの仕様が違うせいだと理解できます。 　　ごく希に、この程度の「画像面積の縮小」ではJPEG値が変化しない場合があるかもしれません。　その場合は、カメラ搭載のJPEGエンジンと手持ちのソフトのエンジンの特性が限りなく近いのだと理解しておきましょう。　（カメラメーカー提供の専用ソフトがあれば、適切なのかもしれません） 　　これまでも、これからも、「JPEG操作で縮減が大きくなることは悪いこと／JPEGエンジンが低級なこと」と言うものではありません。　ただ言えることは、「追加操作でJPEGサイズが大きくなることは殆んどなく、失われた情報が戻ることは決してない（非可逆性）」と言うことです。　つまり、無意識のJPEG操作でファイルが小さくなることを望むのも、小さくならないのを喜ぶのも、いずれも、本末転倒だということです。 　［１／２縮小テスト］　　 　　第二に提案するテストは、画像の「１／２縮小」テストです。　ここで１／２とは寸法で半分にしますから、面積では１／４です。 　　２つのことに興味があります。　 　　第一は、手持ちの、ある特定ソフトで、一旦１／２縮小して、更に「別のテスト」をしたらどうなるかと言うことです。　「別のテスト」には、更に二つモデルを用意します。　（総てを試みる必要はありません）　テストの趣意も含めて、理解し易い／イメージし易いものを確かめたら多分充分です。　二つのモデルとは、同じソフトを使った「更に１／２縮小」と「９９％に縮小」です。　結果を示す前に、もう一つの提案に進みます。 　　第二のテストは、手元に２つ以上のソフトがある場合です。　大体提案の趣意が読めてきたと思います。　「ソフトＡとソフトＢを組み合わせた」テストです。　判り易いモデルでは「Ａで１／２縮小した後、再びＢで１／２縮小」と「Ｂで１／２縮小した後、再びＡで１／２縮小」を行うことです。　一方で「Ａを使った１／２縮小、１／２縮小の連続２段技」。　同じことをＢで行って、更に「Ａによる直接１／４」、「Ｂによる同じ操作」の６つの結果を互いに比較するのです。

表示オプション

横に並べて表示：

変化行の前後のみ表示：

極道な唄／ハンティングメモ

記事メニュー

緊急事項／作業

　新年度対策０８／０４?

ユーティリティ

　人名ノオト　
　地名ノオト
　地名人名　
　キーワード表
　ＨｏｍｅＰａｇｅリンク集　集積中

　町自慢邨自慢　リンク集　集積中

人気記事ランキング

最近更新されたページ

人気Wikiランキング

atwikiでよく見られているWikiのランキングです。新しい情報を発見してみよう！

全体ページランキング

最近アクセスの多かったページランキングです。話題のページを見に行こう！

「JPEG方式の功罪」(2009/02/15 (日) 16:44:41) の最新版変更点

緊急事項／作業

ユーティリティ

文献依拠

テーマ別

提言／起案