日記緑ログ

2006/12/07 ~ 2006/12/26

目次

戻る

Blog

デスクトップをテレビにする(時刻表示)

[Create: 2006/12/07 19:26] [LastUpdate: 2006/12/07 19:30]

珍しくも無いものですがデスクトップに時刻表示をつけることを以前から思いつづけております。

問題はテクなどまったく関係の無い部分にあります。

12時間表示というモードがあるとしてどうなるのが適切なのかです。

24時表記なら簡単で、0時から23時までやればいいのです(普通24時という表記はしない)。

12時間表示というのは正午に問題が出るのです。

というのも昼0時とはあまり言わないだろうという思いがあるからです。昼は12時というのが定説になっている気がするのです。いや別にだからなんだということでもないのですが。

せっかくのMeiryoをMS Pゴシックの文字幅に合わせるのはなぜ

[Create: 2006/12/14 19:10] [LastUpdate: 2006/12/16 06:26]

Meiryoの文字幅をMS Pゴシックに合わせてスクリーンフォントにするのが流行っているらしい。グレーゾーンな使い方だがなぜそんなことをするのだろうか。

Meiryoは現在のディスプレイに対してのスクリーンフォントとして最適化してある。まるっこくて紙に出力するには適さないと思うがディスプレイ上で表示すると結構読みやすいらしい。

そのMeiryoの文字幅を変更するとどうなるか。スクリーンショットをいくつか見てみたがとても読みやすいとは思えない。字形が大きく崩れてしまっていて見苦しい。

しかしながら人気はあるようだ。なぜなのか。

アスキーアートのためなのである。今世の中に出回っているアスキーアートはほぼMS Pゴシックが基準になっている(12ポイント)。ならばそのまま見ればいいと思うのだが中途半端なこだわりからかフォントを変更したいのだろう。個人的な意見としては

@-moz-document domain("2ch.net") {

 body {

 font-family: "MS Pゴシック";

 }

}

とでもしてやればいいのではないかと思うのだが。あるいはここだけパッチ当てしたフォントを使ってもいい。

----追記 2006-12-15

一 応理解しているところとしてはMSゴシック系の旧来からのフォントはClearTypeが効かないのが最大の難点だということ。やはりディスプレイに最適 化したビットマップフォントだったのだが昨今の液晶攻勢というか液晶カルテルというか液晶しかメーカー側が提供していないせいで液晶だらけになったので CRT時代よりもジャギーが目立つのでそのせいもあるのだろう。しかしAAはオリジナルのフォントで見るのが一番綺麗だと思うが。

カラー電子ペーパーの時代

[Create: 2006/12/15 21:16] [LastUpdate: 2006/12/16 06:43]

JR山手線の車両内に“カラー電子ペーパー”広告が登場

ついにでたかと。

4096色ということだが試験段階だしいいだろう。

画面サイズは13.1インチで、解像度は512×384ドットということは50dpi弱だろうか。いかにも低解像度のような気がするがこれもいずれもっと上がるだろうし、ブリヂストンの方式は半ドット黒とかできたような気がしないでもない。

松下がまた電子書籍リーダーとしてWords Gearなんぞをだしたがやっぱり電子ペーパーにして欲しいと思っている。

さ らに何度も語りかけているのだが専用コンテンツ以外も読めるほうが絶対にいいと思うのだ。今までも何度かそういった試みがなされているがコンテンツサイト が潰れている場合も数多くある。ということは終わってみれば端末が何の役にも立たなくなってしまうのだ。それよりも汎用の形式を読めるようにすることで端 末が多く売れることを期待したほうがいいと感じる。

(Words Gearは専用コンテンツ以外のJPEGやMPEG4動画等も再生閲覧可能。液晶ということが一番の難だと感じている)

要するにプレーンテキストでもJPEGでもみれる電子ペーパーの端末をくれと。液晶はザウルスでもなんでもいいわけだから。

価格について。

Words Gearはおよそ4万円。高いようだが文庫本百冊程度だ。このぐらいはせいぜい三月でカバーできる。といってもデータも購入するとすればさらにかさんでい くわけだから実本よりもデータの価格が大幅に安くないと意味がなさそうだ。ニュース系のサイトで「百円というありえない値段」のものも出るとか出ないとか 言う話もあったので百円として、一日一冊と見積もり、かつ平日のみとして月二十冊としよう(ヘビーな読書士にはかなり少ないだろうが、この程度読んでる人 は病気扱いする人もいるので参考程度)。

一方文庫ばかり読むとして、価格は五百円としておく。すると、

一月目:42000 10000

二月目:44000 20000

三月目:46000 30000

四月目:48000 40000

五月目:50000 50000

となり、五ヶ月目で同等になる。読み終わったものはどんどん古本屋に流す人はもうすこし違うかもしれないが一般に文庫本は新刊でも買取が激安なのであまり変わらないかもしれない。

電子書籍と端末

[Create: 2006/12/16 17:21] [LastUpdate: 2006/12/16 17:39]

Words Gearについて少しまとめて考えてみた。

そもそも松下はΣBookというものを出していた。まああまり成功はしなかったような気がするが、それはひとえに制限が大きすぎたという判断をしているようだ。

ΣBookは記憶型液晶を使用して消費電力を抑えた端末だった。しかしながらそれなら電子ペーパーを使いたいと思う連中は多かったようだ。

Words Gearはカラー液晶で、動画、音声再生も可能だという。iPodのようなものがおおはやりしたから安心して出せるということか。しかしそれならザウルs(ry

今回はJPEGも閲覧可能としっかり明記されているので、azurでもT-Timeでも使ってイメージ書き出しして使えばつかるのではないかという期待もある。が、そんなことをするならザウルs(ry

液晶も普通の液晶なので充電電池で六時間。行き帰りの電車のなかでと考えてもせいぜい片道二時間程度だろうから一日は持つ。が、出張では無理かもしれない。

コンテンツ配信だが、はやり電車で読む人が多いと思う。家で読んでもいいわけだが、外では駅周辺で購入したい。ということはなんだ、SDカードを差し込んでコンテンツを購入する自販機が欲しい。

まあコンビニのポチポチ端末のようになるでしょうな。

で、実際これを購入するのもいいのだができればフルカラー電子ペーパー(ハイカラー程度でもいいけど)での読書端末(むしろ音声とか邪魔な気がしてならない)が欲しいところですね。待ちですかね。

ち なみにコンテンツもまだまだ足りない気がする。これの場合は実本にする必要がないから印刷も製本も要らない。場所も取らないし、配送も必要が無い。という ことは絶版にしないでよい(HDDは食うけど)。1年も店頭にありつづけられない本が多いので実はそっちが目的なのだが、超人気物も超マイナーも無いよう な気がするのが残念。ただし出版社は結構乗り気に見えるので(JASRACあたりとは違うのかEMIとかSCとかそっちか)今後益々発展することに期待し たい。

そしてそのころまで紙で待ちたい。人柱? 嫌です。

絶句店員

[Create: 2006/12/17 20:14] [LastUpdate: 2006/12/17 20:22]

別にどうって事は無いのだがマニュアル通り、あるいは経験則で動いている何らかの店の店員というのは予想外の事態が起きることを想定していないようで、稀にヘンな客(私)がヘンな行動、言動をとると絶句することがある。

それ自体は問題は無いが納得できる事例と納得できない事例を合わせて紹介しておこう。面白くは無い。

納得できる事例:ビデオレンタル店にて会員登録

「会員登録のサービスで一回百円の割引券を七枚発行します。さっそく一枚お使いになりますか。」

・はい

・いいえ←

「……(怪訝な顔をして絶句)」

納得できない例:HDDをPC専門店にて購入

「seagateの○○GのHDDを下さい」

「……(は? という顔をして絶句)」

#恐らくseagateをセアガテと読むと思っているとかそんなところだろう。

Video File APIの拡張案

[Create: 2006/12/25 19:33] [LastUpdate: 2006/12/25 19:44]

話があっちゃこっちゃで申し訳ない。

デファクトスタンダードの地位を確立したVFAPI 1.0だが、その仕様の制限から最近敬遠されている気がする。

というのもPCでTV視聴のような使い方が一般化してきてMPEG系の動画が益々増えてきた(というかその他がほぼ皆無)からだろうと思う。

VFAPIはRGB各色8ビットしか対応していないわけだがMPEG形はYUV形式、YV12であるし、保存形式、中間形式、取り込み形式のような部分でのデータ交換はYUY2というのが標準になっているからだろう。

YUV色空間とRGB色空間では(各色8ビット整数に制限しているため)変換時に誤差が発生する。また変換のために余計な演算をしなければならない。そのためにどうも敬遠されているようなのだ。

拡 張自体は適当に構造体にメンバーを付け加えれば容易な気がする(例えばVF_StreamInfo_VideoにColorSpaceのようなメンバーを 追加すればいいのではないだろうか)。音声も最近では5.1chのような多チャンネルサラウンド音声が普及してきている(とはいってもこれは拡張する必要 すらないかもしれないが)し、場合によっては浮動小数点数で値を扱うこともあるだろう(これはtype定義が必要かもしれない)。

と、思っている人は大勢いるのだろうが何にしろ公式に採用されること、さらにはそれが広く採用されることが必要になってくるわけでなかなか難しいのだろうなあ。

Video File APIの拡張案2

[Create: 2006/12/26 18:45] [LastUpdate: 2006/12/26 18:45]

例えば以下のように拡張する

typedef    struct {
    DWORD dwSize;
    LONGLONG dwLength;
    DWORD dwRate;
    DWORD dwScale;
    DWORD dwWidth;
    DWORD dwHeight;
    DWORD dwBitCount;
    DWORD biCompression;
} VF_StreamInfo_Video,*LPVF_StreamInfo_Video;

biCompressionにはBI_RGB、BI_BITFIELDS、あるいはMAKEFOURCC('Y','U','Y','2');のようにFOURCCを入れる。これはMSが言っていることと同様なので問題はないと考えられる。

さて、更なる案だがRGBでもYUVでもいいが各色のビット数を増やすという手法もありうるはずだ。実際これはよく使われている。が、少しおいておく。

VFAPIの思想を想像すると簡単な仕様と使用があるのではないかと思える。音声こそチャンネル数とビット数に選択の余地があるが映像に関してはまったくない(RGB24ビットのみ)。これは仕様を簡潔にすることでの実装時のバグの混入を防ぐのに効果がある。

そこで、遅くなるのは十分に承知しているが、画像処理ということを考えて小数以下切り捨て誤差を防ぐための浮動小数点数を導入するのはどうだろうか。

ビ デオ処理ではフィルタ演算の回数を増やすと切り捨てによる誤差の蓄積が大きくなってくる。はっきりと言ってしまえば数回では問題にならないだろう。また実 用範囲では16ビット整数でも問題無い程度だと思う。が、どうせファイルに書き出すわけではなくメモリ間でのやり取りだけなのだから多少贅沢に使っても問 題無いだろう。32ビット精度の浮動小数点数でも十分だ(倍精度は必要ないだろう)。

ただそんなにVFAPIで渡り歩く必要も無いだろうとは思うのでAPP内部演算で十分かなあとも思わないではない。

むしろ整数を捨ててこれだけにしたAPI体系ということも考えられないではない(そのほうが簡潔になるため)。

どちらかといえばYUV色空間に対応するほうが重要かなあ。まあどっちにしろ単なる案ですけど。