リボン・スキャニングが持ち込んだ「新しい土俵」 その2
本日のお題：「ながら」作業は非効率
このシリーズは、リボン・スキャニングについて、概要はご理解いただけていることが前提となっています。もし、なじみがなければ、以下を先にご覧ください。
http://d.hatena.ne.jp/denshikA/20100517
http://d.hatena.ne.jp/denshikA/20100518
http://d.hatena.ne.jp/denshikA/20100520
http://d.hatena.ne.jp/denshikA/20100525
前回（http://d.hatena.ne.jp/denshikA/20100526）に引き続き、リボン・スキャニングが持ち込んだ「新しい土俵」について、紹介していきたいと思います。
昨年、ちょっと「余計なお世話」な発表がありました。
携帯音楽プレーヤーiPod（アイポッド）を聞きながら、ネットで動画を見、インスタントメッセージを打ち、Eメールをチェックし、フェースブック（Facebook）をアップデートする――複数の作業を同時にこなす「マルチタスク」は良いどころか、どれもうまくできないとする研究結果を、米スタンフォード大学（Stanford University）の研究チームが[2009年8月]24日発表した
http://www.afpbb.com/article/environment-science-it/it/2634341/4496053
らしく、ほとんどの方が該当するのではないでしょうか？実際、今、電車で目の前に座っている女性も、音楽を聴きながら、難しそうな本を開いて、居眠りしています。（器用ですね。）
かく言う私も、Youtube見ながら、これを書いています。なので、誤字脱字、脱線、誤報は、お許しください、全て、「マルチタスク」のせいです。
気を取り直して、本日は、マイクロフィルムのスキャンにおける「マルチタスク」についてです。手短に行きます。
リボン・スキャニングが出現する前、マイクロフィルムのスキャナーは、「マルチタスク」を強いられていました。つまり、従来のマイクロフィルム・スキャナーは、
１．スキャンをしながら、
２．コマの自動検出をして、
３．コマを切り取って、
４．それぞれのコマをJPEG圧縮などして、
５．保存していく
という一連の作業を、一台でやらされていたわけです。
ところが、これまで見てきたので、お分かりいただけるように、リボン・スキャニングを採用しているマイクロフィルム・スキャナーは、
１．スキャンをしながら、
２．保存していく
ということしかしません。あとの画像処理は、別のPCに入っている、別のソフトにお任せするのです。
このことは、とても重要です。
従来のマイクロフィルム・スキャナーというのは、「マルチタスク」のせいで、スキャンスピードを上げることができませんでした。なぜなら、スキャンすると同時に、画像処理まで担当しなくてはならなかったのですから。ところが、リボン・スキャニング以降のマイクロフィルム・スキャナーは、スキャンと保存に専念できますので、チャキチャキ処理を進めていくことができるようになりました。
そして、スキャンしただけのRAWデータは、画像処理専用のPCに送り込まれ、こちらも「マルチタスク」の呪縛から解き放たれて、チャキチャキとスピーディーに処理を進めていくわけです。
人間だけでなく、マイクロフィルム・スキャナーだって、「ながら」作業は非効率だったのです。
というわけで、これまで見てきたリボン・スキャニングの長所は、「コマ自動検出にしくじった場合」に関係することだったので、「従来型スキャナーだって、しくじらなきゃいいんでしょ」という言い訳の余地を残していたのです。ところが、「マルチタスク」からの解放によるスピードアップについては、従来型スキャナーに弁解の余地はもうありません。やはり、時代の流れとして、リボン・スキャニングなのです。これが、リボン・スキャニングが持ち込んだ「新しい土俵」 その2です。
リボン・スキャニングが持ち込んだ「新しい土俵」 その1
本日のお題：ないものは見つからない
さて、リボン・スキャニングについて、概要はご理解いただけたことでしょう。
もし、なじみがなければ、以下を先にご覧ください。
http://d.hatena.ne.jp/denshikA/20100517
http://d.hatena.ne.jp/denshikA/20100518
http://d.hatena.ne.jp/denshikA/20100520
http://d.hatena.ne.jp/denshikA/20100525
これから、リボン・スキャニングが持ち込んだ「新しい土俵」について、いくつか紹介していきたいと思います。
ちょっと復習から始めます。マイクロフィルムをスキャンすると、こんな感じの画像が取り込めますね。
コマの自動検出がうまく機能したとすると、こんな感じになりますね。
そして、コマの自動検出をしくじると、こんな感じですね。
さて、応用に行きましょう。
もし、コマの自動検出をこんな感じでしくじると、どんなことになると思いますか？
こうなるのは、予想できますよね。
そして、ここから先は少しヤヤコシクなっていきますので、ゆっくり進んでください。
リボン・スキャニング以前の検査方法では、出来上がった画像を見ていきます。
なので、このような画像を検査していれば、「あれっ、3番目の画像がおかしいぞ！」と気付くわけですね。それで、再スキャンへ回すことが可能なわけです。（こちらを検査Ａと名付けておきます。）
ところが、
このような画像を見ていても、一体どこが異常なのか分からないですよね？（こちらを検査Ｂと名付けておきます。）
もうすでにお分かりだと思いますが、最初の検査Ａは、こちらのコマ検出ミスに該当しますね。
そして、次の検査Ｂは、こちらのコマ検出ミスに該当しますね。
つまり、リボン・スキャニング以前の検査方法では、「コマの抜け」に関しては、かなり無力だったんです。
ところが、一方、
リボン・スキャニングでは、
このような状態で検査していきますので、「コマの抜け」に関しても、ちゃんと検査できて、「おいおい、なんだよ、ここの部分で、コマ抜けになってるじゃないか」と気付き、その場で、コマ枠の修正ができるのです。
本日のお題にもある通り、「（そもそも画像として）ないものは（その異常性すら）見つからない」わけです。
というわけで、リボン・スキャニングが持ち込んだ「新しい土俵」その1として、
マイクロフィルム上のコマを全て電子化できているかどうか、という網羅性において、リボン・スキャニングはとっても優れた、新しい方法を持ち込んだんですよ
というものを挙げておきます。
リボン・スキャニングとは何か？その4
過去3回、リボン・スキャニングというものを説明してきました。
http://d.hatena.ne.jp/denshikA/20100517
http://d.hatena.ne.jp/denshikA/20100518
http://d.hatena.ne.jp/denshikA/20100520
リボン･スキャニング以前のスキャン方法の問題点は、ズバリ、再スキャンが発生した時の「頭だし」にあったと思います。個人的に、それ以外は、特に不満はなかったです。リボン・スキャニングの出現で、「頭だし」が不要になり、作業の効率の面でも、総合的な品質の面でも、大きく前進しました。
今回のシリーズの最後として、「頭だし」がなくなったワークフローを確認してみましょう。
まず、こんな感じで、どんどんとスキャンして、取り込んでいきます。
全てスキャンしたな、と思ったら、取り込んだ「リボン*1」を開いて見ましょう。
こんな感じで、開くボタンを押して、保存先のフォルダを選択すると、
こんな感じで、グァーっと画像が並びます。このとき、すでにコマ自動検出が働いて、コマ枠として、黄緑色っぽい枠が現れます。
各コマをちょっと拡大表示にしてみましょ。そして赤丸部分が、コマ自動検出をしくじっちゃったと想定しましょう。
まず、変更したい黄緑枠をクリック。紫枠に変化しますね。
とりあえず、間違った紫枠を削除。
紫枠は、移動したり、枠を拡大・縮小したりできますよ。
お好みの紫枠になったら、確定ボタンを押せば、
ほら、変更完了！
最後に、「じゃ、これで切り抜いて、1コマづつの画像にしてください」ボタンを押すと、指定フォルダ内に、マイクロフィルム1本分の画像ができあがるわけです。
ねぇ、ちょっとだけスゴいでしょ？
というわけで、要するに、コマ自動検出のしくじりを発見した時、これまでは、
わざわざフィルムを持ち出してきて、おおよその目星をつけて、（腱鞘炎に耐えながら）ひたすら早送りし、目星近辺に来たら、（眼精疲労にも負けず）虫眼鏡でお探し画像をひたすら探し、見つかったら、スキャナにセットして、画像をスキャンして、フィルムはもとあった場所へ戻しに行く
ことをしていたわけですが、リボン・スキャニングを採用していれば、
その場で、間違った枠を削除・移動・拡大・縮小することで、チャチャっと直せてしまう
わけでして、この両者の作業効率の差を、ご理解いただけたでしょう。
「でら、便利になったでしょ？」
*1:取り込んだフィルム丸ごと画像のことを、リボンと呼んでいます。かわいいでしょ。
リボン・スキャニングとは何か？その3
本日のお題： VHSの時代を思い出して！
前々回（http://d.hatena.ne.jp/denshikA/20100517）、リボン・スキャニングという「（自称）超マイナーでありながら、メジャー級の進歩」を紹介し、前回（http://d.hatena.ne.jp/denshikA/20100518）、コマの自動検出について、
マイクロフィルムを電子化していくとき、白黒のグラフをもとに、コマを検出し、自動的に切り抜いていくことが理論的に可能なこと
を説明し、
ところが、「理論的に可能」なことは、たいてい、現場では通用しません。
という、ありきたりな流れですね。流れについてけてないな、と思う方は、http://d.hatena.ne.jp/denshikA/20100517から始めてください。
そこで、本日、現場ではどんなことになるのか、ということを説明していきましょう。ただし、話を分かりやすくするために、かなり尾ヒレをつけて、脚色しますので、鵜呑みにしないでください。なんとなく、雰囲気を味わってください。
マイクロフィルムをスキャンすると、こんな感じの画像が取り込めますね。
コマの自動検出がうまく機能したとすると、
こんな感じになり、それぞれのコマを保存していきますので、
こんな感じの画像がたくさんできてくるわけですね。前にも引用しましたが、「16mmフィルムは幅16mm、長さが100フィート（約30.5m）でA4サイズの書類が2400枚程度撮影できます。*1」ということなので、1リールのマイクロフィルムをスキャンすると、2400枚画像ができる、というわけです。
ところが、これは理論上のお話です。
実際は、コマの自動検出をしくじる場合があります*2。緑枠がしくじってしまったところです。
すると、こんな感じの画像が出来上がってきます。
スキャン後の検査で、こんなコマ検出のしくじりを発見してしまうと、当然スキャンのやり直しをすることになるわけです。
でも、「しくじった部分だけ再スキャンすればいいんでしょ？」と思いますよね。ピンポン！正解です。
でも、「じゃあ、たいしたことないですね？」と思いますよね。ブブーッ！不正解です。
ここで、本日のお題「VHSの時代を思い出して！」の登場です。ヤングな方はご存知ないかもしれませんが、その昔、VHSというビデオテープがありました。ビデオテープの中のドラマとかを見ようとすると、「頭だし」なんてものをしなくてはいけなかったんです。ヤングな方、知ってます？／オールドな方、覚えてます？（以下、知っている人、思い出した人を対象に、話を進めます。）
マイクロフィルムのスキャンで、コマ検出のしくじりを発見した場合、しくじった部分だけ再スキャンすればいいんですが、そのしくじった部分を「頭だし」するのが、やたらと大変なんです。なぜなら、フィルムは長さ30mくらいで、中には画像が2400個くらい入っているんですから。
実際の流れでみていきましょう。
- うーん、大変だ、コマ検出のしくじりを発見 おおよそ何番目の画像だ？*3
- フィルムを頭だしするぞ！
- ここだ、ここ、フィルムをスキャナにセットして、はい、チーズ、カシャ！
さて、ここで、みなさん、「おおよそ何番目の画像だ？」というところで、例えば、1200番目くらいだと判明したとしましょう。マイクロフィルムの長さは30mくらいだとして、おおよそ半分の15m分を、手でハンドルを(300回転くらい)回して、早送りしていかないといけません。そして、だいたい1200番目と思われるあたりで虫眼鏡を用意して、1コマづつチェックしながら、スキャン画像と同じものをマイクロフィルムの中から探しだすのです。（場合によっては、頭だしが面倒なので、はじめから、スキャンし直しちゃうこともあるんです。そんで、またもや、コマ検出をしくじって、再々スキャンに突入し・・・という永遠のループに。）毎日こんなことしてたら、腱鞘炎になって、目も疲れて、寿命が縮みます。
VHSビデオでも、そうでしょう？おおよその時間が分かっていたら、そのあたりまで早送りでどんどん送っていって、近くにきたら、とりあえず再生して、ちょい早送りで頭だししてましたよね？途中、行き過ぎちゃったら、少し戻して、戻しすぎたら、少し送って、などと繰り返しながら。
その点、DVDは便利でいいですよね？頭だしする必要がなくて、見たい番組をメニューから選んで、ボタンをポチっと押すと、すぐにその部分から始まりますよね。
そうです、マイクロフィルムにおいても、リボン・スキャニングというものを利用すれば、そういうDVD的な簡単スタートが可能になってくるわけです。
というわけで、次回は、やっと、元に戻って、リボン・スキャニングにおける作業フローでも確認してみましょう。きっと、「でら、便利になったじゃん」と思っていただけるはずです。
*1:http://jcws.or.jp/microfilm.html
*2:多いか少ないか、それは分かりません。ただ、たった1個でも見つかると、以下で説明するような、かなり大変な作業が待っています。
*3:この画像の場合、単に3番目くらいになっていますが、もっと長いフィルムの一部をアップにしていると考えてくださいね。
リボン・スキャニングとは何か？その２
本日のお題： マイクロフィルムのコマ検出
前回、リボン・スキャニングという「超マイナーでありながら、メジャー級の進歩」と、私が勝手に思い込んでいるものを紹介しました。そして、
話を聞いただけだと、「なんだ、たいしたことないな」と思うかもしれませんが、この技術が出現する前に、マイクロフィルムがどうやってスキャンされていたのか、ということを知ると、「でら便利になったじゃんね」と思うはずです。
という流れですね。流れについてけてないな、と思う方は、http://d.hatena.ne.jp/denshikA/20100517から始めてください。
今日は、ちょっとだけ、技術的な「寄り道」をします。
マイクロフィルムというのは、幅16mmとか35mmのフィルムの中に、こんな感じで書類などが撮影されているわけです。
http://www.city.sano.lg.jp/reiki/reiki_int/reiki_honbun/ar12406221.html
そして、ひとつひとつの写りこんでいる書類の部分を、「コマ」と呼んでる（ようです）。
このマイクロフィルムをスキャンすると、こんな感じの画像になります。
そして、下図の赤線の部分に注目すると、ほとんど「黒」です。一方、青線の部分に注目すると、ほとんど「白」です。
この「黒」と「白」をグラフにしてみましょう。
ここまで来ると、お分かりだと思いますが、グラフで「谷」になる部分が、マイクロフィルムに写っている書類の「区切り」になりそうですね。こんな感じです。
さて、ついでですので、縦方向も見てみましょう。先ほどと同様、下図の赤線の部分に注目すると、ほとんど「黒」です。一方、青線の部分に注目すると、ほとんど「白」です。
この「黒」と「白」をグラフにしてみましょう。
またもや、グラフで「谷」になる部分が、マイクロフィルムに写っている書類の上下の「区切り」になりそうですね。こんな感じです。
そして、紫と緑の線で切り抜いていけば、コマの画像が取り出せそうですね。
という感じで、マイクロフィルムを電子化していくとき、白黒のグラフをもとに、コマを検出し、自動的に切り抜いていくことが理論的に可能なことがおわかりいただけたでしょう。
ところが、「理論的に可能」なことは、たいてい、現場では通用しません。そのことがもたらす、大混乱を、次回見ていきましょう。
リボン・スキャニングとは何か？
さて、このへんで再び、新聞電子化の現場をご紹介しましょう。本日の題材は、こちらのビデオ*1です。
以前、ちょろっとご紹介したように、書籍や新聞の電子化プロジェクトは、
すでにマイクロフィルム化されている場合はマイクロフィルムから電子化し、マイクロフィルムが無い場合は、紙面[ないしは原本]を直接電子化していきます。
マイクロフィルムから電子化したほうが、数段、楽チンだからです。
その「マイクロフィルムから電子化」について、ちょっと前に、地味に、大幅な技術的な進歩があったので、ご紹介しておきましょう*2。
その名は、「リボン・スキャニング」です。その他にも、別称がいくつか存在していますが、おそらく、「リボン・スキャニング」が一番通じると思います。
「リボン・スキャニング」というのは、
というような意味です。
先ほどの動画の最初の方をチラッとみると、
という感じで、マイクロフィルムがどんどんスキャンされて、PC画面上にどんどんつながっていってる様子がわかると思います。、
例えば、こちらにあるように、
16mmフィルムは幅16mm、長さが100フィート（約30.5m）でA4サイズの書類が2400枚程度撮影できます。
ということですので、縦16mm x 横30,500mmの画像を作成することになります。300dpi/グレースケールだとして、約500MBくらいの大きさです。当然、35mmフィルムでしたら、その倍くらいで、約1GBくらいでしょう。*4
ただし、画像を表示させるときに、横30,500mmの画像なんて、ひたすら右にスクロールしていかないといけなくなってしまいますので、実際は、
このように、ある程度のところで、「改行」して表示していきます。そして、画像を編集したりするときは、右端と次の行の左端はくっついてるもんとして処理されます。
話を聞いただけだと、「なんだ、たいしたことないな」と思うかもしれませんが、この技術が出現する前に、マイクロフィルムがどうやってスキャンされていたのか、ということを知ると、「でら便利になったじゃんね」と思うはずです。*5
次回は、この技術が出現する前に、マイクロフィルムがどうやってスキャンされていたのか、ということを見て行きます。
とりあえず、今日のところは、「リボン・スキャニング」というものがあって、それは「マイクロフィルム1本を1つの画像として取り込む」技術であり、その技術のおかげで、スキャン現場は大いに助かってます、とだけ知ってください。
*1:分かりやすいビデオを選んだだけですので、ここで紹介されている商品がオススメです、とか、私がこの会社から何らかのインセンティブを受け取っている、というようなことはありません。私のオススメを知りたい方は、別途メールなどで問い合わせてください。
*2:話を分かりやすくするために、細かい点で、正確じゃない記述を含みますが、大枠を理解する目的なら、支障がないはずです。
*3:実際には、分割されたBMP画像などがいくつもできる感じで、表示させるときや、加工するときに、それらがあたかもひとつの画像であるかのように扱う、という仕組みです。
*4:実際は、こんなに単純ではないので、35mmフィルムの場合だと、25〜50GBくらいの画像ファイルができあがる、と考えてください。
*5:まだ、細かい点で、ソフトが不安定だったりして、「でら」とつけて良いかどうかは微妙ですが、方向性としては「でら」です。
コンピュータに画像はどう見えるのか？ その4 傾き補正編
本日のお題画像：
非常に分かりにくいのですが、お題画像の左側、
この画像、左に0.8度くらい傾いています。ウソだとお思いなら、分度器で測ってみてください。
大量のスキャン画像を処理する場合、その都度、分度器で測定するわけには行きません。
そこで登場するのが、今までに何度か登場しているHough変換（ハフへんかん）です。
すでに、http://d.hatena.ne.jp/denshikA/20100420で確認したとおり、「赤枠内の交差点の位置だけで、緑枠内に線が、どのあたりに、どんな傾きであるのか、分かってしまう」わけです。
今日は、傾きに注目してみましょう。とりあえず、以下の4つを見てください。
うすうすお分かりのように、緑枠の縦っぽい線が左に45度づつ傾くと、赤枠内の交差点が右に1/4づつ進みます。
つまり、赤枠内の横軸は、ゼロから180までをあらわしていて、交差点の位置から、その傾きの角度を教えてくれる、という仕組みです。
昨日は、言葉なしで載せてみましたが、本日は、少しだけ入れて見ましょう。*2
元画像を、白黒画像にして見ましょう。
次に、画像の枠となる部分だけ、抽出してみましょう*3。
この画像を、左側の縦っぽい線だけ、Hough変換してみましょう。
あらまっ、不思議。赤枠内の横軸0.8度のところに、交差点ができました。
そして、Hough変換で分かった0.8度で、画像を回転させれば、
という感じで、画像の傾きが、すっきり直りました。
結論：このように、Hough変換ってものは、書籍電子化や新聞電子化で、使われてるんですよ、ってこと。
*1:データ元などは、こちらを参照http://d.hatena.ne.jp/bookscanner/20060920
*2:今回、説明を分かりやすくするために、かなり、イジってます。なので、大きな流れをつかむつもりで、細かい部分は、かなり間違ってるよ、くらいの認識でいてください
*3:この処理については、後日、詳述するかもしれません
