2007年08月

これってカメラ??

今日のニュースで面白い話題があった。

カシオ、世界最速! 60枚/秒の超高速連写に対応する次世代デジカメの試作機を発表

1秒間に60コマ???
いや、すごいのだけれど、それって一般的な映像/ビデオを超えているじゃないの!

日本はNTSCで、1秒間に30コマ。
ここNZはPALで、1秒間に25コマ。

面白いものではあるけれど、そういうのを(スチール)カメラって言うのだろうか?

60コマを撮るのは凄いけれど、フォーカスの追随ってどうなるの?

カシオはなんか面白いものを出してきたなぁと思った。

そういえば、かなり前の記事で、将来、(今のような?)スチールカメラはなくなるっていう記事を読んだ覚えがある。
いやいや、スチールカメラにはスチールカメラのよさがあるのだから、そんなことは起こらないだろうと僕は思っている。

しかし、こういう製品が出てきたら、それに近い状態になるのかなぁ、とも思う。

いや、しかし、動画のようにコマ送り状態で一瞬を捉えるのではなく、ここぞ!という時にシャッターを切って捉えるのがスチールカメラの醍醐味。
成功の時もあれば失敗の時もある。

数打ちゃ当たる、ではないのである。

まぁ、この辺は写真をやっている人の変なこだわりといえばこだわりだけれど...

このカメラで気になったのが、センサー。
CMOSを使っているようで。

コンパクトデジカメ系でCMOSを使うなんて珍しいね。
ほとんどがCCDなのに。

僕がこの写真の仕事を始めた頃、とあるプロの人とデジ一眼のことについて話をした。
その人は、CCDを推す人だったようだけれど、僕は理由なく、直感的に、デジ一眼はCMOSになるだろう、と思っていた。
CMOSは画像のノイズを抑えるのにいいセンサーだっていうを何かで読んだから余計にそう思った。
すると、案の定、今あるそれなりのデジ一眼はCMOSになってしまっている。

きみまろズームを使っていて思ったこと。
このカメラのセンサーはCCDなのだけれど、点光源があると、横筋のような光が写りこむ。
神聖な場所で撮れば、「おお、神よ!」みたいな感じになるけれど、映像機器のプロの人から教えてもらったのは、CCD特有の現象なのだそう。
しかし、CMOSではそんなことは起こらない。
CMOSの画像に慣れていたので、最初見た時は結構驚いた。
高級なCCDであればまた違うのかもしれないけれど。
興味があれば、強ーい点光源に向かってコンデジのシャッターを切ってみて頂戴。
そういう写真が出来上がる(かもしれない)。

というCMOSの強みもあるからか、高感度時の低ノイズを目指したからかわからないけれど、NikonもCMOSを乗せた上位、中堅機種を発表した。
このニュースはデジ一眼業界には結構衝撃的だったようだ。

その前の週に、Canonが最上位機種の1Ds MarkIII(2,000万画素超)と40Dを発表しただけに、なおのこと衝撃が大きかったようだ。

Nikonが出したのは、ようやくフルサイズとなったD3とAPS-CのD300。

すごいとは思ったけれど、逆に言えば、今までのNikonがふがいなかったのではないの??と思うのは僕だけではないはず。
そこそこのものしか出してこなかったから、相対評価もあって、余計に衝撃が大きくなってしまったのが今回の発表。

Canonも堅実にやっているのだけれど、このNikonの発表でめっきり影を潜めてしまった。かわいそうに。
このNikonの発表を受けて、Canon側では何かしら対策を練っているようだ。

今までのデジ一眼上位機種では、Canonの独り相撲状態だったけれど、ようやくNikonが同じ土俵に上がってきたっていう感じかな。

なんであれ、一人勝ち(特に上位機種)はよくないと思うので、両者に切磋琢磨してもらい、安くていい機能のものを出してもらいたいものだ。
そうすれば、消費者にもメリットが出てくる。
Canonも今までのように出し惜しみのようなことは出来なくなるであろう。

ちなみに僕は、Nikonがどういうカメラを出してきても、乗り換えは出来ない。
そんなお金ありません・・・
だから、Canonにはもっと頑張ってほしいのである!

これでもう1社くらい加わればもっと面白いことになるのだけれど。
言われているのがSonyなんだけれど、果たしてどうなるやら。

面白いのが、デジ一眼(35mm)を出しているメーカー。
全て日本のメーカーである。
Canon、Nikon、Sony、Pentax、Olympus、Fuji、Sigma。
以前はKodakもいたのだけれど、撤退。
あ、現役では、Samsungもあるけれど、どうなんでしょう??
なんであれ、凄いものである。

中判カメラになると海外のメーカーが出てくるんだけれどね。

日本のメーカーも自分の技術力にあぐらをかいていてはいけないと思うけれど、やはり日本はこういう精密系には強いんだなぁと思わされる。

もっと頑張れニッポン!!国旗

またデータベース

はい、またつまらない話を書きます。

この間、テキストデータベースについて書いたけれど。
専門的な話にもかかわらず、頑張って最後まで読んでくれた人もいたようで、感謝でございます。
今回も間違いなくチンプンカンプンでしょう。(笑)

さて、その時に、以前の会社の後輩から、Oracle 10g Express Editionは無料で使えますよ、という情報をもらった。
なんかそんな話聞いたことあるなぁ、と思いながら、検索してみた。

アメリカのOracleからダウンロードできるようだ。
ここから。

まず、ユーザ登録しないといけない。
そして、上記のページを同意してクリックした次のページにある「Oracle Database 10g Express Edition (Universal)」をダウンロードすればよい。

久しぶりにOracleのサイトを見たけれど、なんともまぁ、一杯ソフトウェアのあること!
驚いてしまった。
僕が開発に関わっていた時なんて、しょぼいツールしかなかったのに...
どこまで生産効率が上がるのかわからないけれど、Webベースのシステムを作るツールなんかも配布されていたし。
やはり時代は進んでいるのだ、とそれを味わった。

インストールやらプログラミング、その他のことは省いて、なんでまたここでデータベースについて書こうと思ったか。

それは、この間紹介したtxtSQLとOracleのパフォーマンスの違いを見てみたかったから。
txtSQLはどこまで検討するか?
Oracleは圧倒的なパフォーマンスを見せつけるか??

大規模なデータでは検証していない。
そして、ローカルのWindowsで動くPHP5で動作させた。
メモリにデータを残さないように、また、何か設定を変えるごとに、DBを再起動したり、PHP5を再起動したりした。

この間お見せした。僕のMP3リストを使って。全件2,450。
いやはや、面白い結果が出たよ。

まず、Oracle。
インデックスありとなしをやったけれど、この件数ではさしてパフォーマンスを発揮できないのか、インデックスある方が遅かった。
たかだか数千件では意味がないっていうことかな。
ということで、インデックスなしの状態のものを以下に示す。単位は秒。
英字は検索文字。

全件表示 - 0.2586
hayley検索(141件) - 0.0740
hayley, charl検索(190件) - 0.088
hayley, charl, celtic検索(253件) - 0.097

そして、txtSQL。

全件表示 - 0.7413
hayley検索(141件) - 0.0594
hayley, charl検索(190件) - 0.0747
hayley, charl, celtic検索(253件) - 0.1154

どうよ!

txtSQLはものすごく検討していると思うけれど?

さすがに全件表示するには時間が掛かっているけれど、絞り込めば絞り込むほど速度が出ている。

あれ?Oracleの方の僕が書いたプログラムがおかしいのか?と思ってひいき目に微調整をしたけれど、それでもこういう結果。

Oracleって、DBに接続するのに何かかまして接続していたと思うけれど、それが影響しているのだろうか?
あとは、このOracle 10g Express Editionが上位バージョンでないから??

他にも、もっと少なく絞り込む検索をしてみたけれど、やはりtxtSQLの方が速い。

このtxtSQL、速度を売りにしているというけれど、確かに侮れない存在だ。

一体、何万件、何十万件まで耐えられるのかわからないけれど、個人で利用するようなDBなら、これでも十分。
Oracleのようなお金が掛かって重いDBなんて不要でしょう。
もちろん、リレーショナルDBがほしい人はtxtSQLは対象外になるだろうけれど。

ちなみに、僕がサイトの方にアップロードした方のDBで同じ事をやってみた。
全件表示 - 2.6613
hayley検索(141件) - 2.7307
hayley, charl検索(190件) - 3.6408
hayley, charl, celtic検索(253件) - 13.1429

まぁ、色々な条件が掛かってくるからこれくらいは仕方ないのかな?

そして、ついでにMySQLでも同じ事をやってみた。
これもインデックスありとなしをやったけれど大差なかったので、なしの方を。

全件表示 - 0.0106
hayley検索(141件) - 0.0196
hayley, charl検索(190件) - 0.0157
hayley, charl, celtic検索(253件) - 0.0570

おいおい、めちゃくちゃ速いではないですか??
なんか間違ったことしたのか?と思ってしまうくらい。(笑)
しかし、こういう結果。
うーん、オープンソースでこれだけの処理能力があるんだから、そりゃ皆使うわな。

あと、メモリ消費量にも違いが。
設定次第かもしれないけれど、デフォルトの状態だと、Oracleのプロセスが40MB強、MySQLが4MBほど。
これも大きな違いが出ている。

mixiはMySQLを使っているとのこと。記事
あれだけの会員数がいながらも、それなりの速さが出ているんだから凄いよね。

こうなってくると、さてさて、Oracleってどういう立場?という疑問が出てくる。
特殊な処理、独自関数、トリガーやら何やらを使う場合かな?
あとは、(有料)サポートになるのだろうか?

なんであれ、個人で使うにはtxtSQLで十分。
うまく構築すれば、楽に持ち出せるDBが作れるし、なにより、テキストデータベースなので、プロバイダーを選ばないのがGood!

久しぶりにプログラミングして頭の中が・・・(苦笑)
でも、いい頭の体操になったし、少しは最近の動向を体験できてよかったと思う。


追伸 : 8月31日

今日気付いたのだけれど、プログラム内の時間計測場所にちょっと問題が。
txtSQLはDBにコネクトする部分を入れずに計測。
Oracle、MySQLとも、DBにコネクトする部分から計測。

txtSQLでDBにコネクトする部分から計測すると、随分遅くなってしまった。
一方、OracleでDBにコネクトする部分を入れないで計測すると、MySQLと似たような数値になった。
が、若干MySQLの方が速かったりする。

昨日の続きをちょっと

昨日の既月食は皆さん、ちゃんと観られました?

日本では、場所によっては雨やら何やらで観られなかったそうで。

ここAucklandっていうか、僕の近所だけっていう局地的な天候の変化もあり、必ずしも常に観られたわけではありません。

昨日のBlogにも書いた通り、月食が始まる前までは嵐。
その後、風は強かったけれど、雨は止み、空はキレイに晴れ上がった。
そんな時の写真をアップした。

ほぼ月が隠れてしまった時に撮影を区切り、昨日のBlogを書いていた。
さすがNZ。
またいきなり雨が降り出した。
止めてよかった、と思ったけれど、それもすぐに止んだり。

その後は空を時々観ていたけれど、曇ったりもしてもう止めようと思って寝てしまった。

写真をアップしていた時に気付いてはいたけれど、そんなもんなんだろう、と思っていたが、ネット上でこっちの新聞を読んでいると、赤くなる皆既月食とか書いていた。

え?じゃぁ、あの色がそうなの??と今頃気付く始末。
なんとも情けない...
なんでも、地球のチリ(dust)を通り抜けた光が赤外線だそうで、それが月を赤くしたとか?

他にも赤く染まっているものはあったけれど、昨日のものとは変わり映えしない。
が、せっかくなので、もう1枚だけあげておこうと思う。

昨日も言った通り、5D+200mmを等倍。
img_1215b.jpg


で、実際はこんな感じ。
img_1215a.jpg


小さい~。
本当は星も写っているのだけれど、縮小すると消えてしまう。

でも、面白いよね。
北半球と南半球では見え方が違っているから。

こっちでは、下から欠けていき、再び光り出したのが、右下辺りから。
日本では逆だったでしょ?
月の模様も逆だしね。

次観られるのは7年後とのこと。

さてさて、その時は僕はどこにいるのだろう??ロケット ウサギ

P.S.
NZ Heraldに寄せられた皆既月食。
それ、嘘だろ?っていう位真っ赤なのがあるのですが??(笑)

Eclipse

Eclipse

これはなんという意味でしょう?

正解は、その昔、三菱自動車が出していたスポーツカー!

というのは冗談で、普通の意味は、食。
日食とか月食とかの食。

そう、今日は月食の日なのである。
(きちんと言えば、Moon eclipse。)

これを書いている現在も、NZでは月食中。
日本でも観られるんだよね?

今日のAucklandは荒れ模様の天気だった。
これは無理だな、と思ったのだけれど、雨の音が消えたので、外に行って月を見てみると、お、見ている!ということで撮影の準備。

意識して月食を撮影するのは初めて。
いや、僕の人生の中で、月食を見るのが初めてかも。

撮り始めた時、21時10分頃には既に月食が始まっていた。
eclipse01.jpg


残念ながら、僕は天体屋ではないし、鳥屋でもないので、望遠レンズはたったの200mmまで。
5Dにそれを付けての撮影。
この写真は、トリミングしてほぼ等倍。
超望遠レンズを持っていればもっといい解像度で記録できたんだけれど、まぁ、それは仕方ない。

とりあえず、こんな感じ、というのを見て頂ければと。

きみまろズームでも撮ってみようと思ったけれど、こいつはシャッタースピードを変えられないので、話にならん、ということで断念。

雲が通りかかったので、そういう雰囲気で。
eclipse03.jpg


普通に撮るだけでは面白くないよなぁ、と思って色々と設定を変えて撮影。
これは、ダイアモンドリングのように撮影できないか?と思って撮影。
eclipse05.jpg


おー、どんどん月食が進んでいるぅ。21時42分頃。
eclipse09.jpg


目にはこんな風には見えていない。
シャッタースピードを遅くしたので、暗い部分も明るく見えている。
上部の白くなっている部分が、実際に光っている部分。
eclipse11.jpg


eclipse12.jpg


光っている部分が本当に少なくなってきた。
eclipse13.jpg


これが見た目に近いかも。
eclipse14.jpg

eclipse15.jpg


月が暗くなったので、近くにあった星も光って見える。
eclipse17.jpg


とまぁ、僕ができるのはこんな感じ。

現在もまだ月食中。
今これを書いている22時38分現在、右側部分が微妙に光っていた。
この月食は、0時過ぎから1時過ぎまで続く模様。

日本でも空を見上げて下さいね!

テキストデータベース

テキストデータベースの話題。

もう、これは興味のない人には全く興味のない話でしょう。
でも、興味のある人は本当に興味のある話でしょう。

僕のサラリーマン時代は、データベース(DB)とネットワーク関連の仕事をしていた。
結構大きい会社だったにもかかわらず、僕がその仕事を始めた当時としては、MCP、Oracle Master、Novel CNEの3つを持っている人もそうそういなかったと思う。
資格だけを見ればお主なかなかやるな、っていう感じだったかも。

でも、資格は所詮資格。
やはり実践の場の方が余程勉強になるし、知らないことを色々と勉強できた。

そんなことで、結構早い時期から、Oracleを使って仕事をしていた。
しかし、さっぱりわからん!
今のようにあちこちに情報のある時代ではなかったので、試行錯誤しながら、関連部署や数少ない書籍を頼りにしながら仕事をしていた。

そういうこともあって、DBという分野にはとても興味ある。

その頃から、これからの時代はDBとネットワークの時代だよなぁと思っていたけれど(インターネットがちょうと普及し始めるちょっと前)、本当にその通りになった。

あの頃はとても高いDB製品しかなかったけれど、今は、Linusさんのお陰でLinuxがオープンソースになって多くの人に安価で使えるものになったし、MySQLなんていうこれまたオープンソースのDBソフトがあったりしてとても便利な時代になった。

2000年過ぎてからNZに来たし、その手の分野にあまり手を出さなかったのでとんと疎くなってしまい、技術的なことも含めてさっぱりわからん!っていう状態。
この間もJavascript関連で苦労したばかりだし。

それでもやはり時々血湧き肉躍る時がある。

MySQLやそれ以外のRDB系は、サイトを作る時に使えなかったりする時がある。
サーバ側の条件で、そういうものを置かせてもらえないところが案外ある。
それでもDBを使いたい!っていう人がいると思う。

そういう時にどうするか?
テキストデータベースを使えばよろしい。

最近知ったテキストデータベースが2つある。
Gladius DB
txtSQL


どちらも、DBがバイナリーではなく、本当にテキストなのである。
前者は、SQL文がほぼそのまま使えるようだし、後者は独自のSQL文だけれど、速度を売りにしている。

残念ながら、Gladius DBの方は、なぜだか僕の環境では使えなかった。
DBの作成、テーブルの作成は出来たのだけれど、Select文を発行する時の「GetArray」という関数(?それとも配列?)が原因でエラーになってしまう。
情報がないだけに、さっぱりわけわからん、ということで早々に断念してしまった。

そして、txtSQLの方は、それなりに使えたので、週末にこんなものを作ってみた。

曲検索DB
ゲストブック検索DB
(リンク先は削除済み。)

前者は、僕のPCに入っている一部のMP3の曲名やら何やらをDB化してみた。
後者は、HayleyのサイトのゲストブックをDB化してみた。
(本家の方はCGIで作られたもの。興味があれば、検索比較してみてね。)

どちらも検索できるので、どういうものか触ってみて頂戴。
DBのことを知っていないと、だから??っていう感じかもね。(笑)

まず、曲検索DB。

2,400件ちょっと入っている。
これをアーティスト名、アルバム名、曲名で検索できるようにしたのだけれど、動的にWhere句が作れない!!
色々と試行錯誤したけれど、このtxtSQLの独自仕様のせいで、どうもできなさそう。
だから、仕方ないので、べた書きのWhere句にして、しかも3つまでの単語検索という制限を付けてしまった。
SQL文については後述。

これだけの件数があるわりにはそこそこのスピードが出ているのではないだろうか?
全検索するとサーバにある程度の負荷が掛かると思うので、あまりやりすぎるとサーバ運営会社に怒られそう。(苦笑)

そして、ゲストブック検索DB。
これは400件弱入っている。
題名、本文の中から全文検索する。
これもなかなかのスピードではないだろうか?

削除も出来るので、追加して遊んでみて下さい。
くれぐれも変な文章は入れないでね。

これで困ったこと。

最初は、なんと言っても、文章の改行「\n」。
何も処理せずに、そのまんまデータをぶち込んでいたのだけれど、どうもこの改行コードがダメなようで、検索なんてしてくれなかった。
仕方ないので、データ追加時に、「\n」をHTMLの「<br>」タグに置き換え。
まぁ、どうせブラウザの表示に使うのでこれでいいかな、と。

次は文字化け。

やってはいけないことだったのだろうけれど、S-JISで最初はDBに突っ込んでいた。
色々と調べてみると、S-JISはやはり鬼門のようで、「\」コードとぶつかる有名な漢字群で文字化け。
やはりEUC-JPでデータを作らないといけないらしく、それで解決。
(それでも一部の文字がおかしかったので、最終的にはUTF-8で作り直し。)

知らないことばかりなので、本当に勉強になった。

PHPも全く初めてだったので、これまたネット上の情報を元にお勉強。
無駄書きが多いとは思うけれど、別に顧客納入するわけではないからいいかな、と。
機能的にはまだまだやらないといけないことはあるけれど、とりあえずどういうものかを知りたくて作ってみたもの。

さて、このtxtSQL本体。

これはなかなかのすぐれものだと思う。
扱うライブラリーはたったの2つ。
「txtSQL.class.php (41KB)」「txtSQL.core.php (63KB)」。
どちらも100KBもないライブラリーなのである。
これだけでそこそこのことが出来るんだから、大したものだ。
設置するのはこれら2つのファイルと、ユーザ情報が入っているテキストDBのみ。
後は、上記のようなDBを設置して終了。
ものすごく簡易なのである。

そして、気になるSQL文はこういう感じ。

$result = $sql->select(array(
'db' => 'guestbook',
'table' => 'guestbook',
'select' => array('key', 'date', 'title'),
'where' => $where1 = array('contents =~' .$ary[0], 'or', 'contents =~' .$ary[1], 'or', 'contents =~' .$ary[2], 'or', 'title =~' .$ary[0], 'or', 'title =~' .$ary[1], 'or', 'title =~' .$ary[2]),
'orderby' => array('date', 'DESC')
));

普通のSelect文とは違うのでかなりとまどいがある。

そして、先述のWhere句。
見てのとおり、かなり不格好。
いや、これはこれでしか仕方ないのだけれど、この「array」という入れ籠を使って動的にWhere句を作ろうとしてもそれがうまくいかない。
まぁ、ここで詳細に語っても誰もわかってくれないからこれ以上書かないけれど、なんであれ、これがクリアーできれば、何単語でも検索できるようになるんだけれど...

もう一つの問題。
orderby句。
これ、1つしか指定できない?!?!
色々と試したけれど、2つ以上のorderbyの指定が出来ない。
SQL文ならただつなげるだけなのに。
だから、曲検索DBでは、アーティスト名の昇順並びだけになっている。
本当なら、アーティスト名、アルバム名、トラック番号という順番で並び替えたかったのだけれど...

これら2つをクリアーすれば、結構いい感じのものになりそうなんだけれどなぁ。
本家のサイトで質問してみようかと考えている。

次にデータ。
どういう感じで格納されているか?
曲検索DBから。

i:0;a:7:{i:0;i:1;i:1;s:6:"Adagio";i:2;s:13:"Andre Gagnon";i:3;s:10:"Romantique";i:4;s:0:"";i:5;s:14:"Easy Listening";i:6;s:1:"8";}

どうも、これが1曲分のデータのようだ。
これで検索できるのだから大したものだ。

ちなみに、テーブル情報は、別のファイルに格納されている。

データ容量はこんな感じ。
オリジナルの読み込みで使ったテキストファイルは、157KBほど。
このDBは、348KBほど。
MySQLとかだったらどれだけの容量になるのだろう??

なんであれ、本気でここまでこのテキストデータベースtxtSQLを使い込んでいる日本人もそうそういないでしょう。
だから、情報が少なすぎて困った困った。
本家のマニュアルもわかりづらいし。

同時アクセスやら何やらは試していないのでわからないけれど、ちょっとしたDBを作ってみたい、MySQLのようなDBの設置は出来ない、でも、PHPは使えるっていう人には面白いものだと思う。
個人的には、名刺管理DBでも作ってみようかな、と。
作っただけで使わなかったりして。(苦笑)

Hayleyのサイトの全文検索DBを作ってみようかと思ったけれど、データを作り込むのにえらく時間掛かるなぁ...
あると面白いだろうけれどね。

ということで、これ以上書いても面白くない話かもしれないのでやめておく。

そうそう、今回の件で、Windows版のApacheやらなにやらをインストールしたのだけれど、こういう便利なものがあるんだね。
XAMPP for Windows
インストールも楽だし、起動も簡単だし。

数年前は、phpdevを使っていたのだけれど、なんか開発が止まってしまったようで。
ということで、こちらの方に乗り換えた。

最後に。

色々と調べてはみたけれど、どうもいいサイトが見つからなかったので知っている人は教えてほしい!

こういうDBで検索した時、僕が今回やっているように一気に何百件も表示するのではなく、10件ずつとか、100件ずつとか小分けにして表示していきたいのだけれど、これがサクッとわかるサイトってないのでしょうか?
手を尽くして探してみたのだけれど、なんかいいものがみつからなくって。
検索の仕方が悪いのかなぁ...
それともDB開発者にとっては当たり前すぎること??!!
プロフィール

おは

タグクラウド
QRコード
QRコード
  • ライブドアブログ