フリーな動画フォーマット、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は以下のようにエンコード。

## ffmpeg -i $input -f mp4 -vcodec libx264 -qscale 20 -acodec libfaac -ar 8000 -ab 32 $outp

ut

H.264の動画はこの設定では音声がかなり不自然になってしまうような…。実際に使うためにはオプションを調整することになるだろうけど、サイズの比較には使えるんじゃないかと思う。

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で

## yum install cinepaint

でインストール、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

スクリプトは以下の通り。

理論はわかりませんが、少しずつためていたサンプル画像を観察すると、だいたいEV補正値が0.5違う場合、JPEGで見えるRGBの値(0～255)で20程度違いがあります。20という値が正確なのかどうかはわかりませんが、色の平均をとってみると、そんな感じで出る画像が多い。EV補正±0.3の場合は10程度の差に見える。 そのため、オートブラケットでEV補正±0.5で3枚撮った場合は、RGBの範囲が0～255だったのが-20～275くらいに広がるという感じにまではできそうです。 明るいほうと暗いほうに、だいたい7～8%ずつ増えて、256階調→約300階調くらいになる程度ですね。ちょっと物足りない感じもしますが、あくまでも「お手軽」だからこのくらいでいっか、という気もするところ。 0～99を暗め明るめの画像から、100～199(元画像の値で80～179)は中くらいの画像から、200～300(160～255)を明るめ暗めの画像から採用すれば、そこそこ色の範囲が広くなるのではないかと思います。 (追記) 2008/02/20(水) 19:44 「明るめ」と「暗め」が逆でしたね。

今回はメタデータについて。Raw(DNG)にもjpegにもEXIF情報が入っていて、撮影したときの情報を得ることができる。実際に出ている色のみで処理するのもいいけど、こういうメタデータをもとに明るさ情報を取り出してどうのこうのする、というのもアリだと思います。 EXIF情報を眺めると、ブラケット撮影で変更しながら撮影された明るさの情報が入っているのは、ExposureBiasValueという部分です。EV値(意味はわかりませんが高いほど明るい画像になるようです)の差分が入っている。これは…分数型かなぁ。 もともとのEV値は直接は入っていなくて、計算しなくてはならないようだ。BrightnessValue+log2(ISOSpeedRatings/3.125)+ExposureBiasValueの値がEV値、という情報をWebのどこか(URL忘れました)で仕入れて計算。 私のカメラでは、DNGでもJPEGでもこのスクリプトで食えています。

asciiの並びでは、「-」は数字やアルファベット、「/」や「.」よりも前、「_」は数字やアルファベット大文字より後ろでアルファベット小文字より前、という特性がある。

!"#$%&’()*+,-./0(略)9:;<=>?@A(略)Z[]^_`a(略)z{|}~

そのため、あるものに追加して属性を書く目的では、「-」よりも「_」が適している。何を言おうとしているのかというと、以下の2つのファイルがあるとすると、

• 01234.jpg
• 01234-1.jpg

名前でソートしたときの並び順が

• 01234-1.jpg
• 01234.jpg

である。「.(ドット)」よりも「-(ハイフン)」が前にあるためだ(拡張子を特別扱いするような面倒なソート方式を使っていれば別)。そのため、「_0」しかないときでも省略することができない。これが「-」ではなく「_」なら、

• 01234.jpg
• 01234_1.jpg

という順番になり、「_0」を省略しても構わないことになる。

今からasciiコードや拡張子の区切り文字を再定義できればなぁ…と思う人ってけっこういるんじゃないかな(「.」はもっと前にあるべき文字だよ…)。でも実現できるもんではないので、我々はあるものに合わせていくしかない。