「画像処理プログラミング」シリーズ第10回記事。
![_c0032138_19565368.jpg]()
デジタル画像のピクセル毎に、数学的な計算処理をPC等で
行い、検出、抽出、診断、判断、変換、加工等を行う為の
技術（テクノロジー）の事である。
ここでデジタル画像には、静止画と動画、二次元や三次元等
の様々な区分があり得るが、本シリーズ記事では対象として
「二次元静止画・画像処理プログラミング」に限定する。
なお、Photoshop等の画像編集（レタッチ）ソフトを用いて、
画像を手動で加工する「技能」については、「画像編集」
と呼んでいて、「画像処理」とは明確に区別している。
（注：世間一般では、テクノロジーの方の「画像処理」は、
殆ど理解されていない為、多くのカメラマンや画像関連職業
の人達は、「画像編集」の事を「画像処理」と呼んでいるが、
その混乱を避ける為、本ブログでは定義を明確化している。
理解されていない理由は、これが専門的な技術分野であり
高度で難解である事も確かだが、本記事で色々と説明する
ように、この技術分野が未発達である事も原因であろう）
本シリーズ記事では、前者の「画像処理」を実現する
ソフトウェア（アプリケーション）を、完全独自で開発
する事を主眼としている。
ここで「完全独自」とは、「外部ライブラリ（OpenCV等）
一切使用禁止」「他者のソースコード引用禁止」という
制限で、OS(.NET)に用意されている関数モジュール等を除き、
全てのプログラムやアルゴリズム（≒計算手順）を全部
自力で考案し、それを自分で打ち込む（プログラミング
する）という意味である。
何で、そんな非効率的な事をやっているのか？と言えば、
「世の中に無い、全くの新しいものを生み出す」（創造する）
目的があるからで、その為には、まず、あらゆる「人真似」
を排除する事が必須だ、と思っているからだ。
（つまり人真似や「習い事」では、新しい事は得られない）
この開発作業は、完全な自身の為の「趣味」であるので、
完成したプログラムを販売・公開・頒布等は一切しない。
また、画像処理アルゴリズムの内容は、非常に高度かつ、
新規性の高いものである場合も多く、これは「知的財産」に
相当するが、これの特許化や、IPコア化（＝Intellectual
Property Core：画像処理LSI等に、まとまった機能と
して埋め込む事）も一切しない。
要は、完全に趣味の範疇の作業であり、自身の知的好奇心
を満たしながら、スキルアップする為のものである。
こういう作業をブログ記事で公開する理由は、「このように
考えながらプログラミングを行う」というサンプル的手順を
公開する為であり、世の中における「プログラミング学習」
というものが、単なる「プログラミング言語の文法の習得」
であったり、「特定の動作環境でロボット等の機器の動作の
条件をプログラムする」といった、非常に狭い視点での
「常識」への警鐘の意味もある。（つまり「プログラミング
とは、習い事では無い！」という事を説明する為の記事だ）
![_c0032138_19565351.jpg]()
ややこしい、まず順を追って説明していこう。
本シリーズ第5回「ボケ質解析ソフトのプログラミング」
の記事において・・・ (上写真のソフトウェア）
そのソフトでは「写真用レンズのボケ質の良し悪し」を、
ある程度（完璧では無いが）解析する事が可能であった。
様々な写真用レンズに「ボケ質」の良否が存在する事は
銀塩時代の昔から、中上級マニア層等においては常識と
して知られていた。
まあ、銀塩時代のMF一眼レフ等では、50mm/F1.4級の
標準レンズがキット（セット）で販売されていたので、
そうした大口径レンズであれば、多くの撮影条件において
多大な背景/前景ボケを得る事が出来た。（＝すなわち、
被写界深度が浅い状態を、誰でも簡便に得る事が出来た）
だが、近年においては初めてカメラを買う際にキットと
して付属してくるレンズは、標準ズーム等になっていて
ビギナー層等のユーザーでは
ビ「絞りの値を変えても、写真の教科書等に載っている
ようには背景が上手くボケ無い・・・」
という疑問や課題を良く口にしている。
近年でのカメラ/交換レンズ市場の縮退により、大口径
の交換レンズを購入するユーザー層もかなり減ってきて、
そもそも多大な「ボケ量」を得るような撮影機材環境を
持つユーザー数が少ない。ましてや、背景等をボカした
際での「ボケ質」等に言及できるマニア層も相当に減り、
現代では、中上級マニア層や上級層以上あたりで無いと、
「レンズのボケ質に良否がある」という事実を認識して
いないかも知れ無い。（そもそも「ボケ質」という
ちゃんとした定義も広まっておらず、あえて「ボケ味」
という曖昧な表現をされている場合すら、多々ある）
まあ、そんな状況もあって、以前に「ボケ質解析ソフト」
の完全自力開発に着手した次第であった。
つまり、ユーザー（消費者）側が、全体的にスキルダウン
してしまっている為、例えば、メーカー側や流通側が、
「このレンズはボケ味が良いのです」等と言って来たら
「はいそうですか、では買います（買いません）」等と
購入側の主体性が無い選択をせざるを得なくなってしまう。
それは「ユーザー（消費者）の負け」と、私が呼ぶ状況
であり、購買行動において、最も戒めるべき状態だ。
そうならないようにするには、ユーザー（消費者）も
「武器」を持たないとならない、その武器の１つが、自作
「ボケ質解析ソフト」であり、これでメーカー側や評論家
（＝市場/流通側に属する専門的評価者）の言う事の真偽を
ユーザー側で判定してやろう、という意味（理由）である。
で、そのソフトを使って、ボケ質を解析すると、例えば
いわゆる「平面マクロ（レンズ）」（注：1970年代頃
に、コピー機の代用として写真複写用に開発された交換
レンズ。解像力が高いが、ボケ質が極めて「固い」）
では、下写真のようになり、背景ボケ部に青色や水色の
「ボケの固い」部分が多数検出される。（注：赤色と黄色
の表示部は、特にボケには問題が無い状態を示す）
![_c0032138_19565412.jpg]()
「アポダイゼーション光学エレメント」(APD/STFと省略
される場合が多い、以下、そう記載する）搭載レンズ
（注：2021年までで、5機種のみ存在している。
参照：特殊レンズ・マニアックス第0回記事
「アポダイゼーション・グランドスラム」編）
であれば、下写真のように、背景ボケ部に青色や水色の
ボケが「固い」部分は、一切検出されない。
![_c0032138_19565470.jpg]()
変わってくるが、それらを含めての解析手法が必要だ）
さて、で「ボケ質を検出したけど、どうしようも無い」
というのが、当該ソフト「Trance Focus」の開発後に
ずっと不満に思っていた事である。
つまり、レンズの良否はわかった。だけど、ボケ質に
配慮したAPD/STFレンズのような、綺麗な背景ボケは、
一般レンズでは、全く得ようが無かった訳だ。
すなわち、ボケが気に入らなければ、ボケ質が優秀な
レンズを買わなければならない。でも、それではまるで
「パンが無ければブリオッシュを食べれば良い」という
「ブルジョワ（金満家）的な思想」であり、そんな風に
「何でも金で解決すれば良い」といった発想は、あまり
好ましい解決策とは言えないであろう。
もっと、知恵を使って、何とかならないものか・・？
余談だが、電子楽器の「（ミュージック）シンセサイザー」
では、もう40年も昔から、シンセ楽器上のボタンを押すと、
プリセットした音色が選べ、それは「ピアノ」「オルガン」
「ギター」「バイオリン」「トランペット」・・のように、
利用者（演奏者）が、好きな音色を選ぶ事ができる。
これは、電子楽器のアナログ時代（～1980年代）では、
それに似た音色をシンセのパラメーターをいじくって
作り上げて、（ファクトリー）プリセットとしていた。
サンプリング時代（1990年代前後）では、実際の生の
楽器の音をサンプリング（≒録音）して、それをシンセに
入れていた。さらに、モデリング時代（2000年代頃～）
では、（生）楽器の特徴等を、デジタル的に解析し、
それを生成（モデリング）して、よりリアルな（本物）の
楽器のような音色を、演奏技法（例：鍵盤タッチの強弱）
に応じて、自動的に生成できるようになっている。
カメラ（映像、写真）の世界では、デジタル化は、音響の
世界でのデジタル化(例：CD登場が1980年代）よりも、
およそ15年も遅かった。
まあ、音声と映像ではデジタル化する為のデータ量の規模が
違う事が、その最大の理由であろう、つまり音響のデジタル
化の方が容易であった訳だ。
で、音響の世界では、そのように楽器音をシミュレートする
ような事は、ごく普通に出来ているのに、カメラ（映像）の
世界では、あいかわらず、実際（本物）のレンズを一々交換
（購入）しないと、異なる画像特性を得る事は出来ない。
これは画像処理の「技術」というより、その「用法」の発展が、
音声処理技術に比べて大きく遅れている状態ではなかろうか？
例えば、カメラ上にメニューがあって、「オールドレンズ」
や「ツァイスのプラナー」とか「ミノルタSTF」のような
レンズの特徴的な特性（描写傾向）を、ボタン１発で選べる
ようになれば、どんなに楽しい事であろうか？
（例：PENTAX Qシリーズには「Auto110モード」が存在し、
古い時代の銀塩カメラっぽい写りをシミュレートできる。
また、FUJIFILM Xシリーズ・ミラーレス機では「Velvia」
「ASTIA」「PROVIA」等の、フィルムの種類別の特性を
シミュレーションできるモードが存在する。
ただし、交換レンズをシミュレートした前例は無い）
（注：それと、2010年代からのコンパクト機の一部や、
2010年代後半のスマホでは、ピントの合った写真と、
ピンボケ写真を合成し、背景ボケを仮想的に作り出す
機能を搭載している機種もある。しかしながら、それらの
ボケ生成機能は、そのボケ質までは制御する事はできない）
まあ、この内容（レンズ特性のシミュレート）も、今回の
プログラム開発の中で、実験的に行ってみたいと思う。
余談はともかく、まだ説明の続きだ。
「ボケ質解析ソフト"Trance Focus”」で検出された、
「ボケが固い領域（画像の一部分）」に対し、ボケ質を
改善する「画像処理フィルター」を入れて、画像全体の
ボケ品質を向上できるようなソフトが出来ないだろうか？
これが、今回の「ボケ質改善ソフト」の開発目的である。
ただ、これは１発で、様々な画像のボケ質が改善される
ように作るのは難しそうだ。概ね3段階の画像処理が必要に
なるだろう・・
1)ボケ質の解析（ボカが固い部分・領域を抽出する）
2)抽出したボケが固い領域のボケ質を改善する。
3)元の画像に、改善したボケ質部を合成する。
で、この全ての流れを自動的に行うのも、プログラム
の構造がやや複雑だ。
そこで今回は、上記の2)の部分の画像処理、すなわち
「画像のボケ質の全体（または部分）の改善処理」のみ
をテスト用プログラム「Bokeh」として開発してみる事
とする。（「Bokeh」とは、日本語の「ボケ」の概念が
世界的に広まり、英語化されたもの。つまり、海外では
「ピンボケ」の概念(Out focus)はあったが「ボケ（質）」
の概念は広まっていなかった、という次第である）
その後、今回のテストプログラムの処理内容をモジュール
（機能部品）化し、それを組み込んだ、自動ボケ質改善
ソフトの開発に着手しよう（後編記事で、それを紹介する）
さて、では今回は「ボケ質改善」すなわち「（全体の）
画像をボカしてしまう」、という、比較的シンプルな
テスト用ソフトのプログラミングの話となる。
![_c0032138_19570531.jpg]()
を使用する。年代に応じてバージョンが色々とあるが、
今回も「起動が軽い（立ち上がりが速い）」という特徴を
持つ、Visual Studio 2013年版を使う事とする。
（素早く起動して、ちょこちょこと修正するのに適する）
![_c0032138_19570523.jpg]()
非常に複雑な画像処理内容の場合は、別途(Visual)C++
言語で、外部計算エンジンを開発した方が効率的だが、
今回の程度の内容（ボリューム＝量/レベル＝難易度）で
あれば、C#のみで何とか処理出来る範囲であろう。
なお、この開発環境により生成された.exeプログラムは、
逆コンパイル（Decompiler、逆アセンブルとも）により、
容易にリバース・エンジニアリング（他者によりソフト
の内容/中身を調査解析する事）が出来てしまう。
まあ、このシリーズ記事で開発しているソフトウェアは、
完全な趣味の範疇での個人用途であり、他者にこれを配布
する事は一切無いから良いのだが・・
もし、業務用等のソフトで販売・頒布する等の場合は、
重要な知的財産を含む部分（画像処理アルゴリズム等）は、
それをC#等のままでは記述せず、別途C++言語等で作った
後に.dll化や.exe化して、それらを、C#から呼び出す
ようにした方が、若干だが安全性が高まる。
それと、C#のままでも、「難読化」という処理は可能では
あるが、そうしても、プログラム全般の流れ（フロー）は、
逆コンパイルにより、読めてしまう為、あまり安全な対策
とは言えないであろう。
さて、「ボカし」プログラムはすぐに出来そうなのだが、
ちょっとだけ前述の工夫を入れてみよう。
![_c0032138_19570579.jpg]()
>Old Lens
>Zeiss Planar
>Apodizasion
の、3つのItem(≒メニューの選択肢）を入れている。
これは、それぞれボカし方（アルゴリズム）を変えて
みる予定である。
具体的に、どんな処理結果を期待するか？ だが、
>Old Lens（オールドレンズ）
→あまり複雑な計算をせず、ともかく単純にボカす。
>Zeiss Planar（ツァイス プラナー）
→変形ダブルガウス型のレンズ構成における、発明者
ガウスにちなみ、ガウス関数を応用したボカし処理
を行う。
>Apodization（アポダイゼーション）
→被写界深度内の被写体の解像感にあまり影響を
与えずにボカし処理を行う。
という処理を各々の画像処理モードで行ってみよう。
なお、これらの画像処理を個々に掛けたからと言って、
本物のオールドレンズ、プラナー、STFのような写りが
得られる訳ではない。あくまで「雰囲気」だけだ。
しかし、前述の電子楽器の例で言えば、初期のアナログ
シンセサイザーのプリセット音色は、シンセの多数の
ツマミ設定をいじくって、それっぽい楽器音を作り上げた
ものであり、「ピアノ」や「ギター」と書いてはあっても、
あまり本物の楽器音とは似ていなかった。
だが、重要なのは「どこまで音色が良く似ているのか？」
では無く、「音色プリセット」という概念を発明した事が
画期的なのであり、それが無ければ、アナログシンセ
の音作りは、ずっと「マニュピレーター」等と呼ばれた、
「エンジニア」と「ミュージシャン」のスキルを合わせ持つ、
「専門のシンセサイザー操作者」でしか出来なかった状態
であっただろう。
（参考：有名なシンセ・マニュピレーターとしては、
初期のアナログシンセサイザーの時代で言えば・・
国内：富田勲、喜多郎、松武秀樹、ミッキー吉野、
深町純、細野晴臣、坂本龍一、小室哲哉・・
海外：ウォルター・カーロス、キース・エマーソン、
マイク・オールドフィールド、リック・ウェイクマン、
クラウス・シュルツェ、ハワード・ジョーンズ・・
等が挙げられる。
いずれも、音楽から技術まで、多方面の才能を合わせ持つ
高度な専門家であり、世界を見渡しても、そういう人達の
数は、さほど多くない）
まあつまり、カメラの世界は、「遅れている」訳だから
こういう風な「交換レンズをプリセットする」といった
全くの新しい発想を取り入れていかないと進歩が無い、
と、そういう事を言いたい訳だ。
最初の発想（アイデア）だけ出してしまえば、いずれ
カメラ（レンズ）メーカー等の技術者達により、そういう
発想は、より洗練された技術となっていくだろう。
そういう新しい発想が無い状態では、「新製品のカメラは
旧機種が毎秒10枚の連写速度だったのが、毎秒12枚に
性能向上しました・・・」等の、何も面白くも無い改良
しか出来ない事となってしまう。
秒10コマだろうが12コマだろうが、どうでも良いでは
ないか？ あるいは最高ISOが160万だろうが、320万
だろうが、もうどうでも良い話だ。そんな風に数値性能の
改善しか出来ないメーカー側もどうかと思うし、そんな
単なるカタログ上の数値スペックにしか魅力を感じない
ビギナー消費者層も、やはり、どうなのだろうか？
もっと、誰も持っていない発想を創造しない限り、カメラ
やレンズの市場は、どんどん縮退していくばかりになる
のは間違い無い話であろう。（＝つまり、面白く無い）
さて、余談が長くなった、プログラミングの話に戻る。
ボケ質をチェックするのは、サンプルの画像が必要だ、
勿論、自分で撮影した写真は、いくらでも持っているが、
アルゴリズムの動作を確認検証する為には、今回のソフト
専用のサンプル画像が必要だ、と思った。
特に、一般的には、ボカし画像処理は、グレースケール
（≒モノクロ）画像にて行う。カラーでの画像処理は、
グレースケールよりも複雑なので、バグ（ミス）を出し
易い。そこで「カラーバー」（テレビ放送等のテスト用
パターン）のような画像を作る事とした。
![_c0032138_19570591.jpg]()
作っていく。「ソフトで自動生成した方が簡単か？」
とも思ったのだが、計算式が良くわからない（汗）
8色が、縦の列、横の行の各々で重複しないような
並び方だが「計算式にするよりも、手動で作った方が
早いか？」と思って、作り始めてしまったが・・
匠「ぐぅっ！ これだと赤色が、縦に２つづつ重複
している（将棋で言う所の「ニ歩」のような配置）
意外に難しいな（汗）まるでパズルのようだ・・」
ああでも無い、こうでも無い、と考えながら、なんとか
全部の行と列に８色が重複しない配置が完了した。
![_c0032138_19571141.jpg]()
無理に考えずに良かった（汗）
きっと、このパターン画像を自動生成するアルゴリズムは、
恐ろしく難しいに違いない。手作業で、パズル感覚による
試行錯誤で作るのが、やはり最も簡便だった事であろう。
何故、こうしたテスト画像（テストパターン）が必要か？
と言えば、この画像をボカした際の、隣接する２色毎の
中間色を、RGB値の変化で確認する必要があるからだ。
上のテストパターンであれば、全ての色同士が各々隣接
しているので、その詳細確認をする事が出来る。
つまり例えば、グレースケール（≒モノクロ）画像で
白（0xFF）と黒（0x00)のピクセルが隣接している
ならば、それをボカした場合、(0xFF(255)+0x00)/2
で、0x7F（127）又は0x80(128)になれば良い。
（注：「0x」とは、16進数を表す技術用語だ）
・・だが、カラー画像の場合、隣接する２つの
赤のピクセル（R=0xFF0000)と、
青のピクセル（B=0x0000FF)とを、ボカした場合、
間を0x7F007Fと計算したならば、なんだか「暗い線」
となってしまう。ましてや、２画素からのみでは無く、
もっと周囲の画素を含めて計算した場合、なおさら
この問題は顕著になる。（＝ボカし境界が暗くなる）
人間が目で見て不自然では無い明るさに近くするならば、
あまり世の中にあるが通りの（＝参考書通りの）方法論
では、上手く行かない可能性が高い。
「カラー画像をPhotoshopでボカした場合、境界が暗くなる」
という問題点については、近年、米国(?)のYouTuberにより
指摘されている模様で、これを日本語翻訳した記事も見掛けた。
だが、これらの投稿で指摘している内容は正しいのだが、
あくまで「画像編集屋」的視点での問題提起であり、
「画像処理屋」的な感覚では、それは必ずしも正確な内容
とは言えず、かつ技術面での正しい問題解決の方法論も
示されてはいない。
「PhotoShop」においては、オプション設定の「RGBカラー
ブレンド部分をガンマ補正」にチェックを入れると、この
問題が解決する、との事が提示されており、「何故この処理
がデフォルト（最初から標準）になっていないか？」という
指摘もあった。
まあ、確かにその通りだが、それも「画像編集屋」的発想だ。
「画像処理」的に言えば、この「ガンマ補正」の計算式は、
Y=255.0*Math.pow((double)X/255.0,1.0/gamma);
という、計算コストを浪費する（＝計算が遅い/重い）補正
であるから、大画素の写真画像等に対して、いつでもこれを
各ピクセルに掛ける気には、（遅くて）到底なれない。
（まあ、この問題がある為、オプション処理になっている
事は明白だ。デフォルトにすると「遅い」と文句が来る）
それと、このガンマ補正は対処療法であり、アルゴリズム上
の弱点を画像処理技術的にカバーしている訳では無いと思う。
「じゃあ、どうするのだ？」という話だが、まず前述の
「ボカし境界が暗くなる」という課題は・・
特定の「ボカしアルゴリズム」を使用し、かつ、その元処理が
グレースケール（モノクロ）画像用であったものを、そのまま、
カラー画像処理用アルゴリズムに転用した場合のみに発生する
問題（≒バグ）である。
だから、それに近いアルゴリズムを用いてカラー処理する
場合は、適切な補正式を入れてあげないとならない。
これを確認する為に、上記の「パターン画像」を作った訳だ。
それと、ガンマ補正は計算時間がかかりすぎる為、自分用の
アルゴリズムに適した新たな補正式を入れよう。
そして、それが固定的な補正式であれば、一々複雑な計算を
せずとも「テーブル化」という処理で計算時間を高速化できる。
以下は、そういう手法で「テーブル化」した例。
（「テーブル化」とは「配列を作る」と置き換えても良い）
![_c0032138_19571149.jpg]()
C++での計算結果の出力配列を、C#言語の本ブログラムに
移植し、さらに手動で、配列の数値を少し修正している。
（注：技術者（エンジニア）または数学者等は、数式により
作られた数列を「美しい」と感じ、「それに手を入れる事は
ご法度だ」とも考えるが・・ 芸術家（アーティスト）は、
逆に、そういう数列を「機械っぽい」と感じ、あえて人間が
手を入れた感覚的な状態を好む。まあ、これは、どちらが
正解とも言えず、開発者の好きに処置すれば良いであろう）
まあ、これで問題点は解決している筈だ。
上記「（カラー）パターン画像」を入れて試してみよう。
![_c0032138_19571119.jpg]()
念のため、計算結果を保存し、思い切り拡大して確認する。
![_c0032138_19571262.jpg]()
いないが（色毎での輝度の暗い部分での補正結果がイマイチ。
多分、前述の補正テーブルは、一次元では無く、RGB色毎の
二次元配列にした方が良いのではなかろうか？とも思った。
色毎に、人間の目が感じる明るさに差がありそうだからだ）
でもまあ、だいたいは、これでＯＫそうだ。
趣味のプログラミングでは、この程度で十分であろう。
完璧を期すのは、あくまで、こういった画像処理ソフトを
開発して製品化・市販化する人達の仕事だ。
まあでも、こういう課題が何十年もほったらかしにされて
しまうのだから、画像処理の世界も困ったものである。
本ブログでは、良く「光学の世界の原理が、デジタルの
世界では、殆ど当てにならない」と嘆いているのだが・・
どうも、画像処理の世界も、同様に、必ずしも、正しい
情報ばかりが流れている訳では無さそうだ。
（＝当てにならない情報が極めて多い、という状態。
光学や画像処理の分野で、稀に「ここがおかしい」等と
書かれている個人Web等を見掛けるが、実は、その項目
だけが問題点なのでは無い。非常に多くの項目がおかしい
のであって、これはもう個々に糾弾していてもきりが無く、
何か疑問に感じる項目や情報があれば、自分自身の方法論で、
それの真偽を確かめていくしかない。で、私は、少なくとも、
そうした検証作業を数限りなくやっていたり、あるいはその
対処方法を自分なりに考察したりして、それを本ブログの
記事中で公開したりしている訳だ。自分自身で何も対策を
取らず文句だけ言っているのでは、何も解決しないと思う）
まあ、そういう現状だからこそ、「人真似を一切せずに
全て自分で考えて、全て自分でプログラムを作る」という、
本シリーズ独自のルールを作って、それを守っている訳だ。
そうそう・・ 画像処理のテスト画像と言うと、皆が必ず
使う、非常に有名なテスト画像（著作権フリー）が、
以下の、通称「Lena」と呼ばれている画像である。
![_c0032138_19572536.jpg]()
または自分で生成した画像「以外」の掲載だ。
（注：今時の一般層のSNSでは、他者の著作権や肖像権
のある映像ばかり、パクって掲載しているものばかり
であり、情けないどころか、完全に違法な措置でもある）
・・・で、この画像、色味が悪いと思わないだろうか？
カラー・ヒストグラムを見てみると、G（緑）とB（青）
の成分が極端に不足していて、カラーバランスが悪い。
これではカラー画像処理のテスト画像には向いていない。
ちなみに、「何故、皆がこの画像を使うのか？」と
疑問に思ったので、出自を調べてみた。
すると、なんと、この画像は、1970年代初頭、つまり
今から50年も昔に、米国において、当時の画像処理
研究者により、米国版「PLAYBOY誌」のピンナップ
（プレイメイト）写真をスキャンして作られた画像の
ようだ。
まあ、50年前のスキャナーならば、色味が悪いのも
やむをえないかも知れない。
（参考：米PLAYBOY誌（雑誌版）は、コロナウィルス
の影響?により、2020春号を持って廃刊、以降はWeb版
のみとなる模様だ。創刊号でマリリン・モンローが表紙
となって以降、約60年間も続いた男性誌であった）
で、勿論、写っている人はモデルさん（Lenaさん）なので
肖像権はあるし、PLAYBOY誌（社）の著作権もあった。
当初、「勝手に画像を使うな」とPLAYBOY誌側から文句が
出た模様だが、研究者等が、こぞってこの号を買い
（まあつまり、この画像の下は服を着ていない訳だから、
その「続き」を皆が見たがった訳だ・笑） 716万部と
いうビッグセールスとなった為、PLAYBOY誌（社）側は
「学術利用に限定する」という条件で訴え（警告）を
取り下げ、Lenaさんの許可も取れた模様で・・
この画像は、パブリック・ドメイン（≒著作権フリー）
となった訳だ。で、後にLenaさん（スウェーデン人）は、
米国の画像処理学会にゲストとして招かれた、との事。
ただ、前述のように、「Lena」は、どう見てもカラー
画像処理のサンプル画像には向かないので、グレー
スケール処理専用画像と考えておくのが無難であろう。
・・というか、世間での画像処理は、そのほとんどが
グレースケール処理ばかりであり、カラー画像処理は
あまり発展していない（やっている人が少ない）事も
大きな課題であろう。（カラー画像処理アルゴリズム上の
バグ等が、なかなか改善されないのも、これが原因か？）
もう１つ、このLena画像のオリジナルは、50年前の
スキャナーの性能上、512x512pixelの、僅かに26万
画素程度しか無い。これは、本ブログで掲載している
写真の程度の低解像度であり、現代のデジタルカメラ
で撮影した写真は、これの100倍程度の、数千万画素と
なる事が普通だ。
・・で、画像処理の研究者、あるいは学生は、こうした
低解像度のサンプル画像ばかりで実験・研究を行う為、
例えば、空間フィルター処理における、カーネル半径
（オペレーターとも。対象ピクセルの周囲の画素値を
計算する為の行列のサイズ/半径等）も、小さいものを
使う（3x3とか、5x5とか）事が普通だ。
だが、そういう小カーネルの処理は、Lena画像等の
低解像度の画像に対しては良く効果が現れるのだが、
数千万画素のデジカメ画像に対しては、殆ど効果が
出ない場合もある。
この為、本来であれば入力画素数（≒解像度）に応じて
画像処理の空間フィルターのカーネル半径を拡張する
措置が望ましいのだろうが、どの程度拡張すれば良いか？
という定説は存在しない。
それに、カーネル（≒オペレーター）は、拡大すると
恐ろしく複雑化する。例えばガウス関数（ガウシャン
フィルター）は、3x3から5x5程度のカーネル係数は、
Webや教科書等、どこででも参照する事は出来るが、
これが、三千万画素画像処理用に、例えば31x31等の
サイズに巨大化した場合の実例は見つからないと思う。
まあ、このカーネル係数を自動生成する事は、さほど
難しくは無いが・・ 仮に、そんなものを使ったら
計算時間（計算コスト）が係りすぎる課題がまず１つ、
そして、カーネルが大きくなって元画像からはみ出した
場合、そこをどう補填処理するか？などの定説も無い。
（輪郭止め、計算対象画素数減らし、折り返し鏡像処理、
等の方法論はあるが、どれが正しいかは不明だ）
「じゃあ、高解像度画像の画像処理は、技術者達は、
皆、どうしているのか？」と言えば・・
なんと、たいていの場合で、Lena画像(512x512）や
VGA（640x480）程度の、20～30万画素に縮小した
上で、様々な画像処理を掛けているのだ。
それでは、「靴に足を合わせろ」みたいな処理であり、
あまり褒められた処理手順では無いとも思えるのだが、
「計算時間を、あまりかけたくない」などの理由を
大義名分として、こうした50年前の画素数レベルの
画像処理（技術）が、何十年間も続いている次第だ。
なんとも不条理な世界であるが、デジタル画像処理や
デジタル光学の世界は、本当に未発達であり、まともな
技術発展が無い状態なのが、大きな課題であろう。
まあ、だからこそ、私のような「日曜プログラマー」が
趣味のレベルの研究でありながら、大企業とか、優秀な
研究施設での最先端研究に「対抗しよう」という気に
なれる訳だ。つまり、この分野の技術内容が未発達だから、
誰が研究しても、個人で研究しても、組織で研究しても、
大差が無い、という訳だ・・
![_c0032138_19572594.jpg]()
無いのだが、特に今回の記事では、あまり詳しく説明
する内容も多くは無い。メインはあくまで後編での
「自動ボケ質改善ソフト」であり、今回は、その為の
試験（テスト）プログラムの開発に過ぎない訳だ。
そして、今回のソフトは、部分的（局所的/ローカル、
と画像処理用語では言われる）な画像処理ではなく、
あくまで、全体的（グローバル）な画像処理だ。
ただ、プログラムの構造として、局所処理の関数を
サブルーチンとして記述しており、それを連続的に
全ピクセルに対して呼び出す事で、グローバル処理化を
している。
つまり、ボケ質解析ソフト「Trance Focus」と合体
させる為の構造を、あらかじめ意識している訳だ。
（関数の呼び出しの為のスタック処理で、計算時間は余分に
かかるが、次のソフト開発を見据えておく事の方が重要だ）
で、特にテストで確かめたかったのは、「ボケモード」
つまり、「レンズ形式のシミュレーション」が、有効に
動作しているか否か？のチェックである。
![_c0032138_19572925.jpg]()
弱いボカしレベルの設定では、全体的に解像感が減り、
かなりシャープさが失われている甘い画像だ。
が、だいたいだが、「オールド大口径標準レンズ」での
絞り開放近くで球面収差等が多大に発生している描写
傾向に近いと思われる。これは、これで良いであろう。
![_c0032138_19573337.jpg]()
思っていたよりも、合焦部のボケ、つまり解像感の
全般的な低下が強い印象だ。これだと、本物のプラナー
レンズのような、「ピント面はくっきり、ボケは綺麗」
という風な特性にはなっていない。
ただしこれは、次に作るソフトでは、被写界深度内に
含まれると思われる部分は自動的にボカし処理をしない
構造とする為、まあ、今の段階では、これで良い。
![_c0032138_19573756.jpg]()
被写界深度内の被写体はビクともしない解像感を保持
している。「本当にこれで効いているか？」と不安に
思う位だが、このボケモードのアルゴリズムは、一応
そのようになるように意識はしている。
これを、ローカル（局所）処理に組み込んでも、効き目
（効果）は薄いかも知れないが、ボケ質の細かい部分を
改善するのに役に立つかも知れない。
実際には、世間一般の画像処理のエンジニアと大きく
異なるのは、私の場合では、「入力する画像（写真）を
自由自在に撮れる」という点である。
Lenaさんの画像とかの、いつも同じような著作権フリー
の画像を使わないでも、自分で撮った写真を百万枚以上も
保有しているし、それらには、あらゆるパターンの画像が
含まれている訳だ。
あるいは、自分が作った「画像処理アルゴリズム」に向く
ような画像を、それに向く撮影機材で、新たに撮って来る
事も出来る。
つまり例えば、「プラナー」モードで計算させる画像を
あえて本物のプラナー(Zeiss Planar）系レンズで撮影
してくる事も出来る。
「プラナーで撮った画像を、プラナー画像処理したら
プラナーっぽくなるのは当たり前であろう？」
と思うかも知れないが・・ まあ、それが相乗効果で
良くなるのか？ 悪くなるのか？は、現時点では、誰も
答えを持っていない、これは全く新しい試みだからだ。
![_c0032138_19574505.jpg]()
画像を、ボカし処理中の模様。
「アポダイゼーション」モードの中間段階レベルで、
軽く背景の固いボケを消そうと試している状態である。
処理済みの画像を単体で保存してみよう。
![_c0032138_19574580.jpg]()
そう、「ボケ質」の評価など、所詮そんなものであり、
三次元の被写体を、二次元の写真として撮っても、
その立体的なボケの遷移（移り変わり）などは、殆ど
肉眼では判別できない。
だから、例えばNIKONの提唱する「三次元的ハイファイ」
のレンズ等も、ユーザーや評論家の誰もが、正しく評価
する事は出来ない訳だ。
（予定：レンズマニアックス第63回三次元的ハイファイ)
で、マニア層が昔からよく言う「このレンズのボケ質は、
良い（悪い）」等も、同様であろう。 撮影条件（例：
レンズの種類、カメラ側センサーの特性、撮影距離、
背景距離、背景の空間周波数分布（≒図柄）、絞り値）
等が、すこし変わるだけで、ボケ質は、かなり変化して
しまい、再現性が全くない。
目で見ても良くわからない、再現性も無い、まあこんな
状態だからこそ、画像処理のテクノロジーを新規に応用
研究開発し、レンズの特性を調べたり、あるいは、その
短所を補正したりする事を目指している訳だ。
さて、本ソフトの「アポダイゼーション」モードで処理
した画像を、もう１度、ボケ質解析ソフトに入れてみよう。
![_c0032138_19574682.jpg]()
大差が無い模様だが、弱いボケ遷移を検出するならば、
状況が少し改善されている模様（下写真は単体保存）
![_c0032138_19575086.jpg]()
あるとは言い切れない。
引き続き、もう少し、サンプルとして適正な入力画像を
選別する事、適正なソフト上のパラメーター設定を行う事、
さらには、画像処理アルゴリズムにも微調整が必要かも
知れない。
まあ、元々、そんなに一朝一夕で出来るようなレベルの
研究では無い。真面目にこれをやろうとしたら、ライフ・
ワークに相当するような長期間と、非常に高度な技術内容
が必要になる。既に趣味のレベルを完全に凌駕しているが
まあ、誰もやっていないからこそ面白い、とも言えよう・・
----
では、今回のボケ質改善（前編）記事は、このあたりまでで。
次回は、後編記事を掲載予定。
デジタル画像のピクセル毎に、数学的な計算処理をPC等で
行い、検出、抽出、診断、判断、変換、加工等を行う為の
技術（テクノロジー）の事である。
ここでデジタル画像には、静止画と動画、二次元や三次元等
の様々な区分があり得るが、本シリーズ記事では対象として
「二次元静止画・画像処理プログラミング」に限定する。
なお、Photoshop等の画像編集（レタッチ）ソフトを用いて、
画像を手動で加工する「技能」については、「画像編集」
と呼んでいて、「画像処理」とは明確に区別している。
（注：世間一般では、テクノロジーの方の「画像処理」は、
殆ど理解されていない為、多くのカメラマンや画像関連職業
の人達は、「画像編集」の事を「画像処理」と呼んでいるが、
その混乱を避ける為、本ブログでは定義を明確化している。
理解されていない理由は、これが専門的な技術分野であり
高度で難解である事も確かだが、本記事で色々と説明する
ように、この技術分野が未発達である事も原因であろう）
本シリーズ記事では、前者の「画像処理」を実現する
ソフトウェア（アプリケーション）を、完全独自で開発
する事を主眼としている。
ここで「完全独自」とは、「外部ライブラリ（OpenCV等）
一切使用禁止」「他者のソースコード引用禁止」という
制限で、OS(.NET)に用意されている関数モジュール等を除き、
全てのプログラムやアルゴリズム（≒計算手順）を全部
自力で考案し、それを自分で打ち込む（プログラミング
する）という意味である。
何で、そんな非効率的な事をやっているのか？と言えば、
「世の中に無い、全くの新しいものを生み出す」（創造する）
目的があるからで、その為には、まず、あらゆる「人真似」
を排除する事が必須だ、と思っているからだ。
（つまり人真似や「習い事」では、新しい事は得られない）
この開発作業は、完全な自身の為の「趣味」であるので、
完成したプログラムを販売・公開・頒布等は一切しない。
また、画像処理アルゴリズムの内容は、非常に高度かつ、
新規性の高いものである場合も多く、これは「知的財産」に
相当するが、これの特許化や、IPコア化（＝Intellectual
Property Core：画像処理LSI等に、まとまった機能と
して埋め込む事）も一切しない。
要は、完全に趣味の範疇の作業であり、自身の知的好奇心
を満たしながら、スキルアップする為のものである。
こういう作業をブログ記事で公開する理由は、「このように
考えながらプログラミングを行う」というサンプル的手順を
公開する為であり、世の中における「プログラミング学習」
というものが、単なる「プログラミング言語の文法の習得」
であったり、「特定の動作環境でロボット等の機器の動作の
条件をプログラムする」といった、非常に狭い視点での
「常識」への警鐘の意味もある。（つまり「プログラミング
とは、習い事では無い！」という事を説明する為の記事だ）
ややこしい、まず順を追って説明していこう。
本シリーズ第5回「ボケ質解析ソフトのプログラミング」
の記事において・・・ (上写真のソフトウェア）
そのソフトでは「写真用レンズのボケ質の良し悪し」を、
ある程度（完璧では無いが）解析する事が可能であった。
様々な写真用レンズに「ボケ質」の良否が存在する事は
銀塩時代の昔から、中上級マニア層等においては常識と
して知られていた。
まあ、銀塩時代のMF一眼レフ等では、50mm/F1.4級の
標準レンズがキット（セット）で販売されていたので、
そうした大口径レンズであれば、多くの撮影条件において
多大な背景/前景ボケを得る事が出来た。（＝すなわち、
被写界深度が浅い状態を、誰でも簡便に得る事が出来た）
だが、近年においては初めてカメラを買う際にキットと
して付属してくるレンズは、標準ズーム等になっていて
ビギナー層等のユーザーでは
ビ「絞りの値を変えても、写真の教科書等に載っている
ようには背景が上手くボケ無い・・・」
という疑問や課題を良く口にしている。
近年でのカメラ/交換レンズ市場の縮退により、大口径
の交換レンズを購入するユーザー層もかなり減ってきて、
そもそも多大な「ボケ量」を得るような撮影機材環境を
持つユーザー数が少ない。ましてや、背景等をボカした
際での「ボケ質」等に言及できるマニア層も相当に減り、
現代では、中上級マニア層や上級層以上あたりで無いと、
「レンズのボケ質に良否がある」という事実を認識して
いないかも知れ無い。（そもそも「ボケ質」という
ちゃんとした定義も広まっておらず、あえて「ボケ味」
という曖昧な表現をされている場合すら、多々ある）
まあ、そんな状況もあって、以前に「ボケ質解析ソフト」
の完全自力開発に着手した次第であった。
つまり、ユーザー（消費者）側が、全体的にスキルダウン
してしまっている為、例えば、メーカー側や流通側が、
「このレンズはボケ味が良いのです」等と言って来たら
「はいそうですか、では買います（買いません）」等と
購入側の主体性が無い選択をせざるを得なくなってしまう。
それは「ユーザー（消費者）の負け」と、私が呼ぶ状況
であり、購買行動において、最も戒めるべき状態だ。
そうならないようにするには、ユーザー（消費者）も
「武器」を持たないとならない、その武器の１つが、自作
「ボケ質解析ソフト」であり、これでメーカー側や評論家
（＝市場/流通側に属する専門的評価者）の言う事の真偽を
ユーザー側で判定してやろう、という意味（理由）である。
で、そのソフトを使って、ボケ質を解析すると、例えば
いわゆる「平面マクロ（レンズ）」（注：1970年代頃
に、コピー機の代用として写真複写用に開発された交換
レンズ。解像力が高いが、ボケ質が極めて「固い」）
では、下写真のようになり、背景ボケ部に青色や水色の
「ボケの固い」部分が多数検出される。（注：赤色と黄色
の表示部は、特にボケには問題が無い状態を示す）
「アポダイゼーション光学エレメント」(APD/STFと省略
される場合が多い、以下、そう記載する）搭載レンズ
（注：2021年までで、5機種のみ存在している。
参照：特殊レンズ・マニアックス第0回記事
「アポダイゼーション・グランドスラム」編）
であれば、下写真のように、背景ボケ部に青色や水色の
ボケが「固い」部分は、一切検出されない。
変わってくるが、それらを含めての解析手法が必要だ）
さて、で「ボケ質を検出したけど、どうしようも無い」
というのが、当該ソフト「Trance Focus」の開発後に
ずっと不満に思っていた事である。
つまり、レンズの良否はわかった。だけど、ボケ質に
配慮したAPD/STFレンズのような、綺麗な背景ボケは、
一般レンズでは、全く得ようが無かった訳だ。
すなわち、ボケが気に入らなければ、ボケ質が優秀な
レンズを買わなければならない。でも、それではまるで
「パンが無ければブリオッシュを食べれば良い」という
「ブルジョワ（金満家）的な思想」であり、そんな風に
「何でも金で解決すれば良い」といった発想は、あまり
好ましい解決策とは言えないであろう。
もっと、知恵を使って、何とかならないものか・・？
余談だが、電子楽器の「（ミュージック）シンセサイザー」
では、もう40年も昔から、シンセ楽器上のボタンを押すと、
プリセットした音色が選べ、それは「ピアノ」「オルガン」
「ギター」「バイオリン」「トランペット」・・のように、
利用者（演奏者）が、好きな音色を選ぶ事ができる。
これは、電子楽器のアナログ時代（～1980年代）では、
それに似た音色をシンセのパラメーターをいじくって
作り上げて、（ファクトリー）プリセットとしていた。
サンプリング時代（1990年代前後）では、実際の生の
楽器の音をサンプリング（≒録音）して、それをシンセに
入れていた。さらに、モデリング時代（2000年代頃～）
では、（生）楽器の特徴等を、デジタル的に解析し、
それを生成（モデリング）して、よりリアルな（本物）の
楽器のような音色を、演奏技法（例：鍵盤タッチの強弱）
に応じて、自動的に生成できるようになっている。
カメラ（映像、写真）の世界では、デジタル化は、音響の
世界でのデジタル化(例：CD登場が1980年代）よりも、
およそ15年も遅かった。
まあ、音声と映像ではデジタル化する為のデータ量の規模が
違う事が、その最大の理由であろう、つまり音響のデジタル
化の方が容易であった訳だ。
で、音響の世界では、そのように楽器音をシミュレートする
ような事は、ごく普通に出来ているのに、カメラ（映像）の
世界では、あいかわらず、実際（本物）のレンズを一々交換
（購入）しないと、異なる画像特性を得る事は出来ない。
これは画像処理の「技術」というより、その「用法」の発展が、
音声処理技術に比べて大きく遅れている状態ではなかろうか？
例えば、カメラ上にメニューがあって、「オールドレンズ」
や「ツァイスのプラナー」とか「ミノルタSTF」のような
レンズの特徴的な特性（描写傾向）を、ボタン１発で選べる
ようになれば、どんなに楽しい事であろうか？
（例：PENTAX Qシリーズには「Auto110モード」が存在し、
古い時代の銀塩カメラっぽい写りをシミュレートできる。
また、FUJIFILM Xシリーズ・ミラーレス機では「Velvia」
「ASTIA」「PROVIA」等の、フィルムの種類別の特性を
シミュレーションできるモードが存在する。
ただし、交換レンズをシミュレートした前例は無い）
（注：それと、2010年代からのコンパクト機の一部や、
2010年代後半のスマホでは、ピントの合った写真と、
ピンボケ写真を合成し、背景ボケを仮想的に作り出す
機能を搭載している機種もある。しかしながら、それらの
ボケ生成機能は、そのボケ質までは制御する事はできない）
まあ、この内容（レンズ特性のシミュレート）も、今回の
プログラム開発の中で、実験的に行ってみたいと思う。
余談はともかく、まだ説明の続きだ。
「ボケ質解析ソフト"Trance Focus”」で検出された、
「ボケが固い領域（画像の一部分）」に対し、ボケ質を
改善する「画像処理フィルター」を入れて、画像全体の
ボケ品質を向上できるようなソフトが出来ないだろうか？
これが、今回の「ボケ質改善ソフト」の開発目的である。
ただ、これは１発で、様々な画像のボケ質が改善される
ように作るのは難しそうだ。概ね3段階の画像処理が必要に
なるだろう・・
1)ボケ質の解析（ボカが固い部分・領域を抽出する）
2)抽出したボケが固い領域のボケ質を改善する。
3)元の画像に、改善したボケ質部を合成する。
で、この全ての流れを自動的に行うのも、プログラム
の構造がやや複雑だ。
そこで今回は、上記の2)の部分の画像処理、すなわち
「画像のボケ質の全体（または部分）の改善処理」のみ
をテスト用プログラム「Bokeh」として開発してみる事
とする。（「Bokeh」とは、日本語の「ボケ」の概念が
世界的に広まり、英語化されたもの。つまり、海外では
「ピンボケ」の概念(Out focus)はあったが「ボケ（質）」
の概念は広まっていなかった、という次第である）
その後、今回のテストプログラムの処理内容をモジュール
（機能部品）化し、それを組み込んだ、自動ボケ質改善
ソフトの開発に着手しよう（後編記事で、それを紹介する）
さて、では今回は「ボケ質改善」すなわち「（全体の）
画像をボカしてしまう」、という、比較的シンプルな
テスト用ソフトのプログラミングの話となる。
を使用する。年代に応じてバージョンが色々とあるが、
今回も「起動が軽い（立ち上がりが速い）」という特徴を
持つ、Visual Studio 2013年版を使う事とする。
（素早く起動して、ちょこちょこと修正するのに適する）
非常に複雑な画像処理内容の場合は、別途(Visual)C++
言語で、外部計算エンジンを開発した方が効率的だが、
今回の程度の内容（ボリューム＝量/レベル＝難易度）で
あれば、C#のみで何とか処理出来る範囲であろう。
なお、この開発環境により生成された.exeプログラムは、
逆コンパイル（Decompiler、逆アセンブルとも）により、
容易にリバース・エンジニアリング（他者によりソフト
の内容/中身を調査解析する事）が出来てしまう。
まあ、このシリーズ記事で開発しているソフトウェアは、
完全な趣味の範疇での個人用途であり、他者にこれを配布
する事は一切無いから良いのだが・・
もし、業務用等のソフトで販売・頒布する等の場合は、
重要な知的財産を含む部分（画像処理アルゴリズム等）は、
それをC#等のままでは記述せず、別途C++言語等で作った
後に.dll化や.exe化して、それらを、C#から呼び出す
ようにした方が、若干だが安全性が高まる。
それと、C#のままでも、「難読化」という処理は可能では
あるが、そうしても、プログラム全般の流れ（フロー）は、
逆コンパイルにより、読めてしまう為、あまり安全な対策
とは言えないであろう。
さて、「ボカし」プログラムはすぐに出来そうなのだが、
ちょっとだけ前述の工夫を入れてみよう。
>Old Lens
>Zeiss Planar
>Apodizasion
の、3つのItem(≒メニューの選択肢）を入れている。
これは、それぞれボカし方（アルゴリズム）を変えて
みる予定である。
具体的に、どんな処理結果を期待するか？ だが、
>Old Lens（オールドレンズ）
→あまり複雑な計算をせず、ともかく単純にボカす。
>Zeiss Planar（ツァイス プラナー）
→変形ダブルガウス型のレンズ構成における、発明者
ガウスにちなみ、ガウス関数を応用したボカし処理
を行う。
>Apodization（アポダイゼーション）
→被写界深度内の被写体の解像感にあまり影響を
与えずにボカし処理を行う。
という処理を各々の画像処理モードで行ってみよう。
なお、これらの画像処理を個々に掛けたからと言って、
本物のオールドレンズ、プラナー、STFのような写りが
得られる訳ではない。あくまで「雰囲気」だけだ。
しかし、前述の電子楽器の例で言えば、初期のアナログ
シンセサイザーのプリセット音色は、シンセの多数の
ツマミ設定をいじくって、それっぽい楽器音を作り上げた
ものであり、「ピアノ」や「ギター」と書いてはあっても、
あまり本物の楽器音とは似ていなかった。
だが、重要なのは「どこまで音色が良く似ているのか？」
では無く、「音色プリセット」という概念を発明した事が
画期的なのであり、それが無ければ、アナログシンセ
の音作りは、ずっと「マニュピレーター」等と呼ばれた、
「エンジニア」と「ミュージシャン」のスキルを合わせ持つ、
「専門のシンセサイザー操作者」でしか出来なかった状態
であっただろう。
（参考：有名なシンセ・マニュピレーターとしては、
初期のアナログシンセサイザーの時代で言えば・・
国内：富田勲、喜多郎、松武秀樹、ミッキー吉野、
深町純、細野晴臣、坂本龍一、小室哲哉・・
海外：ウォルター・カーロス、キース・エマーソン、
マイク・オールドフィールド、リック・ウェイクマン、
クラウス・シュルツェ、ハワード・ジョーンズ・・
等が挙げられる。
いずれも、音楽から技術まで、多方面の才能を合わせ持つ
高度な専門家であり、世界を見渡しても、そういう人達の
数は、さほど多くない）
まあつまり、カメラの世界は、「遅れている」訳だから
こういう風な「交換レンズをプリセットする」といった
全くの新しい発想を取り入れていかないと進歩が無い、
と、そういう事を言いたい訳だ。
最初の発想（アイデア）だけ出してしまえば、いずれ
カメラ（レンズ）メーカー等の技術者達により、そういう
発想は、より洗練された技術となっていくだろう。
そういう新しい発想が無い状態では、「新製品のカメラは
旧機種が毎秒10枚の連写速度だったのが、毎秒12枚に
性能向上しました・・・」等の、何も面白くも無い改良
しか出来ない事となってしまう。
秒10コマだろうが12コマだろうが、どうでも良いでは
ないか？ あるいは最高ISOが160万だろうが、320万
だろうが、もうどうでも良い話だ。そんな風に数値性能の
改善しか出来ないメーカー側もどうかと思うし、そんな
単なるカタログ上の数値スペックにしか魅力を感じない
ビギナー消費者層も、やはり、どうなのだろうか？
もっと、誰も持っていない発想を創造しない限り、カメラ
やレンズの市場は、どんどん縮退していくばかりになる
のは間違い無い話であろう。（＝つまり、面白く無い）
さて、余談が長くなった、プログラミングの話に戻る。
ボケ質をチェックするのは、サンプルの画像が必要だ、
勿論、自分で撮影した写真は、いくらでも持っているが、
アルゴリズムの動作を確認検証する為には、今回のソフト
専用のサンプル画像が必要だ、と思った。
特に、一般的には、ボカし画像処理は、グレースケール
（≒モノクロ）画像にて行う。カラーでの画像処理は、
グレースケールよりも複雑なので、バグ（ミス）を出し
易い。そこで「カラーバー」（テレビ放送等のテスト用
パターン）のような画像を作る事とした。
作っていく。「ソフトで自動生成した方が簡単か？」
とも思ったのだが、計算式が良くわからない（汗）
8色が、縦の列、横の行の各々で重複しないような
並び方だが「計算式にするよりも、手動で作った方が
早いか？」と思って、作り始めてしまったが・・
匠「ぐぅっ！ これだと赤色が、縦に２つづつ重複
している（将棋で言う所の「ニ歩」のような配置）
意外に難しいな（汗）まるでパズルのようだ・・」
ああでも無い、こうでも無い、と考えながら、なんとか
全部の行と列に８色が重複しない配置が完了した。
無理に考えずに良かった（汗）
きっと、このパターン画像を自動生成するアルゴリズムは、
恐ろしく難しいに違いない。手作業で、パズル感覚による
試行錯誤で作るのが、やはり最も簡便だった事であろう。
何故、こうしたテスト画像（テストパターン）が必要か？
と言えば、この画像をボカした際の、隣接する２色毎の
中間色を、RGB値の変化で確認する必要があるからだ。
上のテストパターンであれば、全ての色同士が各々隣接
しているので、その詳細確認をする事が出来る。
つまり例えば、グレースケール（≒モノクロ）画像で
白（0xFF）と黒（0x00)のピクセルが隣接している
ならば、それをボカした場合、(0xFF(255)+0x00)/2
で、0x7F（127）又は0x80(128)になれば良い。
（注：「0x」とは、16進数を表す技術用語だ）
・・だが、カラー画像の場合、隣接する２つの
赤のピクセル（R=0xFF0000)と、
青のピクセル（B=0x0000FF)とを、ボカした場合、
間を0x7F007Fと計算したならば、なんだか「暗い線」
となってしまう。ましてや、２画素からのみでは無く、
もっと周囲の画素を含めて計算した場合、なおさら
この問題は顕著になる。（＝ボカし境界が暗くなる）
人間が目で見て不自然では無い明るさに近くするならば、
あまり世の中にあるが通りの（＝参考書通りの）方法論
では、上手く行かない可能性が高い。
「カラー画像をPhotoshopでボカした場合、境界が暗くなる」
という問題点については、近年、米国(?)のYouTuberにより
指摘されている模様で、これを日本語翻訳した記事も見掛けた。
だが、これらの投稿で指摘している内容は正しいのだが、
あくまで「画像編集屋」的視点での問題提起であり、
「画像処理屋」的な感覚では、それは必ずしも正確な内容
とは言えず、かつ技術面での正しい問題解決の方法論も
示されてはいない。
「PhotoShop」においては、オプション設定の「RGBカラー
ブレンド部分をガンマ補正」にチェックを入れると、この
問題が解決する、との事が提示されており、「何故この処理
がデフォルト（最初から標準）になっていないか？」という
指摘もあった。
まあ、確かにその通りだが、それも「画像編集屋」的発想だ。
「画像処理」的に言えば、この「ガンマ補正」の計算式は、
Y=255.0*Math.pow((double)X/255.0,1.0/gamma);
という、計算コストを浪費する（＝計算が遅い/重い）補正
であるから、大画素の写真画像等に対して、いつでもこれを
各ピクセルに掛ける気には、（遅くて）到底なれない。
（まあ、この問題がある為、オプション処理になっている
事は明白だ。デフォルトにすると「遅い」と文句が来る）
それと、このガンマ補正は対処療法であり、アルゴリズム上
の弱点を画像処理技術的にカバーしている訳では無いと思う。
「じゃあ、どうするのだ？」という話だが、まず前述の
「ボカし境界が暗くなる」という課題は・・
特定の「ボカしアルゴリズム」を使用し、かつ、その元処理が
グレースケール（モノクロ）画像用であったものを、そのまま、
カラー画像処理用アルゴリズムに転用した場合のみに発生する
問題（≒バグ）である。
だから、それに近いアルゴリズムを用いてカラー処理する
場合は、適切な補正式を入れてあげないとならない。
これを確認する為に、上記の「パターン画像」を作った訳だ。
それと、ガンマ補正は計算時間がかかりすぎる為、自分用の
アルゴリズムに適した新たな補正式を入れよう。
そして、それが固定的な補正式であれば、一々複雑な計算を
せずとも「テーブル化」という処理で計算時間を高速化できる。
以下は、そういう手法で「テーブル化」した例。
（「テーブル化」とは「配列を作る」と置き換えても良い）
C++での計算結果の出力配列を、C#言語の本ブログラムに
移植し、さらに手動で、配列の数値を少し修正している。
（注：技術者（エンジニア）または数学者等は、数式により
作られた数列を「美しい」と感じ、「それに手を入れる事は
ご法度だ」とも考えるが・・ 芸術家（アーティスト）は、
逆に、そういう数列を「機械っぽい」と感じ、あえて人間が
手を入れた感覚的な状態を好む。まあ、これは、どちらが
正解とも言えず、開発者の好きに処置すれば良いであろう）
まあ、これで問題点は解決している筈だ。
上記「（カラー）パターン画像」を入れて試してみよう。
念のため、計算結果を保存し、思い切り拡大して確認する。
いないが（色毎での輝度の暗い部分での補正結果がイマイチ。
多分、前述の補正テーブルは、一次元では無く、RGB色毎の
二次元配列にした方が良いのではなかろうか？とも思った。
色毎に、人間の目が感じる明るさに差がありそうだからだ）
でもまあ、だいたいは、これでＯＫそうだ。
趣味のプログラミングでは、この程度で十分であろう。
完璧を期すのは、あくまで、こういった画像処理ソフトを
開発して製品化・市販化する人達の仕事だ。
まあでも、こういう課題が何十年もほったらかしにされて
しまうのだから、画像処理の世界も困ったものである。
本ブログでは、良く「光学の世界の原理が、デジタルの
世界では、殆ど当てにならない」と嘆いているのだが・・
どうも、画像処理の世界も、同様に、必ずしも、正しい
情報ばかりが流れている訳では無さそうだ。
（＝当てにならない情報が極めて多い、という状態。
光学や画像処理の分野で、稀に「ここがおかしい」等と
書かれている個人Web等を見掛けるが、実は、その項目
だけが問題点なのでは無い。非常に多くの項目がおかしい
のであって、これはもう個々に糾弾していてもきりが無く、
何か疑問に感じる項目や情報があれば、自分自身の方法論で、
それの真偽を確かめていくしかない。で、私は、少なくとも、
そうした検証作業を数限りなくやっていたり、あるいはその
対処方法を自分なりに考察したりして、それを本ブログの
記事中で公開したりしている訳だ。自分自身で何も対策を
取らず文句だけ言っているのでは、何も解決しないと思う）
まあ、そういう現状だからこそ、「人真似を一切せずに
全て自分で考えて、全て自分でプログラムを作る」という、
本シリーズ独自のルールを作って、それを守っている訳だ。
そうそう・・ 画像処理のテスト画像と言うと、皆が必ず
使う、非常に有名なテスト画像（著作権フリー）が、
以下の、通称「Lena」と呼ばれている画像である。
または自分で生成した画像「以外」の掲載だ。
（注：今時の一般層のSNSでは、他者の著作権や肖像権
のある映像ばかり、パクって掲載しているものばかり
であり、情けないどころか、完全に違法な措置でもある）
・・・で、この画像、色味が悪いと思わないだろうか？
カラー・ヒストグラムを見てみると、G（緑）とB（青）
の成分が極端に不足していて、カラーバランスが悪い。
これではカラー画像処理のテスト画像には向いていない。
ちなみに、「何故、皆がこの画像を使うのか？」と
疑問に思ったので、出自を調べてみた。
すると、なんと、この画像は、1970年代初頭、つまり
今から50年も昔に、米国において、当時の画像処理
研究者により、米国版「PLAYBOY誌」のピンナップ
（プレイメイト）写真をスキャンして作られた画像の
ようだ。
まあ、50年前のスキャナーならば、色味が悪いのも
やむをえないかも知れない。
（参考：米PLAYBOY誌（雑誌版）は、コロナウィルス
の影響?により、2020春号を持って廃刊、以降はWeb版
のみとなる模様だ。創刊号でマリリン・モンローが表紙
となって以降、約60年間も続いた男性誌であった）
で、勿論、写っている人はモデルさん（Lenaさん）なので
肖像権はあるし、PLAYBOY誌（社）の著作権もあった。
当初、「勝手に画像を使うな」とPLAYBOY誌側から文句が
出た模様だが、研究者等が、こぞってこの号を買い
（まあつまり、この画像の下は服を着ていない訳だから、
その「続き」を皆が見たがった訳だ・笑） 716万部と
いうビッグセールスとなった為、PLAYBOY誌（社）側は
「学術利用に限定する」という条件で訴え（警告）を
取り下げ、Lenaさんの許可も取れた模様で・・
この画像は、パブリック・ドメイン（≒著作権フリー）
となった訳だ。で、後にLenaさん（スウェーデン人）は、
米国の画像処理学会にゲストとして招かれた、との事。
ただ、前述のように、「Lena」は、どう見てもカラー
画像処理のサンプル画像には向かないので、グレー
スケール処理専用画像と考えておくのが無難であろう。
・・というか、世間での画像処理は、そのほとんどが
グレースケール処理ばかりであり、カラー画像処理は
あまり発展していない（やっている人が少ない）事も
大きな課題であろう。（カラー画像処理アルゴリズム上の
バグ等が、なかなか改善されないのも、これが原因か？）
もう１つ、このLena画像のオリジナルは、50年前の
スキャナーの性能上、512x512pixelの、僅かに26万
画素程度しか無い。これは、本ブログで掲載している
写真の程度の低解像度であり、現代のデジタルカメラ
で撮影した写真は、これの100倍程度の、数千万画素と
なる事が普通だ。
・・で、画像処理の研究者、あるいは学生は、こうした
低解像度のサンプル画像ばかりで実験・研究を行う為、
例えば、空間フィルター処理における、カーネル半径
（オペレーターとも。対象ピクセルの周囲の画素値を
計算する為の行列のサイズ/半径等）も、小さいものを
使う（3x3とか、5x5とか）事が普通だ。
だが、そういう小カーネルの処理は、Lena画像等の
低解像度の画像に対しては良く効果が現れるのだが、
数千万画素のデジカメ画像に対しては、殆ど効果が
出ない場合もある。
この為、本来であれば入力画素数（≒解像度）に応じて
画像処理の空間フィルターのカーネル半径を拡張する
措置が望ましいのだろうが、どの程度拡張すれば良いか？
という定説は存在しない。
それに、カーネル（≒オペレーター）は、拡大すると
恐ろしく複雑化する。例えばガウス関数（ガウシャン
フィルター）は、3x3から5x5程度のカーネル係数は、
Webや教科書等、どこででも参照する事は出来るが、
これが、三千万画素画像処理用に、例えば31x31等の
サイズに巨大化した場合の実例は見つからないと思う。
まあ、このカーネル係数を自動生成する事は、さほど
難しくは無いが・・ 仮に、そんなものを使ったら
計算時間（計算コスト）が係りすぎる課題がまず１つ、
そして、カーネルが大きくなって元画像からはみ出した
場合、そこをどう補填処理するか？などの定説も無い。
（輪郭止め、計算対象画素数減らし、折り返し鏡像処理、
等の方法論はあるが、どれが正しいかは不明だ）
「じゃあ、高解像度画像の画像処理は、技術者達は、
皆、どうしているのか？」と言えば・・
なんと、たいていの場合で、Lena画像(512x512）や
VGA（640x480）程度の、20～30万画素に縮小した
上で、様々な画像処理を掛けているのだ。
それでは、「靴に足を合わせろ」みたいな処理であり、
あまり褒められた処理手順では無いとも思えるのだが、
「計算時間を、あまりかけたくない」などの理由を
大義名分として、こうした50年前の画素数レベルの
画像処理（技術）が、何十年間も続いている次第だ。
なんとも不条理な世界であるが、デジタル画像処理や
デジタル光学の世界は、本当に未発達であり、まともな
技術発展が無い状態なのが、大きな課題であろう。
まあ、だからこそ、私のような「日曜プログラマー」が
趣味のレベルの研究でありながら、大企業とか、優秀な
研究施設での最先端研究に「対抗しよう」という気に
なれる訳だ。つまり、この分野の技術内容が未発達だから、
誰が研究しても、個人で研究しても、組織で研究しても、
大差が無い、という訳だ・・
無いのだが、特に今回の記事では、あまり詳しく説明
する内容も多くは無い。メインはあくまで後編での
「自動ボケ質改善ソフト」であり、今回は、その為の
試験（テスト）プログラムの開発に過ぎない訳だ。
そして、今回のソフトは、部分的（局所的/ローカル、
と画像処理用語では言われる）な画像処理ではなく、
あくまで、全体的（グローバル）な画像処理だ。
ただ、プログラムの構造として、局所処理の関数を
サブルーチンとして記述しており、それを連続的に
全ピクセルに対して呼び出す事で、グローバル処理化を
している。
つまり、ボケ質解析ソフト「Trance Focus」と合体
させる為の構造を、あらかじめ意識している訳だ。
（関数の呼び出しの為のスタック処理で、計算時間は余分に
かかるが、次のソフト開発を見据えておく事の方が重要だ）
で、特にテストで確かめたかったのは、「ボケモード」
つまり、「レンズ形式のシミュレーション」が、有効に
動作しているか否か？のチェックである。
弱いボカしレベルの設定では、全体的に解像感が減り、
かなりシャープさが失われている甘い画像だ。
が、だいたいだが、「オールド大口径標準レンズ」での
絞り開放近くで球面収差等が多大に発生している描写
傾向に近いと思われる。これは、これで良いであろう。
思っていたよりも、合焦部のボケ、つまり解像感の
全般的な低下が強い印象だ。これだと、本物のプラナー
レンズのような、「ピント面はくっきり、ボケは綺麗」
という風な特性にはなっていない。
ただしこれは、次に作るソフトでは、被写界深度内に
含まれると思われる部分は自動的にボカし処理をしない
構造とする為、まあ、今の段階では、これで良い。
被写界深度内の被写体はビクともしない解像感を保持
している。「本当にこれで効いているか？」と不安に
思う位だが、このボケモードのアルゴリズムは、一応
そのようになるように意識はしている。
これを、ローカル（局所）処理に組み込んでも、効き目
（効果）は薄いかも知れないが、ボケ質の細かい部分を
改善するのに役に立つかも知れない。
実際には、世間一般の画像処理のエンジニアと大きく
異なるのは、私の場合では、「入力する画像（写真）を
自由自在に撮れる」という点である。
Lenaさんの画像とかの、いつも同じような著作権フリー
の画像を使わないでも、自分で撮った写真を百万枚以上も
保有しているし、それらには、あらゆるパターンの画像が
含まれている訳だ。
あるいは、自分が作った「画像処理アルゴリズム」に向く
ような画像を、それに向く撮影機材で、新たに撮って来る
事も出来る。
つまり例えば、「プラナー」モードで計算させる画像を
あえて本物のプラナー(Zeiss Planar）系レンズで撮影
してくる事も出来る。
「プラナーで撮った画像を、プラナー画像処理したら
プラナーっぽくなるのは当たり前であろう？」
と思うかも知れないが・・ まあ、それが相乗効果で
良くなるのか？ 悪くなるのか？は、現時点では、誰も
答えを持っていない、これは全く新しい試みだからだ。
画像を、ボカし処理中の模様。
「アポダイゼーション」モードの中間段階レベルで、
軽く背景の固いボケを消そうと試している状態である。
処理済みの画像を単体で保存してみよう。
そう、「ボケ質」の評価など、所詮そんなものであり、
三次元の被写体を、二次元の写真として撮っても、
その立体的なボケの遷移（移り変わり）などは、殆ど
肉眼では判別できない。
だから、例えばNIKONの提唱する「三次元的ハイファイ」
のレンズ等も、ユーザーや評論家の誰もが、正しく評価
する事は出来ない訳だ。
（予定：レンズマニアックス第63回三次元的ハイファイ)
で、マニア層が昔からよく言う「このレンズのボケ質は、
良い（悪い）」等も、同様であろう。 撮影条件（例：
レンズの種類、カメラ側センサーの特性、撮影距離、
背景距離、背景の空間周波数分布（≒図柄）、絞り値）
等が、すこし変わるだけで、ボケ質は、かなり変化して
しまい、再現性が全くない。
目で見ても良くわからない、再現性も無い、まあこんな
状態だからこそ、画像処理のテクノロジーを新規に応用
研究開発し、レンズの特性を調べたり、あるいは、その
短所を補正したりする事を目指している訳だ。
さて、本ソフトの「アポダイゼーション」モードで処理
した画像を、もう１度、ボケ質解析ソフトに入れてみよう。
大差が無い模様だが、弱いボケ遷移を検出するならば、
状況が少し改善されている模様（下写真は単体保存）
あるとは言い切れない。
引き続き、もう少し、サンプルとして適正な入力画像を
選別する事、適正なソフト上のパラメーター設定を行う事、
さらには、画像処理アルゴリズムにも微調整が必要かも
知れない。
まあ、元々、そんなに一朝一夕で出来るようなレベルの
研究では無い。真面目にこれをやろうとしたら、ライフ・
ワークに相当するような長期間と、非常に高度な技術内容
が必要になる。既に趣味のレベルを完全に凌駕しているが
まあ、誰もやっていないからこそ面白い、とも言えよう・・
----
では、今回のボケ質改善（前編）記事は、このあたりまでで。
次回は、後編記事を掲載予定。