2001-04-29[n年前へ]
■ファイト!縦文字文化
縦と横の解像度を考えよう
今年も去年に引き続き英語研修を受けている。といっても、去年は毎日十五分の英語研修だったが、今年は週二日のものを二種類受けている。何事も、「一番弱いところを強くするのが一番」というわけで、それが私の場合は英語であるわけだ。いや、もちろん弱いところは数え切れないほどあるのだが、英語はもうどうしようもないくらいダメなのである。
その英語研修を受ける中で、本当に実感するのが「頭の中でも英語で考えないとキツイ」ということである。頭の中で日本語で考えてから英語で喋ろうとすると、その「日本語→英語変換」のオーバーヘッドはすさまじくて、とても会話にならないのである。もちろん、当然その逆もしかりで「英語→日本語変換」なんかもやっていたら、あっというまに相手の喋るスピードについていけず、「ここはどこ?私はだれ?」状態になってしまう。
もちろん、「頭の中で英語で考えられる位なら、そもそも苦労はせんのじゃぁ!」と叫びたくなることもしばしばあるわけで、実際のところ私にはどうしたら良いのか全然わからないのである。「頭の中に言いたいことは沢山あるけど、それを伝えられない状態」と「頭の中でたいしてものを考えることができない、それを伝えられる状態」とどっちかを選べと言われても困ってしまう。残念ながら、「英語で頭の中でビュンビュンと考えて、それが口からペラペラとでてくる」状態は私には遠い夢物語のようなのである。
こんな苦労は、日本語人生一本やりだった私が英語を使う場合にはどうしても避けられない話なのであるが、そんな「私の苦労」と似たような話はコンピュータの世界にも実はある。例えば、「今日の必ずトクする一言」でもよく登場する「Windowsの日本語化のオーバーヘッドに関する一連の話」などがそうである。超漢字あたりであれば話は別なのかもしれないが、Windowsに限らずどんなOSであっても英語だけを使うときと、日本語のような言語を使うときではスピードが全くと言って良いほど違ってしまう。
例えば、英語版のWindowsであれば最新型のPCでなくてもサクサク動くのであるが、これが日本語版のWindowsともなると、最新型のPCでなければカタツムリのようなスピードに変わってしまうのである。最新型のWindowsやMacOS***の推奨マシンスペックは○×○×です、とOSメーカーが言ったところで、それは英語圏での話で日本語人生の私のようなものにはそれは当てはまらないのだ。わずか100文字ほどのアルファベットですむ英語の場合と、約七千字ほどもある日本語を使う場合とでは文字・フォント処理のスピードが違ってしまうのは当たり前の話である。
ところで、英語と日本語をコンピューターなどで扱う時の大変さというものは文字数だけの話なのだろうか?数が多いから大変なのは当たり前なのだが、それだけではないのではないだろうか。単に文字数が多いというだけではなくて、一つの文字当たりの情報量も日本語の方が遙かに多いと思うのである。例えば、アルファベットの中でも複雑な形をしている"M"と、日本語というか漢字の中でも結構複雑な形をしている「廳」を比べてみれば一目瞭然だろう。"M"よりも、「廳」の方がずっと複雑な形状をしている。
漢字の文字数が多いということは、そのたくさんある文字を区別するためにも漢字という文字の形状自体が複雑にならざるをえないわけで、それはすなわち漢字一文字の情報量はアルファベット一文字の情報量よりも遥かに多いということだ。ということは、
- 一文字辺りの情報量が多くて
- しかも文字数が多い
しかし、「PC内部での処理も大変ではあるが、それを外部に出すときも大変だろう」というのが今回の話のテーマである。モニタやプリンタに出力する時の大変さも英語と日本語では大違いで、しかも英語文化で考えると見えない落とし穴があるのではないだろうか、という話である。
まず、文字を表示するスペースというのは大体決まっている。そんな限られた同じスペースの中に、一文字辺りの情報量が少ないアルファベットと多い漢字を同じように詰め込めるだろうか?先ほどの"M"と「廳」を縮小して10pt程度にしてみると、その答えはすぐにわかる。アルファベットの"M"の方はちゃんと読めるとは思うが、漢字の「廳」の方がちゃんと識別できる環境の人がいるだろうか?PCの画面に表示されている「廳」はずいぶんと省略されたてしまっていたり、あるいは潰れてしまっていたりするはずである。
つまりは、PCの内部でも漢字のような文字を扱うのは大変であるが、それを外部へ表示したりするのも実際問題大変なのである。英語圏のアルファベット文化から考えれば、10ptなんて大きくて読みやすいと思うのかもしれないが、漢字などを考えると今のモニタの解像度では10ptでも小さすぎるのである。逆にいえば、アルファベットなどを表示する時に比べて漢字などの文字を表示する時には、遥かに高い解像度のモニタが必要とされるのである。PC自体の能力だけではなくて、モニタなどの出力機器も遥かに高い能力が必要とされるわけだ。
もちろん、それは漢字だけの話ではない。世界中の文字で当てはまるハズの話である。試しに、
- 世界の文字 (http://www.nacos.com/moji/)
アラビア文字あたりはラテン文字であるアルファベットと同じ程度の複雑さであるが、その他の文字はやはり遥かにアルファベットよりも複雑な形状をしている。「この中の半分くらいは使われていない文字じゃねぇーか!」という声も聞こえてきそうな気もするが、そんな小さいことを気にしてはいけない、とにかくアルファベットは色々ある文字の中でも単純な形状をしていて、漢字は複雑な形状をしているのである。
次に、それぞれの文字画像の複雑さの特徴を眺めるために、それぞれ二次元フーリエ変換をかけて、周波数空間に変換してみたものを示してみることにしよう。まずは、漢字の例を示して図の見方を説明してみたい。
図の横・縦方向が実際の文字の横・縦方向に対応し、図の中で中央から外周方向に向かって低周波から高周波の成分の量を示している。強さは 小 ← 赤 黄 黄緑 青 紫 → 大の順番になっている。 たとえば、この漢字の例だと |
上の説明に書いたように、こんな風に文字画像を周波数空間に変換すると、「漢字は縦と横の線が多い」ということがよくわかる。しかも、
の時に調べたように、漢字は「縦方向に周波数成分が多い」、すなわち言い換えれば「横方向の線が多い」こともわかるのである。 さて、世界の文字六種に戻って、それぞれを周波数空間に変換して並べてみると、こんな感じになる。
こうして六種の文字種を周波数空間に変換して眺めてみると、色々なことが判る。例えば、
- アラビア文字はほとんど高周波を含まない
- ヒエログラフは比較的高周波が少なく、方向性も持たない
- 漢字に含まれる高周波成分はほとんどが縦・横方向のみであり、その中でも「縦方向に周波数成分が多い」、すなわち言い換えれば「横方向の線が多い」
- アルファベットは低周波がメインであり、縦横では横方向の方が高周波を含んでいる、すなわち縦の線が多い
- マヤ文字は一番高周波まで含んでおり、比較的方向性も少ない
- ロンゴロンゴ文字はアラビア文字よりも高周波が多いが、それでも比較的低周波メインであり、方向性もない
もちろん、ラテン文字が比較的高周波が少ないからといって今の表示装置で十分だというわけではなくて、ラテン文字でもより高解像度のディスプレイが必要とされている。例えば、液晶画面などで文字を多量に読むことを想定している電子ブックなどの用途のためには、
で調べたMicrosoftの「ClearType」などの技術がある。これは液晶のRGBの画素の配列が横方向に並んでいることを利用して、横方向の解像度を高める技術である。ということは、こういう技術は横方向の高周波成分が多いラテン文字などでは効果が大きく、またラテン文字自体が比較的高周波成分が少ないために、こういう技術を使えば必要十分ということになるのかもしれない。しかし、日本語(漢字)のようなもともと高周波成分が多くしかもそれが縦方向に多い、というようなものでは効果は比較的少ないことが考えられる。もちろん、それは液晶というデバイスの特徴によるもので仕方のない部分もあるのだが、もしかしたらもしかしたら日本語のような縦方向の高周波を再現しなければならない言語のことを意識していないせいかもしれない。
こんなことは液晶などのモニタだけではなくて、一般的なプリンタもそうだ。例えば、インクジェットプリンタではエプソンのPM-900Cの仕様などを眺めてみても、標準で720×720dpiで、高画質モードでは1440×720dpiとなっている。それはレーザービームプリンタなどでも同じで、リコーのプリンター大百科からウルトラスムージングテクノロジーを見てみても、やはり横方向の解像度のみを高めて2400dpi×600dpiとなっている。やはり、プリンタなどの印字装置でも横方向の解像度を高めようとはするが、縦方向の解像度は低いままにしているのである。もちろん、縦方向の解像度を高くすると印字速度が遅くなってしまうという、プリンタの特性があるにしても、やはり日本語を印字するためには不利な設定となっているのである。日本人としては、解像度表示は縦方向を重視するべきで、横方向の解像度表示にダマされるべきではないのである。高解像度2400dpiなんて言われても、「ヘヘン、オレは縦文字文化の日本人だから関係ないんだもんね」くらいは言って欲しいわけである。
実際のところ、せっかく日本語(漢字)を使うのだから、日本語の特性に応じたPCやモニタやプリンタがあっても良いのになぁ、と思う。いや、というより日本語の特性をもっと理解するところから始めなければならないのかもしれない。そうだ、私はまずは日本語の勉強から始めるべきなのだ。英語の勉強をしている場合ではないし、頭の中で英語で考えていたりすると、縦文字文化に合った発想ができなくなってしまうに違いないのである。って、英語学習から逃げてるだけだったりして…
あぁ、しまったぁ。今回はホントに真面目な話になってしまったぞ、と。しかも、まるで国粋主義者みたいだし。
2001-10-11[n年前へ]
■「アートという心 テクノロジー」セミナー
10月22日、午後6時、東京駅近く、と。めもめも。(リンク)
2002-02-18[n年前へ]
■「非線形処理+畳み込み処理」の公知資料
特開2001-216513を出願した方からメールをもらった。「自然対数を使う数式自体は昔からあるとは思いますが、画像処理ソフトで、この計算を使ってピンボケを作り出すソフトまたはそのアルゴリズムが存在したのかご存じないでしょうか。」ということだった。
「非線形処理+畳み込み処理」はおそらく公知資料があるのではないか、ただし、非線形処理と畳み込み処理のいずれもが実装されたソフトは昔から多々あるが、それをワンアクションで実装したソフトは無いかもしれない、と返事を出した。また、「ところで、私自身は特許はあまり好きではないです。といっても、個人としてはですけど。それに、特許を申請するXXさんの考えも良く理解できます。」と書いた。で、メールの最後に
「それで、少し知りたいのですが、私は自分で作ったプラグインなどもいつもそうしているように何かの話のネタを作って、ソフト自体はフリーで配布すると思います。で、私以外にも自分で画像処理やプログラミングをしている人は多いので、そんなこともあるだろう、と思いますが、そういうときにXXさんはどうされるつもりでしょうか?」
と書いた。それへの返事は来ていないが、もう少し調べてみた。構成としては、特開平08-241407や特開平09-130609が近いか。で、昔に遡れば公知資料もあるかしらん。しかし、特許調査で公知資料探しなんてまるで仕事みたいでイヤだな。
SUB 画像ボケが「非線形変換→畳み込み→非線形」で表されるとの記述は昔の教科書に載ってた。SUB 特開平09-181966畳み込みでボケ味を出す、複数画像を撮影することで任意の距離のボケを実現。 by オリンパスSUB 特開平09-130609等LUT→ローパスフィルター→LUTで画像ボケ信号を作成 by 富士写真フィルムSUB 特開平07-200817フィルタリングによりボケ画像を作成する ダイキン工業SUB 特願平09-542474対数変換をした上で畳み込みを行う画像変換 サイエンスアンドテクノロジーSUB 特開平08-285726畳込みによるカメラなどの光学系シミュレーション ホーヤSUB 特開平08-241407非線形変換→畳み込み→非線形変換の画像変換 IBMSUB 特開2000-20691非線形変換+デコンボリューションによるぼけ復元、背景の説明中に、非線形変換+畳み込みによるボケ計算を説明 キヤノン
2004-01-08[n年前へ]
■Appleのクラスタリング技術『Xgrid』テクノロジー
これはとっても簡単そうなXgrind。少し前に結構いじくりまわした「とっても使いやすい」大日本印刷のAD-POWERs 「通常のグリッドやベオウルフクラスタにくらべて - とっても簡単、利用者にプログラマビリティを与える、遊んでるPCをのっとる - がコンセプトで、複雑なタスクコントロールやIPCなどはまったく用意していなく、並列処理というより並行処理を容易に机上でできるよう考えられていて、エントロピアが似たコンセプトで、pthread使うほうが慣れとコツが必要なくらい」というAD-POWERsよりも、さらにもっと簡単かもしれない。実際、中身を眺めて使ってみると、ずいぶんと簡単にいろんなこと(だけどやっぱり単純な並行処理)ができそうだ。とりあえず、「グリッド」でない「並行」処理のプログラムであれば、既存のプログラムを一瞬で流用できる。これは、結構便利かも。
とはいえ、複数ジョブを簡単に処理させようと思うと、WEB管理システムの付いているAD-POWERsの方が優れているかも。こっちなら、PCが苦手な人にも本当に気楽に使ってもらえるし。 from スラッシュドットジャパン
2004-02-14[n年前へ]
■アダルトビデオの科学 今日のトリビア 編
「帰ってきたオッパイ星人の力学 アダルトビデオ鑑賞 編(仮題)」改め、「アダルトビデオの科学 今日のトリビア編 - 横揺れ縦揺れ2.5ヘルツ -」です。
アダルトビデオの振動方向はジャンルによって違うが、一秒間に2.5往復ほどである。ブロックマッチング、モルレーのウェーブレットで時系列周波数解析、そんなこんなでエロエロを解析。えっ、こんなテクノロジーを使っても解析する対象を間違えているんでしょうか?しかし、そんな科学や新しいテクノロジーを牽引している原動力も(時には)エロエロだったりするわけです。
気づけば今年初の「できるかな?」、しかも聖バレンタインな日にこともあろうに「アダルトビデオの科学」 うぅ。それでも…「それもまた良し」ということにしておきましょうか。