1999-01-10[n年前へ]
■宇宙人はどこにいる?
画像復元を勉強してみたい その1
知人から「自称UFO写真」というのものが冗談半分(いや100%位か)で送られてきた。その写真はボケボケの画像なので何がなんだかなんだかわからない。そこで、ぼけぼけ画像を復元する方法を勉強してみたい。UFOは冗談として、画像復元において進んでいるのは天文分野である。そこで、このようなタイトルなのである。もちろん、画像復元の問題は奥が深すぎるので、じっくりと時間をかけてみる。今回はMathematicaを使って試行錯誤を行った。
ボケ画像を復元するには、ボケ画像がどのように出来ているかを考えなければならない。そこで、ごく単純なぼけ画像を考えてみる。まずは以下の画像のような場合である。
画像:1のような点画像が、画像:2のような分布のボケ画像になるとすると、次のような関係が成り立つ。
(式:1) 画像:4 = 画像:3 * 画像:2
画像:1のような点画像が画像:2になるなら、それを参照すれば、画像:3のような点画像の集合がどう
ボケるかは計算できる。つまり、それが画像:4になる。ここで、*はコンボリューションを表している。
よくある信号処理の話で言えば、画像:2はインパルス応答である。といっても、これはごくごく単純な場合(線形シフトインバリアントとかいろいろ条件がある)の話である。まずはそういう簡単な場合から始めてみる。
このようなごく単純な場合には
(式:2) 画像:3 = 画像:4 * (1/画像:2)
とすれば、画像:3を復元できることになる。
そこで、まずは単純な1次元データで考える。下の画像:5のようにボケる場合を考える。ここでは、ガウス分布にボケるようにしてある。
であったが、* すなわち、コンボリューションは
逆フーリエ変換(フーリエ変換(オリジナル画像) x フーリエ変換(ボケ具合))
と表すことができる。つまり、周波数領域で掛け算をすれば良いわけである。
それでは、試しに適当な1次元データをつくって、画像:6とコンボリューションをとってやり、ボケさせてみる。
逆フーリエ変換(フーリエ変換(画像:9) / フーリエ変換(画像:7))
= InverseFourier[Fourier[Image8] / Fourier[Image6]]; (*Mathematica*)
とやると、次のデータが得られる。
(式:2) 画像:3 = 画像:4 * (1/画像:2)
を見るとわかるが、画像:2が周波数領域で0になる点があったりすると、計算することができない。また、0に近いとむやみな高周波数の増幅が行われて使えない。
そこで、この方法の修正として、ウィーナフィルターなどの最小平均自乗誤差フィルターがある。これにも多くの不自然な条件のもとに計算される(らしい)。しかし、infoseek辺りで探した限りでは、ウィーナフィルターを用いた画像復元の標準であるらしい。
この方法は先の逆変換に対して、次のように変形されたものである。Mathematicaの表記をそのまま貼り付けたのでわかりにくいかもしれない。
Noise ノイズのパワースペクトル
Signal 信号のパワースペクトル
Boke ボケる様子のインパルス応答
Conjugate 複素共役
BokeData ボケ画像
ResData1 計算した復元画像
Boke1 = (Boke^2 + Noise/Signal)/Conjugate[Boke]; (*Mathematica*)
ResData1 = InverseFourier[Fourier[BokeData] / Fourier[Boke1]]; (*Mathematica*)
である。Noise/SignalはS/N比の逆数であるから、SN比の大きいところではインバースフィルターに近づく。また、インバースフィルターの計算不能な点が消えている。
これを使って復元してみたのが、次のデータである。
まずは、ボケのフィルター(PSF=PointSpreadFunction(どのようにボケるかを示すもの)、2次元のインパルス応答)である。
その他線形の画像復元法をいくつか調べたが、ウィーナフィルターやインバースフィルターとほとんど同じような物が(素人目には)多かった。そこで、ウィーナフィルタなどとはやり方がかなり異なるものについて、いずれ挑戦してみたい。
関係はないが、ウィナーと言えばサイバネティクスが思い浮かんでしまう。当然、ロゲルギストが連想されるわけだが、文庫本か何かで岩波版と中公版の「物理の散歩道」が安く売り出されないのだろうか?売れると思うんだけど。新書版は高すぎる。
宇宙人はどこにいるか? そういった話は専門家に聞いて欲しい。わからないとは思うが。
さて、ここからは、1999.01.24に書いている。シンクロニシティとでも言うのか、今回の一週間後の1999.01.17に
日本テレビ系『特命リサーチ200X』で
地球外生命体は存在するのか?( http://www.ntv.co.jp/FERC/research/19990117/f0220.html )
という回があった。何とこの回のコメンテーターは先の専門家と同じなのだ。偶然とは面白いものだ。
1999-03-28[n年前へ]
■ハードディスクのエントロピーは増大するか?
デフラグと突然変異の共通点
fjでKByteの定義(よく言われる話だが)が話題になっていた。「なんで1024Byteが1KByteなんですか」というものである。そのスレッドの中で、
- 整数値だけでなく、分数値のbitもある
- 1bitのエントロピーも定義できるはずで、それならハードディスクは結構エントロピーを持つかも
初めに、「整数値だけでなく、分数値のbitもある」という方は簡単である。{0,1}どちらかであるような状態は1bitあれば表現できる。{0,1,2,3}の4通りある状態なら2bitあれば表現できる。{0,1,2,3,4,5,6,7}までなら3bitあればいい。それでは、サイコロのような状態が6通りあるものはどうだろうか? これまでの延長で行くならば、2bitと3bitの中間であることはわかる。2進数の仕組みなどを考えれば、答えをNbitとするならば、2^N=6であるから、log_2 ^6で2.58496bitとなる。2.58496bitあれば表現できるわけだ。
後の「1bitのエントロピーも定義できるはず」というのはちょっと違うような気もする。そもそもエントロピーの単位にもbitは使われるからだ。しかし、ハードディスクのエントロピーというのはとても面白い考えだと思う。
そこで、ハードディスクのエントロピーを調べてみたい。
次のような状態を考えていくことにする。
- きれいにハードディスクがフォーマットされている状態。
- ハードディスクの内容が画像、テキストファイル、圧縮ファイル、未使用部分に別れる。
- その上、フラグメントが生じる。
画像ファイル、テキストファイル、圧縮ファイル、未使用部分を1Byteグレイ画像データとして可視化してみる。
ところで、このような可視化をすると、ファイルの種類による差がよくわかる。てんでばらばらに見えるものは冗長性が低いのである。逆に同じ色が続くようなものは冗長性が高い。こうしてみると、LZH圧縮ファイルの冗長性が極めて低いことがよくわかる。逆に日本語テキストデータは冗長性が高い。もちろん、単純な画像はそれ以上である。
それでは、これらのようなファイルがハードディスクに格納された状態を考える。
- きれいにハードディスクがフォーマットされている状態。
- ハードディスクの内容が画像、テキストファイル、圧縮ファイル、未使用部分に別れる。
- その上、フラグメントが生じる。
横方向の1ライン分を一区画と考える。ハードディスクならセクタといったところか。その区画内でのヒストグラムを計算すると以下のようになる。この図では横方向が0から255までの存在量を示し、縦方向は区画を示している。
LZH圧縮ファイル部分では0から255までのデータがかなり均等に出現しているのがわかる。日本語テキストデータなどでは出現頻度の高いものが存在しているのがわかる。
それでは、無記憶情報源(Zero-memory Source)モデルに基づいて、各区画毎のエントロピーを計算してみる。
これを見ると次のようなことがわかる。
- 未使用ハードディスクは全区画にわたりエントロピーは0である
- 3種類のファイルが格納された状態では、それぞれエントロピーの状態が違う。
- 画像ファイルでは複雑な画像部分がエントロピーが高い
- 日本語テキストファイル部分は結構エントロピーが高い。
- LZH圧縮ファイル部分はエントロピーが高い。
- フラグメントが生じると、トータルではエントロピーが高くなる。
- しかし、平均的に先のLZH圧縮ファイル部分の状態よりは低い。
0 | 691.28 | 982.139 |
というわけで、今回の結論
「ハードディスクのエントロピーは増大する。」
が導き出される。もし、ハードディスクのデフラグメントを行えば、エントロピーは減少することになる。
こういった情報理論を作り上げた人と言えば、Shannonなのであろうが、Shannonの本が見つからなかったので、今回はWienerの"CYBERNETICS"を下に示す。もう40年位の昔の本ということになる。その流れを汲む「物理の散歩道」などもその時代の本だ。
生物とエントロピーの関係に初めて言及したのはシュレディンガーだと言う。ハードディスクと同じく、企業や社会の中でもエントロピーは増大するしていくだろう。突然変異(あるいは、ハードディスクで言えばデフラグメント)のような現象が起きて、エントロピーが減少しない限り、熱的死(いや企業や会社であれば画一化、平凡化、そして、衰退だろうか)を迎えてしまうのだろう。
1999-05-30[n年前へ]
■パーマンのパラドックス
ボトルネックは何処だ?!
以前、
ハードディスクのエントロピーは増大するか?- デフラグと突然変異の共通点 - (1999.03.28)
の最後に「突然変異(あるいは、ハードディスクで言えばデフラグメント)のような現象が起きて、エントロピーが減少しない限り、熱的死(いや企業や会社であれば画一化、平凡化、そして、衰退だろうか)を迎えてしまうのだろう。」と書いた時に少し不思議な感じがした。それは、次のような矛盾を感じたのである。
まずは、
- 何事につけても、全体としての強さは一番弱いところで決まってしまう。
- 全体としての完成度を高くするためには、どこの強さも同じであるのが理想的である。
- 従って、全体を構成する部分というものは均質であるのが理想的である。
もし、ビルの鉄骨の一部に弱い所があれば、そこから崩壊が始まり、いずれビルが崩壊することは免れないだろう。
精度・力が高い所がいくらあろうと、「一番精度・力が低い所の=全体の精度・力」なのである。従って、一番精度・力が低い所を改良するのが全体としての完成度を高めるための唯一の方法である。
これは、モノであろうが、個人であろうが、グループであろうが同じである。例えば、写真を撮って出力することを考えよう。いくら写真の素材が良くてもカメラマンの腕が悪ければ駄目であるし、写真自体が良くても、写真の出力装置が悪ければ、それもやはり駄目である。そもそも、カメラマンが狙う被写体自体が悪ければ、答えはやはり同じである。
従って、精度・力を揃えた均質的な状態でなければ良いものは生まれないわけである。
これと、先の「画一化、平凡化、そして、衰退」すなわち、「画一化は良くない」ということの間に矛盾を感じたわけである。
しかし、少し考えてみると特に矛盾が無いことがわかる。ロボットを作る場合を考える。
- まずは一人で機械系も電気系もソフト部分も自分で作っていた。
- ソフト部分がどうも苦手なので、ソフトが得意な友達に手伝ってもらう。
- すると、電気系が比較的うまく行かないようだ。
- そこで、友達の友達に電気系を手伝ってもらう。
- それぞれ得意な部分で力を発揮し、特に弱いところもなくなった。
- ロボットの完成だ。
それでは、数学的にふざけたことを考えてみる。といっても、難しく考えるのではなく、中学生でも知っていそうなあの式を使うのである。
簡単の為にX,Y二つの部品からなるものを考える。それらの単独での精度(あるいは、出力)をx,yとすれば、全体としての精度(あるいは、出力)を考えると、それは(x* y)^(1/2)と置くのが自然だろう。それぞれ単独であれば、単なる和としては(x + y)/2であるわけである。ここで、2で割ったり1/2乗しているのは規格化しているようなものである(あとの落ちに繋げるためでもあるのだが...)。
今やりたいことは、(x * y)^(1/2)がなるべく大きくなるようにしたいのである。というわけで、相加相乗平均の関係式の登場である。
x->(0,50),y->(0,50)の範囲で図示したもの | |
(x+y)/2 ...相加 | |
(x * y)^(1/2) ...相乗 | |
(x * y)^(1/2)-(x + y)/2 ...相乗-相加 |
すなわち、x=yの時に(x * y)^(1/2)は最大になるわけである。良く知られている、相加相乗平均の関係式である。今回の話では、それぞれの精度・力が均質であれば理想的というのはこういったことである。異なる分野・方法で力を発揮しという方は簡単だ。異なる分野・方法で力を発揮するのでなければ、わざわざ乗算、すなわち、いっしょに組ませる必要がない。
さて、タイトルの「パーマンのパラドクス」であるが、少々疲れてきたので、本題は次回にしたい。今回はタイトルについての考察を上の話に絡めてしてみるに留める。
私は「パーマン」についてほとんど知識がない。TVアニメを観ていた記憶がある位である。だから、パーマンの名前の由来が何であるか知らない。スーパーマン+罰としての「パー」からきているのかもしれないが、ここで勝手な想像をしてみる。英語で考えてみると、par=同等、同水準、平均であるから、par-manは「平凡な主人公ががんばってスーパーマンになる」という気持ちが込められているのかもしれない。これはありそうな話である。
ここで、「平均」でなくて同等というような意味をそこに入れたらどうなるだろうか?パーマン1,2,3,4号に対して、par=同等、同水準、平均というような視点から考えてみるのである。あるいは、パーマンだけではなく、他で考えたらどうだろうか....
1999-10-15[n年前へ]
■続々ACIIアートの秘密
階調変換 その2
前々回の
の時にASCIIアートに関する情報を探した- 清竹's テキスト絵 HPリンク集 (http://www2.nkansai.ne.jp/users/kiyo/ )
「限られた出力階調を有効に利用するため、画像の濃度ヒストグラムの補正を行ないます。1パス目で、濃度ヒストグラムをカウントし、そこからヒストグラムが平坦になるような濃度変換関数を生成します。(ヒストグラムを平坦にするのは、情報のエントロピーをなるべく保存するためです。)」とある。Q02TEXTはimage2asciiと同様のテキストアート作成プログラムである。前回のの最後で(3).情報量を最大にするモデル というのを導入したが、これがそのエントロピー最大化アルゴリズムに近いものを導入してみたものである。何しろ、この考えを使っていくのは乏しい階調性の出力機器には非常に有効なのだ。今回は、この「エントロピー最大化アルゴリズム」について考えてみたい。
Q02TEXTは「 .:|/(%YVO8D@0#$」の16階調を使用するテキストアート作成プログラムである。それに対して、「ASCIIアートの秘密」で作成したimage2asciiが使用可能な階調数は一定ではない。指定されたフォントを一旦出力してみて、その結果を計測することにより、出力可能な階調数を決定している。したがって、指定したフォントでしか階調の確かさは保証されない。その代わりに、指定されたフォントを使えば割に豊かな階調性を使用できることになる。
また、得られる階調は一般的に滑らかではないので、Q02TEXTが使っているアルゴリズムとは少し違うものを導入している。
通常ASCIIアートは色々な環境で見ることができるのがメリットの一つである。しかし、image2asciiはフォントを限定してしまっている。これは、目的が通常のASCIIアートとは異なるからである。私がimage2asciiを作った目的は、それを仮想的な出力デバイスとしてみたいからである。その出力で生じる様々な問題を調べたり、解決してみたいのである。
さて、前回の最後に示した3種類の画像変換は
- 単純な階調重視モデル
- オリジナルの0を出力画像の最小値に
- オリジナルの255を出力画像の最大値にする
- 拡大した単純な階調重視モデル
- オリジナルの最小値を出力画像の最小値に
- オリジナルの最大値を出力画像の最大値にする
- 情報量を最大にするモデル
- エントロピーを最大にするための階調変換を行う
これら3つの変換方法の違いにより出力画像にどのような違いが生じていたかを、まずはもう一度見てみる。まずは、オリジナル画像である。これは、「私の尊敬する」S大先生である。私は尊敬とともに「ロボコップSさん」あるいは、「ロボSさん」と呼ぶのだ。いや、本当に。
以下にオリジナル画像及びimage2asciiを用いて変換したものを示す。
- (1).単純な階調重視モデルが比較的白い個所では一番オリジナルに忠実な濃度であることはわかるだろう。ただし、黒い部分に関しての表現力は極めて低い。
- (2).階調性を少しだけ改善したものではそれより視認性が改善している。
- (3).視認度の高い画像ではあるが、オリジナルとは濃度などは異なる?
それでは、これらの画像のヒストグラムを調べてみる。先の「(ヒストグラムを平坦にするのは、情報のエントロピーをなるべく保存するためです。)」というのとの関係を調べたいわけである。
ASCII ARTには濃度の表現領域には限度がある。そのため、(1),(2),(3)はいずれも濃度が最大を示す個所でもオリジナルよりかなり濃度が低い。また、(1),(2)はオリジナルとヒストグラムの形状も少しは「似ている」が、(3)においては、かなり異なっているのがわかると思う。(3)はヒストグラムの形状はかなり異なるにも関わらず、視認度は高くなっている。これが、エントロピーを最大化(すなわち情報量を最大化)しているおかげである。ヒストグラムがかなり平坦になっているのがわかるだろう。
というならば、エントロピーの計算もしなければならないだろう。もちろんエントロピーと言えば、
でも登場している。「エントロピーは増大するのみ...」というフレーズで有名なアレである。情報量を示す値だといっても良いだろう。せっかく、「ハードディスク...」の回で計算をしたのだから、今回もその計算を流用してエントロピーを計算してみたい。といっても、無記憶情報源(Zero-memorySource)モデルに基づけば、ヒストグラムが平坦すなわち各濃度の出現確率が等確率に近いほどエントロピーは高いのが当たり前であるが... この前作成したMathematicaのNotebookを流用するために、オリジナルと3つの変換画像を合体させる。そして、そのヒストグラムを見てみよう。このヒストグラムが非常にわかりにくいと思うので、一応説明しておく。あるY軸の値で水平に1ライン抽出して、その部分のヒストグラムを右のグラフに示しているのである。
例えば、オリジナルの画像では髪の毛がある辺り(Y軸で10から30位)では、ヒストグラムを見ればレベルが50位の黒い所が多いところがわかる。それに対して、変換後の画像では、一番濃度の高い所でも150前後であることがわかるだろう。
それでは、それぞれ、Y軸でスライスしてその断面におけるエントロピーを計算したものを次に示してみる。
本来は、画像全面におけるエントロピーを計算するのが、望ましい。しかし、ここで使っているような、Y軸でスライスしてその断面におけるエントロピーでも、オリジナルの画像が一番エントロピーが高く、(3)の変換画像(つまり一番上)のものが次にエントロピーが高いのがわかると思う。つまり、情報量が高いのである。
エントロピー量とあなたの感じる「視認度」とが相関があるかどうかは非常に興味があるところだ(私にとって)。エントロピーが多くても(すなわち情報量が多くても)オレはちっともいいと思わないよ、とか、おれは断然エントロピー派だね、とか色々な意見があったらぜひ私まで教えてほしい。
「お遊び」に見えるASCIIアートも、調べていくと実は奥が深いのだなぁ、とつくづく思う。といっても、もちろん本WEBはお遊びである。なかなか、奥までは辿りつかない(し、辿りつけない)と思うが、この「ASCIIアートの秘密」シリーズはまだまだ続くのである。
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の作者の考えが現れているようにも思う。
しかし、実は私はバナー画像を貼るのは自分ではあまりやらない。しかし、今回作成したバナー画像達、
______
をもし使用したい人がいるならば、それはもちろん大歓迎である。そんな奇特な人がそうそういるとも思えないが、もしいたら、好きな色・パターンを使って頂けたら幸いである。自分では、やらないのだけれど...
そうそう、最後にもう一度書いておこう。これはリンク集であります。