使用しているImageMagickのライブラリ(Magick++)で，ファイル名の処理がMBCSからUTF-8にいつの間にやら変わっていました。それに気づかず，MBCSで渡していたため，処理できなくなっていたようです。ドキュメント見ても，何も書いていないし。。。。(言い訳)

とりあえず，ファイル名を処理する部分をUTF-8化しましたので，これで問題なく扱えるはずです。よかったよかった。ただいま，Vectorで公開手続き中ですので，数日後には公開されるはずです。

今まで，Windowsばかりだったけど，仕事柄Macを使うこと自体は多く，最近はiPhoneアプリなんかを作っていたこともあって，Mac自体はそう違和感はありません。でも，なんで今更乗り換えるかというと，Ruby on Railsのプログラムなど，Web系のプログラムを書く場合，Macの方がなんか作業しやすいんですよね。ベースがUNIXということもあって，シェルは標準でまともに使えるものが入っているし，Apacheも標準装備。

まだ，ものが届いていないのでよくわからないけど，おそらく困るのがキーボード。今，メインで使っているのがThinkPadで，これくらい深いストロークのキーボードでないと辛い。会社では，iMacを使っているけど，標準のキーボードは最悪。腱鞘炎になるかと思ったので，DELLのサーバか何かについてきた安物キーボードと交換。これの方がはるかにまし。マウスも全然だめで，これはマイクロソフトのに交換。

さて，どうなる事やら。

それに対し，雑誌などビジュアルな出版物の電子化は，どうあるべきなのでしょう。
今，iPadで売られている電子雑誌，はっきり言って，魅力的なものは一つもありません。印刷物の誌面をそのまま画像化したものがほとんど。WIREDみたいに，多少インタラクティブなものもあるけど，結局文字は画像化されてしまっていて，読みにくい。

まず，いわゆる週刊誌のような，「読む」雑誌の場合。これは，もうWebと同程度でいいのじゃないかな。必要に応じて，画像やその他のメディアを埋め込み，読みやすいレイアウトにする。よくある電子書籍・雑誌のように「ページ」を意識させる作りではなく，Webのように縦スクロールでいいんじゃないかという気もします。
まあ，ただのHTML(内蔵フォントのみ)では，書体の自由度が低いのがネックですが。

ファッションなど，ビジュアル重視のもの。これは，自分が読まないので，いったいどうするのが読者にとってメリットがあるのかいまいちわかりません^^;。

よく考えると，ほとんどの雑誌は前者の方法で何とかなるのではないかな。インターネット上のWebとの違いは，販売するためにパッケージングするということくらい?

今，一番の疑問は「書籍の電子化は誰が一番望んでいるのだろうか?」ということ。書籍の電子化，すごく魅力的な言葉にも聞こえます。でも，本当にそうなの？

電子書籍の魅力を考えてみます。

• 収納スペースが不要。端末の容量が許せば，蔵書すべてをいつも持ち歩くことも可能。
• 印刷・製本が不要になったり，流通の単純化によって，販売価格が下がる。
• 検索性の向上。
• 読み手の好みに応じた文字サイズ，縦横(文字組方向)の選択が可能。

スペースのメリットは，個人的にはすごく魅力的です。基本的に，本は買ったらめったに捨てないので，どんどんたまっていきます。この問題が解決するというのは大きなメリットです。逆に，デメリットはと考えると，

• ページのめくりにくさ。
• 解像度の低さ。
• 端末の画面サイズによる表示面積の制限。
• バッテリのもち。
• DRMの存在。

ページめくりについては，紙の書籍ならできる「ぱらぱらめくる」という動作ができません。普段本を読むとき，「これはだいたいこの辺に書いてあったな」という記憶から，ぱらぱらと本をめくって目的のところに達するということはあると思います。また，小説を読んでいて，登場人物の関係などがわからなくなったとき，ちょっと戻って見直すというようなこともあるでしょう。電子書籍の場合，このような動作がやりにくい。もちろん，検索してジャンプという方法もあると思いますが，そういつも目的思考で本を読んでいる訳じゃない。

画面の解像度については，iPhone4がどうかというところが一つポイントかと思っています。iPad等の画面は，通常の印刷物と比べると，圧倒的に解像度が低い。特に気になるのは，文字周りで，通常の書籍であれば，2400dpiとかで印刷されています。なので，明朝のような細めの漢字であっても，十分明瞭に視認できるわけです。iPadなどで文字を見ると，アンチエイリアスで何となくきれいにしているけど，やっぱりぼやっとしていて見にくいです。

画面サイズについては，小説と実用書，雑誌，これらを同じ画面サイズで読むってどうよってことです。通常，文庫本，B5の本，A4の雑誌など，内容やレイアウトの特性に応じていろいろな用紙サイズを使い分けています。電子書籍端末だと，小説を読むには大きすぎ，雑誌を読むには小さすぎるような感じです。

最後にDRM。自分も出版業界の人間なので，DRMのようなものが欲しいことは理解しています。ただ，このせいで正規にコンテンツを買った人が不便な思いをするというのは電子書籍普及の妨げになると思います。なんといっても，端末を買い換えたとき，今まで買ったコンテンツがすべて無駄になる可能性があるというのが悪い点ですね。現状の携帯電話コンテンツも同じですが，書籍の場合，よりダメージが大きいと感じます。個人的には，DRMフリーでもいいじゃないかという思いもありますが。。。そうもいかないでしょう。貸し借りができないというのも辛いところ。

いろいろと書きましたが，なんかいまいち電子書籍のメリットが弱いんです。こう，電子書籍の先にすばらしい未来が待っているといいのですが。。。。

現状，日本でEPUBを読む端末というと，iPad上のiBooksでというのが普通かと思います。もちろん，パソコン上でAdobe Digital Editionを使うという手もありますが，あえてパソコン上でEPUBを読みたいというのも少ないかなと。

で，iBooksでEPUBを表示する場合，データで指定されている書体情報が，無視されるんですよね。小説みたいな，「読書」するための本だったらこれでもいいのかもしれないけど，もうちょっとビジュアルなものをEPUB化したい場合，これは厳しい。

あと，規格上，画像データとしてJPEGなどのラスタデータ以外に，SVGが使えることになっています。また，iBooksもとりあえずサポートしているみたいです。ただ，予想はしていたものの，中途半端。Illustrator CS5で作ったSVGデータを挿入したのですが，SVGの中に埋め込まれているラスタデータやグラデーション部分が抜け落ちたりします。ちょっと残念。

パラメータとしては，
二値化閾値：2枚の画像の差分をとった後，バックグラウンドを引く処理をするときの閾値。ここで指定された値以下の領域は，黒と見なされます。
面積閾値：ラベリング処理後，ここで指定された値より小さい面積の領域は，無視されます。
円形度閾値：ラベリングされた領域の円形度を計算し，ここで指定した値以上の領域は，無視されます。

ShootingStarDetector

(正常に動作しない場合があるので，公開停止中)

2009.11.10 再公開 (Version 1.0.2)

このソフトの実行には，.NET framework 2.0が必要です。

LightenCompositeですが，マルチスレッドで動作します。

ただ，CPUの数だけスレッドを生成するので，最新のCore i7とかだと，8スレッドとかいうことになるんです。その場合，メモリとか，ディスクI/Oとかがボトルネックになって，かえって遅くならないかという不安があります。

ただ，手元ではデュアルコアのマシンしかないので，調べられない。