JPEG2000実習 ビットレート編

本日のお題:ビットレートと圧縮率は、コインの裏表


さて、今日は、かなり簡潔に行きます*1


最近の日本における大規模電子化プロジェクトは、JPEG2000のレイヤーを、ビットレートで指定することが多いですね。


例えば、

など。


ところが、これまでに見てきたように、OpenJPEGでは、各レイヤーの指定を圧縮率で指示します。例えば、http://d.hatena.ne.jp/denshikA/20100604で見たように、

C:\image_to_j2k.exe -i C:\test.tif -o C:\aaa.jp2 -r 50,20,10

という場合、「50分の1に圧縮したレイヤーと、20分の1に圧縮したレイヤーと、10分の1に圧縮したレイヤーを作成してください」ということでしたね。


はて、どうしましょう?


その昔、http://d.hatena.ne.jp/denshikA/20091204に書きましたとおり、ビットレートと圧縮率はコインの裏表のように1対1対応してまして、カラー画像で言うと、

ビットレートファイルサイズ
24そのまま
12半分
83分の1
64分の1
46分の1
38分の1
2.410分の1
212分の1
124分の1
0.24100分の1

となります。ちなみに、「ビットレート0.08にしなさい」というのは、グレースケール画像の時に出てくるお話で、ちょうど「100分の1に圧縮しなさい」というのと同義です。


仮にカラー画像で、「ビットレート0.20のレイヤーを作りなさい」と言われたら、

C:\image_to_j2k.exe -i C:\test.tif -o C:\aaa.jp2 -r 120*3

とすればOKです。


そして、仮に「可逆レイヤーとビットレート0.20のレイヤーを作りなさい」と言われたら、

C:\image_to_j2k.exe -i C:\test.tif -o C:\aaa.jp2 -r 1,120

とすれば良いということは、もう皆さんはお分かりですね。


というわけで、レイヤー指定については、ビットレートで指示されようが、圧縮率で指示されようが、恐れることはありません。なぜなら、両者は、コインの裏表なのですから。

*1:しかし、今、大規模電子化プロジェクトなどで使うJPEG2000変換について、あれこれ調べている人にとっては、重要な内容かもしれませんね。

*2:個人的には、0.20というのは中途半端な数字だと思うのですが、何か意図があるんでしょうかね?>某国立図書館さん

*3:ビットレート0.24のとき、100分の1なので、ビットレート0.20のときは、120分の1ですね

JPEG2000実習 ロスレス/ロッシー編 その2

本日のお題:ロッシーの時だけ使える秘密兵器がある


前々々回(http://d.hatena.ne.jp/denshikA/20100602)、JPEG2000の変換について、実習できる環境(OpenJPEG)をご紹介しました。ご自分で変換してみると、よりよく理解できるはずなので、時間の許す限り、やってみてください。*1


そして、前回、JPEG2000には、ロスレス/ロッシー境界線というものがあるんですよ、というような話をして、圧縮率との関係で、ロスレス(可逆)とロッシー(不可逆というものが、決まって来るんですよ、ということだったと思います。(ですよね?http://d.hatena.ne.jp/denshikA/20100607


前回は、どちらかというと、ロスレス側のお話だったので、今日は、どちらかというと、ロッシー側についてお話します。


いきなり、コマンドプロンプトを開いて、OpenJPEGで2つの変換をしてみましょう。

C:\image_to_j2k.exe -i C:\test.tif -o C:\100R.jp2 -r 100
C:\image_to_j2k.exe -i C:\test.tif -o C:\100I.jp2 -r 100 -I


これまでのシリーズを読んでいただいた方には、最初の変換は明々白々ですね。「100分の1に圧縮してくれ」ということですね。そして、2個目の変換は、その変換の末尾に「-I」というのが付いただけですね。


早速、できたファイルを確認してみましょう。

どちらも、107KBですので、ちゃんと100分の1に圧縮されていますね。


では、画像を開いてみて、確認してみてください。何か違いがありますか?

クリックすると、大きな画像が見られます。

  100R.jp2   100I.jp2 
 


おそらく、あまり違いがなかったと思います。


目で見て分からないときは、数値に頼るしかありません。そこで、PSNRとSSIMを測定してみましょう。*2

   100R.jp2   100I.jp2 
PSNR31.21231.654
SSIM0.97480.9760


PSNRで見ても、SSIMで見ても、100R.jp2より100I.jp2の方が高い数値ですね。これは、すでにhttp://d.hatena.ne.jp/denshikA/20090921で説明したとおり、「元の画像により近い」ということを意味しています。つまり、

100R.jp2より100I.jp2の方が画質が良い

ということですね。


このことは、100分の1だけでなく、200分の1でも、500分の1でも同じことです。以下のような変換をして、

C:\image_to_j2k.exe -i C:\test.tif -o C:\200R.jp2 -r 200
C:\image_to_j2k.exe -i C:\test.tif -o C:\200I.jp2 -r 200 -I


C:\image_to_j2k.exe -i C:\test.tif -o C:\500R.jp2 -r 500
C:\image_to_j2k.exe -i C:\test.tif -o C:\500I.jp2 -r 500 -I

PSNRとSSIMを測定してみると、

   200R.jp2   200I.jp2 
PSNR27.13827.965
SSIM0.93450.9412


   500R.jp2   500I.jp2 
PSNR23.48824.206
SSIM0.84470.8667

となります。ね、Iの方が大きいでしょ。


つまり、ここで荒っぽく結論しますと、

「-I」をつけて変換すると、画質が良くなる

ということが言えます。


ただし、注意していただきたいのは、「-I」というのは、ロッシーの場合だけ使うことができる「秘密兵器」なのです。ロスレスで使う*3とどうなるのか、と言うと、

C:\image_to_j2k.exe -i C:\test.tif -o C:\100RI.jp2 -r 1 -I


こんな感じで変換はできちゃいますが、出来上がった画像はロスレスではありません。
本物のロスレスとの比較をしてみましょう。

ニセモノ:C:\image_to_j2k.exe -i C:\test.tif -o C:\100RI.jp2 -r 1 -I
ホンモノ:C:\image_to_j2k.exe -i C:\test.tif -o C:\100RI.jp2 -r 1



ファイルサイズが1,284KBですので、本物のロスレス(1,950KB)より小さいですよね。つまり、ロスレスじゃないんです。


というわけで、ロッシーの場合に限り、「-I」というのを末尾につけることで、画質を改善することができるわけなんですが、この「-I」に関連して、いろいろと用語があるわけで、

「-I」なしの別名 :w5x3フィルタ、整数5/3、単に5/3など
「-I」ありの別名 :w9x7フィルタ、浮動小数点9/7、単に9/7など

というような表記を見つけたら、このことを言ってるのだと思ってください。

*1:でも、実際にやらなくても、わかるようにお話していきますので、ご安心を。

*2:PSNRとSSIMについては、こちら参照。http://d.hatena.ne.jp/denshikA/20100224/

*3:つまり、「-r 1 -I」を末尾につけて変換する、ということですね

JPEG2000実習 ロスレス/ロッシー編 その1

本日のお題:ロスレス/ロッシー境界線


前々回(http://d.hatena.ne.jp/denshikA/20100602)、JPEG2000の変換について、実習できる環境をご紹介しました。ご自分で変換してみると、よりよく理解できるはずなので、時間の許す限り、やってみてください。*1


いきなり、コマンドプロンプトを開いて、OpenJPEGで以下の変換をしてみましょう。

C:\image_to_j2k.exe -i C:\test.tif -o C:\lossless.jp2 -r 1


前回(http://d.hatena.ne.jp/denshikA/20100604)説明したとおり、「-r 1」というのは、「1/1に圧縮する」ということなので、つまり、直訳すると「圧縮しないでね」という意味になりそうですね。


結果を見てみると、

という感じで、予想に反して、おおよそ1/5(≒ 10,672 ÷ 1,950)に圧縮されちゃってますね。おかしいですね?


次に、圧縮率を2から6まで変化させて、

とやってみると、結果が

ですので、「1/2に圧縮」「1/3に圧縮」「1/4に圧縮」「1/5に圧縮」すると、同じサイズのファイルになり、「1/6に圧縮」すると少し小さいファイルができますね。


なんでこんなことになるのか、というところを見て行きましょう。


JPEG2000における圧縮には、ロスレス/ロッシー境界線というものがあります。


ロスレス(Lossless)というのは、ロス(画像情報をうしなっちゃうこと)がレス(ないこと)なので、JP2変換した後でも、元の画像に戻すことができます。(なので、別名、可逆変換とも呼ばれます。)


一方、ロッシー(Lossy)というのは、ロス(画像情報をうしなっちゃうこと)しちゃいます、ということなので、JP2変換した後、元の画像に戻すことはできません。(なので、別名、不可逆変換とも呼ばれます。)


そして、ロスレスなのか、それとも、ロッシーなのか、ということは、圧縮率の問題だと思ってください*2


圧縮率がある範囲内であれば、ロスレスだけれども、ある範囲を超えるとロッシーになってしまうわけです。


今回の実験の場合、おおよそ「1/5に圧縮」と「1/6に圧縮」の間に、ロスレス/ロッシー境界線があるようです。つまり、「1/5に圧縮」で圧縮した画像は、ロスレスだけれども、「1/6に圧縮」で圧縮した画像は、ロッシーですよ。


そして、下図のように、ロスレス/ロッシー境界線のロスレス側は、圧縮率の設定を変えようが何しようが、一定のファイルサイズ(一定の圧縮率)となります。すでにロスレスなのに、それ以上圧縮率を下げても意味ありませんよ、ということらしいです。


(ここから重要)
なので、「-r 1」というのは、額面どおりに受け取ると「1/1に圧縮する」ということなのでですが、その本当の意味は、「ロスレスのレイヤーを入れてください*3」という指示なのです。なぜなら、圧縮率の設定が1なら、必ずロスレス/ロッシー境界線のロスレス側に来るからですね。



(おまけ)
ちなみに、OpenJPEGでは、「-r」の指定を省略すると、「-r 1」が指定されたのと同じ取扱いになりますので、前々回に例示した「C:\image_to_j2k.exe -i C:\test.tif -o C:\out.jp2」という変換は、「C:\image_to_j2k.exe -i C:\test.tif -o C:\out.jp2 -r 1」ということであり、「ロスレスのレイヤーを1つだけ含むJP2を作ってください」ということになります。

*1:でも、実際にやらなくても、わかるようにお話していきますので、ご安心を。

*2:本当は違いますので、次回、訂正しますが、とりあえず、今日のところは、圧縮率の問題だとしておきましょう。

*3:レイヤーについては、前回をご覧ください。

JPEG2000実習 レイヤー編

本日のお題:JPEG 2000の「レイヤー」は、「領地の分け前」のことなんです。


前回(http://d.hatena.ne.jp/denshikA/20100602)、JPEG2000の変換について、実習できる環境をご紹介しました。ご自分で変換してみると、よりよく理解できるはずなので、時間の許す限り、やってみてください。*1


前にJPEG 2000についてお話した時(http://d.hatena.ne.jp/denshikA/20091014)、

今回は、レイヤーに注目してみたのですが、レイヤーというのは、名称が良くない。レイヤーと聞くと、

こんなものを連想してしまいます。ところが、JPEG 2000で言うところのレイヤーというのは、こういう「物理的な積み重ね」ではなくて、「切れば切るほど、画質が鮮明になっていく特殊な金太郎飴」みたいなものです。なので、レイヤーという言葉にダマされないようにしてください。

と書きました。


実際、いろいろな方とJPEG 2000についてお話していると、多くの方が、レイヤーのところで誤解をされています。*2


なので、今日は、スパッと、実習をしてみることで、すっきりさせておきたいと思います。


まずは、コマンドプロンプトを開いて、OpenJPEGで以下の3つの変換をしてみましょう。

C:\image_to_j2k.exe -i C:\test.tif -o C:\10.jp2 -r 10


C:\image_to_j2k.exe -i C:\test.tif -o C:\20.jp2 -r 20


C:\image_to_j2k.exe -i C:\test.tif -o C:\50.jp2 -r 50

前回と異なるのは、末尾に「-r 10」「-r 20」「-r 50」というのが付いている点です。


「-r 10」というのは、「元のファイルを、10分の1に圧縮してください」、
「-r 20」というのは、「元のファイルを、20分の1に圧縮してください」、
「-r 50」というのは、「元のファイルを、50分の1に圧縮してください」、
ということです。


実際に、結果を見てみましょう。

このように、
元のTIFFが、10MB(10,672KB)くらいの大きさですが、
「-r 10」の10.jp2は、1MB(1,042KB)ですし、
「-r 20」の20.jp2は、0.5MB(533KB)ですし、
「-r 50」の50.jp2は、0.2MB(214KB)ですね。
ちゃんと、10分の1、20分の1、50分の1になってますね。


では、本丸へ向かいましょう。レイヤーを作成してみます。


OpenJPEGでレイヤーを作成するときは、「-r 50,20,10」という感じで、それぞれのレイヤーの圧縮率を並べていけば良いんです。この例だと、3つ数字を並べているので、3つのレイヤーができます。OpenJPEGのルールとして、数字が大きい順*3に並べてください。


では、早速、コマンドプロンプトで、以下のように変換してみてください。

C:\image_to_j2k.exe -i C:\test.tif -o C:\aaa.jp2 -r 50,20,10


結果として、こうなりましたよね?


ここからが重要です。


ファイルサイズに注目してください。


通常、「レイヤー」と聞くと、そのレイヤー数だけ、画像があるものだと思います。なので、「-r 50,20,10」という感じで3レイヤーを作成すると、「-r 50」の画像と、「-r 20」の画像と、「-r 10」の画像が組み合わされるので、

0.2MB + 0.5MB + 1.0MB = 1.7MB

となると思っちゃいませんか?少なくとも、JPEG2000に初めて出会った時の私は、そうじゃないか、と思っちゃいました。


しかし、結果からすると、そうなってませんね。aaa.jp2のファイルサイズは、1,045KBですので、約1MBです。圧縮率としては、10分の1で、「-r 10」の結果とほぼ同じです。


中身の細かい話は抜きにして、おおよそ、こんな感じで理解してください。


JPEG 2000のレイヤー付き画像というのは、こんな感じになっていて、

別に、3レイヤーだからと言って、3つの画像があるわけでなく、一番大きな画像「-r 10」の領地内に、「-r 20」が自分の領地を分けてもらって、さらにその分けてもらった領地内に「-r 50」が自分の領地を分けてもらう、という感じです。


そして、

この図のように、「-r 50」の領地だけ表示させることもできますし、「-r 20」の領地だけ表示させることもできますよ、という仕組みです。


さらに、

こんな感じの「領地の分け前」を思い浮かべれば、「-r 10」でレイヤー1つでも、「-r 50,20,10」でレイヤーが3つでも、ほとんどファイルサイズが変わらない、という謎は、納得できませんか?


なので、(論点を明確にするため)極端な結論として、JPEG 2000では、レイヤーが1つだろうが、10,000あろうが、ファイルサイズは大して変わらないんです。レイヤー数が多ければ多いほど、(同心円状の)領地分割が細かい、というだけです。

*1:でも、実際にやらなくても、わかるようにお話していきますので、ご安心を。

*2:最近のJPEG 2000を採用している大型プロジェクトの仕様書にも、「おそらくレイヤーに関して勘違いしているんだろうな」と思われる箇所があります。

*3:つまり、圧縮率が高く、ファイルサイズが小さくなる順

JPEG2000実習 準備編

本日のお題:JPEG 2000の環境を揃えましょう。


最近、JPEG2000の変換について、質問をいただく機会が多くなってきましたので、しばらく、JPEG2000の変換について、実例をお見せしていこうと思います。自分でやってみる、というのが一番分かりやすいです。


JPEG2000の変換ツールは、OpenJPEG*1というフリーのソフトを使いましょう。
こちらに置きましたので、ダウンロードして、とりあえず、Cドライブ直下にでも入れてみてください。をクリックすると、ダウンロード開始するらしいです。*2

image_to_j2k.exe 直


次に、TIFFのファイルを一つ用意して、先ほどと同じように、Cドライブ直下にでも入れてみてください。こちらに、テスト画像も用意しておきました。

test.tif 直


こんな感じになりましたか?


そしたら、コマンドプロンプトを開いて、

C:\image_to_j2k.exe -i C:\test.tif -o C:\out.jp2


と打って、実行してみてください。*3


Cドライブ直下に、out.jp2というファイルができたはずです。それが、JPEG2000で圧縮されたファイルです。


ダブルクリックしても、画像が開かない場合、ビューワを用意しなくてはいけません。


Irfanview*4というフリーのビューワを用意しましょう。
まず、こちらをインストールして、

iview425j.exe 直

次にこちらを実行してみてください*5

irfanview_plugins_427_setup.exe 直


Irfanviewを開いて、先ほどできた「out.jp2」というファイルをドラッグしてみてください。JP2画像が開くはずです。


次回は、レイヤーというのは、一体何か、ということについて、実習を通じて、お見せしていきます。今回ご紹介した環境を整えていただいて、実際に変換してみると、より良く分かると思います。


しばらくの間、JPEG2000変換についてお話していきますので、お付き合いをお願いします。

*1:http://www.openjpeg.org/

*2:Windows以外の方は、http://www.openjpeg.org/index.php?menu=downloadへ行って、Compiled stuffというところにある3つから、自分のOSにあったものをダウンロードしてみましょう。

*3:基本的に、[image_to_j2k.exe] -i [元画像] -o [変換後のファイル名.jp2]という感じです。

*4:http://www.irfanview.com/

*5:JPEG2000を表示させるためのプラグインをはじめ、今、流通しているプラグイン全てがインストールされます。

リボン・スキャニングのまとめ

最後のまとめとして、リボン・スキャニング技術を採用している、実際のスキャナーを見てみましょう。各メーカーの宣伝文句を見てみると、これまでに解説しておいたことが声高に叫ばれているだけなので、あー、あのことね、とお分かりいただけると思います。



まず、Sunrise(サンライズ)社では、リボン・スキャニングのことをReelScanと呼んでいます。

ReelScan allows the operator to change or delete single poorly captured images through a very user-friendly segmenter module, without having to go through the whole re-scanning process.


http://www.sunriseimaging.com/reelscanpr.htm

という感じで、「without having to go through the whole re-scanning process. (再スキャンの必要がありません)」と強調されていますね。なぜ、この点が強調されるのかは、もうお分かりですよね。



次に、Wicks and Wilson(ウィック アンド ウィルソン)社では、リボン・スキャニングのことをVirtual Scanstationと呼んでいます。

Virtual Scanstation is the off-line QA software tool that enables digital images created from roll filmusing the 8850 Scanstation to be checked and reprocessed without having to re-access the microfilm. By separating the capture function from the QA routine, Virtual Scanstation provides a powerful toolkit that allows every image to be checked and adjusted away from the scanner.


http://www.wwl.co.uk/rollfilm-virtualscanstation.htm

という感じで、またもや、「without having to re-access the microfilm.(再スキャンの必要がありません)」と強調されていますね。さらに、後半部分で、「By separating the capture function from the QA routine, Virtual Scanstation provides a powerful toolkit that allows every image to be checked and adjusted away from the scanner.(スキャンと検査を分離することで、スキャナー本体がなくても、画像の検査と修正が可能です)」と言っていますが、すでに皆さんはお分かりのように、ちょっとセールスポイントがずれてますね。スキャンと検査を分離することで、マルチタスクから脱却できて、スキャンスピードが上がる、というところを強調して欲しいですよね。



続いて、NextScan(ネクストスキャン)社では、リボン・スキャニングのことを、まんま、Ribbon Scanningと呼んでいます。

NextStar eliminates the need for rescans resulting from density or frame detection problems, maximizing scanner utilization and productivity.


http://www.nextscan.com/products/nextstar.html

という感じで、またもや、「eliminates the need for rescans(再スキャンの必要がありません)」と強調されていますね。さらに、後半で、「 maximizing scanner utilization and productivity(スキャナーを最大限活用し、生産性をあげる)」とあり、マルチタスクから脱却できて、スキャンスピードが上がる、というところを強調しているように見えますね。



最後に、Mekel(メケル)社についてですが、まず

Roll film. Ribbon scan. Strip scan. Full fiche. Complete capture.
No matter what the technology is called, ・・・


http://www.thecrowleycompany.com/downloads/pdf/sell-sheets/MekelQuantum-SellSheet.pdf

と書いてあり、リボン・スキャニングに関して、「何と呼ばれていようが」という感じで、いろいろな呼称があることを認め、Mekelとしては、まんま、Ribbon Scanningと呼んでいるように思います。

The need to reload has been completely eliminated.

という感じで、またもや、「The need to reload has been completely eliminated.(再スキャンの必要がありません)」と強調されていますね。


というわけで、足早に、私が勝手に「超マイナーでありながら、メジャー級の進歩」と思い込んでいる「リボン・スキャニング」というものを紹介してきたシリーズを、とりあえず、終了します。








パレート法則とリボン・スキャニング

本日のお題:マイクロフィルムの電子化(スキャン)におけるいびつなコスト構造を理解しましょう。

*1


パレート法則とは、おおまかに言って、

20%のコストをかけたものが80%の利益を生み、80%のコストをかけたものが20%の利益しか生まない


ということですね。(wikipedia:パレートの法則)


マイクロフィルムのスキャンに関しても、パレート法則が有効かもしれません。


マイクロフィルムをロール1本スキャナにかけると、ほとんど全部のコマをちゃんと検出していきます。感覚として、99%〜99.9%は成功するでしょう。かなり高い確率なのね、と思うかもしれません。


ところが、「99%〜99.9%成功」というのは、「0.1%〜1%の検出ミス」を意味します。1ロールに2400コマくらい撮影されているとすれば、少なくて2コマくらいの検出ミスで、多ければ20コマくらいですね。


ここで、リボン・スキャニング以前の状況を考えてみましょう。そして、「コマ検出ミスを見つけ出し、そのコマを特定して、マイクロフィルム上から見つけ出し、再スキャンする」スピードがものすごく早い人がいたとします。こんな超人が検査/再スキャンをしたとして、おそらく、5コマくらいを再スキャンかける時間があれば、もう一度、ロール1本まるごと再スキャンしちゃった方が早いでしょう。人件費などを考慮すると、2コマを再スキャンかけるくらいなら、もう一度、ロール1本まるごと再スキャンしちゃった方が費用が安く済むでしょう。*2つまり、0.1%の検出ミスだったとしても、スキャンし直してしまったほうが良い、ということです。


そんな状況だとして、「99%成功」≒「1%の検出ミス」≒「20コマの再スキャン」というものが、どれだけ、コストと時間がかかるものであるのか、想像できますよね。あまり、厳密に計算したこともありませんし、してみようとも思いませんが、パレート法則の「80:20」なんて話ではなく、「90:10」とか、「99:1」とかになるかもしれません。


このように、マイクロフィルムの電子化(スキャン)というのは、基本的に、大部分の時間を再スキャンに費やし、大部分のコストが再スキャンのときに発生するものなのです。


すると、当然のことながら、再スキャンを短縮・省略すれば、大きなコスト削減につながるわけです。これまでに何度か説明していますように、リボン・スキャニングというテクノロジーは、この再スキャンをあまり発生しないようにするためのものであり、マイクロフィルムの電子化において、コスト削減の期待の大型新人なわけです。


そして、前に「マイクロフィルムのスキャンに関しても、パレート法則が有効かもしれません」と言いましたが、ちょっと注意が必要です。パレート法則というのは、80/20を基本としていて、

20%のコストをかけたものが80%の利益を生み、80%のコストをかけたものが20%の利益しか生まない

というような意味だとすれば、リボン・スキャニングが登場して、やっとマイクロフィルムの電子化(スキャン)は、パレート法則が有効な圏内に入ったと言えます。つまり、リボン・スキャニング以前、再スキャンの工程のせいで、

全体の99%の画像を作成する[最初のスキャン]に全体の1%のコストが費やされ、たった1%の画像しか作成しない[再スキャン]に99%ものコストが費やされている

というかなりいびつなコスト構造になっていたと思います。それが、リボン・スキャニングにより、

20%のコストをかけた[最初のスキャン]が80%の画像を作成し、80%のコストをかけた[コマ検出枠の修正]が残りの20%の画像を作成する*3

という状況になりつつあります。


というわけで、マイクロフィルムの電子化における、パレート法則の有効性について、少しはご理解いただけたでしょうか?

*1:提示している数字はあくまでイメージです。厳密な数字ではありませんので、おおよその状況をつかむ程度で聞いてください。

*2:ただし、再スキャンをしたところで、再びコマ検出ミスをしない、という保証はありませんし、むしろ、普通にコマ検出ミスをしますので、「再スキャンしちゃった方が安上がり」というのはあくまで説明を分かりやすくするための方便です。

*3:かなり無理のある言い方ですが、話の流れとして、さらっと流してください。