Ruby用画像処理ライブラリをちょっと改良

Rubyを使ってちょっとした画像処理のアルゴリズムを試したいと思い、(a)PNG形式の画像を読み込み、(b)画素単位で読み書きでき、(c)線と文字が描画できて、(d)結果をPNG形式で保存できる、といった程度の手軽なライブラリを探したところ、NISHIMOTO Keisuke氏のRuby/PureImageというライブラリ見付けました。

さっそく使ってみたところ、私の用途には処理速度的にも充分で、便利に使っていたのですが、ライブラリ付属のサンプル画像を使うと上手くいくものの、自分で用意したPNGファイルでは画像を正しく読めないことに気が付きました。

何でだろうなーと思ってライブラリのコードを見たところ、このライブラリ(バージョン0.1.2)では、画像ファイルの読み込み時にフィルタ処理を端折っているようです。

PNG形式では、圧縮サイズを改善するために、スキャンライン単位で5種類のフィルタ処理(「フィルタ処理なし」を含む)を指定できるのですが、Ruby/PureImageライブラリでは、このフィルタ処理を「フィルタ処理なし」で決め打ちにしており、その結果、フィルタ処理している画像を読み込むと、色が化けます。

Ruby/PureImageライブラリは2006年で更新が止まっているライブラリのようですし、高性能な画像処理ライブラリはたくさんあるのでしょうけれど、シンプルなRuby/PureImageも捨てがたかったので、ちょっと改良してみました。

(速度や機能が必要ならC++ Builderなどを使うので、高性能ライブラリは私がRubyに求めているものとは方向が異なり、使い方を憶える気になれませんでした。Ruby/PureImageライブラリの改良も、探せばどこかで誰かがすでにやっているような気もしますが、たいした手間ではないので…。)

改良点は、pureimage.rbファイルのPNGIOクラスのloadメソッド内で、PNGファイルのイメージ・データをZlibで展開した後、idatから画像を作る「# Create image.」(873行目)の前に、以下のコードを追加します(展開したイメージ・データにスキャンライン単位でフィルタ処理をするコードです)。

これで、自分で用意したPNGファイルも正しく読めるようになりました。よかったよかった。

      # Filtering
      bpp = (color_type == 2) ? 3 : 4
      width_bpp = width * bpp
      dat_index = 0
      for y in 0...height
        filter = idat[dat_index].to_i
        dat_index += 1
        if filter == 0    then  # None
          for x in 0...width_bpp
            idat[dat_index] = idat[dat_index].to_i
            dat_index += 1
          end
        elsif filter == 1 then  # Sub
          for x in 0...width_bpp
            idat[dat_index] = idat[dat_index].to_i + ((x < bpp) ? 0 : idat[dat_index - bpp])
            dat_index += 1
          end
        elsif filter == 2 then  # Up
          for x in 0...width_bpp
            idat[dat_index] = idat[dat_index].to_i + ((y < 1) ? 0 : idat[dat_index - width_bpp - 1])
            dat_index += 1
          end
        elsif filter == 3 then  # Average
          for x in 0...width_bpp
            average  = ((x < bpp) ? 0 : idat[dat_index - bpp])
            average += ((y < 1) ? 0 : idat[dat_index - width_bpp - 1])
            average /= 2
            idat[dat_index] = (idat[dat_index].to_i + average) & 0xff
            dat_index += 1
          end
        elsif filter == 4 then  # Paeth
          for x in 0...width_bpp
            a = (x < bpp) ? 0 : idat[dat_index - bpp]
            b = (y < 1) ? 0 : idat[dat_index - width_bpp - 1]
            c = ((x < bpp) || (y < 1)) ? 0 : idat[dat_index - width_bpp - 1 - bpp]
            pp = a + b - c
            pa = (pp - a).abs
            pb = (pp - b).abs
            pc = (pp - c).abs
            if (pa <= pb) && (pa <= pc) then
              pp = a
            elsif (pb <= pc) then
              pp = b
            else
              pp = c
            end
            idat[dat_index] = (idat[dat_index].to_i + pp) & 0xff
            dat_index += 1
          end
        else # 未知のフィルタ
          raise "Not support scanline filter method: " + filter.to_s
        end
      end

『基礎からのAndroidプログラミング』発売

Androidプログラミングの入門書『基礎からのAndroidプログラミング』が発売されました。
第2章以降を、私が執筆しています。

「HTC Desire」(Android 2.2)と、「Andorid SDK」「Eclipse」「JDK」を使って、主に画面全体をリアルタイムで書き換えるような“ゲーム的”アプリを作る基本的な手順を解説し、その応用例として、「テルミン風楽器」アプリの作成例を紹介しています。

Androidアプリを作る場合、「ボタン」や「テキストビュー」などのAndroid標準のGUIコントロールを配置するのが一般的かもしれませんが、本書ではそのようなアプリの作り方は、4章で基本的な手順を解説するに留めて、5章以降では、「View」クラスと「SurfaceView」クラスの派生クラスを作って、独自に画面を描画するタイプのアプリを作っています。

7章では、その応用例として、「AudioTrack」クラスを使ってリアルタイム音声合成を行なう、「テルミン風楽器」アプリの作成例を紹介しています。スクリーン上で指を動かすと、指の位置に応じた音程・音量で音が再生され、指の軌跡に合わせてアニメーションが表示されます。

作成しているアプリの動作は、エミュレータと、ソフトバンクモバイルのスマートフォン「HTC Desire」(Android 2.2)で確認しています。「HTC Desire」でアプリをデバッグするための手順も解説しています。

ちなみに、7章で作っている「テルミン風楽器」アプリは、こんな感じです。

本書サンプルは、サポートページからダウンロードできます。

『はじめてのiPadプログラミング』発売

iPadプログラミングの入門書『はじめてのiPadプログラミング』が発売されました。
第2部 実践編を私が執筆しています。

「アナログ シンセサイザー」をシミュレートするアプリを作りながら、iPadアプリの制作過程を解説しています。プロジェクトの作り方から、実機を使ってデバッグする手順、iTunes Connectに提出するバイナリの作り方まで一通り解説しており、これからiPadアプリの開発をはじめようと思っている方が、iPadアプリ制作のガイドブック的に読むことを想定した内容になっています。なお、対応しているバージョンはiOS 3.2です。

本書は、7月に発売された『はじめてのiPhoneプログラミング』のiPad版になります。
内容的にもほぼ同じですが、本書ではiPad独特の『Split view-based Application』テンプレートから作成をはじめており、「Split View」と「Popover」に関する解説を追加しています。
また、オーディオバッファのバッファサイズを変更する手続きの記述を増やしています。

ちなみに、本書で作っているサンプルは、こんな感じです。

本書サンプルは、サポートページからダウンロードできます。

『DirectX11 3Dプログラミング』発売

Direct3D 11のプログラミング入門書『DirectX11 3Dプログラミング』が発売されました。
第2部　実践編を私が執筆しています。

内容的には、2007年に発売された『DirectX10 3Dプログラミング』のDirect3D 11対応版になります。『DirectX10 3Dプログラミング』との主な違いは、

• 「Direct3D 11」を使用。
• 演算ライブラリとして、「XNA Math」と「XNA Collisionライブラリ」を使用。
• 「コンピュート・シェーダ」（演算シェーダ）の解説を追加。
• 「エフェクト」機能を使わないように解説を変更。
• 開発環境として、「Visual C++ 2010 Express」＋「DirectX SDK(June2010)」を使用。
• 「Direct3D 11」で削除された機能の解説を削除。

といった感じです。

「Direct3D 10」の「D3DX」(D3DX 10)には算術演算関連の機能が用意されていましたが、「Direct3D 11」の「D3DX」(D3DX 11)では、それらの機能が削除されています。演算機能だけ「D3DX 10」の機能を使うこともできますが、本書では、「XNA Math」と、SDKサンプルとして提供されている「XNA Collisionライブラリ」を使うようにしました。

「Direct3D 11」にもエフェクト関連の機能は存在しますが、いろいろ考えてエフェクト関連は使わない方向に変更しました。SDKサンプルでも使っていないみたいだし……。

「D3DX 10」にあったスプライト表示機能やフォント表示機能が「D3DX 11」では削除されているので、本書の解説からも削除しました。

使用している開発環境は、「Visual C++ 2010 Express」＋「DirectX SDK(June2010)」です。「Visual C++ 2010」では、SDKをインストールしてもヘッダ・ファイルやライブラリのパスが自動設定されず多少面倒になりましたが、それらの設定方法も解説しています。

『はじめてのiPhoneプログラミング』発売

『はじめてのiPhoneプログラミング』が発売されました。
iPhoneプログラミングの入門書です。第2部 実践編を私が執筆しています。

「アナログ シンセサイザー」をシミュレートするアプリを作りながら、iPhoneアプリの制作過程を解説しています。プロジェクトの作り方から、実機を使ってデバッグする手順、iTunes Connectに提出するバイナリの作り方まで一通り解説しており、これからiPhoneアプリの開発をはじめようと思っている方が、iPhoneアプリ制作のガイドブック的に読むことを想定した内容になっています。対応しているバージョンはiPhone OS 3.1.3ですが、iOS 4でも動作に問題はありません。

ちなみに、本書で作っているサンプルは、こんな感じです。

本書サンプルは、サポートページからダウンロードできます。

1) SynthVCFのresonanceを0にすると正常に動作しなくなるバグを修正しました。

2) SynthEGのsustainを0にすると正常に動作しないバグを修正しました。

【お詫び】　7月15日ころまで公開されていたサンプルは、圧縮ファイルの作成ミスでビルドできない状態になっていました。ビルド後のバイナリだけでなく、間違えて、AnalogSynthesizer_Prefix.pchファイルも削除していました。修正したサンプル ファイルはすでに編集部に送っているので、近日中に差し替えられると思います。ダウンロードされた方には、ご迷惑をおかけしました。
なお、削除されているAnalogSynthesizer_Prefix.pchファイルは、以下のようなファイルです。自動的に生成されるファイルなので、各自で用意して頂いても問題ないと思います。

//
// Prefix header for all source files of the 'AnalogSynthesizer' target in the 'AnalogSynthesizer' project
//

#ifdef __OBJC__
    #import <Foundation/Foundation.h>
    #import <UIKit/UIKit.h>
#endif

※7月16日以降は、正しいファイルが公開されているようです。

なお、本書サンプルについて、219ページに『「iOS 4」でも動く可能性は高いですが』と書かれていますが、現状で正常に動いていません(音が出ません)。できるだけ早く対応したいと思います。

サンプルを修正して、「iPhone SDK 4」を使ってビルドし、「iOS4」上で動作することを確認しました。サポートページでは、対応ずみのサンプルが公開されると思います。本文の内容と関係ない部分でミスっていました(むしろ、iPhone 3.1.3上で動作したのが偶然…)。

ちょっと言い訳をさせてもらうと、文章の続きにあるように、執筆時点では「iOS 4」についてはシミュレータを含めて、まったくテストしていませんでした。『「iOS 4」でも動く可能性は高いですが』の部分は編集部で追加した文章だったりします。もちろん、校正の段階で私も見ているので、私も無関係ではありません。

iTunesを9.1にアップしたら

「SyncServerは動作を停止しました」などというエラーが発生するようになってしまった…。

AppleのアプリをすべてアンインストールしてiTunesを再インストールしたけれども、改善せず。

そういえば、前にも似たようなことがあったような気がするな。

今のところ、iTunesでの音楽再生は可能みたいだし、iPod touchやiPhoneとの同期もできているっぽいので、とりあえず、最悪の状態ではないけれども、iPod touchを2台とiPhone 3GSをつないでいると、ことあるごとに3連続で上記エラーが発生するのは鬱陶しすぎる。

いったいどうなってんの？

(追記)
iTunesを9.1.1にバージョンアップしたら解決した模様。

RAIDのドライブ

各種データの保存には、09年1月から裸族の二世帯住宅を使っているのですが、今回、はじめてドライブにエラーが発生しました。めでたい。

いや、もちろん、めでたくはありませんが、何となく、嬉しい気分もあるような…。せっかくRAIDを組んでも、一向にドライブが壊れなかったら、何か損したような気分になるというか。

もちろん、壊れないに越したことはないわけで、よく考えると、同時に購入したWD10EADSが1年で壊れたことをもう少し深刻に考えるべきなのでしょうね。

RAIDなので、ドライブを買い足せばいいのですが、今回は同容量の外付けHDDを1台購入して、そちらにデータを移すことにしました。
RAIDの方は、当分は外付けHDDのバックアップとして方肺の状態で使い、そのうち容量の大きいHDDに2台とも入れ替えるつもりです。

でも、裸族の二世帯住宅って、2TBのHDDまでしか対応していないのね。

クレジットカードから、代金が二重に引き落とされることが実際にある、という経験をした

ビックリした、というか、珍しい体験をしました。
こんなことって、ほんとにあるんだなって感じです。

先日、通販である商品を代引きで購入し、商品受け取り時に、宅配業者にクレジットカードで代金を支払いました。
で、今日、クレジットカードの利用明細を見ていたところ、どう考えても、そのときの商品の支払いとしか考えられない支払い履歴が2重に記載されている(利用日、利用店名、利用金額がまったく同一)のを見付けたわけです。何せ金額が私の普段の利用とは1桁～2桁違いますし、利用店名も宅配業者のサービス名ですから、間違いありません。

すぐに商品を購入した店に連絡して事情を聞いたのですが、販売店が宅配業者に問い合わせたところ、宅配業者のカード管理部門には履歴が1回しかなく、クレジットカード会社の処理の問題になる、との解答を得た、というような話でした。

当然、すぐにクレジットカード会社に連絡してみたのですが、カード会社曰く、宅配業者から2回の請求が来ている、これまでそんなトラブルはない、請求が来ているからカード会社側で取り消すことは出来ない、販売店側から取り消してもらえ、とのこと。

しかし、宅配業者の履歴が1回しかないのが事実であれば、どうやって取り消すのでしょう。なんだか大変なことになった、と思いながら、販売店に、カード会社がこんなことを言っているので、1件を取り消してくれるよう頼みました。

で、販売店の方で再度、宅配業者に調べてもらった結果、宅配業者とクレジットカード会社から私に、重複した1件を取り消す、との連絡があったのでした。

結果的には大事に至らなくて良かった、といった感じですが、腑に落ちないのは、こんなことが何故起こったのか、という両者の説明です。

宅配業者曰く、クレジットカード会社での処理に問題があったので、取り消す手続きをしてもらっている。
クレジットカード会社曰く、宅配業者からのデータに重複が見付かったので、取り消した。

電話で話したので、正確には覚えていませんが、要するに、両者とも自分の責任ではないと言っているようでした。私にはそう聞こえました。
原因はデータの重複らしいのですが、この重複がどの段階で発生したのか、双方とも明言していないわけです。宅配業者の説明だと、クレジットカード会社側で発生したようにも聞こえるし、クレジットカード会社の説明だと、宅配業者のデータに最初から重複があったようにも聞こえます。

クレジットカードというサービスは、もしかすると、私が想像しているより、ずっと脆弱なシステムで運用されているのかもしれません。

正直に言って、今までクレジットカードの利用明細なんて1件1件確認していませんでした。今回気がついたのは、金額が大きく、しかも2つ並んでいて、利用明細で目立っていたからです。これが、普段の利用と同じくらいの金額で、かつ、並んでいなかったら、気がつかなかった可能性は大きいでしょう。
今さらカードを使わない生活など困難ですが、利用明細は多少時間をかけても確認した方がいい、という良い経験をしました。
あー、ビックリした。

遅かった…

PASMOの定期券が不要になったので、定期券売り場に行ってきました。でもって、1ヶ月定期の場合、払い戻しが出来るのは購入後7日以内で、今回の場合、23日までだったことが判明。がっくし。早めに払い戻しておけばよかった。もっとも、定期券の払い戻しのことなんて普段考えていないからなぁ。

窓口の人の話だと、今すぐ定期券を消すことも出来るけれども、それだと払い戻しもなく、定期も使えなくなってもったいないということなので、定期券の期限が切れた後で改めて消すことに。

やはり一極集中は危険だ

iPhone/iPod touch向けにアプリを提供するには、今のところ真っ当な手段としては、Appleが管理するAppStoreを使うしかありません。そして、AppStoreでiPhone向けアプリを提供するには、Appleの定めた規約に従う必要があるわけですが、数日前くらいから、この規約のApple社内での解釈が一方的に変更になったらしく、写真集アプリなど多数のアプリが一方的に削除されて問題になっているみたいですね。

しかもその理由が、TechCrunch Japanなどの記事が正しいとすると、どんなものでも「肌が露出している画像は一切禁止」だとか。

(TechCrunch Japan)Apple、 App Storeへの規制を強める―水着禁止、スケートタイツ禁止、ほのめかしも禁止
http://jp.techcrunch.com/archives/techcrunch-com20100220app-store-rules-sexy/

一言で言うと、バカバカしいし、何のためにアプリにレーティングがあるのか、と思いますが、そもそもAppStoreはAppleによって完全にコントロールされている、“Appleが売りたいものを売る場所”である以上、前からこういう事態が起こりうる危険を孕んでいたわけです。我々デベロッパーは、Appleの意を介し、Appleの為のアプリを開発し提供する存在とも言えます。

もうすぐ登場するiPadのiBooksも、(日本でどうなるかはともかく)、Appleの一方的な管理下にあることにおそらく変わりはないでしょう。アプリ形式でダメな本が、iBooks向けコンテンツならOKとは考えづらい。電子ブックのプラットフォームとしての魅力が一気に消えた感じですよ。Appleの気に入らない本は売れない読めない電子ブックリーダーなんて、グロテスクでしかありません。

幸い、私のアプリには、現在制作中のアプリも含めて、影響がない(と思う)わけですが、そんなことはこの先どうなるか分かりません。やはり、Appleが一方的に管理するAppStoreという仕組みに依存する、現在のiPhone/iPod touchに深入りしすぎるのは危険だと感じますね。Appleもここまで一方的な価値観でAppStoreを管理するなら、AppStore以外で“野良アプリ”を配布するのを認めるべきでしょう。今のやり方では、いずれApple信者以外ついていけなくなると思います。

こういう事態を経験すると、個人的にはますますAndroidのOpenGL ES 2.0サポートが待ち遠しく感じてきますが、Android DevelopersのDiscussionsを見ると、Android framework engineerのRomain氏が2月10日と11日に「OpenGLES 2.0 is coming. 」「Definitely not years :)」と書き込んでいるので、そう遠くないうちにサポートされると期待できそうです。

OpenGL ES 2.0 on Eclair
http://groups.google.com/group/android-developers/browse_thread/thread/5e93f608ddaa10b1/f66539b7182d82b6

でも、AndroidはiPodの代わりにはならないのだよな…。そこが悩みのタネ。

夜中の公園に猫が3匹。

どうやら、この公園には、白黒1匹、黒2匹いるらしい。
LUMIX GF1の液晶モニターを暗視鏡代わりに使いつつ、接近を試みるも、3匹とも警戒心が強いらしく、あまり近寄れない。
こういう目的だと、20mm F1.7だとちょっとつらい。トリミングするとLUMIX GF1の高感度ノイズが気になってしまう。50mm F1.4くらいが欲しいところ。
そういえば、今年は寅年だった。ネコ科つながり。

2009年のまとめ iPhoneアプリ開発とか表現の自由とか

2009年も今日でおしまい。個人的には2008年より内容のある1年だった。

7月に始めたiPhone用アプリ開発は、ようやく12月にAppleからの支払いへと辿り着いた。「被仕向送金」なんて見るのは初めて。本数は少なくても世界中から反応があるのは楽しい。日本で閉じて考える必要はないことを実感した。何事もやってみなければ分からない。他人の情報だけ収集して、頭の中でどれだけ推論しても、オタクのウンチク話にしかならない。米国の弁護士が出てくるようなトラブルもあったが、それも含めて良い経験だと思う。

内心の自由、表現の自由、言論の自由といったものに対する無理解と圧力はますます悪化している。到底看過できないが、ではどうすればいいのかと考えても、妙案はない。何かを規制するのに持ち出される、『犯罪者の○％がそれをもっている。』という類の理由付けは、典型的な詭弁だが、自分と直接関係がない限り、多くの人はその程度の詭弁にも疑問を持たない。『弱者保護』という美名に隠れて『嫌いなものを禁止したい』という欲望を実現せんとする勢力は、実にしたたかだ。『非道徳なことを考えた』とか『机に向かって一人でエログロな絵を描いた』とかそのような理由で犯罪者として罰せられるなど、明らかに間違っている。内心の自由とか表現の自由は、それを取り締まるのが技術的に難しいから自由なのではない。それ自体が大切だから自由なのだ。最近では、脳の反応を可視化できる技術が開発されている。遠くない将来、内心を取り締まれる技術的な手段が開発されるだろう。『“悪いこと”だから取り締まって当然』といった詭弁や論理の飛躍を止めることができないと、将来取り返しの付かないことになるだろう。

OpenGL ES 2.0のシミュレータと実機の違い

OpenGL ES 2.0を使って、iPod touch(2009年64GBモデル)上で、マンデルブロ集合を(ほぼ)リアルタイムでグリグリ動かしてみています。さすがにフラグメント シェーダで単純に計算させるだけでは遅すぎてリアルタイムとはいきませんでしたが、多少の工夫でなんとかなりました。

しかし、OpenGL ES 2.0は、Mac上のシミュレータと実機(iPod touch(2009年64GBモデル))の動作で違いが多くて面倒ですね。今回はフレームバッファ オブジェクトの動作の違いにハマりました。

iPhone OSのOpenGL ES 2.0では、すべてのレンダリングをオフスクリーンのフレームバッファ オブジェクトに対して行ないます。
「OpenGL ES 2.0プログラミング」(ピアソンエデュケーション)によると、

ウインドウシステムは、ダブルバッファ処理されるサーフェースしか提供しない場合がある。一方、フレームバッファオブジェクトは、シングルバッファ処理されるアタッチメントだけをサポートしています。(p.253)

とのことなので、直前のフレームに上書き描画するのに、画面表示につかうフレームバッファ オブジェクトをそのまま使えるかな、と思ったのですが、そう単純にはいきませんでした。

簡単に言うと、画面をクリアせずに直前のフレームに上書き描画したときの描画結果が、シミュレータと実機で違ったわけです。シミュレータ上では想定通り上手くいったのですが、実機上ではダメでした。

どうもMac上のシミュレータでは、画面表示につかうフレームバッファ オブジェクトと、それ以外のフレームバッファ オブジェクトが、どちらもシングルバッファ処理されているように見えるのに対して、実機(iPod touch(2009年64GBモデル))上では、画面表示につかうフレームバッファ オブジェクトはダブルバッファ処理されているように見えます。(ちょっと違う気もするけれども、見た目はそんな感じ)。

結局、テクスチャに描画するようにプログラムを変更しました。
なかなか一筋縄では行かないものですね。
年末までに完成するかな…。

「セラミックファンヒーター」購入

東京に越してきてから10年以上、夏も冬もずっとエアコンを使ってきましたが、もう我慢できん、ということこで、夏に扇風機を買ったわけですが、そろそろ寒くなってきたので、こんどはセラミック ファンヒーターを買ってみました。

購入基準は、テーブルの下に置ける高さ、つまり30センチ以下が条件。出力は、部屋全体を暖房する必要はないので、300Wくらいあれば充分。

というわけで、いろいろ探してみたのですが、高さが30センチ以下のファンヒーターってあまり選択肢がないみたいですね。最終的に、Amazonで「DBK キューブセラミックファンヒーター シルバー DCB1000SB」を購入しました。

1週間くらい使った感想としては、

≪良い点≫

• 想定通りのコンパクトさ。
• キューブ型のデザイン。
• 電源を入れて数秒で温風が出てくる。
• 無段階で温度設定できる。

≪気になった点≫

• 風量調整が出来ない。
• 使用目的には、500Wはちょっと暑かったかな。

といった感じです。500Wはともかく、私の使い方だと風量がちょっと強めに感じます。2段階くらいで調整できればよかったかも。

全体としてはかなり満足です。やっぱり、エアコンよりすっといい。エアコンを使うのを止めると部屋の間取りもかなり自由になったし、もっと早くそうすればよかった。

セラミック ファンヒーターなので、電気代がちょっと心配ですが、常時使うわけでも、部屋全体を暖房するわけでもないので、古いエアコンよりはマシじゃないか、と想定しています。

「audio-technica AT-PHA30i BK」購入

iPod専用ポータブルヘッドホンアンプ「AT-PHA30i BK」を購入しました。

…が、使い方が分かりません。

付属のマニュアルだと、Dockコネクタにつなぐだけで使えると書いてあるけれども、リモコン機能がまったく反応しません。 第1世代iPod touch(16GB)、第3世代iPod touch(64GB)で試したけれども、両方ともまったく同じ。音は出てるけれども、どうなってんの？第3世代iPod touch(64GB)に最初つないだときは、「この機器は対応していない」とか表示されたし…。

ちなみに、第3世代iPod touch(64GB)だと、Dockコネクタのロックタブが機能しないとか…。

とりあえず、audio-technicaのサポートにメールしたけれども、どうなることやら。

(追記)
解決しました。リモコン部分の上側、イヤホン端子の横に小さな「HOLD」スイッチが存在して、このスイッチが入っていたらしい。(たぶん…。いろいろいじっていたら使えるようになったので、よく分かりません。)とりあえず、良かったです。

でも、説明書を見ても、「スイッチを矢印の方向へスライドすると、ホールドします。」としか書いてないのは、説明になっていないと思うな。「ホールドします。」って、何がホールドするんだよ。

とりあえずの感想として、いつも使っているイヤホン(MDR-EX700SL)だと、音が大きいのが気になる。もう1段、音を小さくしたいと思っても、ボリュームを下げると無音になってしまいます。世間ではこの音量が普通なのかな？

(追記2)
ちょっと心配だったバッテリのもちは、全然問題ないみたい。iPod touchに12時間付けっぱなしにして、うち、3時間くらい音楽を再生した程度では、バッテリは全然減りませんでした。サイズも小さいし、これならiPod touchの使い方を変える必要はありません。

問題があるとすれば、やはりDockコネクタのロックが機能しない点ですね。iPod touch本体をジャケットの内ポケットに入れて、AT-PHA30iを内ポケットの入り口にクリップで留める使い方をしていたのですが、地下鉄とかで押されるとDockコネクタが半分抜けることがありました。

「マスコミは善悪を判断する立場ではない」のか?

マスコミというのは本来「善悪」を判断する立場ではないのですよ？【表現規制について少しだけ考えてみる(仮)】
http://otakurevolution.blog17.fc2.com/blog-entry-666.html

何かを世の中に伝えるというのは、伝える内容だけでなく、その行為そのものも、意思表示の一種なのです。

たとえば、上記URLのブログは、他のブログや新聞記事の内容を伝えているもので、ブログ独自と言えるような情報はあまりありませんが、ブログ自体が『「児童ポルノ法」の改定に反対する』という強い意志の表明であることは明らかでしょう。

何らかの意思に基づいて行なわれる行為である以上、そこには必ず価値観や善悪の判断が存在します。「中立性」とか「予断を持たない」などというものは、マスコミ自身の基本的な価値観や善悪判断を前提にしたものです。マスコミの報道にマスコミ自身の価値観が反映されているからこそ、個々の記事だけでなく、全体として批評できるのです。

仮に、マスコミの報道にマスコミ自身の価値観が反映されないとしたら、そのようなメディアは、どのような情報も平等に存在する今のインターネットに近いものになるでしょう。(将来は分かりませんが。)
では、インターネットというメディアだけが存在すればいいのかというと、そんなことはないわけです。ほとんどの人は“インターネットというメディア上に存在する各種メディア”を通じて情報にアクセスしています。上記のブログもそうしたメディアの1つですし、ニュースサイトやgoogleのような検索サイトもそうです。googleはgoogleなりの価値観や善悪判断を元に情報を媒介します。だからこそ、googleには価値があるし、だからこそ、googleだけあれば良いということにはならないのです。

仮に、マスコミが本当に善悪を判断しなくなったら、マスコミが流す情報は、詐欺・インチキ・広告宣伝で溢れかえるでしょう。少し前に、日経BPが永久機関みたいな製品発表をそのまま記事にして批判されたことがあったと思います。そのまま記事にするなら「中立的」で「予断を持たない」から良いじゃないか、と言う人もいるかもしれません。しかし、そうでないのは、そのような記事は多くの人が日経BPに感じている価値に反するからです。

マスコミがもっている(と感じる)思想や価値観を批判するのは自由です。堂々と主張すればいい。しかし、「善悪を判断するな」というのはダメな主張です。なぜなら、判断することこそがマスコミにとって自分が存在する理由であり価値であり、そこに意志がある限り、判断しないことなどそもそも不可能だからです。

OpenGL ES 2.0のフラグメント シェーダの不可解な動作

OpenGL ES 2.0のフラグメント シェーダで次のようなコードを書くと、Mac上のシミュレータでは問題ないのですが、実機(第3世代iPod touch(64GB))では、(1)のgl_FragColorへの書き込みが無視されて、描画されない(ノイズが描画される)という状況が発生し、理由が分からず、困ってしまいました。

void main()
{
  if (…)
  {
    gl_FragColor = …;     …(1)
    return;
  }

  glFragColor = …;   …(2)
}

最初は、書き込んでいる値がおかしいのかと思ったのですが、(1)と(2)で同じ値を書き込んでも、(1)だけ反映されないし、次のようにするとシミュレータでも実機でも問題が起こりません。

void main()
{
  if (…)
  {
    gl_FragColor = …;     …(1)
  }
  else
  {
    gl_FragColor = …;
  }
}

例外的な処理をさっさと終わらせてインデントを深くしたくない、(私には)見やすい、といった理由で、最初のコードの書き方が好きだったのですが、スタイルを変えなきゃダメなのかも…。returnは使っちゃダメなんですかね？

LUMIX GF1で夜の猫撮り

ここ数日、LUMIX GF1＋20mm/F1.7で深夜の猫撮りに挑戦中。
猫は夜行性だし、人のいない夜中の町なら猫も自由にお散歩しているのではないかと思ったのですが、現実はなかなか難しい…。

まずは、深夜の神社。神社には猫がいるものです。たぶん。
SILKYPIX Developer Studio 3.0 SEでの現像時に高感度ノイズを除去したり、多少調整しています。それでもこれだけ写れば、私の必要とする画質的には充分です。
(ココログの1MB制限は本当に不便。せめて5MBに緩和して欲しい)

F1.7で撮影していますが、ISO1600でシャッター速度が1/8秒。F2.8とかに絞ると遅すぎて私には撮影不能でした。深夜の撮影では、F2.8は暗すぎということなのでしょうね。

LUMIX GF1とセットで買った20mm/F1.7以外に望遠レンズが欲しいのですが、F2.8では暗いとなると、SIGMAの50mm/F1.4(35mm換算で100mm)とかになるのでしょうか。でも、このレンズ、LUMIX GF1でAF可能なのかな？しかもフォーサーズ用なのでLUMIX GF1にはアダプタが必要だし…。どこからか、コンパクトな「マイクロフォーサーズ用50mm/F1.7」とか出ないかな…。

追記：SIGMAのフォーサーズレンズはすべてMFになるみたいですね。http://panasonic.jp/support/dsc/connect/g1.html

16:9なのは、壁紙用だからです。
この青いレンズフレアは、20mm/F1.7の特徴なのでしょうか。もう少し気をつけないとダメかな…。

同じ猫。こっちを先に撮りました。深夜にしては、わりと明るい場所だったのですが、見付けたのは数メートルに近づいてから。最初、道の真ん中に座っていましたが、数枚しか撮れませんでした。難しい…。

深夜の撮影で何が難しいって、猫を探すのが難しい。公園や町中を歩いていると、割と猫に遇うのですが、気がつくのは、たいてい、すれ違う瞬間か直前。これはちょっと盲点でした。日常生活でも視力が落ちたことは実感しているので、カメラのレンズを買う前に、私のメガネを買うべきかもしれません。

商標はちゃんと調べよう…

チョンボ発覚。

特許電子図書館で調べる限り、「戦艦ゲーム」や「海戦ゲーム」は商標登録されていませんが、英語での一般的な呼称だと思われる「Battleship」は、ハズブロー社によって「バトルシップ／BATTLESHIP」で商標登録(第9類、第28類、第41類)されているのですね(特許電子図書館は検索結果のページにリンクが張れない構造なのね…。不便だな)。「戦艦」や「海戦」は一般名称・普通名称だよな、という感覚があったのか、英語を調べていませんでした。不覚。

さて、どうしよう。
こういう問題は、弁理士会の無料相談室で聞いてもらえるのかな。
いずれにせよ、週が明けないと動きようがない…。

(追記)
専門家に相談したところ、日本だと非類似で問題ないだろうとのこと。米国でも基本的にはそうなのだけれども、向こうの弁護士はしつこいし、米国で裁判するとなると面倒だとのこと。結局、『こちらは非類似だと考えるけれども、問題を早期に解決するため、名称を変える』ことにしました。

LUMIX GF1でサメ撮り

21～23日の3連休、初日はしながわ水族館、最終日は葛西臨海水族園に行ってきました。もちろん、目的はサメ撮りと「Panasonic LUMIX GF1＋20mm/F1.7」に慣れることですが、葛西臨海水族園では、前回訪れたときに触れなかったネコザメに触れたり、公園内を散策してきました。

しながわ水族館の写真は、こちら(http://lovelyshark.a.la9.jp/blog/?p=161)。
葛西臨海水族園の写真は、こちら(http://lovelyshark.a.la9.jp/blog/?p=187)。

LUMIX TZ3からLUMIX GF1に乗り換えた感想ですが、

• 感度がISO 400くらいまでは圧倒的に綺麗。
• 感度がISO 1000を越えると、ノイズがかなり出る。
• ただし、DMC-TZ3のISO 1000越えと比べて、ノイズの出方はずっと良好。
• ISO 1600でも、現像時に「高感度ノイズ除去優先」を選んでやると充分見れる場合も多い。
• AFはDMC-TZ3よりも速い。それでも動物を撮るには苦しい場合がある。暗い水槽でサメを撮るとフォーカスが合わないことも。MFに慣れる必要がありそう。
• 電源ON/OFFの動作が速くて助かる。
• RAWで撮ると、メモリカードは8GBではぜんぜん足りない。

といった感じでしょうか。メモリカードを8GBしか用意しなかったのは失敗。バッテリがなくなる前にメモリカードがなくなりました。フラッシュを使わずRAWで撮って、だいたい16GBでバッテリ1本といった感じ。

20mm/F1.7(35mm換算で40mm)のレンズは非常に使いやすいです。望遠がもう1本あるとベターだけれども、これ1本でもほとんどOKかも。

葛西臨海水族園では、思いっきり露出の設定を間違いました。背面の液晶モニタだとちょうどいい感じだったのですが、実際には、屋外の写真は全体的に明るすぎで、白飛びしています。補正の大きさは半分以下でよかった。というか、写真に詳しくない私の場合、最終的な露出は現像ソフトで設定するのだから、＋方向の補正はしない方がよかったかも。

↑おみやげ。シャークボックス(フィギュア12種20個)とネコザメのぬいぐるみ

LUMIX GF1のサイズ

まだサメ撮りに行けていません。悲しい。今日の午前中に行こうと思っていたのですが、起きたら2時半でした…。徹夜して明日行こう。

LUMIX GF1は、ここ2日、仕事で1回持ち歩いたのと、夜の公園とかビルを撮影した程度しか使っていませんが、なかなかいい感じです。以下、ちょっとした感想など。

まず、LUMIX GF1＋20mm/F1.7は、私がコンパクトデジカメと同じ感覚で持ち歩けるサイズ的な限界です。これより大きくなると、私としては「カメラ持って写真撮りに行くぞ」といった覚悟というか気合いが必要です。

手持ちのカメラとサイズを比較してみると、今まで使っていた「LUMIX TZ3」の前の前に使っていた「CASIO QV-2800UX」と同程度でした。

QV-2800UXは、40～320mm(F3.2～3.5)のズームを搭載していて、フィルターを付けるのにオプションの類を必要としない、とても便利なカメラでした。撮像素子は200万画素ですが、撮影した写真を誌面に掲載しても、解像度が問題になったことはありません。写真集でも出す人なら話は別なのでしょうが、私としては、デジカメの進化の方向として、解像度よりも1画素の質、高感度時のノイズとかダイナミック レンジとか、そういう性能を向上させるほうに進化して欲しいです。(最近のデジカメではそういう方向の機種も増えてきたようですが。)

今のところ、「絞り優先モード」を中心に使っています。ダイヤル操作で、F1.7からF16まで、連続的に変化させられるのは楽しいですね。

TZ3からGF1に乗り換えてすぐ気がついたのは、(1)ピントが合うのが速い、(2)シャッターが切れるまでのタイムラグが少ない、(3)連写できる、といったところ。今のところ、手ぶれ補正機能がないことは問題になっていません。レンズが明るいからでしょうか。シャッター ボタンを押すとシャッターがすぐ切れるのは、とても快適です。これだけでも買い換えた価値があったかも。

気になっていた高感度撮影については、夜中の都庁を撮影して見比べた程度ですが、GF1はTZ3よりも圧倒的に良い写りで安心しました。これなら、サメ撮りも期待できるかな？

TZ3から乗り換えると、GF1のシャッター音が気になります。シャッターの音は、いかにも写真撮ってるって感じですが、個人的には撮影時にあまり大きな音は出したくないのです。コンパクトデジカメのいいところは、もちろんコンパクトなことですが、撮影時に音がしないことも大きなメリットだと思います。もう少し静かになってくれるといいかな。

最初、RAW+JPEGで撮影していましたが、Vistaのフォトギャラリーやエクスプローラのサムネイル表示で、RAWデータも普通に表示されるようなので、RAWだけにしました。にしても、RAWデータはサイズが大きいですね。つい、コンパクトデジカメと同じ感覚で8GBのSDHCを買いましたが、RAWで撮るとまるで足りません。急遽、16GBを追加しました。

使用しているのは、読み取り/書き込み30MB/秒のカードですが、RAWだと保存にもそれなりの時間が掛かるようです。保存中も連写はできるみたいなので問題はありませんが、これからは速いカードを選んだほうがいいのかも。

明日こそは、サメ撮りに！

「Panasonic LUMIX GF1」購入

今まで使っていた「Panasonic LUMIX TZ3」も、28mmからの10倍ズームは便利だし、明るい場所であまり動かないモノを撮るぶんには綺麗に写るし、悪くはなかった。しかし、水族館でのサメ撮りには力不足と言わざるを得ない！
という訳で、買ってしまいました…。

Panasonic  LUMIX GF1 パンケーキレンズ「LUMIX G 20mm/F1.7 ASPH」付属レンズキット(DMC-GF1C-K)、8GB SDHCカード(SDSDX3-008G-J31A)、PLフィルター(DMW-LPL46)、予備のバッテリーパック(DMW-BLB13)…、ついでに新しい鞄とかもあり、締めて10万円。買う気になれば買えるものですな。これから払えるかどうかはともかく。にしても、純正のPLフィルター高い…。シャッターリモコン諦めたよ。

デジカメなんて種類も多いし、いつもならいろいろ悩むところですが、今回「Panasonic LUMIX GF1」を買うのは、割とすんなり決まりました。

まず、基本的にコンパクトデジカメと同じような感覚で持ち運べそうなカメラを探していたので、伝統的な一眼レフ的なタイプは対象外。

で、最初に考えたのは「SIGMA DP2」でしたが、カメラ自体はとても魅力的なものの、高感度撮影に不安があったので、水族館でのサメ撮りには向いていないかな…ということで残念ながらパス。

「CANON PowerShot S90」はコンパクトデジカメだけれども、高感度撮影に強そう。でも「Panasonic LUMIX TZ3」からのアップグレードであることを考えると、価格の割にちょっと魅力に欠ける気がする…。どうも食指が動かなかった。「Panasonic LUMIX  LX3」とか、その他のハイエンドコンパクトデジカメも同様。

「OLYMPUS PEN E-P1」「E-P2」は、デザインは「Panasonic LUMIX GF1」よりも好きだし、本体で手ぶれ補正できるのも魅力的。でも、ちょっと値段が高い…。少しとはいえ「DMC-GF1」より大きくて重いのも気になると言えば気になるし、そして何より、OLYMPUSの17mm/F2.8よりも、Panasonicの20mm/F1.7のほうがずっと魅力的。さすがに本体とレンズを別々に買うほどの余裕はなかったので、「Panasonic LUMIX GF1」に決定。マイクロフォーサーズも、高感度撮影は得意じゃないみたいだけれども、そこはさすがにコンパクトデジカメ以下ということはないはず…と期待。

で、買ってから調べるのもおかしいけれども、マイクロフォーサーズって思ったよりレンズ少ないのね。興味があるのは45mm/F2.8くらい…。来年もいくつか出るみたいだし、そもそも金もないので、どっちにしろ問題はない、とも言えますが。

早くサメ撮りに行こう。

「OpenGL ES 2.0プログラミングガイド」購入

「OpenGL ES 2.0」周りはこれ1冊で充分。Appleのドキュメントやサンプルを見るだけでも、一応、OpenGL ES 2.0を使ったプログラムの作成はできますが、「組み込み関数」「シェーダ記述言語」とかの正確なところを確認するのに、やっはりこういった本があると便利です。

ざっと読んだ感想としては、やはり組み込み機器向けということか、OpenGL ESシェーダ記述言語にけっこう制限があるのですね。
とりあえず、

1. 配列のインデックスとして、定数の整数式だけをサポート(頂点シェーダで例外あり)。
2. forループの繰り返し回数はコンパイル時に分かっていなければならない。
3. 使用可能なuniform変数の数(最小)：頂点128個、フラグメント16個
4. 使用可能なattribute変数の数(最小)：8個
5. 頂点シェーダでのデフォルト精度は、highp
6. フラグメント シェーダでは、デフォルト精度が決まっていないので、コードで指定する必要がある。

といったところを気にしておく必要がありそうです。でも、1.と2.の制限はちょっときついかな…。

基本的に今後はシェーダ コードだけで済ませたいですが、たとえば私の所有する端末では、第1世代iPod touch(16GB)がOpenGL ES 1.1、第3世代iPod touch(64GB)がOpenGL ES 2.0対応。両対応するにはOpenGL ES 1.1のコードも書かなきゃならなくて面倒なのが現在のOpenGL ES 2.0の問題かも。単純に両対応するにはOpenGL ES 1.1のコードだけでいいわけだし。でもiPhone 3GSが売れてるみたいだし、そろそろOpenGL ES 2.0必須でもいいのだろうか。

Android OSって、まだOpenGL ES 2.0には対応していないのか…。端末側はどうなんだろう？OSさえサポートすれば対応できる端末もあるのだろうか。でも、Androidを買ってもiPod touchは持ち歩くだろうし、それだったらiPhoneのほうが魅力的。Androidには、何かもう一押し、魅力が欲しいなぁ。

「iPhone Core Audioプログラミング」購入

まさか、こんなピンポイントな本が発売されていたとはビックリです。全然気がつきませんでした。
以前、Amazonで「Core Audio」関連の本を調べたときは、来年発売予定の洋書が1冊見付かっただけだったので、日本で、しかもiPhone OSに限定した本が出るとは、日本も捨てた物じゃありませんね。

まだ興味のあるページをパラパラと見ただけですが、とりあえず、iPhone OSのオーディオ周りはこれ1冊あれば充分で、他の資料は必要なさそう。あとは、今月発売予定のOpenGL ES 2.0の本を買えば、もう参考書の類は必要ないかな。

でも、今いちばん困っているのは、iPod touchが思ったよりも非力な点なのよね…。コールバック関数内でちょっと重い処理をしただけで音を上げてしまう。こればかりは参考書を読んでも容易に解決しない。もうちょっとパワーが欲しいですね。

3本目のアプリが公開

3本目のアプリがAppStoreで公開されました。
今回は、10月16日に申請して11月3日に公開だから、公開まで2週間ちょっと。

ちなみに、公開されたアプリ(ミニ ゲーム)の説明はこちらです。

はじめてOpenGL ES 2.0を使いましたが、普通にプログラマブル シェーダを使えるし、いいですね。もう1本くらいOpenGL ES 2.0を使ったゲームを作りたいですが、やはりゲームのようなものは一人で作っていると、いろいろな限界も感じてくるなぁ…。