「画像処理プログラミング」シリーズ第15回記事。
本シリーズで言うところの「画像処理」とは、デジタル
画像（写真等）のピクセル毎に、数学的な複雑な計算を
PC等で行い、検出、抽出、診断、判断、変換、加工等の
処理を行う為の技術（テクノロジー）の事である。
Photoshop等の画像編集（レタッチ）ソフトを用いて、
画像を手動で加工する「技能」については、「画像編集」
と呼んでいて、この「画像処理」とは明確に区別している。
![_c0032138_16384214.jpg]()
まず、「トーンジャンプとは何か？」と言えば、これは
あまり公式な画像処理用語では無いと思うが、画像編集
の世界では一般的な用語になっていると思う。
これを説明する前に、まず「ヒストグラム」についての
理解が必要だ。
「ヒストグラム」とは、画像編集や画像処理を行う際に
入力した画像の特徴を表す１つの表示形態であり、
最も単純には、画像の「輝度」（明るい、暗い）の分布
をグラフで示したものである。
デジタルカメラの多くには、この機能が搭載されていて
ライブビュー撮影前、あるいは撮影後に、写真における
輝度分布を確認する事ができる。
![_c0032138_16384280.jpg]()
この「ヒストグラム」を表示した事のあるユーザーは
多いとは思うが、正しく効能がわかっているだろうか？
このヒストグラムが低輝度側（左側）にグラフが集中
すると、多くの場合「黒つぶれ」が起き、逆に高輝度側
（右側）にグラフが集中すると「白とび」が起こる、と
一般には言われている。
その解釈は正しいが、かと言って、写真を撮る際に、いつも
このヒストグラムを真ん中に集中させ釣鐘形状（≒正規分布）
に近づけよう、とする事自体が、良い写真を撮るコツと
イコールでは無い。
カメラ（の撮像センサー）は、人間の肉眼よりも狭い範囲
（ダイナミックレンジ）でしか、輝度（明るさ）の幅を
捕らえる事は出来ない。
だから、ヒストグラムとは、カメラが検知する事が
出来る輝度の範囲な訳だ。
ヒストグラムを確認して、それが所定の範囲に収まって
いれば、カメラ（センサー）は、
「低輝度から高輝度まで、なんとか範囲内で撮れる」
と言っているだけである。
「作品」においては、例えば思い切りローキー（≒暗い）
やハイキー（≒明るい）といった「表現」を目指す事が
色々とある訳だから、「ヒストグラム（＝カメラの輝度
表現範囲）を適切にして撮る」という事と「撮影者の
意図する表現を得る」とは、決して同じではない。
なお、ヒストグラムの表示要素だが、普通は「輝度」
輝度Y=約0.30*R(赤)+約0.59*G（緑)+約0.11*B（青）
(注：RGB各値に掛ける係数は、いくつかの方式がある）
・・で表現されるが、一部のソフトやカメラ等では、
RGB（赤緑青）や、明度（HSV変換時はRGBの最大値、
HLS変換時はRGBの最大値と最小値の平均）を表示できる
ものもある。（注：上のカメラでのヒストグラムは、Y
(輝度）表示。また、本記事で作成のソフトウェアでの
ヒストグラム表示は「YRGB」方式を使用）
---
さて、で、撮影した写真をPC等の編集ソフトでレタッチ
（Retouch：編集・修正を行う作業の事）する場合だが、
コントラスト（≒明暗差）が低い画像（例：照明の状況、
カメラ設定、オールドレンズ使用時、等を要因とする）
に対して、コントラストを上げ、画像のメリハリを付ける
編集処理を行うケースが良くある。
一般的な画像編集ソフトでは「コントラスト」と書かれた
スライダーや数値等を変更するか、あるいは「トーンカーブ」
というメニューを用いて、これを変更する。
「トーンカーブ」による補正の場合、コントラストを増強する
には、例えば「Ｓ字トーンカーブ補正」を行うと良い。
![_c0032138_16384224.jpg]()
開発した自作の「シグモイド改関数」による、「自動Ｓ字
（トーン）カーブ補正」の模様の図示。
この画像処理では、パラメーター（係数）を変化させる事で
色毎（RGB毎）のコントラストを増強する効果が得られる。
で、一般的な画像編集ソフトでの「コントラスト増強」や
「Ｓ字トーンカーブ補正」を行った場合、画像中の明るい
部分は、より明るくなり、暗い部分は、より暗くなる。
（すなわち、明暗差≒コントラストが強調される）
ところが、この際、前述のヒストグラムを考察してみると
ヒストグラムの幅がコントラストの増強で広がる事となり、
ヒストグラムに「抜け」が生じ、「櫛型」(comb)となる。
（工学分野の技術用語では、「ディップ(dip)が生じる」、
あるいは「ノッチ(notch)が発生する」とも言う）
![_c0032138_16384278.jpg]()
ヒストグラムが「櫛型」となった例である。
この状態を、画像編集界の用語では「トーンジャンプが
発生した」と呼ぶ。
トーンジャンプ（の発生）は、画像中に存在しない輝度
（やRGB）があるという事となり、一般写真（自然写真）等
では目立たないが、グラデーション状に輝度や色が変化する
画像やイラスト等では、あるいは、それらの印刷の際には、
これが目立ってしまうケースもある。
なお、コントラスト増強処理の逆で、コントラストの減少
（圧縮）処理を行った場合は、ヒストグラムの幅が狭まる為、
「逆櫛型」（＝上向きのトゲトゲが生じる）のヒストグラム
となる場合がある。
まあしかし、「コントラストを減らす」画像編集を行う事は
かなり稀な状況だと思うので、「逆櫛型のトーンジャンプ」
は、一般的には、あまり見る事は無いであろう。
---
さて、で、本記事での画像処理ソフトウェア開発だが、
この「トーンジャンプ」を検出するソフトを作ってみよう。
また、可能であれば、このトーンジャンプを補正したり
緩和できる処理も入れてみたいと思う。
「トーンジャンプを検出する」意味、意義であるが・・
1)画像編集時にこれが発生しているという課題を確認する。
2)可能であれば、この検出で「画像編集前」「画像編集後」
を区別（スクリーニング）してみたい。
3)過度なレタッチ（画像編集）を行うと、これが発生する
場合があるので、そうした「過度な画像編集」を行って
いるか否か？を確認する。
4)画像を改ざん（大きく改変している）事を確認する。
これらの用途の内、1)と2)は、あくまで自分用であるが、
3)と4)は自身の他、他者の画像に対しても有効かも知れない、
まあつまり、「画像を大きく改変しているかどうか？」が
確認できるならば、その「証拠能力とか信憑性」についても
判断できるかも知れない訳だ。
----
・・だが、このソフトを作っていくうちに、現代の多くの
（市販等の）画像編集ソフトでは、コントラストの大きな
増強処理等を行っても「トーンジャンプ」が、思っていた
よりも発生し難い事に気づいた。
まあつまり、トーンジャンプは処理上での弱点とも言える
訳だから、その対策を行っているソフトが多いのだろう。
う～ん、それだと、トーンジャンプを確認する為の
サンプル画像を多く集めるのが難しいでは無いか・・
また、今回の研究開発も「失敗」の結果となってしまう
のであろうか？（汗）
いや、絶対、このソフトは何らかの用途がある筈だ、
適切なサンプル画像が無ければ、自分で作ってしまえ。
![_c0032138_16391433.jpg]()
ものだが、盛大に「トーンジャンプ」が発生している事が
わかる。
実は、これの元画像は、
＊デジタルカメラのエフェクトを使用した加工写真で、
＊そこに自作のAWB（オートホワイトバランス）処理の
「試作品」による演算を行い、
＊さらに、コントラストを強く増強したもの
である、そうした「過剰処理」を繰り返した写真は以下
のような感じとなる。
![_c0032138_16385161.jpg]()
（まあ、もっとも、近年の観光ポスター（チラシ等）の
写真の一部には、紅葉とか夜景の状況を「盛って」いて、
これ位のレベルにまで不自然な掲載写真も増えている。
つまり、そうした不自然に「盛った」写真を本ソフトで
判定して、その信憑性を疑うような事もしたい訳だ）
で、ここまで大きく写真を加工（改ざん）するならば、
これはトーンジャンプ検出処理に適正なサンプル画像となる。
しかし、本ソフトの目的の1つに「写真の改ざんの確認」が
あったのに、自分で、せっせと「改ざん写真」を作っている
ようでは、なんだかなぁ・・という感じだ（苦笑）
![_c0032138_16391723.jpg]()
今回のソフトの計算アルゴリズムは、まあ原理的には簡単
ではあるが、計算処理の手順は、やや長いものになりそうだ。
・・なので、操作部（GUI）と、計算部（計算エンジン）を
別々に開発し、最後に合体する事とする。
GUI部は、C#（.NET Framework）で開発する（上図）
計算エンジン部はシーケンシャル（連続的）な処理で
あるので、それが得意なC++言語を使用する（下図）
![_c0032138_16385107.jpg]()
オリジナルであり、他のWeb上や書籍等にあるソースコード
を参照・引用したものでは無いし、画像処理ライブラリ
（OpenCV等）の関数をインポートしたものでもない。
全ソースコードを自分自身で考え、打ち込んだものである。
![_c0032138_16392092.jpg]()
実は、今回の開発手順は、先に計算エンジンを完成させ、
後からGUI部を作った次第だ。
・・と言うのも、ちょっと新規の計算アルゴリズムが
成立するかどうか？が不明だったので、それが上手く
いったらGUIを作るという手順となった、万が一、計算
エンジンが失敗した場合、GUI部を作らないでも済む、
という感じである。
計算エンジン部の開発は、予想通り手間取り、時間が
かかってしまい、延べ3日ほどかかってしまった。
まあ、その分、GUI部の開発は簡略化して、数時間
程度の作業で済んでいる。
今回のGUI開発でのポイントは、画面右上部にある
フォルダー内画像のサムネイル（縮小）表示だ。
これはC#でのControlの「ListView」と「ImageList」
を組み合わせて実現をする。（注：この手法を使った
場合、サムネイル画像は自力で生成する必要がある。
そのサムネイルの画素数（解像度）は、自身で任意に
決める事はできるが、サムネイルの「表示間隔」は、
どうも、Win OSでのアイコン表示間隔の設定に依存し、
自力では変えられない模様である→対策は、この時点では
未考察であったが、後日、特殊な手法で解決している）
計算処理は、入力フォルダー内の複数画像を一括で連続
計算する。今回の計算処理は、若干複雑ではあるのだが
計算コスト（＝計算の手間、速度）は、あまり大きく無い
ので、小画素（数十万画素）であれば、画像1枚あたり
コンマ数秒、大画素（数百万～千数百万画素）でも、
1枚あたり数秒程度で計算が完了する。
（その為、計算の進捗を示す「プログレスバー」の搭載
は省略している。あまり計算時間はかからないからだ）
また、計算後に前述のサムネイル画像をクリックすると、
それが選択され、当該画像、およびそのヒストグラムが
表示されるように作ってある。
![_c0032138_16392550.jpg]()
する事にした。このアルゴリズムは、本シリーズ第3回
「高精度ピーキング比較ソフトのプログラミング」
（Twin Peaks）で研究開発したものと同じである。
![_c0032138_16392557.jpg]()
前述の「改ざんの判定」である。
すなわち、ピンボケ写真をシャープネス処理等で過度に
輪郭を強調したりする編集が行われている、あるいは
他の画像から被写体を切り出して（注：それはピントが
合っている）、別の写真に貼り付けたような「画像合成」
編集が行われている場合、ピーキングの結果が不自然に
なるだろうから、それを見て、写真の過度な編集、または
改ざんが行われているかどうか？を目視で判定する訳だ。
ただ、ピーキング効果の効き具合の設定はGUI操作が
煩雑になる事を避けて、固定の閾値とした。これにより、
少々弊害が出てしまったのだが、それは後述する。
さて、ここまで出来上がったところで、トーンジャンプ
が発生しているかを確認してみよう。
フォルダー内の複数画像中、トーンジャンプが発生して
いる画像は、画面サムネイルエリアに表示された画像に
「赤枠」が追加されて表示される。
加えて、当該画像のYRGBヒストグラム上にトーンジャンプ
が発生した値に対して、黄色の直線が図示される（下図）
![_c0032138_16392505.jpg]()
のみの検出である。
コントラスト減少処理等で「逆櫛型」（トゲトゲの「ピーク」
が複数発生している）の検出処理の実装は、ちょっと現時点
では省略している。
（画像処理アルゴリズム的には、ヒストグラムの「ピーク」の
検出は難しくは無いが、そこで得られた複数の「ピーク」値が、
どのような状態になった場合に、「これは逆櫛型である」と
判定する手法が、すぐには思いつかなかった為に割愛した。
まあ、「あまり低コントラスト化処理は多くないであろう」
という判断もある）
これらの画像処理における途中経過は、中間処理画像、
ヒストグラム画像、CSV形式のデータ、各々の出力で対応
している。
何か、開発中の画像処理アルゴリズム上で懸念事項があれば、
それらの中間（出力）ファイルを見て、画像処理の振る舞い
を確認する訳だ。
（注：これを省略すると、アルゴリズム開発の難易度が
いっきにあがる。なお、アルゴリズム完成時には、こうした
中間出力ファイル群を出力しないように、#define等の
フラッグ/スイッチで制御できるようにプログラムを組む）
下図は、そうした中間ファイルである。
（これはヒストグラムの値をCSVファイルに書き出し、MS
Office Excel/Open Office等で確認できる状態とした物）
![_c0032138_16393355.jpg]()
個人的に、様々な画像編集ソフト上での、ヒストグラムの
画像表示に、不満を持っている。
それは、ヒストグラムの横軸は、輝度YあるいはRGB毎の
輝度値であり、通常これは8bit処理だから、0～255の
範囲に収まる、まあ、変な事（例：色相(Hue)を色相環に
応じた0～359°の範囲でヒストグラム化する等）を
しなければ、一般的なヒストグラム横軸はいつも固定だ。
ここは何も問題は無い。
![_c0032138_16393774.jpg]()
値にはならない）の状態となっている。
例えば、単純な例を挙げれば、100万画素の真っ黒な
画像をヒストグラム化すると、輝度0のヒストグラム値
は100万という数値となり、他の輝度値は全てゼロだ。
しかし、他に、満遍なく輝度等が混ざり合っている画像を
ヒストグラム化すると、その最大値は、恐らく3900
程度となる（100万画素÷256段階≒3900）
同様に、入力画像の画素数が変わると、このヒストグラムの
最大値は、いかようにも変化してしまう。
で、ヒストグラムの縦軸で、その最大値を表示できるように
正規化（ノーマライズ）すると、大きな最大ピーク値
（例：殆どが漆黒の天体写真だとか、殆どが青空の写真とか）
を持つ画像の場合、その最大値を表示する為に、他の輝度
要素が、ヒストグラムの下部にチラホラとしか表示されない。
これはとても見にくいので、なにかしらの対策を施したい
と常々思っていた。
考えられる対応は、以下がある。
1)大きなヒストグラム最大値を、ある一定の上限値で
止めてしまう。
2)ヒストグラムの縦軸表示スケールを指数関数とし、
大きなヒストグラム最大値を、あまり大きな座標とは
せず、逆に小さいヒストグラム値を増強して表示する。
この内、2の手法は、ごく稀に一部の画像編集ソフトに
Linear/Exponential (直線/指数）のヒストグラム表示
切り替えがついている。だが、一々それを切り替える
のも面倒な操作だ。
なお、カメラ上でのヒストグラム表示は、このような
課題はあまり発生せず、比較的見やすいものが多い。
考えた結果、本ソフトにおいては、ヒストグラム画像の
生成に、2つほどの工夫を凝らしている。
まず1つは、ヒストグラム加算対象輝度に上限値と下限値
を設ける事だ。具体的には、Y(RGB)<16 という値は
画像上の、ほぼ真っ黒な部分を示すので、こういう部分は
ヒストグラム化しても、あまり意味が無いし、むしろ
この値がヒストグラム最大値になってしまったら、他の
輝度値（等）が見えにくくなるので困る。
だから思い切って下限値以下のヒストグラムをカットする。
（注：これは、あくまでヒストグラム表示に関わる処理で
あり、画像処理上で最低ラインをカットしている訳では無い）
で、同様に、例えば Y(RGB)>240 といった値は、
ほとんど真っ白な画像部（空等が白とびしている等）
であるから、これも上限値以上をカットする。
第二の工夫として、上記の上限下限値のカット後に残った
ヒストグラム値の最大値の値から、自動的に適正な指数関数
の係数を求めて、それをヒストグラムの縦軸の正規化処理の
内容（計算手法）とする事だ。
これらにより、例えば、特定の輝度に大きなピーク値が
ある特殊な画像の場合でも、比較的見やすいヒストグラムを
生成する事ができる（下図がその例）
![_c0032138_16394071.jpg]()
ピークが極めて大きく、他の輝度が殆ど表示されない
ケースであるが、この処理でなんとか様子がわかる。
なお、一般的な「ヒストグラム表示」（＝正規分布の
ような、釣鐘状のグラフが表示される）とは、ずいぶんと
見た目の印象が変わるので不自然に感じるかも知れないが
「綺麗にヒストグラムを表示する」のが目的では無く、
「細かい部分の様子まで見たい」が、今回の目的であるので
見た目の異様さは無視する。まあ、いずれ慣れるであろう。
縦軸はこれで、Adaptive（適応型）のScalable（変動型）
になったので、様々な画像の特徴に応じて、ヒストグラム
の詳細が見やすい状態となる、別の画像で試してみよう。
![_c0032138_16394350.jpg]()
前述したように、「写真改ざんの確認」の為に、独自開発
のピーキング・アルゴリズムを搭載している。
このピーキング・アルゴリズムは、非常に高精度だが、
計算量が多いので、リアルタイムでの処理は出来ない
（例えば、カメラに組み込んで、撮影時にピーキングを
出す事は無理だ。あくまで撮影後の「事後処理」である）
![_c0032138_16394688.jpg]()
つまり、あまりピーキング表示の閾値を低めてしまうと、
画面内の多くの部分に、ピーキングが反応（検出）して、
その何処が不自然なのか？（つまり、画像内での部分的な
過度なシャープネス編集や、他の画像からの部分合成編集
を行った証拠）を、発見する事が難しくなる。
そこで、今回のピーキングは、検出を思い切り厳しく
（すなわち、非常に弱い閾値による検出）を試してみた。
すると、結果は以下のようになった。
![_c0032138_16395026.jpg]()
一見して見えるのだが・・
良く良く見ると、これは殆ど「輪郭抽出」（の画像処理）
と同等の効果だ。
つまり、完全自作のピーキング・アルゴリズムにおいては、
その処理を弱めていくと、だんだんと、一般的な画像処理
の教科書にあるような「輪郭抽出を試してみましょう」と
いったビギナー的な内容と、効能が変わらなくなって
しまう（汗）
何故、それがまずい事なのか？ と言えば、「成果物の
差別化が出来なくなるから」である。
どんな職業分野でもそうだが、ベテランや上級者等が
新入社員等と同じ（レベル）の仕事をやっているようでは
意味が無い。
カメラの世界で言えば、職業写真家層が、ビギナーの
アマチュアカメラマンでも撮れるような写真を撮って納品
していたら意味が無いのだ。
それらは「差別化が出来ない」というよりも、もっと深刻
には、「あの人に仕事を頼んでも、初心者と同等の品質の
ものしか出来上がってこないから、もう頼むのは止めよう」
となり、仕事を失ってしまう危険性がある事だ。
だから、基本的には、あらゆる業務分野で、その成果物は
その専門家が作るものであれば、初心者の作るものとは
明確に差別化が出来ていなければならない。
ただまあ、その考え方が強すぎると、今度は逆に、
「本来は簡単な内容を、わざわざ難しくレポートする」
（例：専門書、論文、Web上の専門サイトに、そのような
悪い例が蔓延している。著者自身の優位性や差別化要因を
確保しようとするあまり、わざわざ難解なように文章等を
書いてしまう訳だ、これは好ましくない） あるいは
「本来は単純な事務処理を、わざわざ複雑化する」
（例：お役所仕事や大企業の事務処理等で、そうした例が
散見される。つまり本来は単純な業務であるのに、その
担当者でないと処理が出来ないくらいに複雑化してしまう、
まあ、担当者の「保身」の意味も多々あるのだろう）
・・といった、いきすぎた状態にもなってしまうので、
まあ「差別化」も、その「程度や倫理」を考えて、適正な
レベルに留めておくのが良いであろう。
ただまあ・・ 今回（本シリーズ）の画像処理研究開発は
業務ではなく、常に「趣味のレベル」である。
まあなので、あまり「差別化」等は意識する必要は無いが、
それでも、「初級エンジニアの行う輪郭抽出処理と同等」
というのは、ちょっと気に入らない。
いずれ、この「ピーキング・アルゴリズム」もAdaptive
（適応型）に改善し、画像毎の特徴を見ながら、適正な
ピーキング検出量を得られるようにしていこう。
（まあ、いつの事になるか、わからないが・・汗）
---
さて、残る処理だが、「トーンジャンプの改善（補正）」
である。
せっかく「トーンジャンプ」が検出できるのだから、
今度は、それを自動補正して、トーンジャンプを出さない
画像に加工できないだろうか？
画像処理アルゴリズムを自作しているので、画像の内部の
全てのデータを、PCは把握する事ができている。
「だったら、トーンジャンプを起こしているところを
見つけたら、それを平均化したら良いのでは？」という
簡便な解決法を思いつくであろう。
ただ、その方法は簡単にはいかない。
何故ならば、「トーンジャンプを起こしている」というのは
（それが「櫛型」ならば）「存在していないものを探す」
という事になる。いくら画像のデータを（配列等に格納し）
全て把握していても、「無いものを探す」のは困難なのだ。
画像編集者（レタッチャー）の上級層等での対策は、
どう行っているのだろう？ と思って、少し調べてみると
たいていの場合、別レイヤーを準備し、そこにノイズ状の
データを振りまいたり、あるいはさらに、ぼかし（ガウス）
処理を掛けたりして、そのレイヤーを元画像に合成し、
トーンジャンプを目立たなくしているようだ。
ただ、これは「画像の全領域でその処理をしている」事と
「目立たなくする為に、手動調整が必要」な事と、および
「ヒストグラム上でのトーンジャンプが目立たなくなった
としても、実際の画像上で、その編集の効能があるか
どうか？は別問題」
・・といった、いくつかの課題が散見された為、それらの
画像編集者的な手法を画像処理手順化することは見送った。
「画像処理には、画像処理のやり方がある」という事で
あるし、そういう風に、「画像編集」では、手が届かない
細かい所まで、画像をいじくれる（加工編集できる）事が
画像処理（工学）の、大きなメリットな訳だ。
![_c0032138_16395412.jpg]()
するか？
暫定的な手法だが、
1)トーンジャンプが発生した輝度値（複数ある）
を記憶しておく。
2)画像の全域をラスタスキャンし、トーンジャンプ
発生の輝度値と隣接するエリア（領域）を見つける。
3)見つけた「危険領域」に対して、周囲のピクセルと
調和させる空間フィルター処理（平均化、メディアン、
ガススぼかし、のいずれか、または複合処理）を掛ける。
・・という手順をアルゴリズム化し、計算エンジンに
組み込んでみた。
それによる補正結果は、以下写真の通り。
![_c0032138_16395560.jpg]()
良くわからない（汗）」というのが実際のところだ。
「トーンジャンプの自動補正」に関しては、今後、もう少し
処理アルゴリズムの改良が必要であろう。
まずは、トーンジャンプが目立ちやすい画像、等を
複数準備しなければならないし、画像内でのトーンジャンプ
危険領域を自動抽出した結果も図示しないとならないし、
補正アルゴリズムも、もっと強力な処理が必要だ。
多分、「バイラテラルフィルタ」のようなものが有効かも
知れない(？） その「バイラテラル」は、以前、論文を
参考にして自作しているものがあるが、処理が重い（遅い）
ので、殆ど使用していない。また、デバッグも済んでいない
ので、ちゃんと動いているかどうかも、良くわからない。
いずれにしても時間がかかりそうだ、仕事ではなく趣味で
やっている作業なので、気がむいた時しかプログラミングは
やらないし、趣味において、そこまでの高い「研究レベル」
にまで、のめり込むか？どうかは微妙だ。
・・まあ、なんとなく、この時点で、飽きてほったらかしに
しそうな気がする（汗）
----
今回のプログラミング研究の成否は、「△」であろう。
・・で、本シリーズ記事での通算の研究成功率だが、
総合成績＝5勝5負5分け、勝率（成功率）＝3割3分3厘
となった。
下限と思っている「成功率3割」に、だんだん近くなって
来てしまっている（汗） もし成功率が3割を切ったら
「効率が悪い事をやっている」という判断で、この
シリーズも辞めてしまうかも知れない。
次の研究開発は、是非成功させたいものである。
では、今回のトーンジャンプ検出編記事は、このあたり
までで、次回記事（不定期、内容未定）に続く。
本シリーズで言うところの「画像処理」とは、デジタル
画像（写真等）のピクセル毎に、数学的な複雑な計算を
PC等で行い、検出、抽出、診断、判断、変換、加工等の
処理を行う為の技術（テクノロジー）の事である。
Photoshop等の画像編集（レタッチ）ソフトを用いて、
画像を手動で加工する「技能」については、「画像編集」
と呼んでいて、この「画像処理」とは明確に区別している。
まず、「トーンジャンプとは何か？」と言えば、これは
あまり公式な画像処理用語では無いと思うが、画像編集
の世界では一般的な用語になっていると思う。
これを説明する前に、まず「ヒストグラム」についての
理解が必要だ。
「ヒストグラム」とは、画像編集や画像処理を行う際に
入力した画像の特徴を表す１つの表示形態であり、
最も単純には、画像の「輝度」（明るい、暗い）の分布
をグラフで示したものである。
デジタルカメラの多くには、この機能が搭載されていて
ライブビュー撮影前、あるいは撮影後に、写真における
輝度分布を確認する事ができる。
この「ヒストグラム」を表示した事のあるユーザーは
多いとは思うが、正しく効能がわかっているだろうか？
このヒストグラムが低輝度側（左側）にグラフが集中
すると、多くの場合「黒つぶれ」が起き、逆に高輝度側
（右側）にグラフが集中すると「白とび」が起こる、と
一般には言われている。
その解釈は正しいが、かと言って、写真を撮る際に、いつも
このヒストグラムを真ん中に集中させ釣鐘形状（≒正規分布）
に近づけよう、とする事自体が、良い写真を撮るコツと
イコールでは無い。
カメラ（の撮像センサー）は、人間の肉眼よりも狭い範囲
（ダイナミックレンジ）でしか、輝度（明るさ）の幅を
捕らえる事は出来ない。
だから、ヒストグラムとは、カメラが検知する事が
出来る輝度の範囲な訳だ。
ヒストグラムを確認して、それが所定の範囲に収まって
いれば、カメラ（センサー）は、
「低輝度から高輝度まで、なんとか範囲内で撮れる」
と言っているだけである。
「作品」においては、例えば思い切りローキー（≒暗い）
やハイキー（≒明るい）といった「表現」を目指す事が
色々とある訳だから、「ヒストグラム（＝カメラの輝度
表現範囲）を適切にして撮る」という事と「撮影者の
意図する表現を得る」とは、決して同じではない。
なお、ヒストグラムの表示要素だが、普通は「輝度」
輝度Y=約0.30*R(赤)+約0.59*G（緑)+約0.11*B（青）
(注：RGB各値に掛ける係数は、いくつかの方式がある）
・・で表現されるが、一部のソフトやカメラ等では、
RGB（赤緑青）や、明度（HSV変換時はRGBの最大値、
HLS変換時はRGBの最大値と最小値の平均）を表示できる
ものもある。（注：上のカメラでのヒストグラムは、Y
(輝度）表示。また、本記事で作成のソフトウェアでの
ヒストグラム表示は「YRGB」方式を使用）
---
さて、で、撮影した写真をPC等の編集ソフトでレタッチ
（Retouch：編集・修正を行う作業の事）する場合だが、
コントラスト（≒明暗差）が低い画像（例：照明の状況、
カメラ設定、オールドレンズ使用時、等を要因とする）
に対して、コントラストを上げ、画像のメリハリを付ける
編集処理を行うケースが良くある。
一般的な画像編集ソフトでは「コントラスト」と書かれた
スライダーや数値等を変更するか、あるいは「トーンカーブ」
というメニューを用いて、これを変更する。
「トーンカーブ」による補正の場合、コントラストを増強する
には、例えば「Ｓ字トーンカーブ補正」を行うと良い。
開発した自作の「シグモイド改関数」による、「自動Ｓ字
（トーン）カーブ補正」の模様の図示。
この画像処理では、パラメーター（係数）を変化させる事で
色毎（RGB毎）のコントラストを増強する効果が得られる。
で、一般的な画像編集ソフトでの「コントラスト増強」や
「Ｓ字トーンカーブ補正」を行った場合、画像中の明るい
部分は、より明るくなり、暗い部分は、より暗くなる。
（すなわち、明暗差≒コントラストが強調される）
ところが、この際、前述のヒストグラムを考察してみると
ヒストグラムの幅がコントラストの増強で広がる事となり、
ヒストグラムに「抜け」が生じ、「櫛型」(comb)となる。
（工学分野の技術用語では、「ディップ(dip)が生じる」、
あるいは「ノッチ(notch)が発生する」とも言う）
ヒストグラムが「櫛型」となった例である。
この状態を、画像編集界の用語では「トーンジャンプが
発生した」と呼ぶ。
トーンジャンプ（の発生）は、画像中に存在しない輝度
（やRGB）があるという事となり、一般写真（自然写真）等
では目立たないが、グラデーション状に輝度や色が変化する
画像やイラスト等では、あるいは、それらの印刷の際には、
これが目立ってしまうケースもある。
なお、コントラスト増強処理の逆で、コントラストの減少
（圧縮）処理を行った場合は、ヒストグラムの幅が狭まる為、
「逆櫛型」（＝上向きのトゲトゲが生じる）のヒストグラム
となる場合がある。
まあしかし、「コントラストを減らす」画像編集を行う事は
かなり稀な状況だと思うので、「逆櫛型のトーンジャンプ」
は、一般的には、あまり見る事は無いであろう。
---
さて、で、本記事での画像処理ソフトウェア開発だが、
この「トーンジャンプ」を検出するソフトを作ってみよう。
また、可能であれば、このトーンジャンプを補正したり
緩和できる処理も入れてみたいと思う。
「トーンジャンプを検出する」意味、意義であるが・・
1)画像編集時にこれが発生しているという課題を確認する。
2)可能であれば、この検出で「画像編集前」「画像編集後」
を区別（スクリーニング）してみたい。
3)過度なレタッチ（画像編集）を行うと、これが発生する
場合があるので、そうした「過度な画像編集」を行って
いるか否か？を確認する。
4)画像を改ざん（大きく改変している）事を確認する。
これらの用途の内、1)と2)は、あくまで自分用であるが、
3)と4)は自身の他、他者の画像に対しても有効かも知れない、
まあつまり、「画像を大きく改変しているかどうか？」が
確認できるならば、その「証拠能力とか信憑性」についても
判断できるかも知れない訳だ。
----
・・だが、このソフトを作っていくうちに、現代の多くの
（市販等の）画像編集ソフトでは、コントラストの大きな
増強処理等を行っても「トーンジャンプ」が、思っていた
よりも発生し難い事に気づいた。
まあつまり、トーンジャンプは処理上での弱点とも言える
訳だから、その対策を行っているソフトが多いのだろう。
う～ん、それだと、トーンジャンプを確認する為の
サンプル画像を多く集めるのが難しいでは無いか・・
また、今回の研究開発も「失敗」の結果となってしまう
のであろうか？（汗）
いや、絶対、このソフトは何らかの用途がある筈だ、
適切なサンプル画像が無ければ、自分で作ってしまえ。
ものだが、盛大に「トーンジャンプ」が発生している事が
わかる。
実は、これの元画像は、
＊デジタルカメラのエフェクトを使用した加工写真で、
＊そこに自作のAWB（オートホワイトバランス）処理の
「試作品」による演算を行い、
＊さらに、コントラストを強く増強したもの
である、そうした「過剰処理」を繰り返した写真は以下
のような感じとなる。
（まあ、もっとも、近年の観光ポスター（チラシ等）の
写真の一部には、紅葉とか夜景の状況を「盛って」いて、
これ位のレベルにまで不自然な掲載写真も増えている。
つまり、そうした不自然に「盛った」写真を本ソフトで
判定して、その信憑性を疑うような事もしたい訳だ）
で、ここまで大きく写真を加工（改ざん）するならば、
これはトーンジャンプ検出処理に適正なサンプル画像となる。
しかし、本ソフトの目的の1つに「写真の改ざんの確認」が
あったのに、自分で、せっせと「改ざん写真」を作っている
ようでは、なんだかなぁ・・という感じだ（苦笑）
今回のソフトの計算アルゴリズムは、まあ原理的には簡単
ではあるが、計算処理の手順は、やや長いものになりそうだ。
・・なので、操作部（GUI）と、計算部（計算エンジン）を
別々に開発し、最後に合体する事とする。
GUI部は、C#（.NET Framework）で開発する（上図）
計算エンジン部はシーケンシャル（連続的）な処理で
あるので、それが得意なC++言語を使用する（下図）
オリジナルであり、他のWeb上や書籍等にあるソースコード
を参照・引用したものでは無いし、画像処理ライブラリ
（OpenCV等）の関数をインポートしたものでもない。
全ソースコードを自分自身で考え、打ち込んだものである。
実は、今回の開発手順は、先に計算エンジンを完成させ、
後からGUI部を作った次第だ。
・・と言うのも、ちょっと新規の計算アルゴリズムが
成立するかどうか？が不明だったので、それが上手く
いったらGUIを作るという手順となった、万が一、計算
エンジンが失敗した場合、GUI部を作らないでも済む、
という感じである。
計算エンジン部の開発は、予想通り手間取り、時間が
かかってしまい、延べ3日ほどかかってしまった。
まあ、その分、GUI部の開発は簡略化して、数時間
程度の作業で済んでいる。
今回のGUI開発でのポイントは、画面右上部にある
フォルダー内画像のサムネイル（縮小）表示だ。
これはC#でのControlの「ListView」と「ImageList」
を組み合わせて実現をする。（注：この手法を使った
場合、サムネイル画像は自力で生成する必要がある。
そのサムネイルの画素数（解像度）は、自身で任意に
決める事はできるが、サムネイルの「表示間隔」は、
どうも、Win OSでのアイコン表示間隔の設定に依存し、
自力では変えられない模様である→対策は、この時点では
未考察であったが、後日、特殊な手法で解決している）
計算処理は、入力フォルダー内の複数画像を一括で連続
計算する。今回の計算処理は、若干複雑ではあるのだが
計算コスト（＝計算の手間、速度）は、あまり大きく無い
ので、小画素（数十万画素）であれば、画像1枚あたり
コンマ数秒、大画素（数百万～千数百万画素）でも、
1枚あたり数秒程度で計算が完了する。
（その為、計算の進捗を示す「プログレスバー」の搭載
は省略している。あまり計算時間はかからないからだ）
また、計算後に前述のサムネイル画像をクリックすると、
それが選択され、当該画像、およびそのヒストグラムが
表示されるように作ってある。
する事にした。このアルゴリズムは、本シリーズ第3回
「高精度ピーキング比較ソフトのプログラミング」
（Twin Peaks）で研究開発したものと同じである。
前述の「改ざんの判定」である。
すなわち、ピンボケ写真をシャープネス処理等で過度に
輪郭を強調したりする編集が行われている、あるいは
他の画像から被写体を切り出して（注：それはピントが
合っている）、別の写真に貼り付けたような「画像合成」
編集が行われている場合、ピーキングの結果が不自然に
なるだろうから、それを見て、写真の過度な編集、または
改ざんが行われているかどうか？を目視で判定する訳だ。
ただ、ピーキング効果の効き具合の設定はGUI操作が
煩雑になる事を避けて、固定の閾値とした。これにより、
少々弊害が出てしまったのだが、それは後述する。
さて、ここまで出来上がったところで、トーンジャンプ
が発生しているかを確認してみよう。
フォルダー内の複数画像中、トーンジャンプが発生して
いる画像は、画面サムネイルエリアに表示された画像に
「赤枠」が追加されて表示される。
加えて、当該画像のYRGBヒストグラム上にトーンジャンプ
が発生した値に対して、黄色の直線が図示される（下図）
のみの検出である。
コントラスト減少処理等で「逆櫛型」（トゲトゲの「ピーク」
が複数発生している）の検出処理の実装は、ちょっと現時点
では省略している。
（画像処理アルゴリズム的には、ヒストグラムの「ピーク」の
検出は難しくは無いが、そこで得られた複数の「ピーク」値が、
どのような状態になった場合に、「これは逆櫛型である」と
判定する手法が、すぐには思いつかなかった為に割愛した。
まあ、「あまり低コントラスト化処理は多くないであろう」
という判断もある）
これらの画像処理における途中経過は、中間処理画像、
ヒストグラム画像、CSV形式のデータ、各々の出力で対応
している。
何か、開発中の画像処理アルゴリズム上で懸念事項があれば、
それらの中間（出力）ファイルを見て、画像処理の振る舞い
を確認する訳だ。
（注：これを省略すると、アルゴリズム開発の難易度が
いっきにあがる。なお、アルゴリズム完成時には、こうした
中間出力ファイル群を出力しないように、#define等の
フラッグ/スイッチで制御できるようにプログラムを組む）
下図は、そうした中間ファイルである。
（これはヒストグラムの値をCSVファイルに書き出し、MS
Office Excel/Open Office等で確認できる状態とした物）
個人的に、様々な画像編集ソフト上での、ヒストグラムの
画像表示に、不満を持っている。
それは、ヒストグラムの横軸は、輝度YあるいはRGB毎の
輝度値であり、通常これは8bit処理だから、0～255の
範囲に収まる、まあ、変な事（例：色相(Hue)を色相環に
応じた0～359°の範囲でヒストグラム化する等）を
しなければ、一般的なヒストグラム横軸はいつも固定だ。
ここは何も問題は無い。
値にはならない）の状態となっている。
例えば、単純な例を挙げれば、100万画素の真っ黒な
画像をヒストグラム化すると、輝度0のヒストグラム値
は100万という数値となり、他の輝度値は全てゼロだ。
しかし、他に、満遍なく輝度等が混ざり合っている画像を
ヒストグラム化すると、その最大値は、恐らく3900
程度となる（100万画素÷256段階≒3900）
同様に、入力画像の画素数が変わると、このヒストグラムの
最大値は、いかようにも変化してしまう。
で、ヒストグラムの縦軸で、その最大値を表示できるように
正規化（ノーマライズ）すると、大きな最大ピーク値
（例：殆どが漆黒の天体写真だとか、殆どが青空の写真とか）
を持つ画像の場合、その最大値を表示する為に、他の輝度
要素が、ヒストグラムの下部にチラホラとしか表示されない。
これはとても見にくいので、なにかしらの対策を施したい
と常々思っていた。
考えられる対応は、以下がある。
1)大きなヒストグラム最大値を、ある一定の上限値で
止めてしまう。
2)ヒストグラムの縦軸表示スケールを指数関数とし、
大きなヒストグラム最大値を、あまり大きな座標とは
せず、逆に小さいヒストグラム値を増強して表示する。
この内、2の手法は、ごく稀に一部の画像編集ソフトに
Linear/Exponential (直線/指数）のヒストグラム表示
切り替えがついている。だが、一々それを切り替える
のも面倒な操作だ。
なお、カメラ上でのヒストグラム表示は、このような
課題はあまり発生せず、比較的見やすいものが多い。
考えた結果、本ソフトにおいては、ヒストグラム画像の
生成に、2つほどの工夫を凝らしている。
まず1つは、ヒストグラム加算対象輝度に上限値と下限値
を設ける事だ。具体的には、Y(RGB)<16 という値は
画像上の、ほぼ真っ黒な部分を示すので、こういう部分は
ヒストグラム化しても、あまり意味が無いし、むしろ
この値がヒストグラム最大値になってしまったら、他の
輝度値（等）が見えにくくなるので困る。
だから思い切って下限値以下のヒストグラムをカットする。
（注：これは、あくまでヒストグラム表示に関わる処理で
あり、画像処理上で最低ラインをカットしている訳では無い）
で、同様に、例えば Y(RGB)>240 といった値は、
ほとんど真っ白な画像部（空等が白とびしている等）
であるから、これも上限値以上をカットする。
第二の工夫として、上記の上限下限値のカット後に残った
ヒストグラム値の最大値の値から、自動的に適正な指数関数
の係数を求めて、それをヒストグラムの縦軸の正規化処理の
内容（計算手法）とする事だ。
これらにより、例えば、特定の輝度に大きなピーク値が
ある特殊な画像の場合でも、比較的見やすいヒストグラムを
生成する事ができる（下図がその例）
ピークが極めて大きく、他の輝度が殆ど表示されない
ケースであるが、この処理でなんとか様子がわかる。
なお、一般的な「ヒストグラム表示」（＝正規分布の
ような、釣鐘状のグラフが表示される）とは、ずいぶんと
見た目の印象が変わるので不自然に感じるかも知れないが
「綺麗にヒストグラムを表示する」のが目的では無く、
「細かい部分の様子まで見たい」が、今回の目的であるので
見た目の異様さは無視する。まあ、いずれ慣れるであろう。
縦軸はこれで、Adaptive（適応型）のScalable（変動型）
になったので、様々な画像の特徴に応じて、ヒストグラム
の詳細が見やすい状態となる、別の画像で試してみよう。
前述したように、「写真改ざんの確認」の為に、独自開発
のピーキング・アルゴリズムを搭載している。
このピーキング・アルゴリズムは、非常に高精度だが、
計算量が多いので、リアルタイムでの処理は出来ない
（例えば、カメラに組み込んで、撮影時にピーキングを
出す事は無理だ。あくまで撮影後の「事後処理」である）
つまり、あまりピーキング表示の閾値を低めてしまうと、
画面内の多くの部分に、ピーキングが反応（検出）して、
その何処が不自然なのか？（つまり、画像内での部分的な
過度なシャープネス編集や、他の画像からの部分合成編集
を行った証拠）を、発見する事が難しくなる。
そこで、今回のピーキングは、検出を思い切り厳しく
（すなわち、非常に弱い閾値による検出）を試してみた。
すると、結果は以下のようになった。
一見して見えるのだが・・
良く良く見ると、これは殆ど「輪郭抽出」（の画像処理）
と同等の効果だ。
つまり、完全自作のピーキング・アルゴリズムにおいては、
その処理を弱めていくと、だんだんと、一般的な画像処理
の教科書にあるような「輪郭抽出を試してみましょう」と
いったビギナー的な内容と、効能が変わらなくなって
しまう（汗）
何故、それがまずい事なのか？ と言えば、「成果物の
差別化が出来なくなるから」である。
どんな職業分野でもそうだが、ベテランや上級者等が
新入社員等と同じ（レベル）の仕事をやっているようでは
意味が無い。
カメラの世界で言えば、職業写真家層が、ビギナーの
アマチュアカメラマンでも撮れるような写真を撮って納品
していたら意味が無いのだ。
それらは「差別化が出来ない」というよりも、もっと深刻
には、「あの人に仕事を頼んでも、初心者と同等の品質の
ものしか出来上がってこないから、もう頼むのは止めよう」
となり、仕事を失ってしまう危険性がある事だ。
だから、基本的には、あらゆる業務分野で、その成果物は
その専門家が作るものであれば、初心者の作るものとは
明確に差別化が出来ていなければならない。
ただまあ、その考え方が強すぎると、今度は逆に、
「本来は簡単な内容を、わざわざ難しくレポートする」
（例：専門書、論文、Web上の専門サイトに、そのような
悪い例が蔓延している。著者自身の優位性や差別化要因を
確保しようとするあまり、わざわざ難解なように文章等を
書いてしまう訳だ、これは好ましくない） あるいは
「本来は単純な事務処理を、わざわざ複雑化する」
（例：お役所仕事や大企業の事務処理等で、そうした例が
散見される。つまり本来は単純な業務であるのに、その
担当者でないと処理が出来ないくらいに複雑化してしまう、
まあ、担当者の「保身」の意味も多々あるのだろう）
・・といった、いきすぎた状態にもなってしまうので、
まあ「差別化」も、その「程度や倫理」を考えて、適正な
レベルに留めておくのが良いであろう。
ただまあ・・ 今回（本シリーズ）の画像処理研究開発は
業務ではなく、常に「趣味のレベル」である。
まあなので、あまり「差別化」等は意識する必要は無いが、
それでも、「初級エンジニアの行う輪郭抽出処理と同等」
というのは、ちょっと気に入らない。
いずれ、この「ピーキング・アルゴリズム」もAdaptive
（適応型）に改善し、画像毎の特徴を見ながら、適正な
ピーキング検出量を得られるようにしていこう。
（まあ、いつの事になるか、わからないが・・汗）
---
さて、残る処理だが、「トーンジャンプの改善（補正）」
である。
せっかく「トーンジャンプ」が検出できるのだから、
今度は、それを自動補正して、トーンジャンプを出さない
画像に加工できないだろうか？
画像処理アルゴリズムを自作しているので、画像の内部の
全てのデータを、PCは把握する事ができている。
「だったら、トーンジャンプを起こしているところを
見つけたら、それを平均化したら良いのでは？」という
簡便な解決法を思いつくであろう。
ただ、その方法は簡単にはいかない。
何故ならば、「トーンジャンプを起こしている」というのは
（それが「櫛型」ならば）「存在していないものを探す」
という事になる。いくら画像のデータを（配列等に格納し）
全て把握していても、「無いものを探す」のは困難なのだ。
画像編集者（レタッチャー）の上級層等での対策は、
どう行っているのだろう？ と思って、少し調べてみると
たいていの場合、別レイヤーを準備し、そこにノイズ状の
データを振りまいたり、あるいはさらに、ぼかし（ガウス）
処理を掛けたりして、そのレイヤーを元画像に合成し、
トーンジャンプを目立たなくしているようだ。
ただ、これは「画像の全領域でその処理をしている」事と
「目立たなくする為に、手動調整が必要」な事と、および
「ヒストグラム上でのトーンジャンプが目立たなくなった
としても、実際の画像上で、その編集の効能があるか
どうか？は別問題」
・・といった、いくつかの課題が散見された為、それらの
画像編集者的な手法を画像処理手順化することは見送った。
「画像処理には、画像処理のやり方がある」という事で
あるし、そういう風に、「画像編集」では、手が届かない
細かい所まで、画像をいじくれる（加工編集できる）事が
画像処理（工学）の、大きなメリットな訳だ。
するか？
暫定的な手法だが、
1)トーンジャンプが発生した輝度値（複数ある）
を記憶しておく。
2)画像の全域をラスタスキャンし、トーンジャンプ
発生の輝度値と隣接するエリア（領域）を見つける。
3)見つけた「危険領域」に対して、周囲のピクセルと
調和させる空間フィルター処理（平均化、メディアン、
ガススぼかし、のいずれか、または複合処理）を掛ける。
・・という手順をアルゴリズム化し、計算エンジンに
組み込んでみた。
それによる補正結果は、以下写真の通り。
良くわからない（汗）」というのが実際のところだ。
「トーンジャンプの自動補正」に関しては、今後、もう少し
処理アルゴリズムの改良が必要であろう。
まずは、トーンジャンプが目立ちやすい画像、等を
複数準備しなければならないし、画像内でのトーンジャンプ
危険領域を自動抽出した結果も図示しないとならないし、
補正アルゴリズムも、もっと強力な処理が必要だ。
多分、「バイラテラルフィルタ」のようなものが有効かも
知れない(？） その「バイラテラル」は、以前、論文を
参考にして自作しているものがあるが、処理が重い（遅い）
ので、殆ど使用していない。また、デバッグも済んでいない
ので、ちゃんと動いているかどうかも、良くわからない。
いずれにしても時間がかかりそうだ、仕事ではなく趣味で
やっている作業なので、気がむいた時しかプログラミングは
やらないし、趣味において、そこまでの高い「研究レベル」
にまで、のめり込むか？どうかは微妙だ。
・・まあ、なんとなく、この時点で、飽きてほったらかしに
しそうな気がする（汗）
----
今回のプログラミング研究の成否は、「△」であろう。
・・で、本シリーズ記事での通算の研究成功率だが、
総合成績＝5勝5負5分け、勝率（成功率）＝3割3分3厘
となった。
下限と思っている「成功率3割」に、だんだん近くなって
来てしまっている（汗） もし成功率が3割を切ったら
「効率が悪い事をやっている」という判断で、この
シリーズも辞めてしまうかも知れない。
次の研究開発は、是非成功させたいものである。
では、今回のトーンジャンプ検出編記事は、このあたり
までで、次回記事（不定期、内容未定）に続く。