「鳥の数を数える」ソフトのプログラミング

「画像処理プログラミング」シリーズ第14回記事。

いつもの「画像処理プログラミング」シリーズである。
近年、このシリーズネタが多いのは、2020年のコロナ禍
において外出を自粛したステイホーム期間があり、その際、
それまで何年間も考えていて、「いつか実現してやる」と
思っていた画像処理（自動的に画像を解析や加工する技術）
のいくつかを集中的に研究開発したからである。

コロナ禍第一波の際に研究開発したソフトは7つ程あった
が、もうそろそろ、本記事あたりで、それも終了だ。
このシリーズでの画像処理の研究開発は、仕事ではなく、
あくまで趣味の世界に限定した話なので、今後は、また
スローペースでの研究開発になるかも知れない。

さて、では今回の開発テーマだが・・
「鳥の数を数えるソフト」である。
その昔、NHKの「紅白歌合戦」では、客席に居る観客が
演者である赤組、白組の、どちらを勝ちとするのか？を、
一斉に札を上げていた。
その札を「日本野鳥の会」や「大学の野鳥研究部」等の、
双眼鏡を持ちながら数を数える技能を持つ専門家の人達が、
人力でカウントして、赤組と白組のどちらが有利な結果か？
を集計判断していた。（1985年～2002年頃での話）

勿論、その後の時代では、そういう客席投票システムは
電子化された訳なのだが・・　人力カウントの方がむしろ
エンタメ的要素もある為、2013年頃から、大学の野鳥
研究部が再び、この人力集計をやるようになったそうだ。
まあ、人力で鳥等の数をカウントする「特技」については、
ちょっとうらやましくもあり、伝説的な話ではある。

で、今回の記事は、その「鳥を数える」事を自動で行う
ソフトを研究開発しプログラミングする、というテーマだ。

「何故、鳥なのだ？　他の被写体ではダメなのか？」
という疑問点であるが。一般に、空を飛ぶ鳥の写真は、
背景が空であったりする、だから、恐らく、鳥は単独で
画像処理でき、カウントしやすいであろう。
それに対して、地上に居る鳥、あるいは草木の中に居る
昆虫やら小動物やら草花等では、背景が各々異なる為、
なかなか、それをカウントするのは困難ではなかろうか？
という考え（事前の予想）があったからだ。

まあ、上手くいくようならば、アルゴリズム（画像処理
を行う為の手順。これは自力で考えなければならないと
いうルールとしている）は、追々改良していけばよい。

それに、被写体をカウントする方法も、ざっくり言って
複数の方法論が考えられる、具体的には・・

1)被写体の形を（単純化して）判断する方法
2)被写体の明るさ（輝度）の分布を比較する方法
3)被写体の色（や、その分布）を判断する方法
4)被写体の色や模様等の特徴を判断する方法
5)被写体を線分（ベクトル）で表し、その類似度
　を判断する方法
6)その他の被写体の特徴（量）（＝角、線、丸等）
　を数値化して他と比較する方法
7)フーリエ変換を行い、画像の位相成分を元に
「位相限定相関法」を用いてマッチングする方法

・・など、様々である。

これらの一部は「パターンマッチング」等と呼ばれ、
近代においては非常に進歩している技術分野だ。
特に「AI」（人工知能）や「AR」（仮想現実）等と
組み合わせ、その被写体や対象物を抽出したり特定を
したりをする。

その技術の応用分野は数限りなく有り、医療、防犯、
製品検査、機械制御、統計解析、人物特定、画像検索、
写真撮影、宣伝広告、災害救助、軍事、等、様々だ。

だったら、そういう、進歩した「パターンマッチング」の
エンジン（＝機能をパッケージ化したプログラム）を
探してきて、ちょこちょこっと外側（＝GUI画面等）を
プログラミングすれば、目的は達成できる訳だが・・
例によって本シリーズ記事では、そういう「他人の成果」
を横取りして、あたかも「自分が作った！」とでも言う
ようなモノを作る事は全く好まない。

（同様な思想で、個人的には「SNS映え写真」も好まない。
例えば美味しそうなデザートをスマホで撮ったところで、
それは、そういう「作品」を作った人が凄いのであって、
その撮影者には、何ひとつ主体性や手柄は無い訳だ・・
あと、昔から良く言わている、別の「たとえ」だが、
「手作りチョコ、と言うならば、市販のチョコを溶かして
　固めて終わり、ではなく、カカオ豆から栽培する位の
　事は、やらんかいな？！」という皮肉にも共通する）

で、相当に無茶な話だが・・「被写体（鳥）検出エンジン」
そのものから、自作をする事としよう。

「天邪鬼（あまのじゃく）だ」やら「非効率的だ」やらと、
色々と意見もあるだろうが、これはあくまで趣味の分野
での研究である、だったら、好きにやらせてもらっても
良い訳だし、これを作る事自体が非常に勉強にもなる。

加えて、もしこれが上手くいけば、他者の技術を引用して
作っただけのソフトを組むよりも・・　あるいは、自身が
全く関与していない他者の作品やら、借景やらを勝手に
撮影し、それを「SNS映え」等と言っている状態よりも、
百倍も千倍も達成感がある事であろう。

さて「鳥検出エンジン」だが、統計学で言う相関係数の
考え方をベースとするが、そのままでは作らない。
そして、これに画像処理工学的に前処理を行った画像を、
ぶち込んで計算をさせる。
その際の前処理は高度な内容なので、知的財産に相当
する為、詳細説明は割愛させてもらうが、ごく簡単に
言えば、2次元の画像を、異なる特徴量からなる2平面、
合計の4次元で計算を行うように設計してみよう。
これが上手くいくかどうかはわからないが、まあやって
みなければわからない点もある。
いきなりだが、上図が「鳥」検出結果の一例だ。
建物の上に居る6匹（羽）の鳩が検出されている。

ここで肝心な点は3点ある。

1)これは「完全自動で鳥を検出する」エンジンでは無い。
　まずは対象となる鳥（被写体）を手動で選び、それと
　似ている鳥（被写体）を自動的に検出する仕組みである。

2)一般的なパターンマッチングのエンジンを用いると、
　恐らくだが、完璧に一致したものしか選ばれない。
　今回のエンジンについては、そのあたりの検出基準を
　あえて「甘々」に作り上げる。
　すなわち、「ちょっとでも似ていたらＯＫ」という風に
　曖昧（ファジー）なエンジンとしたい訳だ。

3)ファジーな計算エンジンは、その結果、誤検出（余計な物
　まで鳥等と見なす）は、発生するであろう。
　その際、ファジーの効き目をどの程度強く/弱くするかは
　単なる閾値の他、前処理での次元（＝画像の複数の特徴量
　を並列に扱うという意味）を増やす事で、対応する。

これらの仕様による完全自作「鳥検出エンジン」は結果的
に良好に動作する。上写真では、鳥の数＝６　がカウント
されていて、目的とする性能に対しては、バッチリだ。

ただまあ、そんなに単純（簡単）な話では無い。
何が難しいか？は、追々、本記事で説明していこう。
上写真は本ソフトのGUI（操作部）を開発中の画面。
例によってC#(.NET）言語を用いたイベントドリブン方式。

もう何度も、この、趣味のソフト開発をやっているので
基本となるソースコードも溜り、1時間程度の短時間で
GUI（のみ）を作り上げる事ができるようになっている。

だが、課題は、このような側(がわ、GUI操作画面の事）では
無い。どうやって「鳥検出エンジン」を開発するか？だ。
こちらが、別途、C++言語での「鳥検出エンジン」の
開発中の様子。

今回のソフト開発は、正直言って時間がかかっている。
趣味のソフトでは、だいたいやる事が決まっていて、1日か
2日で出来てしまっていたが（注：それくらいの簡単なもの
しか、趣味の範囲では作れない、という意味もある）
今回のアルゴリズムは、新たに試すべき事柄が多く、
実働日数（工数）は1週間くらいか？　まあそれでも、
一般的な研究では、何ヶ月も何年もかかってしまう事が
普通なので、それに対しては極端に短時間だ。

その（速くできる）理由は、「こうやれば出来る」という
プログラムの全体の流れが、細かい点まで決まるまでは
決してプログラミングに着手しないからだ。

このソフトも、その構想には数ヶ月もかかっている。
その期間、ああでも無い、こうでも無いと検討をし、
あるいは、他に自身で作ったこれまでの趣味のソフト等
で部分的な実験を繰り返し、「よし、これならばいける」
と思ってから、やっとプログラミングを始める訳だ。

いつも言うように「やる事が決まっていなければ、
プログラミングはしてはならない」という、最も重要な
点がここにある。ビギナープログラマー等では、それを
守らず、プログラミング開発環境の前で、「これは違う、
こうしたら良いか？」等と無駄な試行錯誤をしてしまう
ので、ベテランのプログラマー等に対して、酷い場合
では、100倍以上も遅い、というレベルでの時間差が
出来てしまうような次第だ。
さて、こうして出来上がったソフトが「Image Detector」
である。（画面のキャプチャーでは、ソフトのタイトルが
ミススペルしている・汗　後でこれは修正しているが、
今回はもう、やむなく間違ったままにしておこう。

なお、Ver（バージョン）は、0.93となっている。
本シリーズで作るプログラムは、Ver 0.90から始める
通例だが、Ver.0.93というのは、0.91,0.92,0.93と
3度も手を入れて改修している、という意味である。
普通、趣味のプログラムなので、あまり何度も改修を
する事は無いのだが、本ソフトは相当に複雑なので、
長期間、何度も手を入れた、という事になる訳だ）

・・で、このソフトでは、

1)画面左側に入力した画像の中から
　任意の１つの被写体（鳥）をマウスで矩形選択する。

2)矩形選択した対象がGUI画面の中央部に表示される。

3)その対象（TARGETと呼んでいる）が、右側に示した
　画像の中に、いくつ存在するか？を探す訳だ。

4)同じものが見つかれば赤色の枠で示し、似ている
　被写体が見つかると水色の枠で示す。

5)結果の画像は保存できるように作ってある。
　単独でそれを見てみよう。
残念ながら、「パーフェクト」という結果では無い。
検出漏れの（探せなかった）鳥が多数出ている。

ただ、これは、ある程度は、やむをえない。
「似たものを探す」というエンジンであるが、では
「どの程度似ていれば合格と見なすのか？」という
設定によりけりの部分が大きいであろう。

よって、この「鳥検出エンジン」には、いくつかの
設定パラメーターが存在し（GUI画面上のTHやDUと
いうスライダーやスイッチ類）それの設定いかんで
「検出の曖昧さ」が変化するようになっている。
ただ、あまりに「甘々」に設定すると、何も無い空間
とかも拾うようになってしまう（上の結果では、既に、
それが１箇所発生している）

なお、一般に、実際にこうしたパターンマッチング系の
ソフトを作ろうとすると、「微妙に合致している」という
領域が沢山出て来てしまい、その結果、ここまで示した
ように、矩形（四角）の検出結果が単独で（１つだけ）
ビシっと存在する事は、まず無い。

本ソフトでは、近接した領域で重複検出をしないような
工夫が色々と入っている。
その方法論はあえて説明はしない、複数の対処法があるとは
思うし、そういう事を考える事自体がアルゴリズムの開発
なのであり、決められた解決策がある訳では無いのだ。
（この「ゼロから考える」という事が最も重要だ）

それから・・
「左右が同じ画像で無いと、検出できないのか？」
と疑問に思うかも知れないが、それについては、本ソフト
では、両者がバラバラ（な画像）でも問題は無い。

つまり、ある画像から、まず検出元（対象）を選んで、
他の画像から、それと似ている被写体（鳥）を探せる訳だ。
こちらが、左の写真と右の写真を異なるものとした実例。

ただし、この場合、左の写真と右の写真は、同じ画素数
となっている（いずれも約100万画素。ちなみに画素数は
最大1600万画素まで計算可能なように作ってはあるが、
画素数が増えると計算時間がとても長くなってしまう為、
通常は、20万～120万画素程度での処理が望ましい）

もし、これが極端に画素数が異なる場合であるが・・
いくら「曖昧」に探索をしても、その対象(TARGET)の
サイズが大きく異なる場合は、今回のアルゴリズム
（計算手法）においては、検出が厳しくなる。

そこで、このソフトでは対象のサイズを、0.25倍～
1.75倍まで可変拡縮できる仕組みを入れていて、これで
左右の画素数が4倍程度異なる場合にも対応できている。

さて、検出結果を単独で画像保存してみよう。
やはり、対象(TARGET）と、大きくフォルム（形状）が
異なる場合には検出できていない。
まあ、そういう原理で作っているから、当然であろう。

ここは、今後のアルゴリズムの改良が必要だ。
恐らくは計算の次元数を上げる必要があり、最大6次元
程度で類似度を判定するのが、まず第一の改良点。

加えて、自動的に対象を「拡大縮小回転」させながら
（＝すなわち、「アフィン変換」の計算をしながら）
似ているものを探すのが良さそうだ。

たぶん、こちらの方法論が世の中で行われている対象
探索の原理（例：工業計測分野等）なのだろうが・・
これ（アフィン変換）は、自作の計算サブルーチンを
まだ作っていないし、この計算は恐らく重く（遅く）なる
だろうから、どうやって高速で処理をするのが適正か？を
考えるのが大変だ。（まあ、いずれまた作ってみよう）

あるいは、画像の拡大や回転は手間（計算時間）が多く
かかるので、画像上の特徴点（角や直線部等）だけを
抽出して、それを比較する方がスマートな処理であろう。
多分、近代の「AR」技術では、そうなっていると思う。

・・ただ、自然物（鳥や、各種の生物、植物等）は、
工業計測や、AR技術でのマーカー（比較対象）よりも、
はるかに複雑で、はるかに多種多様の物が存在している。
その探索は難しいし、探索手法を色々と拡張した事で、
あまりに似ていないものを探しあてても、その結果が
利用者にとって必要（有益）か否か？もあるだろう。

また、後述するが、「種類の異なる鳥」が混ざっている
ケースもある。
そんな場合は、可能であれば、「同じ鳥だけを探す」
という風な高い計算精度も欲しい訳だ。

それと、「背景が無いから上手くいっているのでは？」
という疑問もあるだろう。それはまあ、当然の疑問だ。

ここまでの写真は、多くが曇天（雨天）で撮った状態で
あり、背景が灰色の単色である。（注：あえて、やや暗い
ままで画像処理をしているのは、この背景の輝度値が
概ね、0x80（＝128、256段階の半分）となっていて、
”画像処理計算上で背景の影響が出難い”というテスト
（試験作業）上での理由もある）

で、対象（TARGET）の選択は、現時点ではあくまで矩形
（四角形）であるから、この中には背景が残っている。
ここに背景が入っていたら、検出精度が落ちる懸念がある。

では、そういう（背景のある）パターンで試してみよう。
こちらは「山麓を背景にした鳥」を対象とした検出結果。
この場合、検出先にも山麓の背景がある場合、それは
検出が出来てはいるが、逆に、空を背景とした鳥は検出
できていない。（下写真は結果の単独保存）
まあ、ここも改善点ではあろう。

だが、これの改善（改良）については、現在のエンジンの
計算アルゴリズムの仕様上では、やや難しい。
まず、現在のままの方式では、対象(TARGET）の背景を抜く
（消去する）必要がある。
手動で抜くのは、マウス等での微妙な操作（輪郭に沿って
マウスを動かす）必要があり、面倒かつ技能が必要であったり
あるいは対象の画素が小さすぎて、操作不能であったりする。

では、対象の背景を自動で抜くのはどうか？
これについては「これが背景だ」という手動指定操作が1回
必要だと思われる。または、それを自動化する手段としては、
できるだけ周辺の画素を背景と見なし、「ここが背景か？」
と推測すれば、自動で出来るかも知れない。

だが、課題となるのは、検出対象画像の方も、常に背景を
抜きながら検出する必要がある事だ、これは恐ろしく面倒で
計算時間もかかるし、どんな背景パターンでも、それが
うまくいく保証も無い。

ならば、まったく別のアプローチとして、チラリと前述した
ように、背景とか被写体とかは無関係な、画像の特徴量
（例：角や線分等）だけを抽出するか？である。
その手法であれば、恐らく上手くはいく。だが、その為には
全く新しい別のアルゴリズムを、また1から作る必要がある。
そして、自然物の複雑な背景の中には、たまたま被写体と
同様な特徴量を持つものも出て来てしまう危険性も高い。

まあ、その背景問題については、現時点では「棚上げ」と
しておき、今後、さらにこれを改良しようと思った際に
あらためて考察する事としよう。

ただ、これは趣味の研究であり、自作の「鳥検出エンジン」
が動いている時点で、もう「知的好奇心」の大半は満足して
しまっている。　つまり、ゼロから1を生み出す創造性や
それを実現する作業が楽しい訳であり、1を、さらに2や
10にするように改善をしていく、という志向性は、私は、
あまり持っていない。

むしろ、そういった「改良の志向性」は、世の多くの
技術者が持つ資質であるから、逆に、それと同じには
なりたくない訳だ。（例：これまでのカメラの画素数が
2000万画素だったのが新製品は3000万画素にしました、
といった志向性。あまり、こういうやり方は好まない）

まあつまり「既存技術の改良は、誰でもやりそうな仕事だ、
でも、全くのゼロから１を生み出す事は、誰にでも出来る
ものではない。可能な限り全く新しいものを生み出したい」
という考え方が、個人的には、とても強い訳だ。

だから、本ソフトの改良は、多分行なわない。
いずれまた気が向けば画像の特徴量をもって対象と類似の
ものを検出する新しいアルゴリズムを搭載したソフトを
別途作るかも知れない。それは改良ではなく、全くの
新しい創造となるから、そちらの志向性の方が強い訳だ。

まあ、だいたい、その新方式の構想は頭の中にはあるが
さらに何ヶ月か、何年か、ちゃんと良く考えて固めないと、
プログラミングには着手できない状態であろう。

・・さて、とは言いつつも、本ソフトをプログラミング
している段階で、その「特徴量」に類似の数値の検出
結果をエクセルの表（というか、.csv形式ファイル）に
出力してはある。
GUI画面上のボタン「RESULT_D」を押す事で、エクセル
(MS Office Excel)が自動的に開き、そのデータを見る事
ができる。
ただし、ここに表示される表データは、「エクセルで開く」
という制限の中で、縦横の２次元のデータ群でしかない。
現状、こうした中間データは６種類出力されているが、
全てを同時に見る手段が（一般的には）無いのだ。
上は、また異なる中間データファイル。

「縦横高さ（XYZ）」の3次元データ位までであれば、
フリーの3次元表示プログラムがあるから、それに対する
XYZのデータを吐き出して噛ませてやれば、簡単に3次元
表示が出来るのだが・・　生憎、本ソフトで扱う次元数は、
それ以上あるし、そもそも、他者のソフトを安易に利用する
手法は、本シリーズ記事では「禁止」とするルールである。
（そんな安直なスタンスでは、新しいものを生み出す事は
できない、という強い持論があるが故の厳しいルールだ）
何かまた、上手い表示方法（次元圧縮等）を考えて、
それで中間データの表示を扱うしかなさそうだ。

さて、「このソフトは鳥以外の物は検出できないのか？」
という点だが、これは実際、鳥以外の何であっても原理的
には検出可能である。
ただ、その際、「精度がどの程度なのか？」が重要な
課題となるだろう。

では、観覧車の写真から、箱（ゴンドラと呼ぶのか？）
を検出してみよう。
何も無い空間を、誤（過剰）検出している。
ただまあ、想定範囲だ。これは最も簡単な検出手法とした
ケースである。

計算時間は余分にかかるが、検出次元を四次元まで上げて
やってみよう、この機能は画面上の「C-Plane」のボタン
にチェックを入れるだけで、その計算手法に変わる。
（注：個々の用語に重要な意味は無い。いずれも全く新しい
概念である為、C-Plane等、新しい用語を使わざるを得ない）
計算結果はバッチリ。
ただし、この状態では何故か「完全一致」となる赤枠が出ず、
全てのゴンドラが水色枠での「よく似ている」の結果にしか
ならない。
計算次元数が高くなると、なかなか完全一致が出ないの
だろうと思われ、検出の強さを調整しないとならないかも
知れない。（まあでも、十分な精度であろう）
上は、種別の異なる被写体が混在している例。

この写真には、「オナガガモ」（尾長鴨）のオスとメス、
および「マガモ」（真鴨）のオスとメスが入り混じって
いる。

この状態で、「オナガガモ」と「マガモ」という種別、
あるいはオスとメスが識別できないだろうか？という実験だ。

上の検出では、「オナガガモ」を対象(TARGET)としているが、
見事に「オナガガモ」だけを拾っている。しかし、メスが
1匹だけ混じってしまっている（画面中央やや左下）

では今度は、「マガモ」を対象(TARGET)としてみる。
こちらは、「マガモ」のオスのみ選ばれたが、ここで
「マガモ」のメス（画面中央）は検出されていない。
なお、こちらの結果を得る為には、高次元検出計算は
していない。
以下、出力画面のコピーを示す。
まあ、なかなか良い識別結果ではあるが、恐らくは、単に
偶然に上手くいっているのであろう・・（汗）

そして、この結果を得る為に、あれこれとパラメーターを
調整しているのだから、これはあまり適切な「操作系」とは
言えず、できれば、そういう手間をかけずとも、完全自動で
処理を行って欲しいし、元々の、本ソフトの開発目的は
「鳥の数を数える」訳だから、鳥の種類まで判別して数える、
というのは、目的外（不要なまでの精度）である。
いやむしろ、「オナガガモ」を指定しても、「マガモ」の
数をも数えてくれるくらいの、ファジー（曖昧）な効果を
期待してしまう訳だ。

だとすれば、まだこのソフトは、だいぶ改善の余地が
あるという結論になる。
上は、本来の本ソフトの目的である多数の鳥のカウント。

頑張って検出してはいるが、やはり鳥のフォルム
（向きや、はばたきの状態）が違うものは未検出と
なっている。（下画像は出力結果の単独表示）
未検出はあるが、ただまあ、ここまでの鳥の数となると
手動で数える（あるいは、野鳥の会や野鳥研究部のように
双眼鏡を見ながらカウンターで計る）のは困難だ。

精度には若干問題があっても、「概算の数」がわかる事は
それなりに意味があるのだろうと思う。
上は、左右で異なる写真を用いて、左側の対象(TARGET)を
右側写真から探した例。
これもまあ、精度不足ではあるが、ある程度は拾えている
状態だと思うし、背景（山や里）の影響も少ない。

---
さて、総括として、本ソフトにおける研究開発の成否
であるが、△（微妙、不明）という結論にしておこう。
バッチリ条件がハマれば高精度ではあるが、それを設定
するのに試行錯誤が必要であるので、本来の目的である
「（簡便に）鳥の数を数える」には、少々不足だ。

・・で、本シリーズ記事での通産成功確率だが、
総合成績＝5勝5負4分け、勝率＝3割5分7厘
となった。

まだ、勝率（研究の成功率）が3割を超えているので
かろうじてOK（目標値は5割、最低値が3割の成功率だ）
だが、そろそろ3割の最低ラインを切りそうな感じ
である（汗）
次のプログラミングは、出来るだけ成功させたいもの
ではあるが、あまり成功率の目標値に拘って、難しい
テーマへのチャレンジ精神を失ってしまっても困る。

場合により、「研究難易度」という評価点も加えて
いくことにしようか？　ちなみに、今回の研究は、
【難易度】＝★★★★（5点満点で4点）
くらいであろうか・・

本ソフトも相当に高難易度ではあるが、もっと難しい
研究テーマも他にあるとは思う。
（例：本シリーズ第3回「高精度ピーキング」や
第5回「ボケ質解析ソフト」等は、より高難易度だ）

----
では、今回のプログラミング記事は、このあたりまで。
次回記事掲載は、例によって不定期としておく。