「画像処理プログラミング」シリーズ第20回記事。
本シリーズでは、「画像処理」、すなわち、写真等の
デジタル画像のピクセル毎に数学的な演算をPC等で行い、
その結果としての、検出、抽出、判断、変換、加工等を
行う為の技術（テクノロジー）を新規開発し、実現する
事を目指している。
![_c0032138_06531984.jpg]()
アプリ等に搭載されている画像編集機能である、
「カラー写真の中から特定の色を抽出して、それを
モノクロ画像の上で表現する」という処理を
自作のソフトウェアで実現する事を目指す。
で、その編集機能名は、カメラメーカー等ごとに
異なるが、「セレクトカラー」「スポットカラー」
「ワンポイントカラー」「モノカラー」「色抽出」
等と様々に呼ばれている。（以下「色抽出」と呼ぶ）
で、それらのカメラに搭載された「色抽出」処理は、
概ね1～3色を選択し、かつ抽出の強度を選ぶ事が
できる事が普通なのだが、課題として・・
「（有限個の）選んだ色しか抽出表示されない」
「選んだ色が、そのまま表示できるだけ」
「横浜写真（本シリーズ第1回記事参照）のように
選択色を代表色に置換できない」
「モノクロがベースとなり、セピアカラー上に
表示できない」
という不満があった。
ちなみに、「横浜写真」とは、明治時代の初期に
横浜で発祥した、外国人向けの「土産品」としての
絵葉書のような加工（彩色）写真であり・・
カラー写真がまだ無い時代であった為、実際の写真
（モノクロや若干のセピア色）に、絵師（職人）が
一々、手で彩色（色を塗る）を加えたものだ。
これは、絵画と写真の中間的なものと言えよう。
「横浜写真」は、独特の色味が個人的に興味深い
のだが、手間のかかる製作の為に、恐らく、数は
少なかったのであろう。現代においては簡単には
入手できるようなものでは無い。
おまけに、土産品であるから、日本国内ではあまり
現存しておらず、稀に、博物館等で見れる程度だ。
で、後年には勿論、カラー写真や印刷の絵葉書に、
とって代わられてしまっている。
![_c0032138_06531967.jpg]()
ソフトウェアを自力開発する事としよう。
１）選択色は、最大12色（色相）として、
ほぼ全ての色が抽出できる事。
２）抽出強度を４段階程度に選べる事。
３）選択した色は、いくらでも（最大12色）
複数重ね合わせる事を可能とする事。
４）色を乗せるベースは、モノクロとセピアが
選択できる事。
５）色を乗せる際に、選択色の色相を12段階で
変化させ、色相変換（置換）を行える事。
６）描画色に「横浜写真」のように、代表色を
自動的にベタ塗りができる事。
これの画像処理のアルゴリズム（計算手順）は
結構、簡単である。
様々な色変換処理を繰り返せば良いので、本ソフト
の開発の為に、新たに考え出す事（≒研究要素）は、
殆ど無い。
冒頭の図で、色変換したハスの画像を以下に示す。
![_c0032138_06531941.jpg]()
カメラの内部エフェクトでしか実現されていないか？
（＝画像編集ソフトには、あまり搭載されていない）
については、まずこの処理内容はカメラ上の画像処理
エンジンで、とても簡単に実現できる事が１つある。
それと、これを画像編集ソフトに搭載しようとすると
まず、操作性が繁雑となる点が１つ、さらには、この
処理を行って色抽出した画像を、その後どう扱うのか？
つまり特定の色を選んだ他はモノクロ写真であるから
そこで処理が「終わり」となって、その後では何も
色に関係する編集を行う事ができなくなってしまう。
・・なので、この「色抽出」は、通常、カメラ内の
エフェクトとして搭載され、画像編集ソフトでは
あまり前例が無い状態なのであろう。
さて、このソフトの名前を「Cross Color Converter」
と称する事としよう。
「Cross」は、交差する、という意味を持ち、
つまり、「色を交換・置換する」というイメージだ。
（注：本記事でのソフトの画面では、CCC Closs・・
と、スペルミスをしている（汗） まあ、ソフトの
名前は後で直したのだが、もう、本記事では、この
ままの状態で画面の画像を掲載しておく）
で、もうソフトの仕様も決まっているし・・・
だいたい、２時間以内での完成を目指して、早速、
プログラミングを開始する。
![_c0032138_06531906.jpg]()
言語はC#（.NET）のみである。
まあ、もはやクラッシックな開発環境ではあるが、
プログラミング言語を、もっと新しいものに変えた
ところで、「凄い機能のソフトが作れる」だとか、
「ソフトが速く完成する」という訳でも無いだろう。
（例えば「新型のカメラを買えば、もっと凄い写真
が撮れるかも知れない」と勘違いをして、高価な
カメラに買い換えてしまうビギナー・カメラマンも
これと同じ事だと思う。カメラやコンピューターは
あくまで「目的を実現する為の道具」でしか無い）
むしろ、手馴れていて、そして、この言語で過去に
開発した様々な成果物（ソースコード）を転用する
事で、恐ろしく効率的にソフト開発が出来る。
だから「2時間で作る」と言ったのは、決して無茶な
話では無い次第だ。
画面のイメージは、沢山のスライダー（TrackBar）
が並び、あたかも「音響（用）ミキサー」だとか、
「アナログ・シンセサイザー」（電子楽器）や
「グラフィック・イコライザー」（音響機器）の
ような雰囲気である。
まあでも、こういう雰囲気の機械は個人的にも好み
であり、昔から現代に至るまで、色々とこうした
沢山のスライダーが並ぶ音響機器を所有している。
でも、世間一般では、沢山のツマミ等が並ぶ機械を
前にすると、たいていビビってしまう模様である。
何故かと言えば、それらの沢山のツマミ等の操作子
の効能が良くわからないから、「一度動かしてしまい、
元に戻せなくなったら、どうしよう？！」と不安に
思ってしまうのが理由なようだ。
だが、音響ミキサー等では、単に同じ効能のものが
沢山並んでいるだけである。そこにヴォーカルやら
ギターやらドラム等から来る音声信号が、アサイン
されて（割り振られて）いるだけだ。
だから、「どのフェーダーに、何の楽器がアサイン
されているか？ 配線した人で無いとわからない」
という課題はあるものの、個々の操作子の意味が
わからないという事態には、まずならないと思う。
（注：これがシンセサイザーの場合には、多少は
構造や原理の理解が必要だ）
ちなみに、沢山の操作子が並んでいるメリットと
しては・・
「全ての操作子の状態が、目視で一目瞭然な事」
「複数の操作子を同時に操作する事が可能な事」
「電源がOFFの際とか、デジタル的な表示が無い
場合でも、固有の操作子を所定の値まで操作が
可能な事」
といった、多数の利点がある。
対して、弱点は、
「操作子が多すぎる場合、状態が把握しにくい」
「同、多すぎると、一定の数くらいしか、同時には
操作する事ができない」
「場所や面積を喰い、機器が大型化してしまう」
「個々の操作子の設定を、記憶させる事が困難。
たとえ記憶できたとしても、それらを動かして
しまうと、記憶値と現在値での矛盾が出てしまう」
となっている。
（注：この事は、音響機器とかソフト等に限らず、
カメラでも、あるいは多くの機器（例：飛行機の
コックピット等）とかでも、同様だと思う）
このうち「操作が面倒だ」という弱点に関しては
本ソフトでは、一応だが「デフォルト復帰」という
機能を付ける。このボタン一発で初期値に戻す事を
可能としよう。
もし、さらなる高機能にしたい場合は、
１）設定の記憶機能を付ける。
（注：これは仮想のソフトウェアであるから、
記憶値と設定値が異なる場合、瞬時に操作子の
位置を画面上で移動させる事が出来る。
もし、これが実際の物理的な音響ミキサー等では、
「モーターフェーダー」と言って、沢山のツマミを
全てモーターで記憶値にまで動かす、といった
とても大掛かりな機械的な仕組みが必要となる）
２）いくつかの代表的なプリセット値を設ける。
（例：黄色を抽出して青色に変換する措置等）
といった機能を、後から追加してあげればよい。
![_c0032138_06541324.jpg]()
ここまで、宣言どおり２時間もかからず出来たのだが
いざ動かしてみると、早速、大きなバグ（ミス）を
発見してしまった。
どうも色相（色味）の並び方がおかしい・・
例えば、色相は、赤から紫まで、360度という
単位で表現される場合があり、本ソフトでも、
その360度を12分割し、30度刻みで、色相を表示、
調整できるように作ってある訳だ。
原因を調べてみると、沢山並んでいるツマミ
（TrackBarコントロール）の順番がおかしくなって
いる。左から順次1番、2番、3番・・・12番で
なくてはならないのに、1,2.3,4,8,7,6・・ の
ような、変な順番となっている。
これの原因だが、沢山のツマミを並べるのが
面倒で、1～4個まで作ったところで、それらを
コピーしてペーストした事が課題であった。
5,6,7,8のように順番が並んでいるとばかり
思っていたのに、実際には、8,7,6,5のように
貼り付けた際に、逆順となってしまっていた。
これは要注意だ、C#言語で複数のコントロールを
まとめてコピーする際、「期待する順番どおりに
並ばない可能性がある」という事である。
なお、こういう開発手法だと、複数のコントロール
毎に、同じようなソースコードを書く必要があり、
なんだか手間だし、スマートでも無いと思う。
だが、例えば、コントロールを配列化したりすると、
ソースコード量は激減するが、プログラミングが
複雑化したりして、余計に時間を喰ってしまうと
思われる。短時間でプログラミングをする場合は
多少ベタでスマートではなくても、同じコードを
コピペして作った方が早いし、バグも出難い。
あと注意点だが、沢山のツマミを並べている最中
に、画面の背景用に「パネル（Panel）」という
部品（コントロール）を貼り付けているのだが、
これの貼り付けのタイミングや手順によっては、
ツマミ（TrackBar）の座標が、ソフト全体での
絶対座標か、あるいはパネル上での相対座標か、
の差異が発生してしまうようだ。
この座標系の差は、プログラム自体の効能（動作）
には影響が無いので、各コントロールの「親子関係」
（≒どの背景に属するのか？）を調整するまでも
無いのだが、ツマミの位置をデザイン的に揃えよう
として微調整している時に、座標が違っている事が
ちょっと気になった。
・・という事で、沢山のツマミを正しく並べ替えた
ところで、プログラムが完成。2時間少々掛かった
が、ほぼ予定通りだ。
![_c0032138_06532911.jpg]()
変換しつつ、モノクロの画面上に自動生成してみる。
何も問題なく動作しているようだ。
また、各ツマミの抽出量や置換量、効能のON/OFF
も正しく動作している。
なお、注意点だが、各ツマミの効能のON/OFFには
「チェックボックス」（四角の中にチェック印）
というコントロール（≒操作子）を使っている。
これを「ラジオボタン」（丸の中に点）にした方が
デザイン的には格好良いと思うのだが・・
「ラジオボタン」は一般に、複数のグループの中
から１つだけを選択する際に使うものであるから、
パネル上、等に配置して（半自動的に）グルーピング
を行うと、どれかのラジオボタンを押したら
そこだけが有効となり、他が自動的にOFFになって
しまう。つまり、「複数のラジオボタンを同時に
選択する事ができない」状態となる。
この問題を回避する手段は、無い訳では無いのだが
繁雑であり、ちょっと採用する気にはなれなかった。
（以前に試してみて、とても面倒であった）
やむなく、デザイン的には不恰好だが「チェック
ボックス」を、そのまま使う事としよう。
後、下部の色相変換のツマミ群は、現時点では
「相対置換値」となっている。つまり、「全ての
ツマミの値を最も下げた状態が、元の色相を
そのまま踏襲する」という意味（仕様）である。
したがって、同じツマミの高さ（値）にした場合
では同じ色相が得られる、「絶対置換」では無い。
従前の、本シリーズ第8回「野獣派」変換プログラム
では、「絶対置換方式」を採用したのだが、
そのソフトでの色相変換数は、6色であった。
今回は12色と増えているから、あまり複雑な設定は
やりにくいと思ったからだ。つまり絶対置換の場合に
おいてデフォルト（色変換なし）にしたいならば、
12個のツマミを細かく階段状に設定しないとならない。
プリセットやデフォルト復帰のボタンを使わない限り
それは操作が繁雑だ。今回の「相対置換」方式ならば
全てのツマミを全部ゼロ（一番下）に動かしてやれば
位置を微調整しなくても、「色変換なし」とできる。
ただ、この方式の場合、ツマミの位置関係を見た
だけでは、どの色に変換されるかがわからない。
勿論、画面下部に変換された後の色相が表示される
のだが、「どちらの方向に、どれくらい動かしたら
どんな色になるのか？」が、ツマミ操作時には
予想が難しい訳だ。
まあつまり、どちらの「操作系」を採用した場合
でも、一長一短ある、という事がここでわかった。
今後、似たようなソフトを作る場合は、状況に応じて
両方式を使い分ける事としよう。
![_c0032138_06532999.jpg]()
処理を行っている写真に対して、さらにクロスカラー
（＝別の色に置換する）の処理を加えてみた状態。
勿論、赤色が緑色へ変換され、正しく動作している。
だが、なんだかこのあたりで「面白くない」という
事に気づいてしまった（汗）
何が面白く無いのか？と言えば、このソフトでは、
狙った色に対して違う色を割り当てる、という処理が
出来るのだが、この動作は、ほぼ「予想通り」の結果
となる。
すなわち、思うような結果にする為、様々な操作子
（しかも沢山ある）を、個別に微調整しなくては
ならない。しかも、結果が予想通りであれば、もう
それは「創造的な活動」ではなく、単なる「作業」だ。
![_c0032138_06533034.jpg]()
例である。
前述の、「単なる作業」、という話だが・・
そういえば、自分でも思ったが、個人的には、写真の
撮影時において「後で画像編集すれば良い」等とは
あまり思わず、撮影時に様々なカメラ設定を行って撮り、
できるだけ後編集を避けるような事をいつもしている。
(注：RAW現像も一切しない。全てがJPEG撮影だ）
これについては「撮影時に被写体に対峙して感じた事は、
後では再現できない」という、もっともらしい理由を
いつも述べてはいるが、実のところ「単純な作業が嫌い」
という事が原因なのかも知れない（汗）
・・ただ、その結果として、カメラ設定が効率的では
無い機種では、撮影時の細かいパラメーター設定操作が
やりにくくなってしまい、とても困る。
つまり、そうした「操作系・操作性が悪いカメラ」は、
本ブログのカメラの紹介記事でも、いつも低評価と
なってしまっている次第だ。
だが、現代の大半の初級中級カメラユーザーでは、
カメラ設定等は、せいぜい絞り値や露出補正、AF測距点
を変更する位で、他は、全く触らずに撮影している
だろうから、こういった評価内容は、他者には参考に
ならない事だ。
（つまり、ユーザー個々に、写真を撮る目的もスキルも
全てが異なる訳だから、他人の評価は参考にならない、
という意味である）
![_c0032138_06542210.jpg]()
オールド・デジタル一眼レフ（NIKON D2H、2003年）
で撮った写真で、ちょっと薄い色味である。
しかも、そのカメラは、カメラ本体内での画質調整
機能を持たず（特殊なセンサーを使っていたからだ）
その点、当時のユーザー層に不評であった次第だ。
本来、こういう薄い色味は、任意の画像編集ソフトで
調整すれば、どうにでもなる話である。
今回は、ちょっと別のアプローチとして、本ソフトを
用いてみる。
まずこの写真をセピア色に変換してしまい、全体的に
モノトーン化する。
そして背景にある青い光だけ活用し、それを抽出して
赤色の光に変換してみよう。
すると以下のようになる。
![_c0032138_06544162.jpg]()
あ、それと、本ソフトでは「CONVERT」ボタン、
つまり「計算開始」ボタンがついているが、思えば
それは不要だったかも知れない。
この画像処理は比較的単純であり、多くの計算量を
必要とするものでは無いからだ。
だから、何かのスライダーやボタンを触った直後に
自動的に計算を開始する操作系でも十分だったと思う。
まあ良い、いずれ気が向いたら、「即時計算方式」に
プログラムを変更する事は容易だ。
![_c0032138_07243960.jpg]()
として撮っている、という次第だ）
これは珍しい事象であるから、さらに本ソフトで
加工して 「現実にはあり得ない色味」にしてみよう。
![_c0032138_06544446.jpg]()
色が違う、というだけで人間は全く別の感覚を持つの
かも知れない。
まあ、色彩心理学とか、そういう類の学問や研究も
あるし、そこまで学術的ではなくても、たとえば
芸術分野では、絵画の後期印象派や野獣派等においては、
「色彩を対象物の本来の色の束縛から解放」して、
新しい色を絵画表現に用いていた訳だ。
また、現代の商業デザイン等では、色の与える心理効果
を当然意識して、ポスターとか看板とか、企業のロゴ
マーク等をデザインしている。
まあだから、色が心理に与える効果というのは普遍的な
話だと思う。
さて、単なる色変換の「作業」だけでは面白くなく
なってきたので、本ソフトに備わる「FLAT TONE」機能
を試してみよう。
これは抽出した色、または置換した色の彩度を強調し
「ベタ塗り効果」を得る事ができる機能だ。
本シリーズ第18回記事の「Saturation補正ソフト」
と類似の原理・効能ではあるが、本ソフトにおいては、
「セピアカラー変換効果」と組み合わせる事で、
本シリーズ第1回記事の「横浜写真生成ソフト」の
類似/バリエーション的な効果が得られるのでは？と
期待するところがある。
![_c0032138_06544709.jpg]()
ポイントは女性の和服の色味の「黄、緑、青、赤」
そして、背景の橋の「朱色」を、どう変換するか？
というところなのだが、元写真には無い色味に変換
してしまうのは、少々やりすぎとなるだろうから、
元写真の色相を抽出しながら「FLAT TONE」機能で
彩度を一定のレベルに高めてみよう。
ベースは一応「セピア」とする、これで「横浜写真」
のようになるだろうか？
![_c0032138_06545091.jpg]()
は無く、全体に「濃い」色調に変換されてしまった。
どうも「ベタ塗り」(FLAT TONE)の機能は、使い道が
難しい模様だ。場合により、次のバージョンでは
「ベタ塗り」のレベルをコントロールできるように
プログラムを改変するのも良いかも知れない。
以下参考まで、本シリーズ第1回記事の「横浜写真
生成ソフト」「Yokohama Type1」を用いて
同じ写真の自動処理を行った結果を掲載しておく。
![_c0032138_06545327.jpg]()
よりも不自然ではあるが、元々「横浜写真」とは
職人（絵師）が彩色した擬似カラー写真であるから、
だいたいこんな感じに仕上がる事が普通だ。
だから、映像的な表現として考えれば、本ソフト
での、ありきたりの画像編集結果のような物よりも、
「横浜写真」の方が、面白いといえば面白い。
さて、「FLAT TONE」機能には、もっと別の使い道
は無いものだろうか？
例えば、夜景イルミネーションを「ぐるぐるボケ」
の特殊効果レンズを用いて撮った写真を、色相置換
と「FLAT TONE」化してみよう。
![_c0032138_06545710.jpg]()
基本的には、どんな色相に変換するのも「アリ」だ
とは思う。
でも、もはや、元の写真の色味は、もうこの結果
には存在しないから、ここでは勝手に自分の好きな
世界観を創り出している状態となる。
でもまあ、それはそれで現代のデジタル写真での
本質、という風にも考える事は出来るかも知れない。
もはや「写真とは”真を写す”と書く」といった
古い時代の概念は、全く成り立たない時代となって
いる訳だ。
----
最後に、本ソフトウェアの研究開発の成否だが、
一応は「○」（成功）という風にしておこう。
すると、本シリーズ記事のここまでの通算（総合）
成績は、以下のようになる。
総合成績＝8勝6敗6分、勝率＝4割0分0厘
本シリーズ記事でのルールとしての、最低ラインの
勝率3割を超えてはいるが、目標の勝率5割には
届かない。
でもまあ、ここのところ、あえて簡単な画像処理の
内容のソフトばかりを作っていて、「ちょっと勝率
を稼いでおこう」といった”よこしま”な理由も、
無きにしもあらずだ（汗）
あまり、こういうシンプルすぎるソフトをチマチマ
と作っていないで、次あたりでは、かなり難易度の
高い画像処理に挑戦してみるとしようか。
そう、本シリーズでの作業（研究開発）は、あくまで
趣味でやっている事だ。知的好奇心が満たせれば
良いのであって、本質的には、その研究が成功するか
否かは、ある意味、どうでも良い話だと思う・・
---
では、今回のプログラミング記事は、このあたりまで。
次回記事掲載は、例によって不定期としておく。
本シリーズでは、「画像処理」、すなわち、写真等の
デジタル画像のピクセル毎に数学的な演算をPC等で行い、
その結果としての、検出、抽出、判断、変換、加工等を
行う為の技術（テクノロジー）を新規開発し、実現する
事を目指している。
アプリ等に搭載されている画像編集機能である、
「カラー写真の中から特定の色を抽出して、それを
モノクロ画像の上で表現する」という処理を
自作のソフトウェアで実現する事を目指す。
で、その編集機能名は、カメラメーカー等ごとに
異なるが、「セレクトカラー」「スポットカラー」
「ワンポイントカラー」「モノカラー」「色抽出」
等と様々に呼ばれている。（以下「色抽出」と呼ぶ）
で、それらのカメラに搭載された「色抽出」処理は、
概ね1～3色を選択し、かつ抽出の強度を選ぶ事が
できる事が普通なのだが、課題として・・
「（有限個の）選んだ色しか抽出表示されない」
「選んだ色が、そのまま表示できるだけ」
「横浜写真（本シリーズ第1回記事参照）のように
選択色を代表色に置換できない」
「モノクロがベースとなり、セピアカラー上に
表示できない」
という不満があった。
ちなみに、「横浜写真」とは、明治時代の初期に
横浜で発祥した、外国人向けの「土産品」としての
絵葉書のような加工（彩色）写真であり・・
カラー写真がまだ無い時代であった為、実際の写真
（モノクロや若干のセピア色）に、絵師（職人）が
一々、手で彩色（色を塗る）を加えたものだ。
これは、絵画と写真の中間的なものと言えよう。
「横浜写真」は、独特の色味が個人的に興味深い
のだが、手間のかかる製作の為に、恐らく、数は
少なかったのであろう。現代においては簡単には
入手できるようなものでは無い。
おまけに、土産品であるから、日本国内ではあまり
現存しておらず、稀に、博物館等で見れる程度だ。
で、後年には勿論、カラー写真や印刷の絵葉書に、
とって代わられてしまっている。
ソフトウェアを自力開発する事としよう。
１）選択色は、最大12色（色相）として、
ほぼ全ての色が抽出できる事。
２）抽出強度を４段階程度に選べる事。
３）選択した色は、いくらでも（最大12色）
複数重ね合わせる事を可能とする事。
４）色を乗せるベースは、モノクロとセピアが
選択できる事。
５）色を乗せる際に、選択色の色相を12段階で
変化させ、色相変換（置換）を行える事。
６）描画色に「横浜写真」のように、代表色を
自動的にベタ塗りができる事。
これの画像処理のアルゴリズム（計算手順）は
結構、簡単である。
様々な色変換処理を繰り返せば良いので、本ソフト
の開発の為に、新たに考え出す事（≒研究要素）は、
殆ど無い。
冒頭の図で、色変換したハスの画像を以下に示す。
カメラの内部エフェクトでしか実現されていないか？
（＝画像編集ソフトには、あまり搭載されていない）
については、まずこの処理内容はカメラ上の画像処理
エンジンで、とても簡単に実現できる事が１つある。
それと、これを画像編集ソフトに搭載しようとすると
まず、操作性が繁雑となる点が１つ、さらには、この
処理を行って色抽出した画像を、その後どう扱うのか？
つまり特定の色を選んだ他はモノクロ写真であるから
そこで処理が「終わり」となって、その後では何も
色に関係する編集を行う事ができなくなってしまう。
・・なので、この「色抽出」は、通常、カメラ内の
エフェクトとして搭載され、画像編集ソフトでは
あまり前例が無い状態なのであろう。
さて、このソフトの名前を「Cross Color Converter」
と称する事としよう。
「Cross」は、交差する、という意味を持ち、
つまり、「色を交換・置換する」というイメージだ。
（注：本記事でのソフトの画面では、CCC Closs・・
と、スペルミスをしている（汗） まあ、ソフトの
名前は後で直したのだが、もう、本記事では、この
ままの状態で画面の画像を掲載しておく）
で、もうソフトの仕様も決まっているし・・・
だいたい、２時間以内での完成を目指して、早速、
プログラミングを開始する。
言語はC#（.NET）のみである。
まあ、もはやクラッシックな開発環境ではあるが、
プログラミング言語を、もっと新しいものに変えた
ところで、「凄い機能のソフトが作れる」だとか、
「ソフトが速く完成する」という訳でも無いだろう。
（例えば「新型のカメラを買えば、もっと凄い写真
が撮れるかも知れない」と勘違いをして、高価な
カメラに買い換えてしまうビギナー・カメラマンも
これと同じ事だと思う。カメラやコンピューターは
あくまで「目的を実現する為の道具」でしか無い）
むしろ、手馴れていて、そして、この言語で過去に
開発した様々な成果物（ソースコード）を転用する
事で、恐ろしく効率的にソフト開発が出来る。
だから「2時間で作る」と言ったのは、決して無茶な
話では無い次第だ。
画面のイメージは、沢山のスライダー（TrackBar）
が並び、あたかも「音響（用）ミキサー」だとか、
「アナログ・シンセサイザー」（電子楽器）や
「グラフィック・イコライザー」（音響機器）の
ような雰囲気である。
まあでも、こういう雰囲気の機械は個人的にも好み
であり、昔から現代に至るまで、色々とこうした
沢山のスライダーが並ぶ音響機器を所有している。
でも、世間一般では、沢山のツマミ等が並ぶ機械を
前にすると、たいていビビってしまう模様である。
何故かと言えば、それらの沢山のツマミ等の操作子
の効能が良くわからないから、「一度動かしてしまい、
元に戻せなくなったら、どうしよう？！」と不安に
思ってしまうのが理由なようだ。
だが、音響ミキサー等では、単に同じ効能のものが
沢山並んでいるだけである。そこにヴォーカルやら
ギターやらドラム等から来る音声信号が、アサイン
されて（割り振られて）いるだけだ。
だから、「どのフェーダーに、何の楽器がアサイン
されているか？ 配線した人で無いとわからない」
という課題はあるものの、個々の操作子の意味が
わからないという事態には、まずならないと思う。
（注：これがシンセサイザーの場合には、多少は
構造や原理の理解が必要だ）
ちなみに、沢山の操作子が並んでいるメリットと
しては・・
「全ての操作子の状態が、目視で一目瞭然な事」
「複数の操作子を同時に操作する事が可能な事」
「電源がOFFの際とか、デジタル的な表示が無い
場合でも、固有の操作子を所定の値まで操作が
可能な事」
といった、多数の利点がある。
対して、弱点は、
「操作子が多すぎる場合、状態が把握しにくい」
「同、多すぎると、一定の数くらいしか、同時には
操作する事ができない」
「場所や面積を喰い、機器が大型化してしまう」
「個々の操作子の設定を、記憶させる事が困難。
たとえ記憶できたとしても、それらを動かして
しまうと、記憶値と現在値での矛盾が出てしまう」
となっている。
（注：この事は、音響機器とかソフト等に限らず、
カメラでも、あるいは多くの機器（例：飛行機の
コックピット等）とかでも、同様だと思う）
このうち「操作が面倒だ」という弱点に関しては
本ソフトでは、一応だが「デフォルト復帰」という
機能を付ける。このボタン一発で初期値に戻す事を
可能としよう。
もし、さらなる高機能にしたい場合は、
１）設定の記憶機能を付ける。
（注：これは仮想のソフトウェアであるから、
記憶値と設定値が異なる場合、瞬時に操作子の
位置を画面上で移動させる事が出来る。
もし、これが実際の物理的な音響ミキサー等では、
「モーターフェーダー」と言って、沢山のツマミを
全てモーターで記憶値にまで動かす、といった
とても大掛かりな機械的な仕組みが必要となる）
２）いくつかの代表的なプリセット値を設ける。
（例：黄色を抽出して青色に変換する措置等）
といった機能を、後から追加してあげればよい。
ここまで、宣言どおり２時間もかからず出来たのだが
いざ動かしてみると、早速、大きなバグ（ミス）を
発見してしまった。
どうも色相（色味）の並び方がおかしい・・
例えば、色相は、赤から紫まで、360度という
単位で表現される場合があり、本ソフトでも、
その360度を12分割し、30度刻みで、色相を表示、
調整できるように作ってある訳だ。
原因を調べてみると、沢山並んでいるツマミ
（TrackBarコントロール）の順番がおかしくなって
いる。左から順次1番、2番、3番・・・12番で
なくてはならないのに、1,2.3,4,8,7,6・・ の
ような、変な順番となっている。
これの原因だが、沢山のツマミを並べるのが
面倒で、1～4個まで作ったところで、それらを
コピーしてペーストした事が課題であった。
5,6,7,8のように順番が並んでいるとばかり
思っていたのに、実際には、8,7,6,5のように
貼り付けた際に、逆順となってしまっていた。
これは要注意だ、C#言語で複数のコントロールを
まとめてコピーする際、「期待する順番どおりに
並ばない可能性がある」という事である。
なお、こういう開発手法だと、複数のコントロール
毎に、同じようなソースコードを書く必要があり、
なんだか手間だし、スマートでも無いと思う。
だが、例えば、コントロールを配列化したりすると、
ソースコード量は激減するが、プログラミングが
複雑化したりして、余計に時間を喰ってしまうと
思われる。短時間でプログラミングをする場合は
多少ベタでスマートではなくても、同じコードを
コピペして作った方が早いし、バグも出難い。
あと注意点だが、沢山のツマミを並べている最中
に、画面の背景用に「パネル（Panel）」という
部品（コントロール）を貼り付けているのだが、
これの貼り付けのタイミングや手順によっては、
ツマミ（TrackBar）の座標が、ソフト全体での
絶対座標か、あるいはパネル上での相対座標か、
の差異が発生してしまうようだ。
この座標系の差は、プログラム自体の効能（動作）
には影響が無いので、各コントロールの「親子関係」
（≒どの背景に属するのか？）を調整するまでも
無いのだが、ツマミの位置をデザイン的に揃えよう
として微調整している時に、座標が違っている事が
ちょっと気になった。
・・という事で、沢山のツマミを正しく並べ替えた
ところで、プログラムが完成。2時間少々掛かった
が、ほぼ予定通りだ。
変換しつつ、モノクロの画面上に自動生成してみる。
何も問題なく動作しているようだ。
また、各ツマミの抽出量や置換量、効能のON/OFF
も正しく動作している。
なお、注意点だが、各ツマミの効能のON/OFFには
「チェックボックス」（四角の中にチェック印）
というコントロール（≒操作子）を使っている。
これを「ラジオボタン」（丸の中に点）にした方が
デザイン的には格好良いと思うのだが・・
「ラジオボタン」は一般に、複数のグループの中
から１つだけを選択する際に使うものであるから、
パネル上、等に配置して（半自動的に）グルーピング
を行うと、どれかのラジオボタンを押したら
そこだけが有効となり、他が自動的にOFFになって
しまう。つまり、「複数のラジオボタンを同時に
選択する事ができない」状態となる。
この問題を回避する手段は、無い訳では無いのだが
繁雑であり、ちょっと採用する気にはなれなかった。
（以前に試してみて、とても面倒であった）
やむなく、デザイン的には不恰好だが「チェック
ボックス」を、そのまま使う事としよう。
後、下部の色相変換のツマミ群は、現時点では
「相対置換値」となっている。つまり、「全ての
ツマミの値を最も下げた状態が、元の色相を
そのまま踏襲する」という意味（仕様）である。
したがって、同じツマミの高さ（値）にした場合
では同じ色相が得られる、「絶対置換」では無い。
従前の、本シリーズ第8回「野獣派」変換プログラム
では、「絶対置換方式」を採用したのだが、
そのソフトでの色相変換数は、6色であった。
今回は12色と増えているから、あまり複雑な設定は
やりにくいと思ったからだ。つまり絶対置換の場合に
おいてデフォルト（色変換なし）にしたいならば、
12個のツマミを細かく階段状に設定しないとならない。
プリセットやデフォルト復帰のボタンを使わない限り
それは操作が繁雑だ。今回の「相対置換」方式ならば
全てのツマミを全部ゼロ（一番下）に動かしてやれば
位置を微調整しなくても、「色変換なし」とできる。
ただ、この方式の場合、ツマミの位置関係を見た
だけでは、どの色に変換されるかがわからない。
勿論、画面下部に変換された後の色相が表示される
のだが、「どちらの方向に、どれくらい動かしたら
どんな色になるのか？」が、ツマミ操作時には
予想が難しい訳だ。
まあつまり、どちらの「操作系」を採用した場合
でも、一長一短ある、という事がここでわかった。
今後、似たようなソフトを作る場合は、状況に応じて
両方式を使い分ける事としよう。
処理を行っている写真に対して、さらにクロスカラー
（＝別の色に置換する）の処理を加えてみた状態。
勿論、赤色が緑色へ変換され、正しく動作している。
だが、なんだかこのあたりで「面白くない」という
事に気づいてしまった（汗）
何が面白く無いのか？と言えば、このソフトでは、
狙った色に対して違う色を割り当てる、という処理が
出来るのだが、この動作は、ほぼ「予想通り」の結果
となる。
すなわち、思うような結果にする為、様々な操作子
（しかも沢山ある）を、個別に微調整しなくては
ならない。しかも、結果が予想通りであれば、もう
それは「創造的な活動」ではなく、単なる「作業」だ。
例である。
前述の、「単なる作業」、という話だが・・
そういえば、自分でも思ったが、個人的には、写真の
撮影時において「後で画像編集すれば良い」等とは
あまり思わず、撮影時に様々なカメラ設定を行って撮り、
できるだけ後編集を避けるような事をいつもしている。
(注：RAW現像も一切しない。全てがJPEG撮影だ）
これについては「撮影時に被写体に対峙して感じた事は、
後では再現できない」という、もっともらしい理由を
いつも述べてはいるが、実のところ「単純な作業が嫌い」
という事が原因なのかも知れない（汗）
・・ただ、その結果として、カメラ設定が効率的では
無い機種では、撮影時の細かいパラメーター設定操作が
やりにくくなってしまい、とても困る。
つまり、そうした「操作系・操作性が悪いカメラ」は、
本ブログのカメラの紹介記事でも、いつも低評価と
なってしまっている次第だ。
だが、現代の大半の初級中級カメラユーザーでは、
カメラ設定等は、せいぜい絞り値や露出補正、AF測距点
を変更する位で、他は、全く触らずに撮影している
だろうから、こういった評価内容は、他者には参考に
ならない事だ。
（つまり、ユーザー個々に、写真を撮る目的もスキルも
全てが異なる訳だから、他人の評価は参考にならない、
という意味である）
オールド・デジタル一眼レフ（NIKON D2H、2003年）
で撮った写真で、ちょっと薄い色味である。
しかも、そのカメラは、カメラ本体内での画質調整
機能を持たず（特殊なセンサーを使っていたからだ）
その点、当時のユーザー層に不評であった次第だ。
本来、こういう薄い色味は、任意の画像編集ソフトで
調整すれば、どうにでもなる話である。
今回は、ちょっと別のアプローチとして、本ソフトを
用いてみる。
まずこの写真をセピア色に変換してしまい、全体的に
モノトーン化する。
そして背景にある青い光だけ活用し、それを抽出して
赤色の光に変換してみよう。
すると以下のようになる。
あ、それと、本ソフトでは「CONVERT」ボタン、
つまり「計算開始」ボタンがついているが、思えば
それは不要だったかも知れない。
この画像処理は比較的単純であり、多くの計算量を
必要とするものでは無いからだ。
だから、何かのスライダーやボタンを触った直後に
自動的に計算を開始する操作系でも十分だったと思う。
まあ良い、いずれ気が向いたら、「即時計算方式」に
プログラムを変更する事は容易だ。
として撮っている、という次第だ）
これは珍しい事象であるから、さらに本ソフトで
加工して 「現実にはあり得ない色味」にしてみよう。
色が違う、というだけで人間は全く別の感覚を持つの
かも知れない。
まあ、色彩心理学とか、そういう類の学問や研究も
あるし、そこまで学術的ではなくても、たとえば
芸術分野では、絵画の後期印象派や野獣派等においては、
「色彩を対象物の本来の色の束縛から解放」して、
新しい色を絵画表現に用いていた訳だ。
また、現代の商業デザイン等では、色の与える心理効果
を当然意識して、ポスターとか看板とか、企業のロゴ
マーク等をデザインしている。
まあだから、色が心理に与える効果というのは普遍的な
話だと思う。
さて、単なる色変換の「作業」だけでは面白くなく
なってきたので、本ソフトに備わる「FLAT TONE」機能
を試してみよう。
これは抽出した色、または置換した色の彩度を強調し
「ベタ塗り効果」を得る事ができる機能だ。
本シリーズ第18回記事の「Saturation補正ソフト」
と類似の原理・効能ではあるが、本ソフトにおいては、
「セピアカラー変換効果」と組み合わせる事で、
本シリーズ第1回記事の「横浜写真生成ソフト」の
類似/バリエーション的な効果が得られるのでは？と
期待するところがある。
ポイントは女性の和服の色味の「黄、緑、青、赤」
そして、背景の橋の「朱色」を、どう変換するか？
というところなのだが、元写真には無い色味に変換
してしまうのは、少々やりすぎとなるだろうから、
元写真の色相を抽出しながら「FLAT TONE」機能で
彩度を一定のレベルに高めてみよう。
ベースは一応「セピア」とする、これで「横浜写真」
のようになるだろうか？
は無く、全体に「濃い」色調に変換されてしまった。
どうも「ベタ塗り」(FLAT TONE)の機能は、使い道が
難しい模様だ。場合により、次のバージョンでは
「ベタ塗り」のレベルをコントロールできるように
プログラムを改変するのも良いかも知れない。
以下参考まで、本シリーズ第1回記事の「横浜写真
生成ソフト」「Yokohama Type1」を用いて
同じ写真の自動処理を行った結果を掲載しておく。
よりも不自然ではあるが、元々「横浜写真」とは
職人（絵師）が彩色した擬似カラー写真であるから、
だいたいこんな感じに仕上がる事が普通だ。
だから、映像的な表現として考えれば、本ソフト
での、ありきたりの画像編集結果のような物よりも、
「横浜写真」の方が、面白いといえば面白い。
さて、「FLAT TONE」機能には、もっと別の使い道
は無いものだろうか？
例えば、夜景イルミネーションを「ぐるぐるボケ」
の特殊効果レンズを用いて撮った写真を、色相置換
と「FLAT TONE」化してみよう。
基本的には、どんな色相に変換するのも「アリ」だ
とは思う。
でも、もはや、元の写真の色味は、もうこの結果
には存在しないから、ここでは勝手に自分の好きな
世界観を創り出している状態となる。
でもまあ、それはそれで現代のデジタル写真での
本質、という風にも考える事は出来るかも知れない。
もはや「写真とは”真を写す”と書く」といった
古い時代の概念は、全く成り立たない時代となって
いる訳だ。
----
最後に、本ソフトウェアの研究開発の成否だが、
一応は「○」（成功）という風にしておこう。
すると、本シリーズ記事のここまでの通算（総合）
成績は、以下のようになる。
総合成績＝8勝6敗6分、勝率＝4割0分0厘
本シリーズ記事でのルールとしての、最低ラインの
勝率3割を超えてはいるが、目標の勝率5割には
届かない。
でもまあ、ここのところ、あえて簡単な画像処理の
内容のソフトばかりを作っていて、「ちょっと勝率
を稼いでおこう」といった”よこしま”な理由も、
無きにしもあらずだ（汗）
あまり、こういうシンプルすぎるソフトをチマチマ
と作っていないで、次あたりでは、かなり難易度の
高い画像処理に挑戦してみるとしようか。
そう、本シリーズでの作業（研究開発）は、あくまで
趣味でやっている事だ。知的好奇心が満たせれば
良いのであって、本質的には、その研究が成功するか
否かは、ある意味、どうでも良い話だと思う・・
---
では、今回のプログラミング記事は、このあたりまで。
次回記事掲載は、例によって不定期としておく。