2000-02-13[n年前へ]
■競馬の写真判定とパノラマ写真 
パノラマ写真と画像処理 Part.2
前回 、
の時にi_matさんから頂いたメールを紹介した。i_matさんは- Ｉ＊ＭＡＴ The HomePage (http://www.nsknet.or.jp/~i_mat/ )
- atoz@gol.com (http://www2.gol.com/users/atoz/index.html )
さて、前回
これらのソフトのStack-Slice機能を用いれば「複数画像(動画)からの走査線抽出」ができる。その使用例と、その面白い座標軸変換について考えてみたい。と書いた。今回もまた「数日後には登場」と言った割には時間が経っているような気もする。しかし、ここのところ文字通り忙殺されていたのである。と、言い訳をしながら今回この作業をやってみることにした。しかし、このページは少々重くなってきた。まして、走査線の抽出の話は使用画像が多くならざるをえない。そこで、次回、詳しく使用例を紹介することにする。
よく、次回登場と言ったまま数ヶ月経つことがあるが、今回は大丈夫である。少なくとも数日後には登場することと思う(多分)。
まずは、
- 「複数画像(動画)からの走査線抽出」
- 「座標軸変換」
以下に示す連続の画像は競馬のゴール地点に競走馬が到着した瞬間である。「馬に見えない」という人がいたら、それは目がおかしい。誰がなんと言おうとこれは馬である。馬と鹿の区別がつかない人は馬鹿と呼ばれるが、これはとにかく馬なのである。
 視野の中に馬がもっと入ってくる。
視野の中に馬がものすごく入ってる。 |
さて、このビデオカメラで撮影された画像は例えば以下のようなものである。
 |
撮影された各時間の画像から、この画像の赤で囲んだところを抽出し、並べたらどのようになるだろうか？
それはこのようになるだろう。よくある競馬の着順判定写真である。
 |
一見、これまで眺めてきたビデオカメラで撮影された画像と同じように見えるが、全く違う。ビデオカメラの撮影画像の動画中における、複数画像間の「位置」は全く変化していない。変化しているのは「時間」だけである。
だから、このような赤い長方形の画像を並べた方向というものは「時間軸」を意味しているのである。それを、下の画像に示してみる。
 |
この画像は縦方向は「空間軸」であるが、横方向は「時間軸」なのである。ビデオカメラの画像が縦横共に「空間軸」を示しているのに対し、その一軸を「空間軸」から「時間軸」に変換したものなのである
この競馬の着順判定写真の場合、カメラは空間に固定され「時間軸に変化するもの」を撮影していた。だから、このように各画像から一部を抽出して並べると、それは「時間軸」に対する変化を示すものを得ることができる。
また、例えば実験条件を変えたときの計測画像に対して「各画像から一部を抽出して並べる」ということをするならば、それは「空間軸」x「実験条件」というものを表す画像を得ることができる。
それでは、時間的には変化しないものを、ビデオカメラで撮影する方向を変化させながら撮影したらどうなるだろうか？例えば、ビデオカメラを下のようにして360度回転させながら撮影をしてみるのである。
 |
この場合撮影画像の各画像は撮影方向角度が異なるわけである。従って、先ほどのように一部分を抽出して並べると、一方向は「空間軸」であり、もう片方の軸は「撮影方向角度」になる。結局当たり前ではあるが、ある位置から眺めた周りの景色が得られるわけだ。
これが、前回i_matさんの要望していた
- ８ミリビデオを横倒しにして、 モーター回転するヘッドでぐるりと３６０度撮影し、
- その撮影した動画ファイルの、各フレームから走査線にして数本分を抽出し（インターレースで２５６本のうちセンター１２８本目の前後数本の走査線分）、
- それを貯めて１枚のｊｐｇファイルにする、
- そのJPEG画像をMakeQTVRPanoramaの入力にして、パノラマムービーを作る、
それでは、その作業を実際にしてみようと思う。i_matさんから送って頂いた動画ファイル
を使い- 動画から静止画に変換し(走査線の狭間-1/60秒の世界を目指せ- (1999.07.08) 参照)、
- Image PC(NIH-imageをWindowsに移植したもの)で、走査線の一部を抽出し並べた静止画を作成する
もういきなり結果を出してしまおう。これが、「動画ファイルから走査線を抽出し、パノラマ写真にしたもの」である。
 |
おや？何が何だかわからない画像になってしまっている。変なモザイクがかかったみたいな画像になっているし、グレイ画像である。参考までに、先ほどの動画から手作業でパノラマ画像を作成したものを以下に示す。上の画像と比較してみると画像の示すものの対応がわかるだろう。
 |
さて、今回の実験結果が
- 変なモザイクがかかったみたいな画像になっている
- グレイ画像である
まず、
- 「グレイ画像」になっている理由
そして、「変なモザイクがかかったみたいな画像になっている」のは(動画中の)各画像から走査線をそれぞれ一本しか抽出しなかったからである。だから、横方向(カメラの撮影方向角度)のデータが足りないのである。そのため、モザイク画像のようになってしまったのである。
本来、抽出する走査線の数は、カメラの回転速度に応じて増やしてやらなければならないわけであるが、それが上手く合っていなかったのである。また、今回の画像を見て頂くと判ると思うが、動画ファイル自体も、実は一秒辺りのフレーム数が間引かれたものとなっている。それにより、抽出する走査線の数が一本ではますます足りなくなってしまっていたのである。
というわけで、今回は「失敗した」と言わざるをえない。何か、前回は「簡単である」などと言い切ったような気もするが、それはきっと気のせいであろう。
やはり、これは適当にあるもので間に合わせ仕事をしようとしたせいかもしれない。いつの日か「mov2panorama.exe」を作成し、必ずや必ずや再挑戦をするつもりである(Macでやるのは少しあきらめモード)。
2002-08-26[n年前へ]
■CleType自主学習（仮）
ちょっと真面目にClearType（仮）
(2002.08.26〜)
- 楽しそうな「iMac」＆「電子ブック」風ノートPC用スタンド -はじまり - (2002.08.26)
- 一本道か、分かれ道か - ドキュメントの縦横比について- (2002.08.29)
- 水平思考と垂直思考 - 文字の縦横解像度 - (2002.08.29)
- 細かくすると楽（粗く）になる？ - ClearTypeの一番の秘密- (2002.09.09)
楽しそうな「iMac」＆「電子ブック」風ノートPC用スタンド -はじまり - (2002.08.26)
Lapvantageという楽しそうな会社を初めて知った。ノートPCをiMac風にするLapvantageDomeやPCを縦置きで使うためのLapvantagePortraitという、とても実用的でいて、それでいて明和電機のような面白い製品を作っている会社である。明和電機は兄弟が運営しているが、こちらのLapvantageの方はビアボーム親子がやっているらしい。iMac風スタンドの方は角度が振れないようのが（特にノートPCを立てられない）残念だが、Lapvantageの方はもう少しデザインがスマートであるならば今すぐにでも欲しくなる。
 |  |
複数の作業を切り替えながら作業をしたり、あるいはツールバーが多数出てくるようなソフトウェアを使って作業をする時には、左右に広いディスプレイが便利で使いやすい。しかし、単純に一つのドキュメントを読んだり、一つのドキュメントを書いたりする場合には上下に長いディスプレイを使うと、見通しがきいて考えをまとめやすくなる。気のせいか、頭の中の見通しがとても良くなるように感じたりする。だから、以前から横長の画面のノートPC(ToshibaPortege 320)を愛用していたりした私はノートPCの画面を横にして使ったり、縦にして使ったりと、画面を切り替えて使ってみたいと感じていた。AdobeAcrobat Readerであれば、画面を回転させて文章を読む機能があるので、これまでノートPCを回転させて電子ブックのようにして文章を読んだりすることもあった。
Lapvantage PortraitはPivotProのソフトウェア付きなので、Windowsの画面を自由自在に回転させることができる。だから、ノートPCを普通に横置きに使ってみたり、スタンドに載せて縦置きに切り替えて使ってみたり、と好きなように切り替えることができる。「これはなかなか便利そうだ」と思い、私も私も30日有効のPivotProのデモ版をインストールして使ってみることにした。
そして、このソフトのインストールをきっかけにして
で調べたClearTypeに関して、ちょっと少し考えてみた。 （続く）一本道か、分かれ道か - ドキュメントの縦横比について- (2002.08.29)
前回書いたように、複数のことを考えるなら「左右に長いディスプレイ」が良くて、一つのドキュメントを読むなら「上下に長いディスプレイ」が良い。その理由を端的に言えば、「目が左右についているから」だと思う。
まず、「目が左右に付いているので、あまりに大きい左右への目の動きは、目にとってとても非対称な作業であるから不自然」だ。だから、左右を眺めるときには自然と頭を左右に振ることになる。その頭を左右に振るという作業は、頭の中での何らかの切り替え作業を伴うような気がする。だから逆に、ツールパレットの切り替えのような「何らかの作業の切り替え」を伴う作業であれば、その左右へ視線を移動する（自然と頭も左右に動かす）ということはとても自然な行為になる。しかし、それは一つのドキュメントを読むような場合には、いたって不自然な行為になってしまう。だから、一つのドキュメントというのは本来「上下に長い＝縦長」であるべきだと思う。
そしてまた、「目が左右についているから」、人は上下方向を「一本道」に繋げて考える。例えば、絵画を眺めるとき、上に見える景色は多くの場合遠い景色で、下に見える景色は多くの場合近い景色だ。漱石の文学論の図を引くまでもなく、この「上下の遠さ、距離」というものを例えば時系列上の「一本道」に繋げるのは、いたって自然な連想だと思う。「遠い上」に見えるものは「遠い過去」で、下に来ればくるほど新しいことになる。それは、ドキュメントを読む場合に対応させて考えると、とても自然だ。それに対して、左右に並ぶものは決して「一本道」ではないのである。それは、「選択肢＝分かれ道」であって、決して一つの道ではないのである。左右に並ぶものは「複数の何か」なのである。
だから、一つのドキュメントは上下に並び、上下に長いべきなのである。ドキュメントの表示も同じく、縦に長いべきなのである。
 漱石 「文学論」より |
最近のPCであると、ディスプレイは通常横に長い。だから、本来縦に長くあるべきドキュメントを眺めようとする場合には、表示を90°回転させてやることもある。そうすると、本の一ページのようにして画面表示を眺めることができる。例えば、AcrobatReaderで表示画面を回転させたり、PivotProなど使ってPCの画面表示自体を回転させてやれば良いわけである。
 |  |
 |
このように、ドキュメント表示のための縦横比については、単にディスプレイの表示を90°回転させてやれば問題は解決する。しかし、表示のためのもうひとつの条件、表示品質が問題になってくる。そもそも、液晶(二十世紀においてきたCRTは無視しよう)の解像度はまだま低くて、それを改善するための技術としてClearTypeやCool Fontがあるのだけれど、AdobeのCool Typeはともかく、Clear Typeの場合には表示が90°回転しているという情報をClearTypeが取り扱わない（知らない）ために、上手く動かなくなってしまう。ClearTypeにしてもCool Fontにしても、液晶のRGBのカラーフィルターの並び方を利用してやることで解像度を高めているわけで、その並びの変化（表示の回転）に対応できない場合には表示品質を大幅に落とすことになってしまう。
次に、「ファイト！縦文字文化 -縦と横の解像度を考えよう - (2001.04.29)」で考察した、文字の解像度についてもう少しちゃんと考えてみることにする。
水平思考と垂直思考 - 文字の縦横解像度 - (2002.08.29)
ドキュメントを表示させるためには、文字を表示させてやらなければならない。しかし、液晶ディスプレイの解像度は必要十分には高くないから、文字はつぶれてしまうことが多い。例えば、「現実問題春夏雪雹資本主義電計算機」なんて文字を表示させてみるとかなり潰れてしまい、非常に読みにくいのが判るはずである。これが、英語の"RealProblem seasons Snow capitalism Computer"なんて文字であれば、まだマシである。
この日本語と英語の文字の解像度の差について考えてみる。比較例は下に示した、「漢字」と「英語」のテキストを用いることにする。
 |  |
まずは、600dpiで20ptのMS Pゴシックのフォントを展開して上のような画像にした後に縦・横方向のそれぞれの解像度を考えてみる。ここでは、縦・横方向の黒い線（あるいは線でない部分）の太さ（幅）の分布を測ってみることにした(今回解析のために作成したソフトはここ（RunLength.lzh）においておく)。テキストのような二値の画像の「解像度特性」を計測するのであれば、このような解析にしなければならない。「ファイト！縦文字文化 -縦と横の解像度を考えよう - (2001.04.29)」でやったようなフーリエ解析は適切な方法ではないのである。
下の図が縦・横方向の黒い線（あるいは線でない部分）の太さ（幅）の分布である。縦方向に計測した黒い線（あるいは線でない部分）の太さというのは、結局のところ横線の太さ（あるいは線の間隔）であり、横方向に計測した黒い線（あるいは線でない部分）の太さというのは、結局のところ縦線の太さ（あるいは線の間隔）ということになる。どれだけの細かさで「太さ」（あるいは「位置」）を描いてやらなければならないか、を示すグラフということになる。
 |  |
「漢字」の場合には「Vertical 方向で計測した線の太さ（あるいは線の間隔）、すなわち横線の太さ（あるいは線の間隔）」が「縦線の太さ（あるいは線の間隔）」に比べて、大きく小さい方にシフトしていることが判ると思う。また、横線の量が縦線の量に比べてずっと多いことも判ると思う。後者は「数字文字の画像学 -縦書きと横書きのバーコード - (2000.01.21) 」で考えたことと全く同じで、「日本語は横線が多い」ということを端的に示している。そして、前者は「Vertical方向で計測した（すなわち横）線の太さ（あるいは線の間隔）」が縦のそれより大幅に小さいということは、「漢字」の解像度は縦方向に大幅に解像度が高い、ということを示している。漢字は縦書き文字故に鉛直思考志向なのである。
一方、「アルファベット」の場合には、これも「数字文字の画像学 -縦書きと横書きのバーコード - (2000.01.21) 」で考えたことであるが、縦線と横線の量においてはむしろ縦線の方が多いことが判る。水平方向に対して情報量が多いのである。アルファベットは水平思考志向なのである。「アルファベット」の情報量はそのかなりの部分が縦線によるものなのである。そしてまた、線の太さ（あるいは間隔）は横線の方が細い（あるいは線間隔が短い）が、その横線であっても「漢字」の縦線程度の解像度であることが判る。「漢字」に比べて「アルファベット」の解像度は低いのである。
ただし、文字の解像度を「線の太さ（あるいは間隔）の最小値」だけで論じることはできない。「適切な線の太さ（あるいは間隔）」にすることができるほどに解像度が十分高いか、ということも重要である。もし、そうでなかったら線が妙に太くなったり、細くなったりしてしまったり、あるいは、線の間隔が妙に近づいたり離れてしまったり、つまりは文字のプロポーションが崩れてしまったりするだろう。上の場合は600dpiで文字を表示させた場合の解析例だが、次に現在の液晶と同じような解像度（例えば）150dpiでこの文字を表示（展開）させてみる。こうすることでことで「適切な線の太さ（あるいは間隔）」にできていない様子を確認してみたい。
細かくすると楽（粗く）になる？ - ClearTypeの一番の秘密- (2002.09.09)
まずは、「現実問題春夏雪雹資本主義電計算機」という漢字と"RealProblem seasons Snow capitalism Computer"というアルファベットを現在の液晶と同じような解像度（例えば）150dpiでこの文字を表示（展開）させてみた。そして、前回と同じようにそのビットマップ画像の「縦・横方向の黒い線（あるいは線でない部分）の太さ（幅）の分布」を調べてみる。その結果が下のグラフである。また、前回に調べた、これよりも４倍程解像度が高い「600dpiで20ptのMSPゴシックのフォントをビットマップに展開してみた場合」をさらに下に比較用として示してみる。
 |  |
| |
150dpiでTrueTypeをビットマップに量子化した場合には、漢字・アルファベットの場合共に、縦・横方向とも600dpi単位で4,8pixelの太さ＝150dpiで1,2ピクセル幅のパターンが発生していることが判る。このようなパターンは、600dpiで20ptのMSPゴシックのフォントをビットマップに展開してみた場合には見られなかったものである。つまり、、着目すべきは例えばアルファベットの場合、
- 縦方向には幅10pixel(600dpi単位)=2.5pixel(150dpi単位)以下の高い周波数は存在していなかった
- 横方向には幅13pixel(600dpi単位)≒3pixel(150dpi単位)以下の高い周波数は存在していなかった
- 縦・横方向共に幅4,8pixel(600dpi単位)=1,2pixel(150dpi単位)以下の高い周波数が生じている
- 縦方向には幅7pixel(600dpi単位)≒2pixel(150dpi単位)以下の高い周波数は存在していなかった
- 横方向には幅11pixel(600dpi単位)≒2.5pixel(150dpi単位)以下の高い周波数は存在していなかった
- 縦・横方向共に幅4,8pixel(600dpi単位)=1,2pixel(150dpi単位)以下の高い周波数が非常に多く生じている
また、これらの文字の場合には本来18〜15≒12pixel(600dpi単位)の線幅・線間のパターンが多いわけであるが、それを150dpi単位（ =600dpi単位で4pixel )で量子化してしまうと、場所により4/12 = 33%もの線幅・線間の位置の誤差が生じてしまうことになる。不必要に狭い幅のパターンが作成されたり、不必要に広い幅のパターンが作成されたりして、これでは文字の線が太くなったり細くなったり、線の位置が狂ったりしてしまい、見にくいことこのうえない。これはすべて、150dpiという低解像度で量子化してしまったためである。「低解像度の表示系の解像度に合わせて量子化（ビットマップ化）してしまうと、ますますその表示系では表示しづらい高周波のパターンが生成されてしまい、結果として読みづらい」という一見逆説的に思えてしまう（しかし当たり前の）現象が生じている。
ところで、本題のClearTypeの場合には横方向（通常の液晶はRGBの3つのサブピクセルが横方向に並べられているから）の解像度を3倍だと仮想的に考えて、横方向を3倍の解像度で量子化を行うことになる。ここで、話の単純のために3倍≒4倍と思うことにすれば、つまりはClearTypeの場合には本来150dpiの解像度であるにも関わらず、サブピクセルを考えて600dpiの解像度で量子化している、ということである。それは結局上の二つのグラフの比較と同じであって、ClearTypeを使うと実は表示すべきパターンが「より表示しやすい低い周波数のパターン」になっているのである。それは、「文字の線が太くなったり細くなったり、線の位置が狂ったりしてしまう」ことがなく、目にとってはとても見やすいパターンになるだろう。この量子化の段階について触れている情報は見たことがないが、実はこの量子化の段階にClearTypeの隠された（しかし、一番重要な）メリットがあるように思う。また、アルファベットの場合にはHorizontal方向に振幅を持つパターン（＝縦線）が支配的に多いため、Horizontal方向に仮想的に高解像度の量子化を行うことは非常にメリットを効果的に得られると考えるのが自然である。
次に、このように量子化されたデータをClearTypeで表示する際の問題点・その解決方法について考えてみていくことにしたい。
P.S.ちなみに解析ソフト（RunLength.lzh）をアップロードしました。
2005-09-18[n年前へ]
■実世界「動画パレット」で絵を描く「I/O Brush」
実世界「動画パレット」で絵を描く「I/O Brush」 実世界の色んなものにブラシを向け、その色やパターンや動きで絵(動画)を描くことができる。
そのブラシを使っている動画(リンク先ページの下の方にある)を眺めていると、とても面白く新鮮。比較的簡単に似たようなものは作ることができそうなので、自分用に一本?作ってみるのも良いかも。
2008-07-10[n年前へ]
■あなたの「パレット」にはどんな色が並んでいるだろう？
「パレット」は、美術や図工の時間に使った「絵具を載せて色を混ぜ合わせたりする板」である。それと同時に、「画家が使う色の種類（組み合わせ・並べ方）」のことを「パレット」ということも多い。モネのパレットというと、「モネが使った絵の具の組み合わせや、その絵の具の並べ方」を意味する。あるいは、ゴッホのパレットというと、ゴッホが使った色（とその並べ方）を指すことになる。画家それぞれが、それぞれの「パレット」を持っている。
そんな「パレット」は、画家でなくとも、きっと誰しも持っていると思う。たとえば、あなたは、普段どんな色のペンを使うだろうか。黒いペン・藍色のペン・四色ボールペン……どんな色の組み合わせの筆記用具を使うだろう？それはまさに「パレット」だ。
好きな色・見やすい色・落ち着く色……人それぞれ選ぶ色は違うと思う。たとえば、右の画像はふだん私が持ち歩いている12色のカラーボールペンである。12色あるけれど、並べてみれば、インクの減り具合から実際には(すでに何本目にもなっている黒と白のボールペンを除けば)7色くらいしか使っていないことがわかる。つまりは、これが私の「パレット」ということになる。
他の人たちにも「パレット」を見せてもらったりすると、色の使い方＝パレットに個性が表れていたりして、意外に新鮮に感じられる。あなたの「パレット」にはどんな色が並んでいるでしょうか？
2010-07-01[n年前へ]
■Excel2003が「カラーパレット」色処理を使っていたことに驚いた。
「Excel 2010になっても、エクセルは未だグラフを今ひとつ綺麗に色を仕上げることができない」とつねづね思っていました。そこで、綺麗な配色のグラフをエクセルで使うためのプログラムを書き始めて、とても驚いたことがあります。Excel 2010,2007の動き（また、それらのグラフを旧バージョンで開いたときの動き)をまだ理解することができていないのですが、少なくともExcel 2003までのExcelでは色処理に「カラーパレット」を使っていたのです。それも、他の箇所で異常な色が発生してしまう、といった問題が起きない範囲で使おうとすると、たかだか32色程度の色しか使うことができなく、さらに、もっと安全に使おうと思うなら、たった8色しか使うことができない、という驚くべき仕様です。
もちろん、自由にRGBで色指定をするコードを書くことができるようには見えるのです。しかし、結局のところ、動作させた結果として表示されるのは、カラーパレットから近似色が選ばれるだけなのです。もしも、そういう動作を好まないのであれば、カラーパレット中の色をRGBで指定した後に、作成した色のインデックスを指定してやらなければならないのですが、さまざまな用途に使われる色がトータルで56色しかない、というなかなかにキツい制限の中で作業を行わなければならないのでした。
とはいえ、そんな苦労を(しかもC++で)したおかげで、（できる範囲内で）自由な配色のグラフを(たとえば、上に示したチャートのように)エクセルでプログラマブルに作ることができるようになりました。そして、エクセルで作られた、カラー表示ソフトウェアを、その色表示の意味については”眉につばつけて”眺めることができるようになりました。何事も、自分でやってみてわかること、というのが多いように思います。
」など。
