「プログラミング」シリーズ記事。
本シリーズ記事は2020年度からの小学校プログラミング
教育の実施に関連し、「プログラミングとは、具体的に
どんな作業を行うのか？」という事の説明が、記事の
主旨の１つとなっている。ただし、勿論、小学校教育で
行うプログラミングは初歩的なものであり、本ブログ
シリーズ記事での、「画像処理」（アルゴリズム）を
主眼としたプログラミング作業とは全くの別物である。
これまでの、こうしたプログラミングの関連の記事では、
番外)「比較明合成」ソフトウェア
1)「横浜写真」生成ソフトウェア
2)「擬似紅葉」生成ソフトウェア
を、それぞれプログラミングし、過去記事で紹介している。
なお、全て写真に係わる画像処理のプログラミングであり、
模型やロボットを動かしたりする為のプログラミング作業
とは全く異なるものだ。
で、今回の記事は「ピーキング処理」を行うソフトウェア
（パソコン上で動作するもの）を自作する、という話である。
まず、「ピーキング」とは、近年のミラーレス機等に搭載
されている機能であり、MF（マニュアルフォーカス）の際に
EVFや背面モニターに映る画像の中で、ピントが合っている
部分を、赤色や水色等の線で合成表示する機能の事だ。
![_c0032138_07264403.jpg]()
「輪郭抽出」と呼ばれる事も多いが、厳密には輪郭抽出の
処理と、ピーキングの処理は、かなり内容が異なっている。
この機能を最初にカメラ（ミラーレス機）に搭載したのは、
記憶によれば、2009年のRICOH GXR、あるいは、「その
機種では、まだ精度が未成熟だ」とするならば、実用的な
レベルにおいては2010年に発売されたSONY NEX-3/5が
最初だと思う（下写真はNEX-3）
![_c0032138_07264469.jpg]()
MFでの撮影の比率がとても高い。何故ならば、大口径レンズ、
マクロレンズ、トイレンズ、オールドレンズ、特殊レンズ等を
趣味撮影で使う事が多く、それらのレンズは、最初からMFしか
無いか、又はAFレンズであっても高いピント精度が要求される。
まあ、いくら高性能な新鋭AFでも、AFのみには頼れない。
（＝AFでは、そこまではピント精度が出ていないからだ）
なので、結局はMFで撮るケースが多くなる訳だ。
それと「輪郭」と「ピント」とは、勿論、用語的な意味や
概念が異なる。
だから少し原理がわかっている人であると「ピーキング機能」
の効能に疑問を感じるかも知れない。
「本当に輪郭抽出でピントが合っていると言えるのか？」と・・
でも、前述のようにピーキング処理は単なる輪郭抽出とは
異なるし、元々、この原理を元にミラーレス機や一眼レフの
ライブビューでの「コントラストAF」が作られている訳である
から、「ピーキング」は、ほぼ「ピント」と等価と見なせる。
もし、それを否定しまうと、世の中のコントラストAFの原理を
全否定する事にもなる。まあ用語自体の印象のみから受ける
「懸念」は、忘れた方が賢明であろう。
・・で、その後、2013年頃からは、各社のミラーレス機にも、
たいてい、この機能が搭載されるようになってきた。
私も、その時代からの各社の機体を色々と入手し、様々な
機種でMF撮影を楽しんでいたのだが、しばらく使っていると、
メーカー毎（稀に機種毎）で、ピーキング処理の精度が高い
カメラと、そうで無いカメラが存在する事がわかって来た。
ピーキング精度が低い（ミラーレス）カメラの場合、MF時の
ピント歩留まり（成功率）が、どうしても低下してしまう。
それに、この原理がコントラストAFでのピント検出に使われて
いると思うと、ピーキング精度の悪いカメラは、AF性能もまた
低いような印象を受け、事実、そんな様相もあった。
（よって、2014年前後からのミラーレス機には、像面位相差
AF等の新技術が併用して使われている場合も多い）
で、画面拡大機能と組み合わせる事等を行えば、MF時での
ピーキングの弱点は若干緩和される場合もあるが、面倒なので、
できれば高精度なピーキングであった方が望ましい事は確かだ。
あまりにピーキング精度が低いカメラで、かつEVFの解像度が
低く、さらに画面拡大操作系が劣悪であったりすると、もう
殆ど対処のしようが無い。そんなカメラも中には存在する為、
近年では「連写MFブラケット」という技法を開発していて、
それで撮る事もある。
これはつまり、連写をしながらMFレンズのピント位置を微妙に
ずらして撮影し、後でパソコン画面等で、ピントの合っている
写真を目で見て選ぶ、という単純な技法だ。
（＝「下手な鉄砲、数撃ちゃ当たる」方式、とも言える）
でも、これを行うと、大量に撮った写真の中から選ぶ作業が
手間で非効率となるし、どれがピントが合っているカットなの
かも良くわからない場合すらある。
特に、被写界深度が極めて浅い大口径レンズやマクロレンズに
よる近距離撮影の場合等だ、これらは被写体の中のごく一部の
距離にしかピントが来ない。又、群生の花等の写真では微妙に
ピント位置が異なっていると、作画的な観点においても、どの
写真を選んだら良いのか？の判断も難しくなってしまう訳だ。
![_c0032138_07264463.jpg]()
まちまちなのは、とても気になっている状態だった。
カメラによっては、ピーキングレベル、つまりその効き方を
調整できる機種も多いが、それを設定しても改善されるとは
限らない。これは恐らくピーキングの「アルゴリズム」自体に
差異があり、その性能差（処理内容の差）が精度の差となって
現れてくるのであろう。
「アルゴリズム」とは、色々と意味があるが、画像処理関連
に限って言えば、「画像処理を行う計算の手順」という事だ。
これは、同じ事（例えばピーキング）をやりたい場合でも、
無数の計算方法が考えられる。だからそこにメーカー毎や
開発者毎によって良し悪しが出てくるのも当然の事だ。
なんだか、カメラ側のピーキング処理に信用が置けなくなり、
「自分でもピーキングのアルゴリズムを作れないだろうか？」
と考えるようになった。少し前の2015年頃の事である。
しかし、カメラのピーキング処理の内容は、当然「企業秘密」
である、だから何処にも公開されていない。
たとえば、画像処理に係わる専門書等を読んでも、どこにも
書かれていないのだ。まあ、それは「企業秘密だから」でも
あるが、画像処理の書籍等には、世の中一般に知られている
ごく普通の計算処理のやり方や、その原理しか書いていない。
![_c0032138_07264429.jpg]()
を書く等は「習い事」になってしまうので、あまり好まない。
「習い事」では「新たな創造」は困難であるからだ。
それと、私は「プログラムは全部自分で1から書く」という
事を信条としているのは、毎回のプログラミング関連記事で
書いて来た通りだ。だから、他人の書いたコードは参照したく
無いし、世に公開されている汎用ライブラリ等も使いたくない。
で、長期間、そうした事を続けていけば、中身を全て理解して
いる沢山の自作ソースコードが溜まってきて、その引用も
容易だし、副次的に、画像処理の事にも詳しくなっていく。
まあ、他の例を挙げれば、パソコンやスマホで「漢字変換」を
すれば、どんな難しい漢字でも一瞬で画面に表示されるのだが、
それでは「絶対にその漢字は覚えられない」という話と同じだ。
漢字を覚える為には、自分の手で「漢字書き取り」をしないと
ならない。
私は画像処理プログラミングにおいて、その「漢字書き取り」を
行っていて、その中身をどんどんと覚えようとしている訳だ。
業務上でそれをやるのは非効率的と言えるが、趣味の範疇とか、
自分自身の勉強や研究においては、これはとても有益な措置だ。
----
さて、「ピーキングのアルゴリズムをどう作るか？」という件だ。
上記「漢字書き取り」を十数年間も繰り返して来た事で、
幸いにして画像処理には詳しくなっている、そうであれば
ピーキングを実現するには、どんな処理と、どんな処理とを、
どのように組み合わせれば出来るかもしれない・・ という事は、
だいたい予想がつく、あとはそれを実際に試してみるだけだ。
ここからは「試行錯誤」である、一般にこの作業はとても
大変だ、特に大事なのは「ひらめき、インスピレーション」
といった感覚的な部分が強く要求される事である。
一般に技術者の素養と言えば、最も重要なのは「論理性」だ。
プログラマーの場合には、特にその資質が要求される。
論理的な思考力が無ければ、プログラムは1行たりとも書く
（作る）事はできない。
本年2020年から学校でも「プログラミング教育」が始まると
聞く。でも以前の記事でも書いたが、プログラミングは決して
「習い事」では無いので、子供にPCやプログラミングソフトを
買い与えて、何処かに習いに行かせたとしても、それだけでは、
まずプログラミングは出来ない。必要なのは、物事、あるいは
目的とする結果を成り立たたせる為に、何をするか？の手順を
考える、という「論理性」を持つ事が一番重要なのだ。
（「プログラミング思考」とか、「フローチャートの構築」と
言い換えても良いであろう）
・・で、画像処理の話に戻るが、「画像処理だけ」ならば、
まあ「習い事」や「論理性」の範疇で留まる。しかしながら
「アルゴリズム」を1から作る（発明する）となった場合には
「論理性」だけではどうにもならない。そこに必要なのは
創造性やインスピレーションといった「感覚的」な要素だ。
「技術者」と言うよりは「芸術家」に近い素養であろう。
（例：ピアノを習いに行って、弾けるようになったとしても
作曲や編曲が出来るかどうか？は、また別の才能である）
大企業のカメラメーカーに何千人の技術者が居るのかどうかは
知らないが、アーティストのエンジニアなど、そう何人もは
居ない筈だ。「画像処理エンジンを開発する」ならば、それは
何十人ものエンジニアで行う共同作業であるから、ユーザー個人
では対抗する手段は無いだろうが、「ピーキングのアルゴリズム」
を発明するのであれば、それは「芸術的な職人芸」であろうから、
個人のユーザー側でも十分に対抗する術（すべ）はある。
余談が長くなったが、あれこれと試行錯誤して、ようやくだが
「ピーキング」のアルゴリズムを新たに考え出す事に成功した。
だが、その詳細は残念ながら公開できない。以前の記事でも
書いたが、このレベルの高い専門性を持つ内容は、それ自体が
「知的財産」であり、また、そのアイデアを生み出す為にも
途方も無い努力や発想が必要だからだ。
そう簡単には公開できない事は勿論だし、それは私に限らず、
各カメラメーカーでも、当然ながら、そうしている。
場合により各メーカーからは特許も出願していない事であろう。
何故ならば、特許化する事で必然的に、その内容を公開している
事になってしまうからだ。とても高度なアルゴリズムであれば、
特許を出さなくても、他社（他者）は誰も同じ事は真似できない
だろうし、公開したら、逆にそれをヒントとし、特許を回避して
同じような事をされるかも知れない。だから特許を出して権利を
守ろうとする必要は殆ど無い訳だ。
それと、「技術」とは、そもそも、ある目的を達成する為に
様々にある方法論の1つに過ぎない。だから、その新技術が目的
（今回の場合は、ピント位置を確認する）に適しているか
どうか？ が最も重要であり、その技術そのもののレベルとか
難易度とかは、実用上では、さほど重要な事では無い訳だ。
世間一般では、そのあたりの誤解が大きく、「なんとか」という
新技術が出来たら、その事だけを見て「凄いカメラだ！」とか、
あまりに安易かつ単純に判断してしまう。ここは要注意だ。
（つまり、メーカー側としては、一般ユーザー層が技術開発
の分野に造詣が深く無い事を良い事に、新技術を過剰な迄に
喧伝する。すると、一般層は、簡単にそれに騙されてしまい
高価なカメラやレンズを買わされる訳だ。これはもう完全に
「ユーザーの負け」であり、好ましく無い状態であるが、
新技術を、その内容も理解できずに、必要以上に盲信して
しまうユーザー側にも多大な責任があると思う）
----
さて、自作ピーキングアルゴリズムは、2種類考え出していた。
1つは、立体的な被写体（ボケを含む）に向く処理であり、
これは一般的な「写真」でのピント検出処理に適する。
もう1つは、平面的な画像（ボケ無し）に向く処理だ、こちらは、
工業製品の検査とか学術用など、特別な用途に向く事であろう。
両者は全く異なる方式であり、被写体共通の汎用性は無い、
つまり、平面アルゴリズムでは写真のピーキングは出来ないし
写真用アルゴリズムでは平面被写体での検出精度は出ない。
基本的には、写真用アルゴリズムの方を採用する事としよう、
平面用処理は、また、いつかそれが必要な時もあるかも知れない。
それに、これは撮る写真のスタイルにも強く関連する、
私が撮る写真の多くは、ボケが大きく、被写界深度の浅い
写真ばかりだ、風景写真をパンフォーカスで撮るような
スタイルとは共通性が無く、ピーキングの必要性も各々異なる。
で、2015年頃に、玩具の「USBパソコン接続型顕微鏡」を用いて、
そこから動画を取り込むソフトをC#言語でプログラムして、
そこに自作のピーキング処理を追加してみた。
![_c0032138_07270223.jpg]()
（映っている被写体は「USBメモリー」である）
ピーキングはちゃんと動作している（右下にピーキング付きの
画像が出る。注：ここでは平面処理用アルゴリズムを使用）
そして、ピーキングの精度もなかなか（かなり）良いのだが、
ここで重大な問題点が、2つ発生してしまった。
1つ目は、画像処理が、とても重い（遅い）という事だ。
玩具の顕微鏡は高々30万画素程度なのだが、その画素数でも
ピーキング計算は、1秒あたり2～3コマ程度しか出来ない。
30万画素とは92万ドットであり、カメラでの実際のピーキング
処理は、それより高精細な144万や236万ドットのEVFでも
秒30コマ以上は計算されている、比較にならない遅さだ（汗）
（まあ、カメラでは専用チップで計算しているのであろう）
この状態を技術的には「計算コストがかかり過ぎる」と呼ぶ。
もう1つは、動画の取り込みも汎用ライブラリを使わず、全て
自分でプログラムを書いたのだが、そのどこかに発見しずらい
バグがあって、このソフトを数十分間程度動かしていると、
パソコンが飛んでしまう（プログラムが止まる） 恐らくは
「メモリーリーク」と呼ばれる類のバグであり、何か間違った
処理をしている事を続ける事で、少しづつ問題が溜まっていき
いつかパソコンの能力を超えて止まってしまう訳だ。
ここの原因は、どうしても発見が出きず、解決できなかった。
（まあ、古い形式のWindows内部関数を用いたので、そこが
新しいWindows OSでは上手く動作していない可能性が高い。
こういう点でも「ブラックボックス」の技術は使いたく無い）
その後、数年間、このソフトの事は忘れていた・・（汗）
---
2019年初頭のある日、私は趣味撮影で、被写界深度の浅い
レンズをピーキング性能の低いカメラで使っていた。
ここで用いたのは、前述の「連写MFブラケット」技法だ。
ピントが合っている保証が無ければ「下手な鉄砲も数撃てば
当たる」方式でしか使いようが無い。
しかし、「家に帰ったら、また同じようなカットばかりだと
見るのも嫌だなあ・・・」とも思っていた。
この時、ふと思いついたのが、数年前に考えたピーキングの
アルゴリズム（のソフト）であった。
その試作品は、動画に対してピーキングを掛けるという考え方
であった、まあ、普通のミラーレス機では、EVF内で動画が
リアルタイムに（撮影前に）表示されているので、それと同じ
概念で設計した訳だ。
しかし、もし「撮った後の写真にピーキングが掛けられる」
のであれば、どうなるだろうか？
別に、”撮影前だけ”でピーキングを掛けるという必要性や、
そうでなくてはならない理由は無いのではなかろうか？
・・そう考えて頭の中でイメージしたソフトはこんな感じだ。
![_c0032138_07270200.jpg]()
その各々にピーキング処理を掛けて比較する事を可能とする。
これは、どちらの写真の方が適切か?を選択する際に効果的だ。
ソフトの名前も思いついた。「ツイン・ピークス」だ（笑）
確か20年位前に流行っていた海外ドラマの名前と同じだ（汗）
そのドラマは見ていないのだが（汗）まあ、そもそも本ソフトは
例によって私個人の専用だ、公開する気も販売する気も無い。
なので、好き勝手な名前で作らせてもらおう。
![_c0032138_07271490.jpg]()
手を抜いて仕様書は書いていない（汗） まあ趣味で作る物だし、
仕様のイメージは、既にだいたい固まっているし、そもそも
休日の1日だけで仕上げてしまう「工数」しか確保していない。
なお、使用言語はC#、動作環境は「Windows PC」である。
ちなみに、OSのバージョンやCPUのBIT数は、比較的新しければ
どれであっても、たいてい動く。
で、上図のC#の開発画面上に、ちょいちょいと、ボタンや
ツマミやらの部品を並べていく、このあたりは何も難しくは無い。
![_c0032138_07272202.jpg]()
ボタンを押す、とか、画像をドラッグ＆ドロップする、とか
そういう操作（イベント）の内容に応じて、プログラムの
ソースコードを書いていく。（上図）
ここからは少々大変だ、構造上では簡単なソフトだ、と言っても、
最低限、数千文字程度はプログラムを打ち込まないと完成しない。
特に画像処理の部分は、結構なプログラム量になる。
・・で、このような複雑な画像処理は、私は旧来であれば
C#言語では書かず、別途、汎用性が高いC++言語で計算部
（計算エンジン）のみを作り、両者を合体していたのだが、
その方法だとプログラミング作業が2度手間になってしまう。
（作るのに時間もかかるし、両者の連携も複雑だ）
近年ではC#言語のみでも複雑な画像処理が出来るような手法を
色々と考え出している。まあここも、自分でソースコードを
全て書いている事でのメリットであり、様々な応用が効いたり、
変更や改良が容易であったりする訳だ。
今回、ちょっと問題となったのは3点。1つは、ピーキングの
計算部をC++言語からC#言語に移植する事に、やや手間取った
のと、第二に、画面上にピーキング画像を合成する処理が
なかなか上手くいなかった（やりかたを忘れていた・汗）
3つ目は、あいからわず計算が遅い事だが、この原因の1つ
として、ピーキング色を、水色、赤、白、緑、黄色と
色々と選べる仕様にしていたのが問題であった。
画像処理の計算は1手順あたりで画素数分の計算が必要だ、
その計算の間に、色を選ぶ為のIF文とかSWITCH文を入れて
しまうと、画素数分だけ、つまり数百万回～2000万回位も
それが計算されてしまう（汗）
（もしかすると、旧来、このアルゴリズムが遅かったのも
ここが主因であったのか？）
ここを高速化するならば、一々、IF文とかで分岐せずに、
もう最初から塗る色を選んで準備しておいて、そのデータを
各画素にハメていくしか無い。
まあ、難しくは無い対策だが、ちょっと面倒なので（笑）
「ピーキング色は水色のみ」に仕様をダウングレードする
事とした。
例えば、PANASONICのミラーレス機ではピーキング色は水色
しか出ないが、それらを数年間使っていて「見え難い」と
不満に感じるような被写体状況は殆ど無かったのだ。
これで、だいぶ高速化できた。数百万画素の画像でも、
2秒程度で計算が出来る。（注：あいかわらずリアルタイム
の処理には間に合っていない、まあ計算アルゴリズムが
とても複雑だし、DSP/ISP/FPGA等の専用チップでは無く
PCでの計算なので、やむを得ない）
もう、ほぼ完成だ。ここまで約5時間、色々と手間取った
割には、まずまずのペースであろう。
出来上がった「ツイン・ピークス」を早速試してみる。
![_c0032138_07272745.jpg]()
個別に画像を保存する事も出来るし、入力画像の画素数も
任意だ。画像処理の多くは、入力画素数に応じて、その
効能が変化してしまう場合が多いが（注：空間フィルターの
カーネル/オペレーターの半径が、画素数に影響されやすい）
本アルゴリズムでは、あまり画素数に依存しないように
特殊な手法を考慮（工夫）して作っている。
また、画像入力はドラッグ＆ドロップのみの操作系としたが、
まあそれでも十分だ。
ソフト画面のイメージではなく、単体の画像でも見てみよう。
![_c0032138_07273013.jpg]()
![_c0032138_07273485.jpg]()
調整できるようになっている。最もピーキングを弱くすると
画面内の、本当にピントが来ている、ごく一部にしか表示が
出ない為、マクロや大口径レンズ等の被写界深度の浅い写真
の場合でも「撮影後のピント位置の確認」をする事ができる。
![_c0032138_07274484.jpg]()
![_c0032138_07274477.jpg]()
を掛けて比較する、という感じだったが、どうやら単一の
画像でもピーキングの有り無しで比較する事にも向いてそうだ。
![_c0032138_07274464.jpg]()
撮ったままでは、鴨の群れに対して、被写界深度の奥行きが
どこまで効いているのかよくわからないが、ピーキングを使えば
これが一目瞭然となる。画像を単体で保存してみよう。
![_c0032138_07274434.jpg]()
（アウトフォーカス）である事が、とても良くわかる。
しかし、手前味噌だが（汗） このアルゴリズムは恐ろしく
高精度だ。
できれば、このレベルの精度を持つピーキング機能が各社の
ミラーレス機に搭載されて欲しいのだが、まあ、今のままでは
計算が遅すぎてカメラへは搭載不可能であろう。処理速度と
計算精度を両立させる事は、大変難しいと思う。
が、ここまで精度が良いと、色々試したくなってくる。
例えば、表面がつるっとした被写体で、ピーキングを使おうが
何をしようが、ピント位置が良くわからないケースなどだ。
![_c0032138_07275191.jpg]()
この辺か？」と、アタリをつけて撮ったのだが、この写真に
ピーキング処理をかけてみよう。
![_c0032138_07275575.jpg]()
ちょっとだけ手前にピントが来ている事が明確にわかる。
ただし、つるっとした被写体部ではコントラストの差も殆ど
無い為、ピーキングもなかなか反応しずらいようにはなる。
その場合にはピーキング表示の有無には拘らない方が良い。
まあこの写真はピント位置的にはセーフであると言えるだろう。、
それから、人物写真はどうか？
![_c0032138_07275845.jpg]()
レンズであるし、MFで撮っていたと思うし、目も少し閉じて
いるから非常に難しい撮影だ、これでは近年の「瞳AF機能」
も動作しない事であろうし、数cm程度の被写界深度内で、
被写体や撮影者が微動だにしない、という状況も考え難い。
さて、ここで知りたいのは、ここで、女性の目の距離に
正しくピントが合っているかどうか？だ。
![_c0032138_07280039.jpg]()
まあ、このように、写真の見た目だけではわからないような
微小な差異にも、このアルゴリズムであれば有効だ、という事
になる。
・・であれば、当初の目的通り、沢山のピント位置を変えて
連写した写真（つまり、連写MFブラケット）の場合でも、
その差異は明確に出るだろうか？
![_c0032138_07280698.jpg]()
2枚並んだ写真で、左側の写真が梅の花にジャスピンであり、
右側の写真の場合には、MFブラケットが行き過ぎていて、
左上の奥の枝の距離にピントが行って、梅の花はピンボケだ。
ここで左側の写真のみ取り出してみよう。
![_c0032138_07280622.jpg]()
1m弱くらい、フルサイズ機で僅かにデジタルズームを
掛けている状態だが、ここで被写界深度は、計算上では、
約3cm程度となる、
まあつまり、ピーキングの効く範囲が、この場合に、
3cm程度と思われる奥行き（被写界深度）にピッタリと
対応しているのであれば、精度がとても良い、という感じだ。
だいたいそのレベルに達しているので、このアルゴリズムは
合格と見なす事が出来る。
さらにもう1つ、2枚の写真で、どっちのピントが良いか?
それが見た目だけではわかりにくい例を入力してみよう。
![_c0032138_07281658.jpg]()
浅すぎて、ヒゲのあたりにしかピーキングが来ていない。
右側のネコの写真であれば、顔の部分全体が被写界深度内
となっているので、こちらを選ぶのが良さそうだ。
さて、ここまで精度が出ているのならば、これ以上の
ソフトの改良も殆ど不要であろう・・
このソフトには、ピーキング強度を調整するツマミがあるが、
例えばだが、画面全体でのピーキングの効きを判断し、
その強度を自動的に調整する機能の実現は考えられる。
まあ、それは撮影時であれば、そういう機能は有効だろう、
まずはピントが合った写真が撮りたいからだ。
でも本ソフトのように撮影後にピーキングを掛ける場合では、
ちょっと目的が変わって来る。
例えばピーキングを非常に弱くして、ピンポイントで
ピントの合っている部分を比較したい場合もあるだろう。
そういう目的にも使うならば写真毎に判断基準はまちまちだ、
だから、そいう自動設定などは、おせっかいな機能となる。
（ただし、完全自動では無いのだが、このアルゴリズムの
一部には、画像の特徴を見て、自動的にピーキングの
効き具合を調整する要素が入っている）
あるいは、ソフトフォーカス（軟焦点）レンズ等の特殊な
レンズの写真のピントを判定する事も、自動調整では難しい
だろうと思われる。
![_c0032138_07281662.jpg]()
一般的に、ソフトレンズの場合は、ミラーレス機のピーキング
は効かず、極めて撮影が困難である事が課題だった。
このアルゴリズムならば、ソフトレンズでもなんとか反応して
くれるので、やはりこれ位の精度のピーキングがミラーレス機に
搭載されて欲しい。各メーカーの開発陣に期待するところだ。
像面位相差AF等の新開発も良いが、旧来の技術であっても、
さらにその完成度を高める事は出来る。ゼロから1を生み出す
のはアート感覚が必要とされ、多くの技術者ではそれは難しいが、
1を5にしたり10にしたりする事は、技術屋ならば得意な筈だ。
あるいは機能追加例として、レンズの被写界深度に応じた
ピーキング強度を自動設定するか？だ。 しかしこれは
レンズ焦点距離と絞り値に加えて、撮影距離を入力する
必要がある。カメラ内部で計算するならばAF合焦距離から
計算可能かも知れないが、事後処理では撮影距離はわからず
お手上げであろう、この改良は実現不能だ。
（逆に言えば、一般的に写真掲載時に、絞り値等のデータを
記載してある例も良く見るが、撮影距離が不明であれば、
そのデータを記載する意味があまり無い）
他に機能を追加するならば、例えばだが、連続して計算して、
ピントの合っているものだけを選び出す、という処理も
理論的には出来そうなのだが・・ それをやってしまうと、
「じゃあ、被写体のどこにピントが合っているのが？
それは、良い写真（撮りたかった写真）なのか？」
という判断となり、それはコンピューターには少々無理だ。
まあ、そこも流行のAI（人工知能）を使えば出来なくは
なさそうなのだが、AI化を行うには、膨大な「教師データ」
が必要となる。つまり、例えば、私が数十万枚の写真を撮り
そこでピントが合っている位置をすべて調べ、そこから
「これは合格。これは不合格」といった判断（アノテーション）
を一通りして、その根拠を示しながらAIに学習させなければ
ならない。
そうする事は、そもそも非常に大変な作業であるし・・
無事、それらをコンピューターに覚えこませたとしても、
では、また全く新しい構図の写真が出てきた際、その構図に
おいて、撮影者は、どんな意図で、構図上のどこにピントを
合わせようとしたのか？ そこまでは、さすがのAIでも
判断不能であろう・・
特に私の撮る写真は「主要被写体の逆転」という技法も良く
使っている、これは例えば、綺麗で主役となるべき風景やら
建物があるのに、あえてそれは背景としてボカしてしまい、
手前の「しょうも無いもの」（汗）に、ピントを合わせたり
する技法だ。（＝「浮世絵」等で良くある構図パターンだ）
そんな写真まで、AIに「学習」させてしまったら、
「とんでも無く偏屈なAI」が出来上がってしまう（汗）
・・まあ、さすがにそういうモノは欲しくないので（笑）
やはりここは人間がチマチマと1枚1枚の写真を見ていくしか
なさそうだ。仮にAIであっても「感情や感性」を持つには、
まだまだ時代や技術は未成熟だ、という感じであろう。
---
さて、今回の記事はこのあたりまでで。
プログラミングを趣味で行うケースはあまり無いとは思うし、
こういう主旨でシリーズ化の記事を構成する事も困難だが、
今後また何か変わったソフトを作る事があれば、その時に、
また記事で紹介しよう。
本シリーズ記事は2020年度からの小学校プログラミング
教育の実施に関連し、「プログラミングとは、具体的に
どんな作業を行うのか？」という事の説明が、記事の
主旨の１つとなっている。ただし、勿論、小学校教育で
行うプログラミングは初歩的なものであり、本ブログ
シリーズ記事での、「画像処理」（アルゴリズム）を
主眼としたプログラミング作業とは全くの別物である。
これまでの、こうしたプログラミングの関連の記事では、
番外)「比較明合成」ソフトウェア
1)「横浜写真」生成ソフトウェア
2)「擬似紅葉」生成ソフトウェア
を、それぞれプログラミングし、過去記事で紹介している。
なお、全て写真に係わる画像処理のプログラミングであり、
模型やロボットを動かしたりする為のプログラミング作業
とは全く異なるものだ。
で、今回の記事は「ピーキング処理」を行うソフトウェア
（パソコン上で動作するもの）を自作する、という話である。
まず、「ピーキング」とは、近年のミラーレス機等に搭載
されている機能であり、MF（マニュアルフォーカス）の際に
EVFや背面モニターに映る画像の中で、ピントが合っている
部分を、赤色や水色等の線で合成表示する機能の事だ。
「輪郭抽出」と呼ばれる事も多いが、厳密には輪郭抽出の
処理と、ピーキングの処理は、かなり内容が異なっている。
この機能を最初にカメラ（ミラーレス機）に搭載したのは、
記憶によれば、2009年のRICOH GXR、あるいは、「その
機種では、まだ精度が未成熟だ」とするならば、実用的な
レベルにおいては2010年に発売されたSONY NEX-3/5が
最初だと思う（下写真はNEX-3）
MFでの撮影の比率がとても高い。何故ならば、大口径レンズ、
マクロレンズ、トイレンズ、オールドレンズ、特殊レンズ等を
趣味撮影で使う事が多く、それらのレンズは、最初からMFしか
無いか、又はAFレンズであっても高いピント精度が要求される。
まあ、いくら高性能な新鋭AFでも、AFのみには頼れない。
（＝AFでは、そこまではピント精度が出ていないからだ）
なので、結局はMFで撮るケースが多くなる訳だ。
それと「輪郭」と「ピント」とは、勿論、用語的な意味や
概念が異なる。
だから少し原理がわかっている人であると「ピーキング機能」
の効能に疑問を感じるかも知れない。
「本当に輪郭抽出でピントが合っていると言えるのか？」と・・
でも、前述のようにピーキング処理は単なる輪郭抽出とは
異なるし、元々、この原理を元にミラーレス機や一眼レフの
ライブビューでの「コントラストAF」が作られている訳である
から、「ピーキング」は、ほぼ「ピント」と等価と見なせる。
もし、それを否定しまうと、世の中のコントラストAFの原理を
全否定する事にもなる。まあ用語自体の印象のみから受ける
「懸念」は、忘れた方が賢明であろう。
・・で、その後、2013年頃からは、各社のミラーレス機にも、
たいてい、この機能が搭載されるようになってきた。
私も、その時代からの各社の機体を色々と入手し、様々な
機種でMF撮影を楽しんでいたのだが、しばらく使っていると、
メーカー毎（稀に機種毎）で、ピーキング処理の精度が高い
カメラと、そうで無いカメラが存在する事がわかって来た。
ピーキング精度が低い（ミラーレス）カメラの場合、MF時の
ピント歩留まり（成功率）が、どうしても低下してしまう。
それに、この原理がコントラストAFでのピント検出に使われて
いると思うと、ピーキング精度の悪いカメラは、AF性能もまた
低いような印象を受け、事実、そんな様相もあった。
（よって、2014年前後からのミラーレス機には、像面位相差
AF等の新技術が併用して使われている場合も多い）
で、画面拡大機能と組み合わせる事等を行えば、MF時での
ピーキングの弱点は若干緩和される場合もあるが、面倒なので、
できれば高精度なピーキングであった方が望ましい事は確かだ。
あまりにピーキング精度が低いカメラで、かつEVFの解像度が
低く、さらに画面拡大操作系が劣悪であったりすると、もう
殆ど対処のしようが無い。そんなカメラも中には存在する為、
近年では「連写MFブラケット」という技法を開発していて、
それで撮る事もある。
これはつまり、連写をしながらMFレンズのピント位置を微妙に
ずらして撮影し、後でパソコン画面等で、ピントの合っている
写真を目で見て選ぶ、という単純な技法だ。
（＝「下手な鉄砲、数撃ちゃ当たる」方式、とも言える）
でも、これを行うと、大量に撮った写真の中から選ぶ作業が
手間で非効率となるし、どれがピントが合っているカットなの
かも良くわからない場合すらある。
特に、被写界深度が極めて浅い大口径レンズやマクロレンズに
よる近距離撮影の場合等だ、これらは被写体の中のごく一部の
距離にしかピントが来ない。又、群生の花等の写真では微妙に
ピント位置が異なっていると、作画的な観点においても、どの
写真を選んだら良いのか？の判断も難しくなってしまう訳だ。
まちまちなのは、とても気になっている状態だった。
カメラによっては、ピーキングレベル、つまりその効き方を
調整できる機種も多いが、それを設定しても改善されるとは
限らない。これは恐らくピーキングの「アルゴリズム」自体に
差異があり、その性能差（処理内容の差）が精度の差となって
現れてくるのであろう。
「アルゴリズム」とは、色々と意味があるが、画像処理関連
に限って言えば、「画像処理を行う計算の手順」という事だ。
これは、同じ事（例えばピーキング）をやりたい場合でも、
無数の計算方法が考えられる。だからそこにメーカー毎や
開発者毎によって良し悪しが出てくるのも当然の事だ。
なんだか、カメラ側のピーキング処理に信用が置けなくなり、
「自分でもピーキングのアルゴリズムを作れないだろうか？」
と考えるようになった。少し前の2015年頃の事である。
しかし、カメラのピーキング処理の内容は、当然「企業秘密」
である、だから何処にも公開されていない。
たとえば、画像処理に係わる専門書等を読んでも、どこにも
書かれていないのだ。まあ、それは「企業秘密だから」でも
あるが、画像処理の書籍等には、世の中一般に知られている
ごく普通の計算処理のやり方や、その原理しか書いていない。
を書く等は「習い事」になってしまうので、あまり好まない。
「習い事」では「新たな創造」は困難であるからだ。
それと、私は「プログラムは全部自分で1から書く」という
事を信条としているのは、毎回のプログラミング関連記事で
書いて来た通りだ。だから、他人の書いたコードは参照したく
無いし、世に公開されている汎用ライブラリ等も使いたくない。
で、長期間、そうした事を続けていけば、中身を全て理解して
いる沢山の自作ソースコードが溜まってきて、その引用も
容易だし、副次的に、画像処理の事にも詳しくなっていく。
まあ、他の例を挙げれば、パソコンやスマホで「漢字変換」を
すれば、どんな難しい漢字でも一瞬で画面に表示されるのだが、
それでは「絶対にその漢字は覚えられない」という話と同じだ。
漢字を覚える為には、自分の手で「漢字書き取り」をしないと
ならない。
私は画像処理プログラミングにおいて、その「漢字書き取り」を
行っていて、その中身をどんどんと覚えようとしている訳だ。
業務上でそれをやるのは非効率的と言えるが、趣味の範疇とか、
自分自身の勉強や研究においては、これはとても有益な措置だ。
----
さて、「ピーキングのアルゴリズムをどう作るか？」という件だ。
上記「漢字書き取り」を十数年間も繰り返して来た事で、
幸いにして画像処理には詳しくなっている、そうであれば
ピーキングを実現するには、どんな処理と、どんな処理とを、
どのように組み合わせれば出来るかもしれない・・ という事は、
だいたい予想がつく、あとはそれを実際に試してみるだけだ。
ここからは「試行錯誤」である、一般にこの作業はとても
大変だ、特に大事なのは「ひらめき、インスピレーション」
といった感覚的な部分が強く要求される事である。
一般に技術者の素養と言えば、最も重要なのは「論理性」だ。
プログラマーの場合には、特にその資質が要求される。
論理的な思考力が無ければ、プログラムは1行たりとも書く
（作る）事はできない。
本年2020年から学校でも「プログラミング教育」が始まると
聞く。でも以前の記事でも書いたが、プログラミングは決して
「習い事」では無いので、子供にPCやプログラミングソフトを
買い与えて、何処かに習いに行かせたとしても、それだけでは、
まずプログラミングは出来ない。必要なのは、物事、あるいは
目的とする結果を成り立たたせる為に、何をするか？の手順を
考える、という「論理性」を持つ事が一番重要なのだ。
（「プログラミング思考」とか、「フローチャートの構築」と
言い換えても良いであろう）
・・で、画像処理の話に戻るが、「画像処理だけ」ならば、
まあ「習い事」や「論理性」の範疇で留まる。しかしながら
「アルゴリズム」を1から作る（発明する）となった場合には
「論理性」だけではどうにもならない。そこに必要なのは
創造性やインスピレーションといった「感覚的」な要素だ。
「技術者」と言うよりは「芸術家」に近い素養であろう。
（例：ピアノを習いに行って、弾けるようになったとしても
作曲や編曲が出来るかどうか？は、また別の才能である）
大企業のカメラメーカーに何千人の技術者が居るのかどうかは
知らないが、アーティストのエンジニアなど、そう何人もは
居ない筈だ。「画像処理エンジンを開発する」ならば、それは
何十人ものエンジニアで行う共同作業であるから、ユーザー個人
では対抗する手段は無いだろうが、「ピーキングのアルゴリズム」
を発明するのであれば、それは「芸術的な職人芸」であろうから、
個人のユーザー側でも十分に対抗する術（すべ）はある。
余談が長くなったが、あれこれと試行錯誤して、ようやくだが
「ピーキング」のアルゴリズムを新たに考え出す事に成功した。
だが、その詳細は残念ながら公開できない。以前の記事でも
書いたが、このレベルの高い専門性を持つ内容は、それ自体が
「知的財産」であり、また、そのアイデアを生み出す為にも
途方も無い努力や発想が必要だからだ。
そう簡単には公開できない事は勿論だし、それは私に限らず、
各カメラメーカーでも、当然ながら、そうしている。
場合により各メーカーからは特許も出願していない事であろう。
何故ならば、特許化する事で必然的に、その内容を公開している
事になってしまうからだ。とても高度なアルゴリズムであれば、
特許を出さなくても、他社（他者）は誰も同じ事は真似できない
だろうし、公開したら、逆にそれをヒントとし、特許を回避して
同じような事をされるかも知れない。だから特許を出して権利を
守ろうとする必要は殆ど無い訳だ。
それと、「技術」とは、そもそも、ある目的を達成する為に
様々にある方法論の1つに過ぎない。だから、その新技術が目的
（今回の場合は、ピント位置を確認する）に適しているか
どうか？ が最も重要であり、その技術そのもののレベルとか
難易度とかは、実用上では、さほど重要な事では無い訳だ。
世間一般では、そのあたりの誤解が大きく、「なんとか」という
新技術が出来たら、その事だけを見て「凄いカメラだ！」とか、
あまりに安易かつ単純に判断してしまう。ここは要注意だ。
（つまり、メーカー側としては、一般ユーザー層が技術開発
の分野に造詣が深く無い事を良い事に、新技術を過剰な迄に
喧伝する。すると、一般層は、簡単にそれに騙されてしまい
高価なカメラやレンズを買わされる訳だ。これはもう完全に
「ユーザーの負け」であり、好ましく無い状態であるが、
新技術を、その内容も理解できずに、必要以上に盲信して
しまうユーザー側にも多大な責任があると思う）
----
さて、自作ピーキングアルゴリズムは、2種類考え出していた。
1つは、立体的な被写体（ボケを含む）に向く処理であり、
これは一般的な「写真」でのピント検出処理に適する。
もう1つは、平面的な画像（ボケ無し）に向く処理だ、こちらは、
工業製品の検査とか学術用など、特別な用途に向く事であろう。
両者は全く異なる方式であり、被写体共通の汎用性は無い、
つまり、平面アルゴリズムでは写真のピーキングは出来ないし
写真用アルゴリズムでは平面被写体での検出精度は出ない。
基本的には、写真用アルゴリズムの方を採用する事としよう、
平面用処理は、また、いつかそれが必要な時もあるかも知れない。
それに、これは撮る写真のスタイルにも強く関連する、
私が撮る写真の多くは、ボケが大きく、被写界深度の浅い
写真ばかりだ、風景写真をパンフォーカスで撮るような
スタイルとは共通性が無く、ピーキングの必要性も各々異なる。
で、2015年頃に、玩具の「USBパソコン接続型顕微鏡」を用いて、
そこから動画を取り込むソフトをC#言語でプログラムして、
そこに自作のピーキング処理を追加してみた。
（映っている被写体は「USBメモリー」である）
ピーキングはちゃんと動作している（右下にピーキング付きの
画像が出る。注：ここでは平面処理用アルゴリズムを使用）
そして、ピーキングの精度もなかなか（かなり）良いのだが、
ここで重大な問題点が、2つ発生してしまった。
1つ目は、画像処理が、とても重い（遅い）という事だ。
玩具の顕微鏡は高々30万画素程度なのだが、その画素数でも
ピーキング計算は、1秒あたり2～3コマ程度しか出来ない。
30万画素とは92万ドットであり、カメラでの実際のピーキング
処理は、それより高精細な144万や236万ドットのEVFでも
秒30コマ以上は計算されている、比較にならない遅さだ（汗）
（まあ、カメラでは専用チップで計算しているのであろう）
この状態を技術的には「計算コストがかかり過ぎる」と呼ぶ。
もう1つは、動画の取り込みも汎用ライブラリを使わず、全て
自分でプログラムを書いたのだが、そのどこかに発見しずらい
バグがあって、このソフトを数十分間程度動かしていると、
パソコンが飛んでしまう（プログラムが止まる） 恐らくは
「メモリーリーク」と呼ばれる類のバグであり、何か間違った
処理をしている事を続ける事で、少しづつ問題が溜まっていき
いつかパソコンの能力を超えて止まってしまう訳だ。
ここの原因は、どうしても発見が出きず、解決できなかった。
（まあ、古い形式のWindows内部関数を用いたので、そこが
新しいWindows OSでは上手く動作していない可能性が高い。
こういう点でも「ブラックボックス」の技術は使いたく無い）
その後、数年間、このソフトの事は忘れていた・・（汗）
---
2019年初頭のある日、私は趣味撮影で、被写界深度の浅い
レンズをピーキング性能の低いカメラで使っていた。
ここで用いたのは、前述の「連写MFブラケット」技法だ。
ピントが合っている保証が無ければ「下手な鉄砲も数撃てば
当たる」方式でしか使いようが無い。
しかし、「家に帰ったら、また同じようなカットばかりだと
見るのも嫌だなあ・・・」とも思っていた。
この時、ふと思いついたのが、数年前に考えたピーキングの
アルゴリズム（のソフト）であった。
その試作品は、動画に対してピーキングを掛けるという考え方
であった、まあ、普通のミラーレス機では、EVF内で動画が
リアルタイムに（撮影前に）表示されているので、それと同じ
概念で設計した訳だ。
しかし、もし「撮った後の写真にピーキングが掛けられる」
のであれば、どうなるだろうか？
別に、”撮影前だけ”でピーキングを掛けるという必要性や、
そうでなくてはならない理由は無いのではなかろうか？
・・そう考えて頭の中でイメージしたソフトはこんな感じだ。
その各々にピーキング処理を掛けて比較する事を可能とする。
これは、どちらの写真の方が適切か?を選択する際に効果的だ。
ソフトの名前も思いついた。「ツイン・ピークス」だ（笑）
確か20年位前に流行っていた海外ドラマの名前と同じだ（汗）
そのドラマは見ていないのだが（汗）まあ、そもそも本ソフトは
例によって私個人の専用だ、公開する気も販売する気も無い。
なので、好き勝手な名前で作らせてもらおう。
手を抜いて仕様書は書いていない（汗） まあ趣味で作る物だし、
仕様のイメージは、既にだいたい固まっているし、そもそも
休日の1日だけで仕上げてしまう「工数」しか確保していない。
なお、使用言語はC#、動作環境は「Windows PC」である。
ちなみに、OSのバージョンやCPUのBIT数は、比較的新しければ
どれであっても、たいてい動く。
で、上図のC#の開発画面上に、ちょいちょいと、ボタンや
ツマミやらの部品を並べていく、このあたりは何も難しくは無い。
ボタンを押す、とか、画像をドラッグ＆ドロップする、とか
そういう操作（イベント）の内容に応じて、プログラムの
ソースコードを書いていく。（上図）
ここからは少々大変だ、構造上では簡単なソフトだ、と言っても、
最低限、数千文字程度はプログラムを打ち込まないと完成しない。
特に画像処理の部分は、結構なプログラム量になる。
・・で、このような複雑な画像処理は、私は旧来であれば
C#言語では書かず、別途、汎用性が高いC++言語で計算部
（計算エンジン）のみを作り、両者を合体していたのだが、
その方法だとプログラミング作業が2度手間になってしまう。
（作るのに時間もかかるし、両者の連携も複雑だ）
近年ではC#言語のみでも複雑な画像処理が出来るような手法を
色々と考え出している。まあここも、自分でソースコードを
全て書いている事でのメリットであり、様々な応用が効いたり、
変更や改良が容易であったりする訳だ。
今回、ちょっと問題となったのは3点。1つは、ピーキングの
計算部をC++言語からC#言語に移植する事に、やや手間取った
のと、第二に、画面上にピーキング画像を合成する処理が
なかなか上手くいなかった（やりかたを忘れていた・汗）
3つ目は、あいからわず計算が遅い事だが、この原因の1つ
として、ピーキング色を、水色、赤、白、緑、黄色と
色々と選べる仕様にしていたのが問題であった。
画像処理の計算は1手順あたりで画素数分の計算が必要だ、
その計算の間に、色を選ぶ為のIF文とかSWITCH文を入れて
しまうと、画素数分だけ、つまり数百万回～2000万回位も
それが計算されてしまう（汗）
（もしかすると、旧来、このアルゴリズムが遅かったのも
ここが主因であったのか？）
ここを高速化するならば、一々、IF文とかで分岐せずに、
もう最初から塗る色を選んで準備しておいて、そのデータを
各画素にハメていくしか無い。
まあ、難しくは無い対策だが、ちょっと面倒なので（笑）
「ピーキング色は水色のみ」に仕様をダウングレードする
事とした。
例えば、PANASONICのミラーレス機ではピーキング色は水色
しか出ないが、それらを数年間使っていて「見え難い」と
不満に感じるような被写体状況は殆ど無かったのだ。
これで、だいぶ高速化できた。数百万画素の画像でも、
2秒程度で計算が出来る。（注：あいかわらずリアルタイム
の処理には間に合っていない、まあ計算アルゴリズムが
とても複雑だし、DSP/ISP/FPGA等の専用チップでは無く
PCでの計算なので、やむを得ない）
もう、ほぼ完成だ。ここまで約5時間、色々と手間取った
割には、まずまずのペースであろう。
出来上がった「ツイン・ピークス」を早速試してみる。
個別に画像を保存する事も出来るし、入力画像の画素数も
任意だ。画像処理の多くは、入力画素数に応じて、その
効能が変化してしまう場合が多いが（注：空間フィルターの
カーネル/オペレーターの半径が、画素数に影響されやすい）
本アルゴリズムでは、あまり画素数に依存しないように
特殊な手法を考慮（工夫）して作っている。
また、画像入力はドラッグ＆ドロップのみの操作系としたが、
まあそれでも十分だ。
ソフト画面のイメージではなく、単体の画像でも見てみよう。
調整できるようになっている。最もピーキングを弱くすると
画面内の、本当にピントが来ている、ごく一部にしか表示が
出ない為、マクロや大口径レンズ等の被写界深度の浅い写真
の場合でも「撮影後のピント位置の確認」をする事ができる。
を掛けて比較する、という感じだったが、どうやら単一の
画像でもピーキングの有り無しで比較する事にも向いてそうだ。
撮ったままでは、鴨の群れに対して、被写界深度の奥行きが
どこまで効いているのかよくわからないが、ピーキングを使えば
これが一目瞭然となる。画像を単体で保存してみよう。
（アウトフォーカス）である事が、とても良くわかる。
しかし、手前味噌だが（汗） このアルゴリズムは恐ろしく
高精度だ。
できれば、このレベルの精度を持つピーキング機能が各社の
ミラーレス機に搭載されて欲しいのだが、まあ、今のままでは
計算が遅すぎてカメラへは搭載不可能であろう。処理速度と
計算精度を両立させる事は、大変難しいと思う。
が、ここまで精度が良いと、色々試したくなってくる。
例えば、表面がつるっとした被写体で、ピーキングを使おうが
何をしようが、ピント位置が良くわからないケースなどだ。
この辺か？」と、アタリをつけて撮ったのだが、この写真に
ピーキング処理をかけてみよう。
ちょっとだけ手前にピントが来ている事が明確にわかる。
ただし、つるっとした被写体部ではコントラストの差も殆ど
無い為、ピーキングもなかなか反応しずらいようにはなる。
その場合にはピーキング表示の有無には拘らない方が良い。
まあこの写真はピント位置的にはセーフであると言えるだろう。、
それから、人物写真はどうか？
レンズであるし、MFで撮っていたと思うし、目も少し閉じて
いるから非常に難しい撮影だ、これでは近年の「瞳AF機能」
も動作しない事であろうし、数cm程度の被写界深度内で、
被写体や撮影者が微動だにしない、という状況も考え難い。
さて、ここで知りたいのは、ここで、女性の目の距離に
正しくピントが合っているかどうか？だ。
まあ、このように、写真の見た目だけではわからないような
微小な差異にも、このアルゴリズムであれば有効だ、という事
になる。
・・であれば、当初の目的通り、沢山のピント位置を変えて
連写した写真（つまり、連写MFブラケット）の場合でも、
その差異は明確に出るだろうか？
2枚並んだ写真で、左側の写真が梅の花にジャスピンであり、
右側の写真の場合には、MFブラケットが行き過ぎていて、
左上の奥の枝の距離にピントが行って、梅の花はピンボケだ。
ここで左側の写真のみ取り出してみよう。
1m弱くらい、フルサイズ機で僅かにデジタルズームを
掛けている状態だが、ここで被写界深度は、計算上では、
約3cm程度となる、
まあつまり、ピーキングの効く範囲が、この場合に、
3cm程度と思われる奥行き（被写界深度）にピッタリと
対応しているのであれば、精度がとても良い、という感じだ。
だいたいそのレベルに達しているので、このアルゴリズムは
合格と見なす事が出来る。
さらにもう1つ、2枚の写真で、どっちのピントが良いか?
それが見た目だけではわかりにくい例を入力してみよう。
浅すぎて、ヒゲのあたりにしかピーキングが来ていない。
右側のネコの写真であれば、顔の部分全体が被写界深度内
となっているので、こちらを選ぶのが良さそうだ。
さて、ここまで精度が出ているのならば、これ以上の
ソフトの改良も殆ど不要であろう・・
このソフトには、ピーキング強度を調整するツマミがあるが、
例えばだが、画面全体でのピーキングの効きを判断し、
その強度を自動的に調整する機能の実現は考えられる。
まあ、それは撮影時であれば、そういう機能は有効だろう、
まずはピントが合った写真が撮りたいからだ。
でも本ソフトのように撮影後にピーキングを掛ける場合では、
ちょっと目的が変わって来る。
例えばピーキングを非常に弱くして、ピンポイントで
ピントの合っている部分を比較したい場合もあるだろう。
そういう目的にも使うならば写真毎に判断基準はまちまちだ、
だから、そいう自動設定などは、おせっかいな機能となる。
（ただし、完全自動では無いのだが、このアルゴリズムの
一部には、画像の特徴を見て、自動的にピーキングの
効き具合を調整する要素が入っている）
あるいは、ソフトフォーカス（軟焦点）レンズ等の特殊な
レンズの写真のピントを判定する事も、自動調整では難しい
だろうと思われる。
一般的に、ソフトレンズの場合は、ミラーレス機のピーキング
は効かず、極めて撮影が困難である事が課題だった。
このアルゴリズムならば、ソフトレンズでもなんとか反応して
くれるので、やはりこれ位の精度のピーキングがミラーレス機に
搭載されて欲しい。各メーカーの開発陣に期待するところだ。
像面位相差AF等の新開発も良いが、旧来の技術であっても、
さらにその完成度を高める事は出来る。ゼロから1を生み出す
のはアート感覚が必要とされ、多くの技術者ではそれは難しいが、
1を5にしたり10にしたりする事は、技術屋ならば得意な筈だ。
あるいは機能追加例として、レンズの被写界深度に応じた
ピーキング強度を自動設定するか？だ。 しかしこれは
レンズ焦点距離と絞り値に加えて、撮影距離を入力する
必要がある。カメラ内部で計算するならばAF合焦距離から
計算可能かも知れないが、事後処理では撮影距離はわからず
お手上げであろう、この改良は実現不能だ。
（逆に言えば、一般的に写真掲載時に、絞り値等のデータを
記載してある例も良く見るが、撮影距離が不明であれば、
そのデータを記載する意味があまり無い）
他に機能を追加するならば、例えばだが、連続して計算して、
ピントの合っているものだけを選び出す、という処理も
理論的には出来そうなのだが・・ それをやってしまうと、
「じゃあ、被写体のどこにピントが合っているのが？
それは、良い写真（撮りたかった写真）なのか？」
という判断となり、それはコンピューターには少々無理だ。
まあ、そこも流行のAI（人工知能）を使えば出来なくは
なさそうなのだが、AI化を行うには、膨大な「教師データ」
が必要となる。つまり、例えば、私が数十万枚の写真を撮り
そこでピントが合っている位置をすべて調べ、そこから
「これは合格。これは不合格」といった判断（アノテーション）
を一通りして、その根拠を示しながらAIに学習させなければ
ならない。
そうする事は、そもそも非常に大変な作業であるし・・
無事、それらをコンピューターに覚えこませたとしても、
では、また全く新しい構図の写真が出てきた際、その構図に
おいて、撮影者は、どんな意図で、構図上のどこにピントを
合わせようとしたのか？ そこまでは、さすがのAIでも
判断不能であろう・・
特に私の撮る写真は「主要被写体の逆転」という技法も良く
使っている、これは例えば、綺麗で主役となるべき風景やら
建物があるのに、あえてそれは背景としてボカしてしまい、
手前の「しょうも無いもの」（汗）に、ピントを合わせたり
する技法だ。（＝「浮世絵」等で良くある構図パターンだ）
そんな写真まで、AIに「学習」させてしまったら、
「とんでも無く偏屈なAI」が出来上がってしまう（汗）
・・まあ、さすがにそういうモノは欲しくないので（笑）
やはりここは人間がチマチマと1枚1枚の写真を見ていくしか
なさそうだ。仮にAIであっても「感情や感性」を持つには、
まだまだ時代や技術は未成熟だ、という感じであろう。
---
さて、今回の記事はこのあたりまでで。
プログラミングを趣味で行うケースはあまり無いとは思うし、
こういう主旨でシリーズ化の記事を構成する事も困難だが、
今後また何か変わったソフトを作る事があれば、その時に、
また記事で紹介しよう。