しばらく前からこのサーバのHDDが壊れがちでSMARTがブータれていました。容量の少なさもあり、昔のデータを消しながらの運用だったこともあり、交換しました。
このサーバは2002年に買ったThinkPadで、かなり古い。本当はfit-PCみたいな小型の省電力マシンを買って、ついでにSATAにして1～2TBくらいの容量にしたいところでしたが、予算の関係でPATAの320GBのHDD(Western Digital)を買って交換しただけ。2.5インチのPATAだとこれが一番容量が大きいようです。値段は1万円もしませんでした。
新しいマシン用の予算とCentOS6を待ちたいという気持ちは大きかったけど、一気にクラッシュする恐怖感には勝てなかったんです。
トラブルはいろいろありました。主な原因は(いつものことですが)手順を考える前に実行してしまったことと、子供の相手があるのでまとまって作業できなかったため、相当横着してしまい、けっこうダウンタイムが発生しました。
私のネット上の活動はこのブログとFlickr、deliciousがメインで、あとは裏でWorld Community Gridは動かしてましたが、このたびネット活動を増やしてみることにしました。
もちろんTwitterじゃないですよ。
というわけで、今日はGPSを使って地図を作るという話です。
この話を始める前に、地図データというのはあまりオープンではなく…ということから話を始めないといけないはずなんだけど、その種の情報はよく知らない。Google mapもYahoo! mapもあるし国土地理院もあるけど、とにかく地図というのはいろいろな意味でフリーなものではない、としよう。だって自分で編集できないでしょ。
世間にはOpenStreetMapというものがありまして、これはみんなでCreative Commonsなライセンスの地図を作ろうというプロジェクトです。地図のWikipediaみたいなもん、と言えばいいんですかね(WikipediaもOpenStreetMapもCC BY-SA)。ユーザが提供したGPSのトラックログなりCCなデータを使って、地図を作る。ユーザはGarminとかのGPSデバイスを持って道路を歩き、そのログをトレースしていけば地図ができるよ、というものです。既存の地図の写しではなく、自前でデータを作って、それをもとにみんなで編集していく。
私にとってはファルコムのゲームと言うとロードモナークです。ゴチャキャラのシミュレーションゲーム。最高傑作と言ってもいいんじゃないか。PC-9801時代にはずいぶん楽しませてもらいました。
音楽フリー宣言で思いだして、検索してみたら、今は無料でダウンロードして遊べるんですね。ユーザが作ったマップでも遊べる。いい世の中になりました。というわけで、先週末は久々にロードモナークで遊んでました。そういえばこんなマップもあったなぁなんて。あの音楽も好きです。
PC-9801当時と比べると、画面の解像度が上がったのでマップの見渡せる範囲が広くなりました。中サイズのキャラでも、ほとんど全部のマップを見渡せます。快適快適。
うちのVistaでは、普通にやると終了時にエラーが出ますが、実行ファイルのプロパティからWindows 95互換モードに設定するとエラーが出なくなります。ただ、セーブがなぜか失敗します。セーブするには、SAVEという名前のディレクトリを掘る必要がありました。
フリーな動画フォーマット、Ogg Theora。こないだ晴れてバージョンが1.0になったので注目を浴びている。いまどきはだいたいMP4(H.264/AAC)が良いとは思うが、永続的に保存する場合はフリーなものという選択肢もある。H.264もいつまで主流か分からないしね。
TheoraはWindows用のコーデックを入れればメディアプレイヤーで再生できるようになる。H.264のMP4はffdshowを入れれば同様にメディアプレイヤーでの再生が可能(ffdshowの新しいのはTheoraにも対応してるのかな？)。デジカメのMotion JPEGのaviは何も入れなくても再生可能。
というわけで、圧縮率を比較してみよう。デジカメを買い替えて、時代によって動画の構成が変わるので、それぞれについて、全部エンコードしてみた。
theoraはffmpeg2theoraでオプションなしでエンコード。H.264は以下のようにエンコード。
ut
H.264の動画はこの設定では音声がかなり不自然になってしまうような…。実際に使うためにはオプションを調整することになるだろうけど、サイズの比較には使えるんじゃないかと思う。
| 元データ(motion JPEG) | Theora | H.264 | |
| EXILIM時代 | 35.54MB | 24.88MB(70%) | 17.39MB(49%) |
| Optio時代 | 70.93MB | 22.55MB(32%) | 18.32MB(26%) |
| GRD時代 | 3763.20MB | 1458.04MB(39%) | 705.16MB(19%) |
GRD時代のファイルがやたらに大きいのは、子供をたまに撮るようになったということと、解像度とFPSが上がったため(320x240/15FPS → 640x480/30FPS)。目安的には、1分で100MBくらいになるという印象。
sqliteにもvacuumあるらしいですね。作り直してコピーするという内容らしいですが、作って消して…と繰り返しているDBはかなり小さくなるという噂。
sqliteは便利です。ほかのプログラムに組み込みやすいし、設定も少ないのにSQLを食えるので、いろんなところで使われています。blogのDBに使っている人もいるし、tracのDBなんかも普通はsqliteですよね。
sqliteはFirefoxにも組み込まれている。そこで、Firefoxのプロファイルディレクトリにあるsqliteファイルをvacuumするスクリプト。
パス名がWindows用です。Linuxで使う場合はbasedirに$HOME/.mozilla/firefoxを入れればよいと思われます。Firefoxを閉じてから実行しないとエラーになります。
ログ取得ツール#! /usr/bin/python
import os,sys
import sqlite3
import glob
basedir=os.path.join(os.environ["APPDATA"], "Mozilla", "Firefox", "Profiles")
for i in glob.glob(os.path.join(basedir, "*.*", "*.sqlite")):
print i[len(basedir):]
con=sqlite3.connect(i)
c=con.cursor()
c.execute("vacuum")
con.close()
確かに、けっこう小さくなりますね。まあ、Firefoxのファイルに関しては気休め程度です。
Calcのテキストファイルのインポートは全く改善されていないような感じ。セルがリンク情報を持っていて(元ファイルの更新に追随できて)、それなりの自由度がないと使えないですよ。たまたまテキストファイルをオープンしたらそれなりの解釈をしてセルにデータを入れるだけというのは私としては受け入れられない。
実はExcel 2007でこのへんの機能は非常に不安定になって不便に思ってます(それでもOOoよりは格段にマシです)。リンクの関係を編集しようとするとExcelが落ちる。MSに情報を送信するかどうかのダイアログボックスで何度かMSに情報を送信してますが、いつか対応されるのかなぁ。
Writerはブログ投稿のxmlrpcのインタフェースがあれば使うかも。HTMLを生成してxmlrpcで送るだけだから、プラグインとかで作れるような気もする。OOoの日本のコミュニティにはあまりいい印象がないのだけど、バグレポートとかフォーラムとか、時間があったらのぞいてみようかな。
最近、IBMのWorldCommunityGrid(WCG)に参加しています。Riceというプロジェクトがお気に入り。Riceは栄養価の高い米を開発するプロジェクトです。始めてから1月くらいですが、累計ポイントは現在4万5千くらい。
地球で生存できる人口は、耕作地のサイズからだいたい計算できると思う。農耕に使える土地の面積から適正な人口が導き出せると。それからすると、日本は人口が多すぎるんではないかなぁ。
人口を増やすor増えた人口を養うには、耕作地を増やすか、海洋資源をもっとうまく使うか、耕作の効率を高めるくらいしか思い浮かばない。米や麦が主食の地域が多いが、米と麦の優劣に関しては米が勝つという認識でいる。米は連作できるし、単位面積あたりのカロリー生産が麦よりもだいぶ高かったはず。その効率の良い米の栄養価をさらに高められれば、世界の人口を増やせるはずだし、日本の人口も維持できたりするんでは？
人口を増やしてどうするかって？ それはわからないな。でも飢餓で死んでしまう人を減らせるなら、悪い話じゃないだろうと。
インストールは簡単で、ユーザ登録してWindowsならWCGのクライアントをダウンロードしてインストールするだけ。ユーザ登録時のユーザ名とパスワードが必要になる。
cinepaintでブラケット撮影の画像を読み込んで1つにできると聞き及び、やってみた。ずれを検出して補正する機能もついていた。Fedora8で
でインストール、cinepaintコマンドで起動できる。さっそくこのへんのチュートリアルを見ながら、「ファイル」-「New From」-「Bracketing to HDR」を選び、ずれ(offset)を検出、HDR画像を生成してみた。紫色のエリアがたくさんできるので、「画像」-「Colors」-「Gamma-Expose」で適当にチェックすると、それらしい画像になった。
ただ、手持ちだとさすがにずれはいかんともしがたいですね。cinepaintの補正は平行移動を仮定しているようだけど、それだけではずれがおさまらないです。非常に手ブレ感のある画像になってしまいます。あと、HDR画像をOpenEXRで保存できませんでした(gamma値が外れているとかいうエラーが出る)。xcfやtiff、hdrなどの形式では保存できましたが、cinepaintとgimpの世代が違うらしく、xcfをFedora8のgimpでは開けないという…まあ、32bit IEEE floatをやめてPNGあたりで保存するのがいいかなぁと思います。8bit unsigned intにしてもjpegで保存できませんでした…
会社の人から「何やってんの、Rawtherapee使えばそんなの楽勝っすよ」と言われたので試してみた。rawtherapee hdriでぐぐると、日本語ではその人のページと2chのログくらいしか検索されないんですけど… さっそくインストールして使ってみた。Windows版にはgtk+のライブラリやら何やらも詰め合わされて入っている。Linuxアプリをgtk+ライブラリ詰め合わせにしてWindows版、Windowsアプリをwine詰め合わせにしてLinux版、で両方配布するのが今後は主流になるのかもね。言語ファイルのenglishをjapaneseという名前にコピーして、自分で翻訳していけばUIも日本語が出るようになるので便利だ(？)。私はこういう技術に疎いので妥当な訳語が分からないですが。 rawのデコードにはdcrawを使っているような雰囲気。機能がありすぎてどれを使えばいいのかよくわからないが、「Color Boost」で最高にブーストすると(?)、不自然に色が強調された、それっぽい絵になった。jpegでもColor Boostすれば、それっぽくなるなぁ。 今までいじっていたufraw(こちらはdcrawのフロントエンドか？)でも似たような感じにまではできる。機能はRawTherapeeのほうが多そうです。 それで、RawTherapeeを使って、jpeg1枚とraw1枚でどういう差が出るのか、対決してみようかと思いました。 このシリーズで初めて画像を出してみよう。元の絵はさきほど撮った室内の様子です。自宅の写真はちょっと恥ずかしいですけど。キャプションをそれっぽくするために、無駄にポラロイド風にして傾けてしまった(笑)。RawTherapeeの設定は、以下のようなもの。操作としては普通に読み込んで、ColorBoostでめいっぱい効果が出るようにしてみただけです。
VMWare経由で使っているFedora 8をx86_64版にしてみた。ホストOSが32bitでもゲストOSを64bitにできるようです。えらいです。
VMを生成するときに警告が出てIntel VTが有効になってないとか言われたので、BIOSを眺めて有効にした。今まで有効だと思って「さすがに速いな…」とか呟いていたのだけど、間抜けでした。VMWareはコードのロード時にバイナリを書き換えて実行するときのオーバーヘッドを減らしているので、無効でもそこそこ速いはずです、というのは言い訳です。
確かに、こころなしか速くなってる気がしますね。気のせいかもしれません。
聞いていたとおり、ポインタとlongが64ビットになってますね。あと特に何かせずに普通にoff_tを使っても64ビットになっているので、面倒だったFILE_OFFSET_BITS=64も必要なくなります。あとは変わらず、かな。
# for i in char short int long "long long" quad_t "void *" off_t; do sh sizeof.sh "$i" sys/types.h ; done sizeof(char)=1 sizeof(short)=2 sizeof(int)=4 sizeof(long)=8 sizeof(long long)=8 sizeof(quad_t)=8 sizeof(void *)=8 sizeof(off_t)=8
スクリプトは以下の通り。