hirax.net::Keywords::「フィルター」のブログ

■モアレはデバイスに依存するか？　

2つの同心円画像、画像1と画像2。上と下は少し中心位置がずれている。

1. 黒(0)+黒(0)=0(すなわち黒)
2. 白(255)+白(255)=255(すなわち白)
3. 黒(0)+白(255)=255(すなわち白)

1. 画像1を白黒反転し、画像1'を作る。
2. 画像2を白黒反転、画像2'を作る。
3. 画像1'と画像2'を加算し、画像3を作成する。
4. 画像3を白黒反転し、画像3'を作成する。

OHPの重ね合わせをPhotoshopで真似た画像3'

計算実験A:同心円のOHP風重ね合わせ(画像1+画像2=画像3')

画像1	画像2	画像3'

　ところで、上の3つの画像をそれぞれ平滑化してみる。すると、以下のようになる。

画像1,2,3'をそれぞれ平滑化したもの

画像1を平滑化したもの	画像2を平滑化したもの	画像3'を平滑化したもの

重ね合わせにおける加算演算

画像A、画像B

1. 黒+黒=黒
2. 白+白=白
3. 黒+白=黒

加算演算の例(左+中央=右)

画像A	画像A	画像A
画像A	画像B	画像C
画像B	画像B	画像B

　これに平均値も示すと以下のようになる。ここでは、LBPなどの紙に出力する際によく使われる、白=0、黒=255という表記をする。

加算演算の例(左+中央=右)
下段は平均値の加算における変化を示す。

画像A	画像A	画像A
128	+ 128	= 128
画像A	画像B	画像C
128	+ 128	= 256
画像B	画像B	画像B
128	+ 128	= 128

ロゲルギストの-モアレが生じる理由は黒さの非線形性による-という言葉はこの「128+128=128、と128+128=256という結果の違いがあり、それがモアレの原因である」ということを示している。

　それでは、そのような現象「128+128=128という非線形性」が起きない状態を作ってみる。それには加算の結果である黒がサチらないようにすれば良い。

サチらない加算演算の例(左+中央=右)
下段は平均値の加算における変化を示す。

画像A	画像A	画像A
64	+ 64	= 128
画像A	画像B	画像C
64	+ 64	= 128
画像B	画像B	画像B
64	+ 64	= 128

計算実験A:同心円のOHP風重ね合わせ(画像1+画像2=画像3')

画像1	画像2	画像3'

計算実験A:画像1,2,3'をそれぞれ平滑化したもの

画像1を平滑化したもの	画像2を平滑化したもの	画像3'を平滑化したもの

計算実験B:グレー+グレー=黒　の場合

画像1の黒=0を128にした画像4を平滑化したもの	画像2の黒=0を128にした画像5を平滑化したもの	画像4,5を加算したもの

モアレのデバイス依存性

　LBPではトナーが有る所、すなわち、画像が有る所はほぼ完全に影になる。例え、2枚重ねてもやはり影のままである。しかし、インクジェットならどうだろうか。OHPで使うと、黒といってもLBPに比べて薄い。1枚のOHPの黒よりも、2枚のOHPの黒を重ねた方がかなり黒い。ということは、「黒+黒=もっと黒」と同じである。したがって、OHPを重ね合わせても濃度が保存されている。すなわち、モアレが比較的に出来にくいことになる。ということは、OHPを何で作るかによってモアレの具合が変わることになる。付け加えれば、実際のOHPの場合には透過率を考えなければならない。透過率というものは単なる重ね合わせでない、具体的に言えば、加算演算でなく乗算演算である。それでも、話としては大体は同じことである。

　今回はOHPの話に絞ったが、透過原稿でなく反射原稿についても同じである。むしろ、反射原稿の方が乗算演算でなく、加算演算である分、今回の話そのままである。したがって、一般的なモアレについてインク(もしくはそれに相当するもの)の加算演算の具合によって、モアレの発生具合が違うと考えられる。

　また、話の単純のために白黒の話に限ったが、カラーのモアレなどについてもほぼ同じであろう。トナーとインク、また、混ざりやすいものと混ざりにくい物の違いなどでも面白い結果が出そうである。TVや液晶のようにほぼ線形の重ね合わせが成り立つであろうものと比較するのも面白そうである。

　今回の話を考えている途中で、OHPの重ね合わせと干渉の共通点については、結構奥が深いような気がしてきた。そのため、別の回でもう少し詳しく考えたい。

■同心円を描くPhotohoのプラグインを作る。　

　「モアレのデバイス依存について考える。」の過程で作成した、同心円を描くPhotoshopのプラグインについてメモしておく。
　作ったプラグインの名前はCirclePlotである。プラグインメニューではJunHiraxというジャンルの中に現れる設定にしてある。

Windows版　プラグインファイル (circleplot.8bf)

　右クリックで「ソースを保存」すれば良いと思う。

　これがCirclePlotプラグインの画面である。スライダーを動かすことにより、同心円の周期、中心位置のX座標、中心位置のY座標、振幅の最大値を調節できるようになっている。

プラグインの画面

　例えば、このような画像を作成することができる。フィルターをかけると、元画像がどのようなものであっても、とにかく同心円を描く。

フィルターをかけた時のサンプル画像

　ちなみに、使ったパラメータは以下のようになる。このパラメータを使えば、Macintosh版でも同じくCirclePlotを使うことができる、と思う。また、パラメータを見れば、どのようにして同心円を描いているかわかるだろう。

パラメータ

■流れている電子メールを解読してみる　

目的のためには手段は正当化されるか?

　今月のC MagazineのNetWatch Cool&Hotはセキュリティ特集だった。その中でEthernetに流れているパケットの中からMailに関するデータを表示するソフトの紹介があった。もちろん、自分宛てのものだけでなく、他人宛ての物も全て表示するソフトである。
　こういったソフトの正しい使われ方というものがあるとは思えないのだが、技術的には興味がある。ネットワークに関する勉強もしてみたかったので、同じようなことをしてみたい。

　言うまでもないが、今回の実験は家庭内のLAN内ですべて行っている。ただし、メールサーバーは外部のものを使用してはいる。

　自分宛てでないパケットを見る(sniffing)にはイーサーネットのインターフェースをプロミスカス・モードで動かしてやれば良いという。UNIXであればtcpdumpを始めとしていくつもフリーのソフトがある。Windows上で動かすことを考えても、いくつかのフリーソフトがあった。また、OpenDesighnNo.10にプログラミングの例があった。OpenDesighnはソース配布がディスクでしか行っていないのが残念だ。

　今回はWindows上でプロミスカス・モードでパケットをダンプしてくれるソフトを用いた。普通に探せば、すぐに見つかると思う。

　それでは、流れているパケットを見てみる。パケットのダンプ画面には部分的に伏せ字を入れた。また、ユーザー名やパスワードはオリジナルとは違う文字に入れ替えてある。

　LANに繋がっているLibretto50でメールサーバーに対してメールチェックを行った際に流れたパケットを同じネットワークに繋がっているPortege320で読み取ったものの一部が下のものである。

Packet No.: XX00000005Time: 0361530480 msec Length: XX
Ethernet Dest: XX.00.F4.5F.2D.F8 Src: XX.00.24.30.08.ACType: 0x0800
000000: XX XX XX 5F 2D F8 XX XX : 24 30 08 AC 08 XX XX XX..._-...$0....E.
000010: XX 34 58 05 40 XX XX 06 : B3 C2 AC 12 XX 02 D2 E6.4X.@. ..... ...
000020: B0 01 04 XX XX 6E XX 2C : 14 F7 XX AE 43 03 XX 18...f.n.,....C.P.
000030: 22 0B 98 18 XX XX XX XX : XX XX XX XX XX XX XX XX".....USER john
000040: XX XX:................

Packet No.: XX00000006Time: 0361530540 msec Length: 88
Ethernet Dest: XX.00.24.30.08.AC Src: XX.00.F4.5F.2D.F8Type: 0x0800
000000: XX XX 24 30 08 AC XX XX : XX 5F 2D F8 08 XX XX XX..$0....._-...E.
000010: XX 4A E0 27 40 XX EE 06 : 5D 89 D2 E6 B0 01 AC 12.J.'@...].......
000020: XX 02 XX 6E 04 XX XX AE : 43 03 XX 2C 15 03 XX 18..n.f..C..,..P.
000030: 22 XX 24 26 XX XX 2B 4F : 4B XX XX XX XX XX XX XX"8$&..+OK Passwo
000040: XX XX XX XX XX XX XX XX : XX XX XX XX XX XX XX XXrd required for
000050: XX XX XX XX XX XX XX XX :john...........

Packet No.: XX00000007Time: 0361530550 msec Length: XX
Ethernet Dest: XX.00.F4.5F.2D.F8 Src: XX.00.24.30.08.ACType: 0x0800
000000: XX XX XX 5F 2D F8 XX XX : 24 30 08 AC 08 XX XX XX..._-...$0....E.
000010: XX 37 59 05 40 XX XX 06 : B2 BF AC 12 XX 02 D2 E6.7Y.@. ..... ...
000020: B0 01 04 XX XX 6E XX 2C : 15 03 XX AE 43 25 XX 18...f.n.,....C%P.
000030: XX XX XX XX XX XX XX XX : XX XX XX XX XX XX XX XX!./...PASS 12345
000040: XX XX XX XX XX:678.............

　このダンプ画面を眺めると、次のような

　Libretto:私はjohnですがメールチェックをさせて下さいな。
　サーバー:じゃぁ、johnさんのパスワードを言って下さい。
　Libretto:12345678です。

IPパケットの構造について(http://www.dtinet.or.jp/~torao/program/)

Hey!Java Programming! (http://www.dtinet.or.jp/~torao/program/protocol/pop3.html)

を参考に考えてみた。 例えば、先のイーサーネットに流れているメールに関するパケットの中からメールの内容を見るにはどうしたら良いだろうか。

　ひとまず、先頭54Byteと末尾2Byteを捨ててやればTCPの部分だけを取り出せて、良いように思える。また、TCPのポート番号のみでフィルターをかけてやれば、任意のプロトコルのみを取り出すことが出来るだろう。多分。ここでは、47,48Byte目か?

　そのようなフィルターを作成し、取得したパケットにかけてみたのが以下である。

. RETR 1 +OK 771 octets Received: from xxxx (xxxx.xxxx.ne.jp[xxxx.xxxx.251.14])
by xxxx.xxxx.ne.jp (xxxx.xxxx.1/3.7W) with SMTP id xxxx
for <xxxx@xxxx.ne.jp>; Wed, 23 Dec 1998 11:20:54 +0900(JST)
Message-ID: <xxxx@xxxxxxxx>
From: "xxxx" <xxxx@xxxx.xxxx.xxxx.xxxx>
To: <xxxx@xxxx.ne.jp>
Subject: test 試験
Date: Wed, 23 Dec 1998 11:43:38 +0900
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Content-Type: text/plain;
charset="iso-2022-jp"
X-UIDL: 57c82a0ae2ea513ae1221c507123f459

This is a test.
これは日本語です。
さて、読めるでしょうか。

. DELE 1 +OK Message 1 has been deleted. QUIT +OK +OK Popserver at xxxx signing off. +OK

　他人のメールの内容を見るのは私的利用であれ、公的利用であれ、許されるとは思えない。また、例えネットワーク管理者が行うにしても、「メールを盗み見する」という予告・了解なしに行って良いとは思えない。先のメールの内容を盗み見するソフトにどんな正当な使い方があるのだろうか？

■宇宙人はどこにいる?　

画像復元を勉強してみたい その1

　知人から「自称UFO写真」というのものが冗談半分(いや100%位か)で送られてきた。その写真はボケボケの画像なので何がなんだかなんだかわからない。そこで、ぼけぼけ画像を復元する方法を勉強してみたい。UFOは冗談として、画像復元において進んでいるのは天文分野である。そこで、このようなタイトルなのである。もちろん、画像復元の問題は奥が深すぎるので、じっくりと時間をかけてみる。今回はMathematicaを使って試行錯誤を行った。

　ボケ画像を復元するには、ボケ画像がどのように出来ているかを考えなければならない。そこで、ごく単純なぼけ画像を考えてみる。まずは以下の画像のような場合である。

左の点画像が右のようにボケる

画像:1

画像:2

本来、左のような風景がボケて右の写真のようになる。

画像:3

画像:4

　画像:1のような点画像が、画像:2のような分布のボケ画像になるとすると、次のような関係が成り立つ。

(式:1) 画像:4 = 画像:3 * 画像:2

画像:1のような点画像が画像:2になるなら、それを参照すれば、画像:3のような点画像の集合がどう
ボケるかは計算できる。つまり、それが画像:4になる。ここで、*はコンボリューションを表している。
　よくある信号処理の話で言えば、画像:2はインパルス応答である。といっても、これはごくごく単純な場合(線形シフトインバリアントとかいろいろ条件がある)の話である。まずはそういう簡単な場合から始めてみる。

　このようなごく単純な場合には

(式:2) 画像:3 = 画像:4 * (1/画像:2)

とすれば、画像:3を復元できることになる。

そこで、まずは単純な1次元データで考える。下の画像:5のようにボケる場合を考える。ここでは、ガウス分布にボケるようにしてある。

赤い線で表したパルスデータが水色で表した分布にボケる

画像:5

左がボケ画像、右がその周波数領域(フーリエ変換)

画像:6

画像:7

　それでは、試しに適当な1次元データをつくって、画像:6とコンボリューションをとってやり、ボケさせてみる。

左が原画像、右が画像:6と画像:8のコンボリューションをとったボケ画像

画像:8

画像:9

逆フーリエ変換(フーリエ変換(画像:9) / フーリエ変換(画像:7))

= InverseFourier[Fourier[Image8] / Fourier[Image6]]; (*Mathematica*)

とやると、次のデータが得られる。

復元されたデータ

画像:10

(式: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比の大きいところではインバースフィルターに近づく。また、インバースフィルターの計算不能な点が消えている。

　これを使って復元してみたのが、次のデータである。

ウィーナフィルターを用いた復元

画像:11

　まずは、ボケのフィルター(PSF=PointSpreadFunction(どのようにボケるかを示すもの)、2次元のインパルス応答)である。

ボケのフィルター(インパルス応答)

画像:12

左がオリジナル画像、右はボケた画像

画像:13

画像:14

復元した画像

　関係はないが、ウィナーと言えばサイバネティクスが思い浮かんでしまう。当然、ロゲルギストが連想されるわけだが、文庫本か何かで岩波版と中公版の「物理の散歩道」が安く売り出されないのだろうか？売れると思うんだけど。新書版は高すぎる。

　宇宙人はどこにいるか? そういった話は専門家に聞いて欲しい。わからないとは思うが。

　さて、ここからは、1999.01.24に書いている。シンクロニシティとでも言うのか、今回の一週間後の1999.01.17に
日本テレビ系『特命リサーチ200X』で

地球外生命体は存在するのか？( http://www.ntv.co.jp/FERC/research/19990117/f0220.html )

という回があった。何とこの回のコメンテーターは先の専門家と同じなのだ。偶然とは面白いものだ。

■ヒトは電磁波の振動方向を見ることができるか？　

はい。ハイディンガーのブラシをご覧下さい

リチャード・ファインマンの本の中で次のような問題があったように思う。
「偏光板がフィルターが一枚だけある。その偏光フィルターの偏光方向をどのようにして知れば良いか？」
その本の中での答えは、
「物体の反射光を偏光フィルターを通して見てみる。」
だった。ブルースター角で入射した光の反射光は、入射面に対して電場の振動方向が垂直になっている、ということを利用するわけである。

分かりやすいように、偏光フィルターを通してみたガラスの反射光をデジカメで撮影してみる。左が反射光を通すような角度に偏光フィルターを回したものであり、右が反射光をカットするような角度に偏光フィルターを回した場合である。この左の場合、すなわち、反射光が一番通過している角度から液晶の偏光面がわかるわけである。

ガラスに映った夕景を写したもの。偏光フィルタの角度を振った。

ところで、このようなファインマンが示したような方法を用いなくても、そもそもヒトは電磁波の振動方向を見ることができるのである。以前、「渡り鳥の秘密- 3000kmの彼方へ - (1999.01.30) 」の中で「鳥は太陽の位置、光の偏光パターンを位置のセンサーに使う」という話があった。ヒトも同じく光の偏光方向、すなわち、電磁波の振動方向を見ることができるのである。鳥はどう見えるかは私にはわからないが、ヒトならば自らが実験台になれるので、電磁波振動方向をどう見ることができるか調べてみたい。というわけで、「渡り鳥の秘密- 3000kmの彼方へ - (1999.01.30) 」の中で「近日中にある実験をする予定である」と書いたものが今回の確認実験である。なお、光の進行方向と磁界の振動方向を含む面を「偏光面」、電界の振動面を含む面を「振動面」と呼ぶ。

電磁波の振動方向をヒトが見ると「ハイディンガーのブラシ "Haidinger'sBrushes"」というものが見える。それを知ったのは、いつものごとく「物理の散歩道」からである。網膜に複屈折性があるために「ハイディンガーのブラシ」が見えるのだという。

私はこれまで、「ハイディンガーのブラシ "Haidinger's Brushes"」を見たことがない。いや、正確に言えば意識したことがない。そこで、判別しやすいように直線偏光を用意してやることにした。そこで、東急ハンズで偏光フィルターを買ってきた。

そして、空を見てみる。もちろん、偏光の偏りが強い、太陽を中心にして90度の角度をなす同心円方向である。詳しくは、

• 可視-赤外域での偏光観測による衛星観測手法の開発基礎研究(http://www.mri-jma.go.jp/Dep/sa/Lab1/labt01-s.html)
• エアロゾル観測(http://mars.im.kindai.ac.jp/KISYO/YPROJECT/kansoku.html)

さて、ヒトである私は、空を眺めて格闘すること5分程で、「ハイディンガーのブラシ"Haidinger's Brushes"」がわかるようになった。私が見たハイディンガーのブラシ"Haidinger's Brushes"を示す。

私が見たハイディンガーのブラシ "Haidinger's Brushes"

この絵で太陽の方向は右上であり、偏光面は次の絵の青の矢印方向になる。

ハイディンガーのブラシと光の偏光面の対応

というわけで、ヒト(少なくとも私は)電磁波の振動方向を見ることができるのである。慣れてしまうと、白い紙を見つめているときなども(条件によっては)見えるようになる。色を扱う人は意識すると面白いと思う。

ところで、偏光フィルターがどういうものか知らない人のために、NotePCの液晶に偏光フィルターを重ねた写真を示す。

偏光フィルタを液晶に重ねたところ。右と左は偏光フィルターの角度の違い。

なぜ、こうなるかわからない方は、

• 液晶の世界 (http://www.sharp.co.jp/sc/library/lcd/)

そして、面白いことに気づいた。NotePCの液晶からの光は直線偏光である。ということは、NotePCの液晶にはハイディンガーのブラシが映っているのである。正確に言えば、NotePCの液晶を見ているあなたの視界の中央には、ハイディンガーのブラシが映っているのである。と、気づいてみると確かに見えている。

というわけで、液晶ディスプレイを使用している方はハイディンガーのブラシを見て頂きたい。以下のやり方がわかりやすいと思う。

1.このWindowを最大化する
2.下へスクロールして画面を真っ白にする。
3.液晶ディスプレイ(NotePC)を回転させる。
4.画面(視点)の中央に(視点に対して位置が)動かない黄色いもやが見えるはず。もちろん、回転はする。
　液晶ディスプレイやヘッドマウントディスプレイ(HMD)を色々見てみたが、どれにもハイディンガーのブラシは存在していた。視界の中央に不思議な十字架のように現れているのである。現代の液晶技術が負う十字架である。
誰もが、目の前にあるのにそれに気づかないというのも、実に面白い。まるで、「青い鳥」のようである。そして、そういうことはとても多いのではないかと思う。それはそれで面白い話だ。