理論はわかりませんが、少しずつためていたサンプル画像を観察すると、だいたい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コードや拡張子の区切り文字を再定義できればなぁ…と思う人ってけっこういるんじゃないかな(「.」はもっと前にあるべき文字だよ…)。でも実現できるもんではないので、我々はあるものに合わせていくしかない。

xyzzyを作業環境にしようと思い立って、auto-save-buffers.lというのを見つけてきて(require ‘auto-save-buffers)してみたら、「名前が衝突するため、exportできません」と言われてしまう。見ると、(in-package “editor”)としているので、editorという名前空間に自前のシンボルをexportしようとしてエラーになっているようにも見えた。

調べてみると、xyzzyのlispの名前空間は勝手に作っていいものではなくて、いくつか決まったものがあってネストされた状態になっている(?)みたいな。そこで、(in-package “user”)に変更したら、うまいこと動いてくれたようだ。xyzzyのlispはEmacs-lispよりもcommon-lispに近いらしいですね。ちゃんと分数(実数)型になるらしい。Lisp系の言語は以前にちょっとかじってた程度なんで分からないけど。

実数型はなんで流行らないのかな。誤差を考えなくて済むので便利だと思うんですけどね。

あとはTortoiseHGを入れてmercurialで作業環境を管理するようにして、Linuxとの同期をとったりできるようにした。auto-save-buffersもこういうものを前提にしたものですしね。Windowsで作業するというのがイメージできていなかったが、そう悪くない環境になるような気がする。xyzzyのPythonのモードも悪くない出来だと思います。

HDRIに憧れる少年がいたとする。まあ実際は30代のオッサンですけど。自分のコンパクトデジカメでできるだけHDRIな人になるにはどうしたらいいのか。いくつか方法を考えてみたいなぁと。 HDRIっていうのはいろんな文脈で使われるようだが、私が言っているのはこっちに近いかな。写真っぽくない、絵画みたいな雰囲気。といっても非現実的になるわけじゃなくて、人間の目で見たものにより近い感じになる。写真だと逆光だのなんだので条件が悪いと猛烈に色が飛んで、目にははっきり見えるものがぜんぜん写らないじゃないですか。芸術を追求したいわけじゃなくて、あれがむかつくんですね。だからHDRIに憧れるといっても、「スクリプトを通せばある程度きれいになります」というレベルでいい。 そんなことができるのか。 このカメラにはオートブラケットの機能がついている。明るさ(用語はわからないが)を変えながら3回シャッターが切られて、３つの画像が保存される。これを組み合わせて、明るい部分を暗い画像から、暗い部分を明るい画像から採用すればそれっぽくなるような気がする。これならPythonのPILで簡単なスクリプトを書くか、Gimp(Script-Fu?)で頑張ればどうにかなるレベル。3枚のうち、暗すぎる部分と明るすぎる部分を捨てながら色を採用orブレンドしていけばいい。ただ、何の単位かわからないが、±0.5までしかないのであまりアグレッシブな(?)絵にはならないかもしれないし、三脚ではなく手で持って液晶を見ながらいい加減に撮るし、ずれると悲惨かもしれないね。ちょっとブレやすい程度で済めばいいけど。 ズレの解消法として、3つの画像をautopano-SIFTとhuginで重ねて、enblendの部分を自分で書くとか？ 自分で書かなくても、enblendのオプションでどうにかなるのかもしれない。ありものをつなぎ合わせるだけでスクリプトにもしやすい(huginの部分はnonaを直接呼べばいいだけ?)。調べてみる価値はあるだろう。 また、このカメラはRaw(AdobeのDNG形式＝tiffの拡張)でも保存できる。Rawでオートブラケットは効かないようだが、とにかくjpegでは飛んでしまう色まで記録できるように作られているはずだから、HDRIに近づけるだろう。OpenEXRに変換すれば、exrtoolsあたりでがんばれば、それなりになるかもしれないし、Pythonのモジュールもあるからどうにかなる可能性が高まる。 ざっと考えるとこの2つ。他にもやりようがあるのかもしれないが。 どっちがいいのかな。最初に気になるのは、Rawのデータのビット数。これが8ビットだと、何やってるんだという話になる。さすがにないか。調べる方法が分からないが手探りでやってみると、

カメラのスペックが「焦点距離 5.9mm（35mm換算値28mm）」だから、huginのcrop factorは28/5.9≒4.75のようだ。毎回計算するのがばからしい。

手すりの部分が大きな失敗

雪の降る中、サーバを移行しました。今までバックアップと兼任だったマシンをサーバに降格させたんですが、途中でバックアップがない状態でファイルを間違って消したり(アップした画像などは復活できませんでした)、いろいろ騒ぎながらもメールとWebサーバの移行ができました。今度のサーバはThinkPad X30(2002年発売の10周年記念の限定モデル)です。

メール関係ではbogofilterをやめてSpamAssassinに。ThunderbirdのSPAM除けがSpamAssassinのヘッダを簡単に(チェックボックスにチェックするだけで)認識してくれるのでそうした。ThunderbirdのSPAM除けと2重チェックになってくれて、良いかもしれない。

OS関係ではCentOS5.1にしておいた。仮想マシン上でサーバを動かして、次回のハードウェアリプレースのときにはマイグレーションでやろうとも思ったけど、Intel VTに対応したマシンでもないし、子供に邪魔されたり奥さんにコキ使われながら移行する作業というのも悪くないので、やめておいた。

私も仕事の関係でExcelなどを使うことがあるが、Excelの日付時刻情報の使いにくさは何とかならないものか。まあ、他の表計算のソフトの状況は知らないのだけど。 何を言いたいのかというと、Excelの日付時刻情報は浮動小数点数で表現されている。1.0が1日。これが曲者だ。1秒はどの値かというと、1/(24*60*60)=約0.00001157407407407407であり、10進の浮動小数点数では正確に表現することはできない。人類は1日の中の時間を表現する時、24進数と60進数を併用している。秒以下の部分(ms, us, ns…)は10進数だが、24進数と60進数を10進数(実際は2進数)の小数で表現するのは無理があると思う。 Excelで日付時刻情報を縦もしくは横軸にとってグラフ化するとき、10秒単位で目盛をつけたいと思ったとする。軸のプロパティから目盛単位を変更するのだけど、どうしたらいいのだろう？ 確か「00:00:10」が正解なのだが(ちょっと手元にないので確認できない)、なんだかなぁという気がする。目盛単位を修正するとき、得体の知れない小数に直されているので、ちょっと10秒を3秒にしたいんだ、というときに10を3にするような手軽さはなく、結局分かりにくいので、何だっけ、SECとかMINUTEとかの関数を組み合わせて秒単位の整数を作ってグラフ化するのが楽ということに(私の中では)なった。 コンピュータで日付時刻を表現するとき、少なくとも私の分野ではコンピュータにおける紀元(EPOCH)からの秒数で表現するという手法が一般的だ。EPOCHは1970年1月1日の00:00:00 GMT。秒以下の精度が必要な場合は、Cのstruct timevalのように秒とusの2つの整数を合わせて使うか、Pythonのように浮動小数点数にするか(usの精度を確保するには仮数部が31+20=51ビット以上あればいいので普通の倍精度浮動小数点数で大丈夫)。これがもっとも単純だ。60進数、24進数といえども整数ならば単純で、整数を整数(60や24)で割ったり剰余を取れば簡単に処理できる。 まあよくよく考えると、精度としては1.0が1日を示すか1秒を示すかに優劣はない。でもなんか気持ち悪いし、実際に処理しにくかったことがあったので書いてみました。

買った電話について。Bluetoothは要するに電話からはスピーカー/マイク(HSP/HFPプロファイル)を使えて、PCからはモデム(DUNプロファイル)として使える、というわけで電話からネットワークとして使える、ということはない。以前にPalm…というかCLIEではPCにつないだUSBのBluetoothアダプタを経由して、適当にNATで道路を作ればネットワークにつながったのだけど、そういうことはできないみたいだ。 次、USB接続。まずUSBのケーブルは普通のミニの5ピン。USBなのに5ピン。以前に不思議に思っていたが今となっては一般的と思っているケーブルだ(参照：USB コネクタ ミニ)。これでつなぐと、いきなり電話の画面にダイアログが出て、Mass Storageを使うかどうか聞かれる。Mass Storageにするとパーティションに分けられていないデバイスが見えた。なぜかマウントはできないな。あとLinuxはパーティションに分けられていない、リムーバブル属性のついたデバイスは/proc/partitionに現れないという、確かそういう挙動をする。そんなことはどうでもいい。まあ、この中身については追い追い調べていくとしよう。 で、Mass Storageにしないように選択すると、いきなり素直なモデムとして認識される。非常に素直だ。/dev/ttyACM0が勝手にできて、cuやminicomでつなぐと特に設定することもなくATコマンドを受け入れる。 そしてATコマンドだが、特殊なものを探したくなるのが人情というもの。まずは「AT@K(数値)」。拾えるアンテナと電波の強度(？)をリストアップする。20まで指定できるらしい。自宅で「AT@K20」と打ったらけっこう出てきた。また、以下のものは確認した。

電話を買い替えてみた。これまで6年前に買ったPHSを使っていたのだが(お疲れ様でした)。 通販で買ったので1日不通になっていた。再配達の申し込みのために、長らく押し入れにしまっていた固定電話を引っぱり出してつないだりして。 しかし最近の電話はすごいんですね。Bluetoothがついてたり、miniSDカードさせたり、USBで充電できたりすんの！ 操作がわからん。着信したときに都合が悪くて留守電応答したいときはどうすればいいんだろう…調べとかないと。 いろいろ環境を整備していると、これはやはりデータ通信に関しては定額の契約にしないとヤバいんじゃないかなと。カード型の端末で使っている回線を解約して電話機のほうを定額の契約にしてみよう。家の中だったら、Bluetoothで接続できるようにしたほうが高速かもしれない(でも家の中ならPC使うよな…)。 とりあえず、日刊スポーツが見れない。他はだいたい大丈夫かな…さすがに遅いけど。一般的なJリーグの速報サイトってどこだろう。やっぱJ’s GOAL？ それと、ざっとぐぐってみたけど、この電話機で使えるsshのクライアントはないようだ。phpshellとwebminあたりでも入れとこうかな。