QuadCamera で遊ぶ

今、メインマシンが使えなくて不自由してるけど、まぁ、それはさておく。

iPhone で手軽に連続写真が撮れる QuadCamera というアプリケーションがある。はっきり言ってとても遊べる。紹介は本家 Art & Mobile にまかせるとして、連続写真が撮れるとなるとやってみたくなるのがそれを動画にすること。で、やはりご本家がやってくれました、その名も　QuadAnimator 。QuadCamera で撮影した写真を GIF アニメにしてくれる。

QuadAnimator は iPhone のアプリケーションではなくて、Flash を使った Web アプリケーションの形を取っている。いろんな事情はあるのだろうけど、iPhone で アニメーション GIF をうまく扱えない（本体内に保存できない）のが大きな理由のひとつらしい。しかし、まだ Labo にある段階とはいえ、ちゃんと使いやすい GUI がついていて、手元の PC/Mac にある連続写真から、GIF ファイルを手元の PC/Mac のディスクに（たぶん）直接生成できるのは素晴らしい。(以下一文 2009-01-26追記) とかなんとか書いていたら、Art & Mobile で WIndows 用と Mac OS X 用のスタンドアロン版が公開されてた。素早い。

実は自分も同じようなこと(分割してアニメ化)を考えていて、QuadCamera （に限ったものでもないけど）の写真を分割するだけの超単機能なプログラムを書いてはいた。アニメーション GIF の作り方が分からなくて、大げさにも Flash CS4 を使ってGIF化してたりはしたんだけど、出遅れ感ありあり（そのうち気が向けばゆっくりと外堀を埋めていってスタンドアロンのアプリにできるかなくらいは考えてたかなぁ）。というか全然勝負になってないなぁ、負けすぎ……。

QuadCamera関連に限った話ではなくても、今本当に iPhone のまわりには楽しいことがいっぱいだ

αSONY 700 + Minolta AF50mm F1.7

αSONY 700 + Minolta AF50mm F1.7
Originally uploaded by rok1966

iPhone を使うようになってから、読書量は減るわ、単体のカメラの利用は減るわ、Twitter での発言ばかり増えて Blog の記事を書かなくなるわで、かなり生活が変わったと思う。

で、久々に α700 にミノルタの 50mm F1.7 を付けてみたのだけど、縦位置グリップなしでこのレンズだとなんとも身軽でかえって頼りない気がするほど。でも機動力は普段の 30%増しくらいで撮影枚数もうなぎのぼり……というわけでにもいかないか。

写真は iPhone の ToyCamera で撮影したもの。周辺減光のシミュレーションがスポットライトを当てたような効果になって、なんかものすごくいい感じに写っていた。

あぁ、Twitter よ……

最近は、Twitter を良く使っている。人によって感じ方は違うと思うけど、自分の場合は言いっぱなし(書きっぱなし)でも気にしないし、誰かになにかを書かれて、それを放っておいても(なるべく反応するようにはしているけど)そんなに気にならない。

だから、とくに皆の目に触れることが問題にならないようなことであれば、メモ的につぶやいてみたり、ブログのネタ帳的な使い方もしている。これは iPhone から気楽に使えるのでできることでもある。

いや、そういうつもりなんだけど、後でなにかしようと思ったつぶやきも、もうその場でつぶやいてしまったことでどうでもいい気がして、そのまま放ったらかしになったりもしてしまう。特にブログのネタにしようと思って書いたことに顕著なんだけど、それもまた Twitter のいいところだと思う。

ん、いいところだと思うって、それでいいのか > 自分。

Picasa for Mac のベータリリース

 
Google の画像管理ソフト Picasa の Mac OS X 版がベータ版として公開された。

さっそくインストールして少し試してみたが、その動作の軽いこと。iPhoto よりもサクサク動く感じがする。iPhone からの写真の取り込みもできるし、iPhoto のライブラリをそのまま参照もできて、なかなか良さげ。

画像管理はともかく、 Blogger のユーザとしては、投稿機能が気になる。そこで、この記事も Picasa で書いている。編集中の画面は、見慣れた Bloger のエディタに似ているのだが、ツールのボタン類が少なくて(Bold, Italic, Link, Quote, Spell Check, Rich Text くらいしかない)、少しまえまでの Safari での利用を思いだす。背景になる Picasa の画面をぼやかすのがなんかかっこいいな。

また、投稿エディタ上での写真のリンク先がhttp://localhost:..../みたいになっているのだけど、これは投稿時にはその写真がアップロードされて、ちゃんと書き変わるのだろうか(追記: ちゃんとアップロードされて書き変わってますね。)。

というわけで、とりあえずこの時点で投稿はしてみる。タグ(ラベル)はここでは付けられないのがやはり惜しい気がする。

---

以下 Blogger のエディタで追記。

Picasa で投稿すると、最後に小さな Picasa のマークのが付く()が、これをクリックすると、Blogger のトップページか、Blogger にログインしているば自分の Blogger の Dashboard が表示されるようになっているようだ。あんまり意味なさそうだけど……。

あと、Picasa で複数の写真を選択しておけば、一つの記事にいくつも写真を載せることはできるのだけど、レイアウトが全部同じになってしまうし、ライブラリ上で離れた位置にある写真をいくつも選択するのはやりにくい。Picasa の投稿編集画面から、写真をさらに追加できるようになってるといいなと思った。

まだ、他は全然試してないのだけど、素性はいいと思うので大事に育てて欲しいな。もっと使い込んだら、またなにか書くかも。

Samba と rsync と Mac OS X

Mac OS X でネットワーク上のストレージを使うときに、Samba や rsync/rcp/scp などを混ぜて使うと困ることがある。

最近は MacBook Pro の内蔵ハードディスクが手狭になってきたので、当座の必要性の薄いファイルはなるべく外付けのディスクかネットワークジ上のファイルサーバにコピーをとることにしている。

必要性の高いファイルはなるべくローカルに置いておきたいし、ディレクトリツリーの構造はなるべくそのままでコピーをとりたいので rsync(1) を使ってアップデートコピーをしていた。最近の Mac OS X の rsync は、HFS(+) にちゃんと対応していて、リソースなどもよきに計らってコピーをしてくれて(-Eオプションを使う)、コピー先が別マシンのときは相手も Mac OS X でないと無視されるなど)非常に便利になっている。ただ、ここで若干の問題が生じることがあるのに最近気付いた。

Mac OS X の HFS(+) 上でのファイル名のエンコーディングと、Samba 上のファイル名のエンコーディングとは異なることが多い。Mac OS X 以外の OS を使ったマシン上のファイルシステムを Samba を使って Mac OS X から使っている人はだいたい知ってると思うけど、最近の Samba を使う限りはこれが問題になるいことは少ない。これは、アジアのペンギン: MacOS X とのファイル共有 に書かれているように、実際のファイル名のエンコーディングが異なっていても、ネットワーク上でやりとりされるファイル名のエンコーディングは問題ないように(ほぼ)統一されているからだそうだ。

SMB/CIFS でのファイル名のやりとりは、Linux や Windows では、非正規化 Precomposed UTF-16LE でやりとりされ、MacOS X では 正規化 Precomposed UTF-16LE でやりとりされています。

正規化処理を行っているか否かという違いはありますが、Linux、Windows、MacOS X のいずれも Precomposed UTF-16LE でファイル名のやりとりを行っていますので日本語ファイル名もほぼ問題なくファイル共有が出来ます。

ただし、ここに rsync や rcp など smb を介さないやりとりがあると問題が起こることがある。

つまりはこういうこと。rsync や rcp や scp などは、ファイル名に関してはなんの変換も行なわない。したがって、Mac OS X で UTF-8-MAC (前記リンク先では Unicode Normalization Form D (NFD) あるいは 正規化 Decomposed UTF-8 と書かれてますね)で表現されたファイル名のままコピー先にファイルが作成されてしまう。このコピーされたファイルを Mac OS X マシンから rsync や rcp を使ってアクセスする限りにおいては問題は生じない。

ところが、このファイルを samba を使ってアクセスすると、ときどき問題が起こる。

Linxu 上の Samba は、ローカルなファイル名が(やはり前記リンク先の表現を借りるなら)非正規化 Preomposed UTF-8 であることを前提にネットワーク向けには(smb経由では) Precomposed UTF-16LE に変換して、Mac OS X 上の samba クライアントと通信する。 ところが、rsync や rcp や scp でコピーされたファイルの名前はもともとの Mac OS X の HFS(+) 上にあったときと同じ UTF-8-MAC なので、これらのエンコーディング間で違いがある場合には Precomposed UTF-16LE へ正しく変換が行われない。UTF-8-MAC と Precompoesed UTF-8 の違いは主に濁点や半濁点などに見られるため(このへん理解があいまなのですが……)、これらが含まれる場合に困ったことになる。

たとえば、rsync でコピーしたファイルが、Samb を使ってファインダーから「見える」のに、実際にアクセスしてみると「存在『しない』」とされてしったり、場合によってはその存在さえ「見えなく」なってしまう。

一つ、実例を挙げてみる。今、Mac OS X 上で「ボ」というファイルを作ったとすると、Finder から見えるそのファイルは、「e3 83 9b e3 82 99」となっている(Mac OS X のhexdumpで確認。エンディアンの問題があるけど、ややこしいので以後 Linux 側でもこちらの表記に合わせることにする)。これを Finder で Linux (Ubuntu 8.04.1) 上の samba のボリュームにコピーすると、コピー先では「e3 83 9c」となっていて、Mac OS X で「ホ」+「゛」に decompose されていたものが、samba によって適切に変換されていることが分かる。もちろん、このファイルは Finder からは(samba を経由するので) decomposed されたように見えているのでファイル操作にはなんの問題も生じないし、Linux からも precomposed UTF-8 のファイル名として普通に扱える。

一方、samba を介さずに rsync を使って直接コピーを行なったとすると、Linux のファイルシステム上でもファイル名は変換されずに decompose された「e3 83 9b e3 82 99」となる。そして、このファイルのあるディレクトリを samba 経由でマウントすると、Mac OS X 側からこのファイルの名前は同じく「e3 83 9b e3 82 99」であるように見える。ところが このファイルにアクセスしようとすると、(sambaは)Linux 上にあるファイル名が前述のように「e3 83 9c」であることを期待するのに、そんなファイルは実際には存在しないという問題が起こる。この問題の現われ方はどうにも素直でなくて、実はこのファイルはファインダで「見る」ことはできるが、どうにも正しい(期待される)ファイルのようには見えなくなったりする(下図: 手前がローカルなボリュームに最初に作ったファイル。奥が samba でマウントしたボリューム上のファイル)。標準テキスト(本当は空のファイルなんだけど)のはずのものがコピーになるとエイリアスのように見えているし、メタデータはめちゃくちゃだし、しかも、このファイルはクリックしたとたんに Finder から見えなくなってしまう。


decomposed UTF-8 と precomposed UTF-8 でファイル名に違いがない場合にはこの問題は起こらない。だから、デジカメの写真を撮ったままのファイル名でバックアップするときには問題になることはないし、普段からファイル名に日本語を使わないような場合にも問題になることは少ない。

また、samba のサーバー側の文字設定(unix charset)を UTF-8-MAC に設定することがきれば(標準でこれができる Liinux は少なそうだ)、Mac OS X からそのボリュームを使う場合に限ってはこの問題は解決する。しかし、その場合でも Windows から アクセスしたり、Linux 上で直接ファイル操作を行う場合に問題が起こりそうなのは同じことだ。

結論としては 、samba でのやりとりとその他の方法でのファイルのやりとりは、(それぞれのファイルシステム上のファイル名のエンコーディングが異なる)クロスプラットフォームでは

混ぜるな危険

ということか。どちらからも全く問題のない解法は今のところはないし、rsync や rcp、scp などのようなプログラムの全てにファイル名の変換機能を付けるというのも非現実的(というか自分でやりたくない/ 自分ではできない )だし。

Animoto を使ってみた

TechCrunch でも紹介されていた ANIMOTO を試してみた。

これは、写真を何枚かまとめてスライドショーというか動画を作ってくれる Web アプリで、自分の場合は iPhone 用に用意された専用アプリを使ってみた。

What I ate

なかなか楽しい。音楽は向こう(ANIMOTO)が用意したものをそのまま使っているけど、それなりにバリエーションがある。

無料版で使っていると、かなり短い動画しか作れないけど、3ドル払えば長さ無制限の動画を一つ作れるようになって、30ドルならいくつでも作れるようになる。ただし、動画の長さは音楽のファイル容量(最大10MB)で決まってしまうので、何十分もあるようなものは作れないらしいけど。

今のところちょっと残念なのが、Web アプリ版で作ったアカウントを iPhone アプリと関連付ける方法が分からないので、iPhone で作った動画を web で編集したり、なにしたりというのができないこと。なんらかの方法があるのではないかと思うんだけど、iPhone 側のアプリにアカウントの設定とかが見当たらないし、Web アプリ側でもよく分からないし。

なんちゃって TimeCapsule には(場合によっては) afp が必要らしい

α700 - SONY AF100mm F2.8 Macro - Preview.app

6 x 3: なんちゃって TimeCapsule を作ってみたで、TimeMachine で使うバックアップ先に samba を使って問題ないよ、ということを書いた。しかし、場合によっては afp が必要になることもあるらしい。

• macosxhints.com - 10.5: Restore from unsupported Time Machine backups

Mac OS X Hints の上記記事によれば、Leopard のインストール用 DVD を使ってフルレストアする場合に smb は使えないとのこと。どうやら、DVD で起動するシステムから smb 関連の機能が省かれているのがその理由。afp ならもともと含まれているのでフルレストアもできるというわけ。

だから、フルレストアをしない場合は、smb でも大丈夫。コメントには、「クリーンインストールしてから移行アシスタントで TimeMachine から必要なものをごっそり持ってくる(超訳)」という手段も書かれている。

また、コメントに nfs なら大丈夫かもと書かれているのもあって、これは機会があれば試してみたいと思う(Mac OS X で nfs マウントするのは実は簡単。unmount までの時間の設定が 3600 秒になっているので、Mac を常に持ち運んで使っているような場合は短くしておくほうがいいかも)。

なんちゃって TimeCapsule を作ってみた。

前からやろう、やろうと思いっていた「なんちゃって」Time Capsule を作ってみた。

参考にしたのは主に次の二つのサイト。

• D COLLECTIONS - エセ Time Capsule Project-FrontPage-Wiki
  
• » TimeCapsuleじゃないNASを使って、TimeMachineを使ってみる | OpenMediaLaboratory

どちらもリモートのボリューム上のスパースバンドル・ディスクイメージをバックアップ先に使うのは同じで、それを TimeMachine が使えるようにする手順が違うだけ。

また、後者では afp が必須で smb だと駄目なように書いてあるけど、うちでは samba を使って今のところ問題なく動いているようだ。もしかしたら、samba の設定によって変わってくるのかもしれない。

というわけで、簡単にまとめてみる。

1. バックアップのディスクを用意する

バックアップを置くボリュームは、おうちサーバの openSUSE 10.3 上の samba。新しく買ってきたディスクをつないで、ファイルシステムを作って適当なところにマウントしておく(ちなみに今回は reiserfs を利用)。さらに該当ディレクトリを samba の設定で、Mac OS X からマウントできるようにしておく。

2. 実際のバックアップ先となるイメージを作る

上のリンク先にあるような手順で(どちらでも同じ)、スパースバンドル・ディスクイメージを作成する。ファイル名は、「コンピュータ名_MACアドレス.sparsebundle」のようにしておくこと。このとき、MACアドレスの Octet 区切の 「：」や「-」は入れない。例えば、コンピュータ名が「macbook.local」で MAC アドレスが 「00:23:32:ab:cd:ef」の場合は、「macbook.local_002332abcdef.sparsebundle」となる。リンク先にあるようにサイズの変更を忘れないように。

3. Mac 側でリモートボリュームへの TimeMachine を有効にする

自分は iTimeMachine を使う方法で行なったが、Terminal で「defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1」する方法でもたぶん大丈夫だと思う(実際 iTimeMachine での設定後に TMShowUnsupportedNetworkVolumes が "1" に設定されているのを確認したが、その他になにをやっているのかは未確認)。それが済んだら、システム環境設定の TimeMachine パネルの「ディスクを変更」で、バックアップ先を設定しておく。

以上でおしまい。本物の TimeCapsule でもそうらしいけど最初のバックアップにはそれなりの時間がかかるので、寝る前に仕込んでおくのがいいと思う。また、次からは該当ボリュームをマウントしておかなくても必要に応じて勝手にマウントしてくれるので(使ったことがないけど)本物の TimeCapsule と使い勝手は変わらない(と思う)。

参考のために、TimeMachine 時のログを抜粋しておく(MACアドレス該当部分は「XXXXXXXXXXXX」で置き換えてある)。
オフトピだけど、下の blockquote 要素中の pre 要素に style="overflow: auto" してあるのに、Safari だとスクロールバーが出ないな……

Dec 19 01:13:07 mbp15 /System/Library/CoreServices/backupd[11787]: Starting standard backup
Dec 19 01:13:07 mbp15 /System/Library/CoreServices/backupd[11787]: Network volume mounted at: /Volumes/timecapsule
Dec 19 01:13:09 mbp15 /System/Library/CoreServices/backupd[11787]: Disk image /Volumes/timecapsule/mbp15.local_XXXXXXXXXXXX.sparsebundle mounted at: /Volumes/TimeCapsuleBackup
Dec 19 01:13:09 mbp15 /System/Library/CoreServices/backupd[11787]: Backing up to: /Volumes/TimeCapsuleBackup/Backups.backupdb
Dec 19 01:13:18 mbp15 /System/Library/CoreServices/backupd[11787]: No pre-backup thinning needed: 2.01 GB requested (including padding), 116.41 GB available
Dec 19 01:13:18 mbp15 /System/Library/CoreServices/backupd[11787]: Waiting for index to be ready (906 > 0)
Dec 19 01:14:33 mbp15 /System/Library/CoreServices/backupd[11787]: Copied 2639 files (81.1 MB) from volume mbp15.
Dec 19 01:14:34 mbp15 /System/Library/CoreServices/backupd[11787]: No pre-backup thinning needed: 1.91 GB requested (including padding), 116.41 GB available
Dec 19 01:14:52 mbp15 /System/Library/CoreServices/backupd[11787]: Copied 1654 files (160 bytes) from volume mbp15.
Dec 19 01:15:00 mbp15 /System/Library/CoreServices/backupd[11787]: Starting post-backup thinning
Dec 19 01:16:40 mbp15 /System/Library/CoreServices/backupd[11787]: Deleted backup /Volumes/TimeCapsuleBackup/Backups.backupdb/mbp15/2008-12-18-005955: 116.41 GB now available
Dec 19 01:16:40 mbp15 /System/Library/CoreServices/backupd[11787]: Post-back up thinning complete: 1 expired backups removed
Dec 19 01:16:40 mbp15 /System/Library/CoreServices/backupd[11787]: Backup completed successfully.
Dec 19 01:16:43 mbp15 /System/Library/CoreServices/backupd[11787]: Ejected Time Machine disk image.
Dec 19 01:16:59 mbp15 /System/Library/CoreServices/backupd[11787]: Ejected Time Machine network volume.

TimeMachine(backupd)が勝手にリモートボリュームとそのボリューム上にあるイメージファイルをマウントしているのが分かる。

これで数日使ってみたが特に問題なく使えている。

それはともかく、これはなかなか便利。もっと早く設定しとけばよかった。

PC 復旧した

• 6 x 3: PC 壊れた。

しばらく前に、うちの Windows PC が壊れたらしい話を書いた。そのときは電源が原因らしいなぁと思っていたので、いろいろ調べて Just MyShop から購入したのがこの電源。

壊れてから、電源を購入してそれが届くまで約2週間。ようやく復旧できると思って、電源をさっそく交換してみた。

しかし、動かなかった、全く交換前と同じ症状。メモリチェックが走って、スクリーンに「Memory T」が出たところで止まってしまう。

ちょっとショックを受けながらも、原点に帰って Google 先生におうかがいを立ててみた。今度はマザーボードのメーカー「GIGABYTE」と 「Memory T」を検索キーワードにして。すると カカクコム の掲示板で同じ症状で困っていた人の話が見つかったのだけど、解決方法がなんと USB の外付け機器を外すというもの。まさかまさかと思いつつも、外付けディスクを外してみると……BINGO! 無事起動。

なんで USB なんだろうとか思いながら、再度繋ぎなおしてみると今度はなんの問題もなく起動する？？？？

なんだかよく分からないけど、普及したのはまぁめでたいことなので取り敢えずはよしとしておく。その後、SPORE も若干進んでとうとう宇宙にも進出したことだし。

iPhone アプリのインストール数

• Life is beautiful: iPhoneユーザーは年間どのくらいアプリの購入に費やすのか？

PhotoShare の Big Canvas の中島さんのブログ "Life is Beautifule" で、「iPhone ユーザは一年間どのくらいアプリの購入に費すのか?」というトピックがあがっていたので、有料のものだけでも数えてみた。

• ToyCamera (230円)
  
• CameraBag (350円だけど購入時はもっと高かった気がする)
  
• Appigo Todo (1200円だけど、RTM純正のアプリが出てほとんど使わなくなった)
  
• PhotoArtist (230円)
  
• OilCanvas (無料。5万ダウンロード以降でも無料なの?)
  
• アスファルト4 (700円だけど、購入時は 900円くらいしてたんじゃないかなぁ)
  
• ネオサメガメ (450円)
  
• 4[働きマン] (115円)
  
• 薬局のポチ山さん (600円)

思ったよりも少ないけど、Appigo Todo、アスファルト4、ネオサメガメ あたりはけっこうなお値段だったので、総額で4000円くらいかな。

無料のものでも、もっとよく使うものや便利なもの、楽しいものもたくさんある。それについてもいずれまとめてみよう。