1999-11-19[n年前へ]
■バナー画像の情報量を探れ 
1文字辺りの情報量編
今回はWEBの世界でよく見かけるバナーについて考えてみたい。
そのきっかけは本WEBにはバナーが存在しないことに気付いたからである。さぁ、作ってみようかと考えた。
作ろうとしたのだが、そもそも、「バナー」って一体何なのだろう?という疑問が沸いた。そこで、まずは「バナー画像」について調べてみることにした。
「バナー」というのは、ある意味WEBの顔である。いや、名刺という方が相応しいかもしれない。あるいは、「招待状」とでも言い換えた方が良いだろうか。そのバナーを辿って、WEBに辿りつく、あるいは、WEBを知るわけであるから、軽んじるわけにはいかないだろう。だから、その「バナー」についてはじっくり考える必要があるのだ。
今回は、特に「マイクロボタン」という88x31ピクセルのバナーについて考えてみたい。よく見かけるサイズでもあるし、私が好きなサイズであるからだ。ちなみに、
この88x31のサイズのバナーは
- IAB ( http://www.iab.net/ )
そのIABのWEBの中に
- IAB/CASIEAdvertising Banner Sizes ( http://www.iab.net/iab_banner_standards/bannersource.html)
さて、その「Micro Button」というバナーについて、私がよく楽しむ、あるいは、使っているWEBの「バナー」を参考にしながら、考えてみることにする。
それでは、私がよく見に行くWEBの中からそのMicro Buttonに近いものをピックアップしてみる。それらを参考にしながら、hirax.netの「できるかな?」用の「マイクロボタン」バナーを作成してみるのである。
今回、参考にしたのは、以下の10個のバナーである。これらのWEBはいずれも非常に参考になるものばかりである。私の「マイクロボタン」作成にもきっと参考になると思うのである。また、今回他のWEBのバナー画像を使用している。その言い訳として、「本ページはリンクページ」である、ということにしておきたい。
まずは、技術系WEBの双璧である「今日の必ずトクする一言」と「Fast&First」だ。
 http://www.tomoya.com/ |  http://www.cds.co.jp/ff/ |
 http://www.infoseek.co.jp/ |  http://www.goo.ne.jp/ |
 http://www.microsoft.com/japan/ |  http://www.apple.com/ |
 http://www.microsoft.com/japan/ |  http://home.netscape.com/ja/ |
 http://www.real.com/ |  http://www.apple.co.jp/ |
- 青色がよく使われている。
- 検索サイトは赤色が主である。
また、検索をかける時の急いた気持ちと赤色は非常に合う。それは、パトカーや救急車と同じである。そうしてみると、上の二つの傾向は他の例でもあてはまるものが多いかもしれない。他の検索サイトのYahoo!でも主たるイメージカラーは赤である。もちろん、それに当てはまらないサイトも沢山あるが...
さて、これら10個の「バナー」と、自分用に作成した4つの「バナー」を例に示しながら、色々と考えて見ることにする。以下に「ノミネート」されたバナー達を示してみる。
| | | |
| | | |
| | ||
 |  |  |  |
まずは、そのバナー画像が持つ情報量について考えてみる。まずは、そのバナー画像の中の文字数に注目してみる。情報を伝える上で、文字というのは非常に重要と考えるからだ。その文字を伝えるためにどの程度ファイルサイズというコストがかかっているか、考えてみるのである。
ここで、文字数は次のように考えている。
- 英数文字1文字=1Byte
- 日本語1文字=2Byte
なお、Fast&Firstのバナー画像は、マイクロバナーとはかなり異なるサイズなので、除外した。また、言うまでもないと思うが、ここでつける順列はあくまでシャレである。念の為に書いておく。
| バナー画像 | 画像中の文字数とそのバイト数 (Byte) | ファイルサイズ(Byte) | 1文字あたりのファイルサイズ(Byte/Byte) | ファイル形式 |
 | 今日の必ずトクする一言 (22Byte) | 2472 | 112 | JPEG |
| Fast&First (5Byte) | ----- | ----- | ------ |
| infoseek Web Kit (14Byte) | 750 | 54 | GIF |
| goo (3Byte) | 881 | 294 | GIF |
| Windows2000 (11Byte) | 3105 | 282 | GIF |
| Mac (3Byte) | 465 | 155 | GIF |
| GET MicrosoftInternetExplorer (28Byte) | 874 | 31 | GIF |
| Netscape Communicator 4.7 (23Byte) | 1003 | 44 | GIF |
| real player 7 FREE (15Byte) | 864 | 58 | GIF |
| QuickTime Get 4. (14Byte) | 3116 | 223 | GIF |
| hirax.net できるかな (19Byte) | 662 | 35 | GIF |
| hirax.net できるかな (19Byte) | 648 | 34 | GIF |
| hirax.net できるかな (19Byte) | 763 | 40 | GIF |
| hirax.net できるかな (19Byte) | 2348 | 124 | GIF |
その、1文字あたりのファイルサイズ(Byte/Byte)順に並べてみる。本WEBのバナーが上位に入っているのは、このテスト用にチューニングしたからである。当然だ。決して、本WEBが優れているという意味ではない。
| 1: 31 GIF | 2: 34 GIF | 3: 35 GIF | 4: 40 GIF | 5: 44 GIF |
| 6: 54 GIF | 7: 58 GIF | 8: 112 JPEG | 9: 124 GIF | 10: 155 GIF |
| 11: 223 GIF | 12: 282 GIF | 13: 294 GIF |
こうしてみると、一位のIEの1文字(Byte)辺り31Byteという情報密度はかなりのものである。最下位のgooは、3文字というトータルの文字情報量の少なさが足を引っ張っている。ファイルサイズ自体は一位のIEとほぼ同じ900Byte弱であるが、いかんせん文字情報量が少ない。そのため、「文字情報密度」が小さいのである。
「今日の必ずトクする一言」「QuickTime」などグラデーションを用いたものは、色数を少なくしづらいのがネックだったろう。また、「今日の必ずトクする一言」は唯一のJEPG陣営である(->後編参考)。
今回はあくまで導入編ということで、「文字情報密度」について考えてみた。次回は、バナー画像のエントロピー・情報密度などについて考えてみたいと思う。
さて、バナー画像自体は「小さな絵葉書」みたいで私はとても好きだ。小さな中にそのWEBの作者の考えが現れているようにも思う。
しかし、実は私はバナー画像を貼るのは自分ではあまりやらない。しかし、今回作成したバナー画像達、
______
をもし使用したい人がいるならば、それはもちろん大歓迎である。そんな奇特な人がそうそういるとも思えないが、もしいたら、好きな色・パターンを使って頂けたら幸いである。自分では、やらないのだけれど...
そうそう、最後にもう一度書いておこう。これはリンク集であります。
1999-12-21[n年前へ]
■恋の力学
恋の無限摂動
クリスマスが近くなると、街のイルミネーションが綺麗に輝き始める。いかにも、ラブストーリーが似合う季節である。そこで、今回は、"Powerof love"、すなわち、「恋の力」について考えてみたいと思う。「恋の力」により、人がどのような力を受け、人がどう束縛されるのか、などについて考えみたいのである。また、恋に落ちたカップルがどのような行動をするのかについて解析を行ってみたい。
「できるかな?」では以前、
において、カップルが他のカップルを意識する力について考えたことがある。カップル同士の間に働く斥力を考えることにより、鴨川カップルの行動を考えてみた。それと同様に、今回はひとつのカップルのみを考え、その中に働く力を考えてみるのである。ひとつのカップルの「男」と「女」の間にどのような力が働くかを考えるのである。そういうわけで、今回の登場人物は「男」と「女」である。その二人は「恋に落ちた二人」である。二人の間には「恋の力」が働いているのだ。その二人の間に働く「恋の力」について考察することにより、恋に落ちたカップルの行動について考察を行ってみることにする。
といっても、「恋の力」を精密に測定した報告例は未だ存在しないので、ここでは適当な値を用いていくことにする。「恋は距離に負けない」とか「遠くて近きは男女の仲」などとははよく言われる。そこで、距離によらないと近似した。また、「遠くて近きは男女の仲」の意味を考えれば、恋の力は無限遠まで働く力である、と考えるのが自然である。
そこで、今回の「恋の力」は距離に関わらず一定であると仮定した。距離=rとした時に-r/Abs[r]の大きさで「相手に惹かれる」ものとした。仮に第一種「恋の力」(仮称)とでもしておく。
今回は「恋の力」は距離によらないものとした。しかし実際は、(通所の距離においては)「男」と「女」は距離が近いほど惹かれ合うし、離れてしまうと惹かれ合う力は弱くなるというのが自然であると思われる。そこで今回の第一種「恋の力」(仮称)は、あくまで大雑把な近似ということにしておく。
恋する二人の間に働く力をもう少し正確に記述しておくと、
- 「恋の力」 = - 「相手の魅力」 * 「二人の間の距離ベクトル」 / 「二人の間の距離スカラー」
- 「恋の力」=優柔不断度 * 「恋の加速度」
であることだ。心がトキメいてもなかなか行動を起こすことが出来ない人がいるだろう。そういう人は「優柔不断度」が高いというわけである。恋の行動における慣性を示すパラメータである。
また、今回は空間を1次元であると簡略化してみた。1次元の空間の中で「男」と「女」が動き回るのである。その時間的変化を調べてみるのだ。従って、シミュレーション結果は空間軸が一次元+時間軸一次元で、合わせて2次元となる。
さて、この「恋の運動方程式」を解くことにより、恋する二人の行動は予測することが可能となるわけだ。試しに、その計算サンプルを示してみる。なお、今回は時間方向で数値的に逐次解を求めている。
初期状態は
- 「男」位置=5, 速度=0,魅力=100,優柔不断度=10
- 「女」位置=0, 速度=0,魅力=100,優柔不断度=10
位置や時間の単位は任意単位である。「0」と「5」は東京と大阪であっても良いし、ロンドンとニューヨークであっても良い。あるいは、実空間でなく精神的な空間と考えてもらっても構わない。すなわち、心の動きを示しているものとするのである。
また、二人の「魅力」や「優柔不断度」は対等である場合だ。その結果を下に示す。このグラフは縦軸が空間位置であり、横軸が時間である。黒線が「男」であり、赤線が「女」である。
 |
「男」と「女」が同じように相手の方向へ向かっているのがわかると思う。これが「恋の無限摂動」である。こういった「恋の無限摂動」の代表的なものには「君の名は」の主人公達の動きなどがある。恋に落ちた二人が、延々とすれ違いを続ける物語である。これは、この「男」と「女」の行動そのものである。
この計算結果では「男」と「女」が糸を紡いでいるようにうまく絡みあっているのがわかる。「恋の無限摂動」の幸せなパターン例である。これは、「男」と「女」が対等であったことがその一因である。
その証拠に、「男」と「女」が対等でない場合の計算結果を示してみる。次に示すのは、
- 「男」位置=5, 速度=0,魅力=10,優柔不断度=10
- 「女」位置=0, 速度=0,魅力=100,優柔不断度=10
 |
「男」が右往左往するのに対して、「女」はほとんど動いていないのがわかると思う。おそらく、この場合には「男」と「女」の「心」もこれと同様のパターンを示しているものと思われる。すなわち、「男」の「心」は揺れ動いているのに対し、「女」の「心」はほとんど動いていないのである。
先の例と異なり、これは実に不幸な計算例である。不幸ではあるが実際によくある例であると思う。以降、これを「男はつらいよ」パターンと呼ぶことにする。「女」に「男」が振り回されているパターンだ。もし、奇跡的に結婚などしても、将来どうなるかは火を見るより明らかである。
それでは、「男」と「女」の「魅力」が同等で、かつ、とてもスゴイ場合を示してみる。すなわち、ドラマの主人公達のようにとてつもなく魅力的な二人が恋に落ちた場合である。一般人とは違う二人が恋に落ちたら、果たしてどのような行動を示すのであろうか?この場合のパラメータは以下に示す、
- 「男」位置=5, 速度=0,魅力=1000,優柔不断度=10
- 「女」位置=0, 速度=0,魅力=1000,優柔不断度=10
 |
「魅力ある二人が恋に落ちた場合には、あまり近づかない方が良い」という教訓をここから得ることができる。
最後に、「男」と「女」の二人ともにあまり魅力がない場合である。パラメータとしては、
- 「男」位置=5, 速度=0,魅力=2,優柔不断度=10
- 「女」位置=0, 速度=0,魅力=2,優柔不断度=10
 |
これなど「恋」と言えるのかどうかもわからない位である。ほとんど、「ただすれ違っただけの相手」である。これがさらに進むと、魅力がお互いに0同士のパターン、
- 「男」位置=5, 速度=0,魅力=0,優柔不断度=10
- 「女」位置=0, 速度=0,魅力=0,優柔不断度=10
 |
これっぽっちも「男」と「女」は「恋」に落ちていないのである。これではカップルの「男」と「女」ではなく、単なる他人である。
さて、今回は行わなかったが、カップルに「恋のエネルギー損失」を導入することにより、「恋の無限摂動」を減衰させることができる。それにより、現実のカップルの行動にさらに近づくことができるのではないかと、私は考える。何らかの抵抗が生じることにより、「恋の無限摂動」が減衰するのだ。そして、二人は接近した状態で停止するわけだ。
さて、今回の登場人物は「男」と「女」だけであった。しかし、現実でも、ドラマの中でも、通常は多くの登場人物が登場する。登場人物が「男」と「女」だけというような理想的な条件のみではない。
人の恋路を邪魔する(主人公からすれば)ヤツも必ず登場する。また、特定の登場人物の間では斥力が働くだろう。そのような場合、一体どのような現象が生じるのだろうか。
そもそも、今回の恋する二人の行動パターンは予測可能であったが、現実そのようなことがあるだろうか？果たして、未来の行動パターンは予測可能なのだろうか？色々な登場人物が現れる場合にも、今回の結論は成立するのだろうか？
それらは次回の課題にしておく。題して、「恋の力学 三角関係編- 恋の三体問題- (仮称)」である。「恋の力」を一般化し、多体問題として解いてみたいのである。恋する人達とその周りの人達がどのような行動をするか、恋の三角関係においてどのような力が働いているのか、について解析を行ってみたい。今回は、そのための前準備というわけである。
2000-01-13[n年前へ]
■WEBサイトの絆
WEBの世界を可視化しよう
目に見えないものを実感できるものにしようと思うことは多い。「直接感じることが出来ないものを感じられる形にする」という作業とその結果には非常にわくわくさせられる。それは、きっと私だけではないと思う。
目に見えないものは色々ある。可視化して見てみたいものは多々あるのだが、以前、
の時に扱った、WEBのトポロジーなどもその最たるものである。WEBページはもちろん目に見えるわけではあるが、それらがどう繋がっているか、すなわち、WEB[= クモの巣（状の物）;織物 ]そのものは目には見えない。ネットワークという目に見えない世界でWEBサイト同士がどう繋がっているか、それは企業のWEBサイト同士であれば企業間の繋がりを示すかもしれないし、公的機関のWEBであれば公的機関内部の繋がりが見えてくるかもしれない。そして、個人WEBであれば、個人どうしの繋がりが見えてくるだろう。そして、さらに考えを進めるならば、それが「WEBの繋がりだ」と端的に言い切ってしまっても良いと思う。
そういう色々なWEBサイト同士が互いに結びつき合う、つまりWEBそのものを今回は可視化してみたい。その結果はきっと「WEBサイトの絆」を私に見せてくれるはずだ。
例えば、ファイルシステムを可視化するものであれば、
- xcruise( http://tanaka-www.cs.titech.ac.jp/~euske/index-j.html )
そして、今回の本題のWEBサイトのHyperlink構造を可視化するソフトウェアも、少し探しただけでも結構ある。例えば、
- Site Manager
- ( http://www.sgi.com/software/sitemgr.html )
- HyperLINKWWW Visualization/Navigation
- ( http://www.acl.lanl.gov/%7Ekeahey/c3/navigate/navigate.html )
しかし、よく調べていないので間違っているかもしれないが、この辺りのソフト(appleを除く)はWEBサイト内のリンクのみに限られるようである。それでは、今回の目的とは違う。何しろ、今回知りたいのはWEBサイト同士のリンクの度合いである。WEBのトポロジーなのである。
そこで、もう少し探してみる。すると、今回の目的にかなり近い情報が
- Web構造の把握 宮久地博臣 都立科学技術大学大学院 平成9年度修士論文
- ( http://home2.highway.ne.jp/miyakuji/shuron.html )
やり方はどうしたら良いだろうか？宮久地氏と同じようにWeb Robotを作成して、データを集めるのが理想的だろう。しかし、「perl入門」を昨日やっと買ったばかりの私にはとても難しそうである。いや、もしそんなことをしたらとんでもないことになるに違いない。
そこで、perlのlwp-rgetを用いて各WEBの内容をローカルのPC内にダウンロードした上で、勉強がてらperlで解析を行うことにした。と、思ったのだが、lwp-rgetが上手く動いてくれない。まだドキュメントをちゃんと読んでいないせいだろうか？何故か、ダウンロードの途中で終了してしまう。仕方がないので、急遽作戦を変更し、ダウンロード作業はlwp-rgetではなくてwgetを用いることにした。
行った手順は以下のようになる。
- 5つのWEBサイトを広いWEB内から適当に選択する
- 選んだ各WEBサイト内のファイルについて、相互のハイパーリンクを抽出し、その数を解析する
- その結果を可視化する
以下に、解析を行った結果、すなわちサイトA,B,C,D,Eの相互に対するリンク数を示す。
| ↓から→へのリンク数 | |||||
0 | 2 | 0 | 27 | ||
1 | 0 | 13 | 273 | ||
20 | 2 | 0 | 43 | ||
0 | 11 | 0 | 285 | ||
1 | 1 | 1 | 1 | ||
合計 | 22 | 14 | 3 | 14 | / |
サイトE「日記猿人」へのリンクがムチャクチャ多いのは投票ボタンという形で、他のサイトからリンクがなされているからである。
さて、上の表からではWEBの絆を実感できないので、「WEBの絆」を3次元空間に可視化するJavaアプレットを以下に張り付けておく。WEBサイトが5つあるので、それぞれのサイトをピラミッド構造(四角柱状)に配置した。
各WEBサイトの表示色は、
- A = 赤
- B = 緑
- C = 青
- D = 黄
- E = 灰
それぞれのサイトから伸びる直線の長さは、そのサイトから他のサイトへ向かうリンク数に比例したものにしている。また、直線の太さもリンク数に比例させている。また、それぞれのWEBサイトを示す立方体の大きさは自分へ向かうリンク数に比例させている。ただし、サイトEの大きさはあまりにも巨大なため、リンク数に比例したものにはなっていない。また、サイトE、すなわち「日記猿人」、へのリンクは省略し、全てサイトEからの直線リンクを表示するだけにした。
さぁ、WEBサイトの構造を自分の目でみて、そしてグリグリ動かして見てもらいたい。このグラフの操作方法は
- 操作 = 作用
- マウス左ボタンドラッグ = 回転
- シフトキー + 垂直ドラッグ = ズームイン・アウト
- シフトキー + 水平ドラッグ = 垂直軸についての回転
- コントロールキー + 垂直ドラッグ = 焦点距離の変更
- マウス右ボタン垂直ドラッグ = 部品除去
- "s"キー = ステレオ画像作成
Java表示が上手く動かない人のために、静止画も一応張り込んでおく。
 |
どうだろう？この5つのWEB間のWEB構造から何が見えるだろうか？こういう解析を数多くのサイトに行うと非常に面白い結果が得られそうである。特に「日記猿人」のようなコミュニティーに対して行うと興味深い結果が得られるはずだ。
私のような「日記猿人」の日記はほとんど読まない(サイトAに関しては大ファンであるが)人間にとっても興味深いのであるから、関係者にとってはきっと...の筈だ。
さて、今回はテストのためにごく少数(5つ)のWEBの解析を行ってみた。いつか、こういった解析を広い範囲で行い、そして、時系列的な変化をも調べようと思う。銀河のvoid構造が観測され、可視化されたものを見たときもとてもわくわくしたものだが、WEBの構造・変化ならばどうだろうか？
不思議なことに、そういうことを考えていると、「新宿都庁」と「思い出横町」が頭の中に浮かんできてしまうのは何故だろうか？押井守の影響だろうか。謎である。
そして、こうも思う。WEBネットワークの中でWEBサイトは何を感じているのだろうか？これらのWEBサイトはもしかしたら孤独を感じているのだろうか、それとも繋がりを感じているのだろうか？あの時のページの中の一フレーズがその答えの一つなのかもしれない。
2000-01-21[n年前へ]
■数字文字の画像学
縦書きと横書きのバーコード
始まりはまたしても「物理の散歩道」である。
- 「新物理の散歩道」 第一集 ロゲルギスト 中央公論社
さて、その中の-横組・縦組と二つの目-という一節中の外山滋比古氏の発言が実に面白い。
「日本の漢字は横の線が発達してますから、横から読みますと目に抵抗が少なくて読みにくいですね。ヨーロッパの文字は縦の線が非常に発達していて、横に読むと非常に能率がいいわけです。数字でも縦の棒を引いて、Ⅰ、Ⅱ、Ⅲ、Ⅳ....としますが、和数字は横に線を引いて一、二、三...となります。...」という発言である。
- 文字は読む方向に対して垂直な線が多い
- また、読む方向に対して水平な線は少ない
- いずれも目のスキャン方向に対して垂直な線が多い
そこで、今回その確認と考察を行ってみることにした。サンプルとしては、外山滋比古氏の発言の通り、ローマ数字と漢字数字を用いることにする。
まずは、本来の書き方の方向に数字を並べた画像である。画像サイズは128x128である。後の処理のために、縦横比を同じにした。すなわち、本来の画像のアスペクト比とは異なる。
 |  |
この二つの画像を読む方向に目を走らせると、まるでバーコードのようである。以前、
の時に作った郵便カスタマバーコードを参考に示してみる。 |
考えてみると、バーコードは検出手段をバーコードの進行方向に走らせて、情報を読み取るわけである。人間が数字の羅列を読み取るのも、数字文字列上に目を走らせるのであるからまったくもって同じである。
一次元バーコードを考えた時、バーコードのバーは進行方向に対して垂直なものがほとんどである(若干のアジマス角を持つものもあるが)。バーコードを読み取る方向に対してのみ情報が書き込まれているのだから、それ以外の方向には等方的であるのが当然である。もし、そうでなかったらスキャン位置がちょっとずれただけでデータの読み取りができなくなってしまう。
そう考えると、先の数字文字に関する
- 読む方向に対して垂直な線が多い
- 読む方向に対して水平な線は少ない
また、本来の数字文字を並べる方向が読み書きの方向と異なる場合を以下に示す。
 |  |
さて、画像を並べるだけではつまらないので、
- 本来の書き(並べ)方
- 本来の書き方と異なる書き(並べ)方
人間の目が数字文字列上をスキャンしていくときに、選られる情報量を考えるために、読む方向に対して画像を微分したものを示す。もう少し正確に言えば、微分値の絶対値を画像にしたものである。
まずは、本来の書き(並べ)方のものを示す。
 818892 |  923836 |
微分画像の下に示した数字は微分(して絶対値)画像のピクセルの値の総和である。これをスキャン方向に対して選られる情報量の指標として扱うことにする。「スキャン方向に対して変化量が大きいということは、情報量が多い」ということだからである。
次に、本来の書き方と異なる書き方の場合を示す。
 536383 |  632338 |
それでは、「微分(して絶対値)画像のピクセルの値の総和」を比較してみることにしよう。
| 本来の書き方の場合 | 818892 | 923836 |
| 本来の書き方と異なる場合 | 536383 | 632338 |
ローマ数字、漢字数字の両方で、本来の書き方の方が(読む方向に対する)画像の変化量が大きいことがわかる。すなわち、「目のスキャン方向に対して選られる情報量」が多く、そうでない方向には冗長なのである。エラー発生率が小さくなるのである。本当にバーコードそのものである。文字はバーコードの祖先だったのである。
さて、「文字の画像学」も色々と面白そうなので、これからちょこちょこ遊んでいこうと思う。
2000-01-30[n年前へ]
■ソフマップでお買い物
磁界の可視化とバーコード
前回、
で「マグネビュアー」を使って磁界の可視化をして遊んでみた。今回はその続きである。ソフマップの磁気カードの中に書き込まれている磁気データを可視化して調べてみるのである。磁気カードには、
- 銀行のキャッシュカード
- クレジットカード
- テレホンカード
- オレンジカード
まずは、ソフマップカードの写真を示してみよう。これがソフマップで買い物をするたびにお世話になるソフマップカードである。
 |
この写真からではどこにデータが書き込まれているのかわからない。そこで、「マグネビュアー」の登場と言いたいところであるが、残念ながら今回は「マグネビュアー」は登場しないのである。「マグネビュアー」はとても便利なのであるが、さすがに磁気カードの磁気データを読もうとすると分解能が不足する恐れがある。
そこで、代打選手に登場願うことにした。代打選手はキヤノン製のLBPのトナーである。以前、
の時に「トナーはクーロン力で制御されて画像を作るのだ」という話があった。キヤノン製の白黒のLBPではクーロン力に加えて磁気力を使ってトナーを制御している。なので、キヤノン製の白黒トナーは磁性体粉末ということになる。テレホンカードが出た頃はキヤノン製のトナーを使ってデータを読み出していた人も多いはずである。みな、テレホンカードの表面を削りトナーを振り掛けていたのである。というのは、聞いた話であり、実体験に基づくものでは絶対にない。神に誓っても良い。その頃にキヤノン製のトナーを使い倒していたということは絶対にないのである。しかも、その数年後に(以下略)。
それでは、磁性体の微少粉末であるトナーをソフマップカードに振り掛けてみよう。
 |
ソフマップカードの磁気データが可視化されたのがわかると思う。磁気によるバーコードが見えるだろう。これがソフマップカードに書き込まれている磁気データである。
とはいえ、トナーの付着具合にムラがある。それは私が雑に実験を行ったからである。こんなにムラがあっても磁気コードが判別できるかどうか疑問を持たれる方も多いと思う。しかし、
- 読む方向に対して垂直な線が多い
- 読む方向に対して水平な線は少ない
そのようにして、ノイズを減らし、S/N比を上げた画像を示してみる。
 |
どうだろうか、驚くほど綺麗になっているのがわかると思う。まさか、と思われるかもしれないが本当である。
さて、これはソフマップカードの磁気データの全体像であるが、もう少し拡大したものを以下に示す。
 |
極めて明瞭に磁気データが可視化されているのがわかると思う。これはトナーを振りかけて、１万円ちょっとのスキャナ(CanonのUSB接続の安物スキャナ)で読み込んだものに対して先の処理をしただけである。これほど明瞭になるのも、全て１次元バーコードの特徴のおかげである。磁気ヘッドの制作などをしなくても良いのである。
磁気カードの記録密度は銀行統一仕様(NTT)でもISO3554でも8.3bit/mm=211bit/inchであるから、最近の600dpi(dot/inch)程度のスキャナーであれば十分磁気データの画像読みとりが可能である。
それでは、もっと拡大してみる。拡大する部分は上の画像の右の辺りである。すると、このようになる。
 |
データ間隔がわかりやすいように、ここでは矢印や文字を書き入れている。この画像を見ると、磁気データは規則的な細かい周期性を持ち、その周期でいうと８つ単位でさらなる周期性があるように思われる。つまり、8bitをひとまとまりとしたデータが書き込まれているように見える。例えば、上の画像では
- ( 白、白、白、白、白、白、黒、黒 ) x 2
- ( 00000011 ) x 2
- ( ああああああたた ) x 2
 |
複数枚のカードのこの部分を比較してみれば、比較的容易にデータ構造は解析することができるだろう。また、一枚のカードからでもカード番号などの数字と磁気データを比較することにより、解析することはやはり困難無しに解析できると思うのである。と、思うわけではあるが、あまりやりすぎるのはマズイと思われるので、今回はこれまでにしておく。
」など。