かにの泡ぶく

_

_

_

_ 南伊豆二泊の旅（10:17記）。

5/4〜5/6と、南伊豆に二泊で観光旅行してきました。

それほどヘビーな旅程ではなかったのですが、昨日は早めに家についてワイン飲みながら晩飯食べて、娘を寝かしつけるのと一緒に私も意図せず寝てしまったようで。

これからバックログ整理します。

_ 5月4日（木）南伊豆二泊の旅：初日

今日から静岡県下田・南伊豆方面へ家族で二泊観光旅行です。

宿は、白浜にほど近いペンションを確保しました。最近、スキーの旅と合わせてペンションづいていますが、これはこれで、気楽でリーズナブルでなかなかにいいものです。
初日である今日の予定は、東名高速の渋滞を嫌って朝5時半に自宅を出発。東名横浜青葉IC→沼津IC→中伊豆天城越え→下田と走り、一気に石廊崎を目指します。

順調であれば、午前11時前には昼食ポイントである「おか田」について昼食。その後石廊崎に昼ごろ着いてのんびり散策し、宿には午後4時すぎチェックインって感じで考えておりましたが、まさにほぼオンタイムな進行で、初日の旅を無事終えました。

宿の夕食は完全和洋折衷でかなりのボリュームです。サザエの壷焼き、お刺身、蟹、塩焼き、ポークステーキ、サラダ、ひじき、苺・・・「ご飯おかわり自由ですからね〜」って言われても、ほんとお腹一杯って感じでとても満足。

_ 5月5日（金）南伊豆二泊の旅：二日目

今日は下田海中水族館で一日のんびり過ごそうかなと。
イルカショーがなかなか見せ方が上手で楽しめました。

↑音量がなぜかかなり大きいので、音量絞って再生されることをお勧めします。

宿の夕食は昨日にも増してのボリュームです。連泊だと食材もレベルUPするのか、かなり豪華です。地鶏焼き、伊勢海老のムニエル、ホタテ網焼き、お刺身、金目の煮付け、サラダ、煮物、フルーツ・・・「ご飯おかわり自由ですからね〜」って言われて、今日はおかわりしちゃいました。とても満足。

_ 5月6日（土）南伊豆二泊の旅：最終日

今日は爪木崎近辺を巡って、下田で早めに昼食を取ってあとは一気に来た道で帰宅です。

途中、東名高速で想定の範囲内の渋滞にちょろっと遭いましたが、大きな問題なく無事午後7時ごろ帰宅。

下田・南伊豆って普段あまり行かない場所ですし、私自身行ったことあるのはたぶん過去に一度だけ。30年近く昔（だと思うのだけどなぁ・・・）に家族で石廊崎に行ったきりぐらいだと思います。

今回、比較的余裕のあるスケジュールで二泊しましたが、まだまだたくさん、のんびり見て回りたいところが多くあります。下田の町も今回散策できませんでしたし、海岸沿いの遊歩道も、もっと歩いていろんな自然に触れてみたいですし。

爪木崎では、溶岩でできたごつごつの海岸を、海のほうまで歩いていけば遠くに黒潮を見ることもできますし、その黒潮から、ほんのわずかにこぼれ、岸までたどり着いてきた潮流は、確かに黒潮の一部であるという匂いがして、普段間近に見ることのできない遥か太平洋の壮大さを感じることができました。

潮の流れというのは、よいものですね。大阪で営業していたころ、徳島に渡るときに橋の上から見た鳴門の渦潮を思い出しました。

_ エスクード燃費記録。

5/4〜5/6の伊豆旅行、出発時に家の近くのガソリンスタンドで給油し、下田〜石廊崎まで回って帰ってきてまた同じスタンドで給油した。

走行428Kmで給油量41.15リットル。燃費はリッター当たり10.4Kmと、納車後はじめてリッター10Km越えた。

途中、東名高速や沼津市内で渋滞（行き帰りとも東名での事故渋滞含み総計で約35Kmぐらい）を食らうも、伊豆半島内は概ね順調。エスクードに限らず過去、いろんな車で伊豆に行ったことあるけど、どの車もベスト燃費を出す不思議な地域。

_ 良い仕事した日は酒が美味い。

つうか、なんにせよ酒はいつも美味いのですが、『決まったな』つう感じの日の酒は、特に美味いものです、はい。

_ 連休明け進行。

はい。ばたばたです。でも、一個ずつ着実に消化していきます。はい。楽しいです。こうじゃなくちゃ、だめですたい。

_ 引き続き連休明けフォロー。

いろいろと。

ぼちぼち落ち着いてきたかな。

_

_ ちょびっと酒残感。

心地よいクラクラ感を伴う寝起き。

最近、私が昔から愛飲しているカティーサークのボトルが変わったのであるが、どうも、それとともに中身も少し変わったようだ。先月ぐらいから、この新しい版のカティーサークを飲んでいるのであるが、なんかどうも昔の味と違って、しっくりこない。また、翌朝に酒が残ったような感じになることが多くなったように思う。単に飲みすぎなのか？　って思って、こないだためしにホワイトホースを飲んでみたら、別になんともなかったし、こちらの味は以前のままだった。

だからこれはきっと、カティーサークはボトルが変わって別物になったに違いない。

_ 昨夜の狂行。

ロバート・デ・ニーロとアル・パチーノが共演しているというなんとも豪華な映画『ＨＥＡＴ』が昨夜、地上波で放映されていたので見てしまった。映画を見ながらウイスキィを飲むと、これまたよく進むのであるがそれはおいといて、悪役のロバート・デ・ニーロはやっぱかっこいい・・・ってこともおいといて。

映画を見終わったあと、なにをトチ狂ったかTWAINの自作駆動ライブラリのコードを編集しだした。

私は確かによく、夜はウイスキィを飲みながらコーディングしたりするが、それは、画像処理アルゴリズムの構築や実験など、どっちかっていうと多少アカデミックな分野での作業のときである。TWAINの駆動ライブラリのコード編集なんてのは、どっちかっていうとかなり事務的な作業であり、どう考えても酔っ払いがやるべき作業では無い。

それをなにを思ったのか昨夜コード編集しだして、新規機能を何点か追加した。

ちゃんと動くのだろうか・・・というか、現状動いていないんですけど＞俺。

_ コンパイル・・・

しなおしたら動いた。なんか嫌な感じだなぁ。

昨夜書いたコードをチェックしてみるも、かなり明快に書かれていて問題となるような箇所は無かった。信頼性も大丈夫そうだ。

_

_ ステーキを焼く。

母の日ということで、今日は私が晩飯の用意。ステーキを焼く。
前回、我ながら良い出来だったソースが、まぐれだったのかそれとも再現性あるものなのかを検証する目的もあり、今日も、前回と同じソースを狙う。

が、なんと、あると思っていた白ワインビネガーが無かった！　これはショックだ。そうか、先日スペシャルな焼きソバを娘に作ってやったときに、全部使ってしまったのだってことを、思い出した。
仕方が無いので、日本酒（黄桜辛口一献）と酢で、なんだか怪しいものを用意して誤魔化す。つうわけで、今回のソースのレシピは：

・付け合せの人参を煮たときの煮汁（これがベース）
・赤ワインをそこそこ
・日本酒をちょろちょろ
・酢をたらたら
・ソース少々
・醤油ほんの少々
・片栗粉ほんの少々（トロミ用）

を、ステーキ焼きあがったフライパン上に入れて一煮立ち、続けて弱火でトロミが出るまで加熱って感じ。

結果、『ぉお、いい感じだ』ってわけで前回に引き続きの高得点で80点。前回より2点ダウンしたのは、今回、ワインを安ものにケチったのであるが（これ専用に安いの買った）、ワインの質は味にテキメンに表れるなってことが判明したことを受けて。

でも、我ながらいい感じだ。ステーキソース、安定して作ることができるようになってきたぞ。

_

_ 林檎とバナナを数える。

5年ほど前の話だが、ほんの出来心で作り始めたらかなり面白くてハマってしまった画像認識。その当時は、取りあえず第一歩として床に適当にばら撒かれた林檎とバナナを写真で撮って画像化し、それぞれの数を自動で数えるというエンジンを作ってみた。まんま、画像認識入門に最適な例題って感じでしょ？

こういうことをする際には、いくつかのキーポイントがある。第一に重要なのは、「対象物を抽出する」という作業。これが出来ないと話にならない。そして、次の段階として特に重要なのは「ラベリング」という作業だ。林檎とバナナを選んだのは、色が特徴的であるから色相で物体を容易に抽出できるだろうと思って（但し床が同色系でないことが条件）。別の言い方をすれば、色相を使って画像を二値化し、これにより分離抽出された領域についてラベリングを実施。円形度が大きいものを林檎、小さいものをバナナとするというような感じの考え方。

出来た実験アプリの動作は極めて良好で、イジワルして林檎と同じような色した四角いものを入れたりしたけど、円形度でちゃんとはじかれて林檎だけがカウントされた。こんな簡単なものでもはじめて動いたときはたいそう感動し、嬉しかった。

このエンジンはその後、顕微鏡写真からの「ミジンコ計数ソフト」にインプリされたり、ある製造ライン上で、変形した商品を自動で発見するソフトにインプリされたりと、結構活躍した。

今回急遽このエンジンを再利用する機会を生じ、久々にコードを引っ張りだしてみた。オリジナルはMacintosh/CodeWarriorで書いたコードであるが今回は、Windows/VC++だ。が、全く修正せずにコンパイルが通り、無事動いた。速度も5年前とは雲泥の差で、5年前はVGA程度の画像の処理に数秒を要していたが、今ではその10倍程度の画像を投入しても、コンマ数秒のオーダーで終了する。

これ使って、またなにか面白いこと、したくなってきたな。

_

_ ・・・・

_ あっという間の一週間。

ほんま、毎日忙しく充実した日々の一週間。ここもロクに更新できないほどであったけど、バルコニーの苺を収穫したり、最近ほっておいた「しいたけ」が突如また発生しだして収穫したりと、ネタはそこそこにあったのだけど・・・

週末にでも時間があれば、ちょいとまとめて（備忘録代りに）載せておくかな。

_ 備忘録。

今週の出来事を、まとめて簡単画像メモ。

5月14日（日）：バルコニー菜園で苺の収穫。

今年はなぜかずいぶん遅い。日照不足のせい？

5月15日（月）：しいたけ収穫。

フェリシモの「おうちできのこ狩り」セット。とても美味しいしいたけが何度か収穫できたのだが、4月上旬の収穫以降、さすがにもう季節は終わったと思ってバルコニーに放置していたのが突如芽吹いた。で、このたび収穫。美味。

5月17日（水）：子ガニ。

味噌汁に入れたあさりの中から発見。

5月20日（土）：ワンカップのある風景。

万一に備えて。

_ お休みの日曜日。

それでも画像に分割線引いたりする仕事をちょろちょろっと。

_ さてと今週も頑張りますか。

6月7日から、パシフィコ横浜で画像センシング展が開かれる。これに向けてかにこむも、今週あたりからいよいよ大詰め。

_ レスポンス関数。

空間周波数の変化をシミュレーションするために、高次の関数を組み合わせてシミュレーターを作ってみたのだけど、処理時間がかかりすぎるっ。

う〜ん・・・

_ ややこしいTWAIN（その3）。

なんだかアプリケーションの内部構造がかなり混沌としてきた。

結局、16/48bitでの画像インポートは無事できるようになったし、DAT_IMAGEMEMXFERもDAT_IMAGENATIVEXFERも正しくハンドリングできている。耐久テスト（スキャナに対して繰り返し1024回連続スキャンを4セット）も合格。1バイトのメモリリークも検出されずでなかなかロバストではあるのであるが、中身がいまいち納得しにくい構造になってしまった。
しかしながら、現状の（アプリケーションがDataSourceを直接ロードするという）構造では、これ以上よい実装がいまのところ思いつかないのも事実。
仮に、このTWAIN DataSourceのIF部だけを別モジュールにしたとしたところで、やはりこのモジュール内が混沌とすることは避けられないわけで、どこかで誰かがやらねばならないわけである。

ということで、可能な限り、コード内、クラス間の見通しを確保しながら、注意深く実装することで勘弁することとしよう。 でもね、私なりに、あの複雑な仕組みを相当綺麗に実装出来たとは思う。

もし、DAT_IMAGENATIVEXFERだけでよいのであれば、アプリ側からは以下のコードでTWAINから画像を取得することが可能だ。

unsigned char *nativeImageP;
char showUI;
int errorCode;
CTwainImage theTwain(m_hWnd /* or NULL */);

nativeImageP = NULL;     /* 念のために。別に不要。 */
theTwain.SelectSource(); /* 必要に応じて。 */
showUI = TRUE;
nativeImageP = theTwain.EnableDS(showUI);
if (nativeImageP) {      /* 画像取得できた。 */
    hogehoge(nativeImageP);
    myDisposePtr((void **)&nativeImageP);
} else {
    errorCode = theTwain.GetLatestError(); /* なんで取得できなかったの？ */
    if  (errorCode != err_Cancel) { /* キャンセルされたのなら問題無し。 */
        ShowError(errorCode);
    }
}

普通のスキャンはまぁこれだけでいけるんで、楽ちんではあるが、この方法は theTwain.EnableDS() 内でメッセージ取得しながらスキャン終わるまでずっとポーリングしつづける。

これがいやな場合に備えて、外部からメッセージ処理関数を呼ぶような仕組みも設けてあり、今回はDAT_IMAGEMEMXFERが必須であることからも後者の仕組みを使っているのであるが、そうすると、もう少し複雑になってしまうがまぁそのくらいのことは、止む無しってところだろうな。

_

_

_ もう金曜日だ。

今週も、あまり晴れなかったなぁ。植物達が日照不足で心配。

_ 画像を見る眼。

私は趣味でもそうだけど、仕事上でもよく撮像システムの撮影画像の評価ということを行う。デジカメの画像だったり、最近であれば携帯電話の画像であったり。で、いろいろな人に質問されるのが、「どんな画像がよい画像なのか？」ということと、「どうすればよい画像と悪い画像を見分けられるようになれるのか？」ということ。

これは大変に難しい問題である。

特に写真というものは、最終的には人間の感性で見られるものだから、ここに曖昧さというか、見る人の趣向が大いに入り込んでくる。
写真というのは、基本的にはその場のそのままの情景を記録するものであるが、実はそうでは無い。実際にはいろいろに色や周波数、トーンが作られて、最終的に画像化されるわけである。センサーからの信号純度が画質に大きな影響を与えるだろうことは容易に想像できるが、センサー後段の画像処理システムが受け持つこの『作りかた』の部分も、センサーと同じかそれ以上に、撮像システムの画質を左右する。

私はよく、この画作りの部分を料理に例える。同じセンサーを使った撮像システムであっても、その後段の処理で画像の性質は大きく変わる。
同じ素材であっても、シェフや板前さんが違えばまるで違った料理になる。

画像の画質という点についても料理の味と似ている点は多い。『これはすごい美味いラーメンだ。』とある人が言ったとしても、同じラーメン食べている隣の人は『なんだこりゃ、ここにはもう来ない。』って思っているかもしれないし、そういうことは実は珍しいことでは無いだろう。画質も、少なからずそのような性質を持っている。

では、よい画像と悪い画像を判断できるようになるためには、どうすればよいのか。

料理の味がわかるようになるためには、なるべく多くのお店の多くの料理を実際に自分で食べてみることに尽きる。それも、なるべく多くの「ホンモノ」あるいは「ホンモノに近い」（これは『高価な』ということとは全く違う）料理を食べてみることが大切だ。
画質も同じ。なるべく多くの画像、いろんなデジカメ、いろんな携帯電話で撮られた画像を自分の眼で見て印刷してみて感じてみることに尽きる。実際に自分で、いろんな画像を比較考察することが重要だ。『このカメラ、×△○先生が雑誌で画質がいいって書いてたよ』など、そんな情報は一切無視して構わない。ま、もちろん、参考情報として収集するのはよいことだけど。

でもまぁ、そうは言ってもデジカメの場合、押さえておかねばならない点というのはあって、そこは最低限度クリアしてくれないとねってところはある。赤が青に写ったり、黄色が水色に写ったりしてくれては困るわけだが、これは料理で言えば砂糖と塩を間違って入れてしまってしかも味見せずに出されてしまったようなもの。さすがにここまで酷いことは、今の時代にはないだろうと信じたい。

「どんな画像がよい画像なのか？」については、またの機会に、ね。

_ のんびり一日。

TWAINモジュール耐久テストも昨日無事終わり、今日は、のんびり過ごす日曜日。

でも、デジタル撮像系でのCTFの件だけ、ちょいと考察。やっぱガンマは戻さないとだめだよね。

_ 今年も薔薇が咲いた。

この株は、三年目かな？　四年目かな？　いやまて、世田谷に住んでいたころに買った株だから、四年目か五年目のはずだ。

お花屋さんの店先で、五百円で叩き売られていた野薔薇。でも、ちゃんと面倒みているためか、毎年ちゃんと咲いてくれる。

なんとなく、コンクリートなバルコニーにあって、ほっとする空間。

_ 恐怖のTWAIN。

どことはあえて言わないが、なんと！　インポートされる画像のガンマをTWAIN Data Source経由で問い合わせると、澄ました顔して『220』なんて返してくるもの発見。

念のために二回問い合わせても『220』。三回訊いても『220』。デバイスに向かって『絶対そうなんだな！』って言ったあとに問い合わせても『220』。

ガンマ220！。驚愕の数値である。いったいそこは、どんなトーンが待ちうける世界なのか、私には想像できない。

・・・・

たぶん、なにかの手違いで、100倍しちゃったのごめんなさいだと思われるが、只今メーカー技術サポート窓口問い合わせ中。

_ モテぢから

Mewさんち（mixi）でリンク発見。いまさらもてたからと言ってなんら問題解決にはならないのであるが、早速やってみた。詳細結果はこちら。

かにこむさんのモテぢからは・・・81／100点
「国民的アイドル級」です。


■総合評価


全体的には飛びぬけて高評価で、この診断では「モテモテ」な人だと断
定できるレベルです。
これでモテないのならば、世の中の女性の見る目がないのでしょう。特
に高く評価できるのはそのポジティブ力です。あまり悩みを引きずらな
い精神的な安定性は、特にココロが弱い人にとって魅力的に感じること
でしょう。それなりの人生経験も積んでいますし、「頼れる男」として
これからも強くありたいものです。なお、年下の女性はお似合いです。

ふ〜ん・・・年下がお似合い・・・か。

_ 画像処理システムによる生成画像の品質差。

5月27日の話題は、興味をもっていただいた方が多かったようで何通かメールでご意見ご感想ご質問をいただきました。

ま、ここ「かにの泡ぶく」でも、久しぶりの画像系読み物でしたしね。

で、なかでも、「センサーが同じでも後段の処理が違うと品質が随分違うんですかぁ、へぇ〜」って感じの感想が多かったので、もう少し、雑談ですが突っ込んでみたいと思います。
例えば私が実験してみたこれ「ちょっとイジワル？」は、なんと、カメラが同じで現像ソフトもメーカー純正でありながら、カメラで作った画像と現像ソフトで作った画像がまるで違うものになっちゃいます。これなども、「センサーが同じでも後段の処理が違うと品質が全然違う」よい例でしょう。また、最近では各社いろんなRaw画像デコードソフト・・・いわゆる「現像ソフト」を出してます。これも、同じカメラのRawを処理してみても、現像ソフトによって出来た画像が全然異なるわけですね。

このような現象は、発生要因がまるで違いますが銀塩の時代からあったものです。

例えば撮影されたネガフィルムを同時プリントで現像に出すとき、お店によって仕上がりがまるで異なるのはよくあること。ラボ店の系列（使っているミニラボ機や印画紙等）が異なれば、これまた全然違う色調になって上がってくることも珍しくありません。

こうなってくると画質を議論するのって難しくなってきちゃいますよね。まず、基準となるべき品質をどこにもってくるかという時点で、喧々諤々です。

そんな状況を少しでも収束させようとしたのかどうなのか、過去にいろんな標準化が試みられ、いまでも試みられているのかもしれませんが、決定打はまるでありません。
それはなぜかと言いますと、写真画質というものの評価基準はあくまでも鑑賞者の主観であって、感覚量であるからです。

確かに標準光でマクベス撮れば、その画像が定義された色域で色再現性が正確かどうか？　階調性はどうなのか？　を定量的に評価することは出来ますが、だからそれがどうした？　って感じで一般のユーザーにはほとんど関係無いことです。マクベスがちゃんと写ることよりも、大切な人が綺麗に写せて、料理がおいしそうな色合いに写って、快晴の日の青空は抜けるような青で写るほうがよっぽど重要なのです。

ただ、ひとつ言えることは、マクベスすらもまともに写せない撮像系は、とてもじゃないけど日常スナップをまともに写すことはできないということです。

今のところ普及型デジカメの出力画像情報量は、RGB各色8bitで、合計約1677万色（同一色相上のグラデーションスケールも色に数えて）。さらに4:2:2のJPEG記録が主流であることを考えますと、実質600万色ぐらいでしょうか。もちろんRawで撮って16bit/chで現像して16bit/chのTIFFで保存すればもっともっと多いですが。
人間の英知をもってしてもまだまだ手に負えない大自然のもつ光の情報を、この、たったの、RGB各色8bitに入れ込むなんていうことはそれはそれは大変なことなのです。
だからこそ、マクベスがちゃんと写るってことは最低限度必要なことであり、マクベスがちゃんと写ってこそ、ようやく話ができますねって感じでしょうか。

デジカメの撮像系・・・特にセンサーからの信号を受け止めて処理する画像処理システムの設計、調整というのはまさに、大自然を相手にした真剣勝負なわけです。