「オリンパス・ブルー」生成ソフトのプログラミング

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

本シリーズ記事では、デジタル画像（写真等）のピクセル
毎に対し、PC（パーソナル・コンピューター）で数学的な
演算を施し、結果としての検出、抽出、判断、変換、加工
等を行う「画像処理」のプログラミングを行っている。

こうした画像処理の方法論は、一般に「アルゴリズム」
と呼ばれるが、本シリーズでは過去に前例の無い、全くの
新しいアルゴリズムを創造・創生する事を主眼としている。
つまり、どこかにあるサンプルのソースコード等を引用
したり、OpenCV等の汎用画像処理ライブラリー等を一切
使わず、「完全自力開発での、自動画像処理のソフトを
新たに研究開発する事」というルールを遵守している。

既に本シリーズでは、11種類の独自プログラムを完成
させていて、本記事は第12回目のプログラミングだ。
また、本シリーズで開発したソフトウェアは趣味の範囲で
自分自身のみの限定用途として使うものであり、これらを
頒布や公開する予定は一切無い。

加えて、ここで独自に研究開発した「アルゴリズム」は
「高度な知的財産」である場合が大半であるので、これらの
具体的内容（フローチャートや計算式、ソースコード等）
も公開しない。

まあつまり、料理等での「秘伝の味付け」とか、製造工場
等での「企業秘密の工程」といったものと同様である。
ただし、処理の内容が公知（公に広く知られている）の
場合には、そうした情報は、秘匿する必要は無い。
特に、今回の記事での画像処理内容は、かなり容易（簡単）
なものであるので、ある程度は公開して行こう。
さて、今回の記事では、「オリンパス・ブルー」を生成
するソフトウェアを開発する。

きっかけとなったのは、2020年6月に「オリンパスが
カメラ事業から撤退」（注：正確には「カメラ事業を
分社化する」）のニュースが飛び込んで来た事だ。

ここで、オリンパスの悲運について語ると冗長となる為、
それについては割愛する。オリンパスの歴史については
例えば、「カメラの変遷」第13回～第14回記事の
「オリンパス編」に詳しいので適宜参照されたし。

で、「オリンパス撤退」に関する多数のニュース記事は
カメラの事に詳しくない記者（ジャーナリスト等）が書いた
ものが大半だったので、それらの内容は、間違った解釈等が
多く、大いに疑問や懸念があったのだが、まあ、一部には
比較的正しい解釈の記事も、当然存在していた。

中には、マニアックな視点で、「オリンパス・ブルー」に
ついて書かれたものもあって、その評判がオリンパス機の
人気を高めた要因であった、という旨の記事もあった。

その「オリンパス・ブルー」とは、オリンパスが
デジタル一眼レフ市場に進出した際の最初の発売機種
OLYMPUS E-1(2003年）から以降、数年間の間では、
その撮像センサーは、当時協業していた米KODAK社製
のCCD型センサーであり、その発色において、例えば

「青空」等が気持ちの良い色味であり、主にマニア層
（特にオリンパス党）からは「オリンパス・ブルー」
（または、稀に「コダック・ブルー」とも）と呼ばれ
賞賛され、評判が高かった。

（注：たとえば、下の写真のような発色。
　または、昭和初期に日本やフランスで活躍した画家の
「海老原喜之助」の作品に見られる「エビハラ・ブルー」
　と呼ばれた独特の青色発色が近い。
　同氏の「船を造る人」の絵画作品を見れば雰囲気は分かる
　だろうが、Web画像や製本印刷によりけりで色味は変わる）
KODAK（Eastman Kodak Company）と言えば、ご存知
写真用フィルムで著名な大企業で、1880年から続く
超老舗ではあるが・・　20世紀も終わりの頃の時代に
なれば、フィルムは当然、いつの日か、デジタルに置き
替わる事は、市場の誰もが予想できていた。
そうであれば、フィルムメーカーとしても、それに備え、
多角化や、新技術の研究を進めていかなくてはならない。

KODAKは、デジタル分野においても早くから研究開発を
進めていて、あまり知られていないが、1975年には
世界初のデジタルカメラを試作していた。
（参考：日本でCONTAX RTSが発売された頃。
＝銀塩一眼レフ・クラッシックス第5回記事参照。
銀塩コンパクト機は、まだAF化もされていない時代だ）

だからまあ、2000年前後において「撮像センサー」を
KODAKが開発・製造し、CANONやオリンパス等に供給して
いた事は別に不思議な状況では無い。

そのKODAKだが、その後2000年代に、急激にカメラは
デジタル化し、もう誰もフィルムを使わない時代となって
しまった為、2012年頃に一旦倒産してしまっている。
すぐさま大幅なリストラを施し、経営再建をしたが、勿論
現代のKODAKではフィルム事業を主力にしている訳では無い。

で、「オリンパス・ブルー」の発色傾向は、初期の4/3
（フォーサーズ）機の展開時期の数年間のみであり、
例えば、E-1(2003)、E-300(2004、冒頭写真）
から、E-500(2005)あたりまでではなかろうか？

恐らくだが、E-330（2006)か、又はE-410（2007、
デジタル一眼第8回記事参照）あたりの機種からは
撮像センサーが（Panasonic製Live MOSに）変更され
（KODAKとの提携も解消された？)　その結果として
「オリンパス・ブルー」の青色発色傾向も失われて
しまったように思える。

・・まあ、ここまでが一般に知られている事実だが、
ここから以下は、私の独自分析の情報である。

まず「何故オリンパス・ブルーの発色が生まれたか？」
という点については、当時の各社製（KODAK製含む）の
撮像素子は、短波長側（青色等）の感度が低く、この
課題を改善する為、画像処理エンジン側等で、短波長の
感度を補正（増強、エンハンス）していたと想像される。

感度増強には、波長での処理、またはB(青色）画素での
処理が考えられるが、本記事で追々検証していこう。

で、そうなると「オリンパス(KODAK)だけが、青色増強
処理を行っていたのか？」という疑問が生じると思う。

・・そう、「技術」というものは、同じ時代であれば、
だいたい何処（各社）も同等の水準に落ち着くものだ。
だから、オリンパス以外の各社の撮像センサーにも同様の
課題があって、それもまた、同様の「青色補正」をして
いたのでは？と類推するのは間違った論理ではない。

事実、私の所有デジタルカメラの中で、2000年代前半
頃に発売された機種群に、同様の特性を持つカメラが
かなり多い。（以下、一覧）

＜オリンパス・ブルー風の青色発色を持つカメラ＞
2000年：（発売年、以下同様）
CANON EOS D30（一眼）
2003年：
CANON IXY DIGITAL L (コンパクト）
2004年：
OLYMPUS E-300(一眼）（故障廃棄）
PENTAX *ist Ds（一眼）
CANON EOS 20D（一眼）（故障廃棄）
CANON IXY DIGITAL L2 (コンパクト）
2005年：
RICOH GR DIGITAL（コンパクト）
2006年：
PENTAX K10D（一眼）
2007年：
SONY α700 (一眼）

「ほとんど全てのカメラが、そうだったのでは？」と
感じるかも知れないが、そうでもない。
例えば、同時代のNIKON機(D2H：2003やD70:2004）
や、KONICA MINOLTA機(α-7 DIGITAL：2004）
等では、オリンパス・ブルーの発色傾向は見られない。
（注：機種によっては、特定の撮影条件（輝度等）
で、それが発生するものもある）

また、これはCCD型撮像センサーだけの発色傾向ではなく、
上記リストには、CMOS型センサー機もいくつか混じって
いる。

まあつまり、多くのメーカーにおいて、撮像センサーの
短波長側の低感度は悩みどころであり、製品化において
それを補正したメーカー（機種）と、あえてそれをしない
メーカー（カメラ）もあった、という分析となる。

何故青色補正をしないのか？と言えば、まず青色補正は
青空等の発色は綺麗であるが、やや不自然なまでに青色が
強くなりすぎるケースがある。（例：夕暮れ時の空等）
また、青色よりも、さらに短波長である「藍色」「菫色」
等の発色は、極めて不自然であり、本物の被写体の色とは
似ても似つかぬ色味となる。
（例：下写真は、本来は「紫色」の花であるが、
青色補正により、本物とは異なる色味となっている）
この為、青色補正（増強）は「諸刃の剣」であり、これを
是としたメーカー（機種）と、そうで無いメーカー（機種）
は、各々開発（企画）方針が異なっていたのであろう。

そうなると「何故オリンパスのカメラだけ、オリンパス・
ブルーと呼ばれたのか？」という疑問が生じると思う。

まあ、要は「知らなかっただけ」というのが実情だろう。
でも、例えば、上級マニア層であれば、他社機も並行
して所有しているケースはあっただろう（注：2000年代
前半のデジタル一眼レフは高価であり、複数の機体を
所有できたのは、上級マニア層くらいであった）から、
「オリンパス機の青色発色が他社機より綺麗」という点には
気づいていたであろう。ただ、恐らくは全社のカメラを比較
した訳では無いので、「オリンパス・ブルー」が他社機にも
存在していた事までは、殆ど誰も気づかなかった。

・・だが、なんとなくだが、これはオリンパス陣営からの
市場戦略であったのではなかろうか？とも私は推測している。
2000年代前半ではインターネットの普及が本格化した頃
である、そこに「オリンパス・ブルー」という文言を
流せば、拡散されていく、という最初期のネット情報戦略
ではなかろうか？　つまり「売る為のキャッチコピー」だ。

（注：「オリンパス党」のファン層も、当時の4/3機は、
他社の一眼レフ陣営に比べて少数派であった為、むしろ
オリンパスを擁護する言動がとても多かった→布教活動。
または、青色以外の発色が不自然となる弱点を隠す為に
あえて、「オリンパス・ブルー」の話を広めたのかも
しれない？　という推測も可能だ）

で、「オリンパス・ブルー」の発色傾向を持つカメラは、
各社でも2007/2008年頃には失われ、皆無となって
しまう。まあつまり、技術が発展し、撮像素子や画像処理
エンジンの特性が、Hi-Fi（高忠実度）かつ、フラットに
なっていったのだ、と思われる。

しかし、私は前述のように「オリンパス・ブルー」の
傾向のカメラを、まだ現役で使用している。
一般カメラユーザーでは、発売から10年を超えたデジタル
機を使っている人は皆無だと思うが、私の場合は、やや
異端で、発売後15年～20年位の極めて古い機種も、
「動態保存」していて、研究目的で、たまに出動させて
撮影を行っている。

で、ここからやっと本題だが、「オリンパス・ブルー」
の発色傾向を持たないカメラで撮影した写真を、
「オリンパス・ブルー」風に加工できないか？　という
の発想が、今回の記事でのプログラミングの趣旨だ。

まあつまり、画像処理において「青色の増強」を行う
（だけ）という、ごく簡単なプログラミングである。

「青色の増強」の手法については、短波長そのものに
撮像センサー側で処理を掛けるか、またはセンサーは
そのままで、後段の画像処理エンジンで補正するか？だ。
恐らくは、画像処理エンジン側で補正していると思われ、
以下、その推測の元に、同様の処理を行うプログラム
を作っていく。

で、計算コスト（撮影後に画像処理を行う為のCPU/LSI
等の計算能力/計算時間）を推察すると・・
あるいは、その当時の画像処理技術のレベル（＝水準。
勿論現代よりも低かった）を推察すると、その方法論は、
以下の3種類しか思いつかない。

1)単なる、直線（Linear）補正
2)ガンマ（Gamma）補正
3)シグモイド（Sigmoid）関数による補正

これらは「画像処理技術者」よりも、むしろ「画像編集
技能者」において、良く知られている画像編集ノウハウだ。

つまり、1)は、単純にスライダーや数値で青色成分を
＋側に加工編集する事。
2）は、トーンカーブをBチャンネルに対して上カーブ補正
するか、又はガンマ補正係数を1.0より大きい値にする事。
3)は、いわゆる「S字トーンカーブ補正」である。
これらの計算式については、単純なので説明を割愛する。

GUI（グラフィカル・ユーザー・インターフェース）設計
であるが、今回の操作系においては、UIの範疇に留まらず
UX（ユーザー・エクスペリエンス）に近い部分まで
踏み込んでみよう。

このUX面で参考になったのは、近年に入手した、古い
4/3機のOLYMPUS E-520（2008年）である。


この機体には「パーフェクト・ショット・プレビュー」

という機能が搭載されている（他社機では類似の機能は
皆無だと思われる。以下、PSPと省略。どうやら何らか
の理由（他社の特許や商標等？　例えば、「PSP」
という愛称がある「SONY PlayStation Portable」は、
2004年発売と、このOLYMPUS E-520よりも古い。
かつて1972年にOLYMPUSが「M-1」を発売した時に、
当時のエルンスト・ライツ社（現：ライカ）から、
「Mは使うな!」と、言いがかりの難癖を付けられた、
という教訓(?)で、SONY等と愛称が被らないように、
安全策を取ったのだろうか？）・・で、正式名称には
ならなかった機能でもあるし、その理由の影響からか？
後年には、カメラへの搭載を省略された機能でもある）

これは同機でライブビュー撮影時に、露出補正または
WB（ホワイトバランス）パラメーターを複数設定した
状況が撮影前にわかり（＝プレビュー）、ユーザーが
好みの設定を選択できるという機能だ（下写真）
で、今まで本シリーズ記事で開発したプログラムは、
画像読み込み→パラメーター設定→計算開始→
計算終了後に処理結果を表示、という「シーケンシャル」
（≒連続的な、順番的）なフローチャートである事が
大半であったが、今回は画像読み込み後、ただちに複数の
パラメーターに応じた計算を開始し、パラメーター毎に
「PSP」機能に類似の、複数の結果画像を自動表示する。

また、パラメーターを変更した場合、その都度、自動的に
計算開始し、PSP風の複数処理結果が自動表示されるように
設計しよう。

なお、何故、これまでの開発ソフトがシーケンシャルな
処理であるのか？は、計算コストが大きい複雑な画像処理
アルゴリズムを研究開発するケースが殆どであったから、
別途「計算開始ボタン」が必要であった訳だ。

複雑な画像処理で、パラメーター調整後に、数秒間も
演算をしているようでは、待っているのが、かったるくて、
そうした自動計算型（方式）には出来ない。

ところが、今回のソフトでは、計算コストは極めて低い
（＝つまり、簡単な計算なので高速である）　よって、
自動計算開始、かつ複数並行計算が可能となる訳だ。
（注：この程度の少ない計算量では、CPUを並列処理に
したり、GPUを使用する等の必要性は無い）
開発環境は、Microsoft Visual Studio 2013版だ。
プログラミング言語はC#(.NET）を使用する。

やや古い環境だが起動が高速なので、簡便なソフト開発は
2013年版で行い、複雑なソフト開発はVS 2017を使用
する事としている。なお、VS2019とVS2017を併用する
のは、インクルードのPATH設定の課題で、やや厳しい。

バグを出さない自信やスキルがあるならば、ソフト的な
安全性が低い、古い（だが高速な）開発環境でも十分だ。
ただし、ビギナーのプログラマーの場合は、使用関数等
のセキュリティ（安全性）のチェックが厳密な、新版の
Visual Studioを使うのが望ましいだろう。
今回のソフト開発は2日かかってしまった。
（通常のソフト開発は１日以内で終了している）
まあ、簡単なソフトではあるが、計算式を考える際に、
一般的なシグモイド関数（近年ではAI等で使われる）が
画像処理上で相性が悪い（係数によっては、値が255に
到達せず、例えば、白を白と表せなくなる）課題が判明し、
シグモイド関数の改良に手間取っていたからである。

計算式の課題が解決した（研究が進んだ）ので、早速、
完成したソフトを動作させてみよう。
超広角レンズで撮影した青空を主体とした写真である。

左側上の画像が元画像、左側下が補正関数の設定
（この例では、Gamma関数で補正している）
右側の４つの画像は、補正関数で処理する際に、
適宜、パラメーターをOFFSET（効果量を変動させる）
させ、それらの異なる計算結果を同時表示している。

なお、補正関数の種類（Gamma、Sigmoid改、Linear)
が変更可、補正係数は0.5～2.0の間で変更可。
（注：関数毎に正規化している）、さらに処理対象の
プレーン（≒色、チャンネルとも）を、B（青）の他、
G（緑）、R（赤）、B+G、B+R、G+Rの、計6種類に
変更できるようにしてある。

また、OFFSET値は、各出力画像エリア毎に-30～50
の範囲（基本的には8bit係数の値だ）で変更可能。
計算結果画面には、各COPYボタンを持ち、気に入った
画像をクリップボードへ保存可能である。

オリンパス・ブルー風で気に入った画像があったので、
早速保存してみよう。
なお、使わなかった画像は消滅してしまうが、まあ
同じ画像で、同じパラメーターにより計算すれば、その
再現性は存在する。（＝毎回結果が異なる訳では無い）
計算時間だが、Web掲載用程度の解像度（数十万画素）
であれば、ほぼ瞬時に4枚の画像が計算される。
デジタルカメラで撮ったままの元画像（数千万画素）
だと、画素数に応じて、それなりに計算時間がかかる
（数秒）ので、技術的な研究開発の場合は、その遅さが
うっとうしいので、ほぼ必ず小画素に縮小した画像を
入力して実験する。

PCのスペックはWinows7以降（.NET Framework 4.5以降）
CPUは、例えばIntel Core i5級以上で十分だが、
Core i3級だと、ちょっと計算が遅く感じるかも知れない。

「空間フィルター」（≒対象となる画素（ピクセル）の
周囲のピクセルを参照して演算を行う方法論）を画像処理
アルゴリズムに使用する場合は、入力画像の画素数の多寡
に応じて、処理効果が変わってしまう場合も多々あるが、
今回のアルゴリズムでは、各ピクセルに対する直接演算で
ある為、画素数の大小による効果の差異は発生しない。

このあたりも、中身のプログラムを全て自分自身で理解
しながら書いている為、何も、迷ったり疑問に思う点が
無く、研究開発を進められる。

で、当たり前の話だが、ピクセル毎にGammaやSigmoid改
の関数（これらには指数関数、PowやExpが含まれる）を
掛けていたら、計算コストが大幅に増加してしまう為
（つまり、いつまでたっても計算が終わらなくなる）
パラメーター設定変更時に、１度だけ計算を行い、それを
係数配列（テーブル）に、ややこしい計算結果を保存し、
画像処理計算を、テーブル参照方式で超高速化している。

まあ、これはプログラミングの中級ノウハウとしては、
基本的なテクニックであろう。（実際のカメラ等の製品
でも、当然、そのように演算していると想像できる）
続く入力画像は、虹の写真だが、ちょっと虹の存在感が
曖昧な（薄い）画像だ。
こんな場合は、Sigmoid改（≒S字トーンカーブ補正）
を、B（青）と、R(赤）チャンネル（プレーン）の
両者に掛ける。

で、ここまでなら上級画像編集技能者(Photoshop使い）
なら、できるかも知れないが、ここから、さらに係数
配列をOFFSETしているので、これはもう「画像編集」
（Photoshop/GIMP/PaintShopPro等）では、不可能な
領域になる、つまり、ここからは、もはや「技能」
（＝画像編集ソフトを扱える）だけでは無理であり、
「画像処理」の「技術」（テクノロジー）を用いないと、
実現できない処理だ。
複数プレーン（チャンネル≒原色の事）の同時補正は、
当初の目的外の処理であるが、なかなか効果的な模様だ。
引き続き、他の画像で試してみよう。
これもなかなか効果的、夕景をドラマチックに演出
する事ができる。
今回ソフトの元々の目的は、「オリンパス・ブルー」の
再現である。これは、現代では失われてしまった、その
発色傾向を蘇らせる、という意図があると同時に、
技術的な探究心としては、「当時のOLYMPUSやKODAK等
の技術者が、いったいどんな手法で青色あるいは短波長
のエンハンス（増強）処理を行っていたのだろうか？」
と、その技術内容そのものを類推する目的もある。

後者は、「他者の技術を盗む」という悪いイメージにも
繋がるかも知れないが、まあ、いつの時代であっても
エンジニアは、他社/他者の技術を大いに参考にしながら、
それを超えるものを目指している訳だ。
その為には他社/他者技術の解析は欠かせない作業だ。

ただまあ、私の場合は、その業界には全く関係が無い
（カメラ技術者では無いし、関わりも無い）為、同様な
作業を全くの趣味の範囲、つまり「知的好奇心」のみで
行う事ができる。
業務（仕事）で無ければ、納期も方法論も自分の好きに
できる訳であり、「成果納品の義務が存在しない」という
趣味の世界でのメリットを最大に活用したいと思っている。

世間一般では、カメラを趣味としながらも、例えば
「失敗が許されない」（＝だから、手ブレ補正内蔵とか
AF性能の優れた機材を欲しがる）という、変な強迫観念に
囚われてしまっているアマチュア層が非常に多い。

「どこにも納品義務が無い」ならば、それは極めて恵まれた
環境である。その環境を活かし、例えば「手ブレ補正無しで
撮影し、自身の限界点を見極め、徹底的に技能を磨き上げる」
とか「MFの技能を修得する為、高性能なAFも超音波モーター
も一切使用しない」とかの練習メニューを行えば良いでは
無いか、そうやってスキルアップできる事は、アマチュア層
または完全に趣味の範疇での撮影でしか有り得ない。

さて、でもまあ、今回の「画像処理」のアルゴリズムだが、
研究開発的な視点からは「こんなに単純な事で良いのか？」
というレベルの技術水準に留まってしまっている点が、
ちょっと気になる。

本シリーズ記事での他の開発済み画像処理のアルゴズム
は、今回やっている事の、少なくとも軽く数十倍程度は
複雑である。それらに比べると、今回のソフトは単純
すぎるのだが、それでも、効果がまずまず出ているので
好ましい。まあつまり、技術の価値は、その効能により
決まるのであり、「複雑で高度な事をやっている」から、
「凄い」とか「偉い」とか、そんな話はまるで無いのだ。

技術の分野に疎い人ほど、たとえば、カメラメーカー等が
新技術をカメラやレンズに搭載し、それの説明を読んで
さっぱりわからなかったとしても、「凄い！高度な技術だ」
と勝手に思い込んで、それを盲信したり、崇拝してしまう
のだが、その考え方は、基本的には誤りだ。

技術の分野に詳しければ詳しい程、「できるだけシンプル
かつ簡素な技術で、最大の効果や効能を得る事が美しい」
という価値観を持つようになる。

漫画での例だが、「ATOM THE BEGINNING」で「A106」
（注：「鉄腕アトム」の試作ロボット?という想定）に
搭載されている高度な人工知能（AI）「ベヴストザイン」
のプログラムは、同じくロボット開発者の（登場人物）
の「堤茂理也」氏が、それを見る機会があり、
「こんなに簡単なコードで成り立っていたのか！」
と驚嘆したほどのシンプルさである。

まあ、この漫画については、技術の事が良くわかって
いてシナリオを書いていると思われ、前述のような、
技術者の持つ価値感覚についても同様に理解しているから、
そういうシーンが描かれているのだろうと思われる。

これが、もし、技術の事が良くわかっていない原作者
であれば、「A106」の人工知能は、人知を超えるレベル
での、物凄い複雑なものとして描かれていた事であろう。
（昔のロボット漫画等では、天才科学者が、物凄い発明
をして、それがロボットに搭載されている、といった
現実味の無いシナリオである事が良くあった）

余談はここまでで、画像処理の話に戻る。
上の元写真は｢変形ペッツヴァール構成」レンズの使用
により、像面湾曲・非点収差を強く発生させ、いわゆる
「ぐるぐるボケ」となった写真。

元写真のままでは、被写体部とぐるぐるボケ部の線引き
が曖昧になっているが、これにG+R（＝緑と赤の光を
混合すると黄色になる）のプレーンに対し、マイナス値
を係数γとしたGamma補正をかけると、だいたいだが
被写体と背景（ぐるぐる）ボケ部の差異が明瞭化する。
こちらではオリンパス・ブルーの解析の為、変形Sigmoid
関数で、青色と、それに加えて赤色にも処理を行っている。

どうやら、オリンパス・ブルーでの増強（エンハンス）
処理は、「波長」では無く、素子のB（青色）チャンネル
のみで行っている様子が少し見えてきている。

まあつまり、撮像センサー側での処理ではなく、これで
あれば、画像処理エンジン側での演算のみで処理できる
ので、シンプルかつ高速だ。
そして、その補正カーブは、どうやらSigmoid（S字補正）
でもなさそうだ。Gammaか、あるいはLinear（直線補正）
であろう。
このソフトの画像処理は、モノクロ画像においても有効
なように作ってある。モノクロ画像を入力すると、一旦
これをカラーに変換する。とは言え、R/G/B=Yという、
ごく簡単な処理である。ここでBプレーン（青色）のみ
にGamma関数等で強調処理を行えば、モノクロ写真に
対しても、オリンパス・ブルー変換処理が行える訳だ。
様々な画像を入力し、様々な補正パラメータ設定にて
実験中の様子。

そのことから期待する内容は、「設計時には想像が
出来なかった、新たな効果を得る」である。
実を言えば、「オリンパス・ブルー生成ソフト」と
言いながらも、単に画像が「オリンパス・ブルー」風に
なるだけならば、あまり興味があるものでは無いのだ。

何故ならば、だいたいもう、ソフトを作って実験している
時点で、「オリンパス・ブルー」の仕組みは解明されて
しまっている。つまり「知的好奇心」が、もう無くなって
いる訳だ。

また、実際に「オリンパス・ブルー」が得たかったら、
前述した「オリンパス・ブルー」傾向のあるカメラ群は
何台も所有しているので、実際に晴天時等に、それらの
カメラを持ち出して撮影すれば、「オリンパス・ブルー
が得たい」という目的は達成できてしまう。

なので、今回のソフトの開発目的（意図）は、完成時点
でほぼ達成されてしまっている為、今後、このソフトを
実用的に使うならば、「思いもよらぬ効果」を得る為の
プラットホームとすれば良い、と思っている。

これは、例えば、写真における「Lo-Fi」（低画質）
技法（概念）での、偶然性の発生（本ブログの用語では
「アンコントローラブルな要素」）を得る為のツールと
して、十分な用途と効能があると思われる。

何故、そんな概念が必要なのか？　と言えば、カメラや
写真の仕組みがわかっていれば、写真はもう、撮る前に
どう撮れるかは、だいたいわかってしまうのだ。
それだと、いつも自分の「想像の範疇」でしか写真を
撮る事ができなくなる状態だ。

2000年代前半の銀塩末期に、一部の初級中級層の
間で、トイカメラ等を用いた「Lo-Fi」写真が流行した
のは、その当時の銀塩末期では、中上級層の撮る写真は、
もう完全に自身の「想像の範疇」（コントローラブル）
な想定内の予定調和のHi-Fi写真ばかりになっていた為、
初級者等による写真撮影時の失敗（ブレ、ピンボケや、
安価な機材による想定外の低画質）も含めた「Lo-Fi」で
Hi-Fi写真に対抗する「映像表現」を得ようとした歴史
がある。まあつまり「偶然性や創造性」を持って、
撮影者自身も想定外の写真（映像）を得る事は、それは
それなりに意味がある、という事となる。

（参考：音楽の世界で言えば「アドリブ」であろう。
勿論、アドリブとは、ただ単に「デタラメに演奏する」
訳ではなく、アーティストの上級者において、新たな
音楽的表現を得る為に行うものであり、その実施には
高い演奏技法や、多くの演奏経験が必要とされる。
しかし、写真の世界では、上級層に至るまで「アドリブ」
を、やろうとしないし、そもそも、そういう発想が無い）
上画像は、予めオリンパス機等でエフェクト（アート・
フィルター等と各社まちまちに呼ばれる）を掛けた写真
をLinear（直線）補正で、さらに加工した例。

本ソフトが、4枚の設定が異なる結果を同時出力できる
のは、前述の「アンコントーラブルな偶然性」を引き出す
用途にも適している事は、このソフトを触っていて、良く
理解できた。

元々、この4枚同時出力の発想は、オリンパス4/3機
(E-520等）の「パーフェクト・ショット・プレビュー」
機能のオマージュ（敬意を払って参考とする）であったが
当時のオリンパスが求めたものは、「ビギナー層による
失敗を無くす為、いくつかの良い効果（結果）が、予め
わかり、それを選んで、最善の写真を撮る」という発想
であったのだろうが・・

本ソフトでは同様の機能を搭載していても、結果的に
目的が全く異なり、本ソフトでは「複数の想定外の
結果を得る事により、操作者が予想もしていなかった
新たな表現を得る」事が可能となっている。

後者の考え方は、実は、これもオリンパス社にあって、
2010年代のμ4/3機（OM-D系列等）に搭載されている
「アートフィルター・ブラケット」という機能がそれだ。

この機能をちゃんと使いこなしているユーザーの比率は
極めて少ないと思うが、これは、私が近代のOLYMPUSの
μ4/3機を購入する理由の１つにもなっている。
この機能では、1回のシャッターレリーズ（撮影）で
数枚～数十枚もの、画像効果（エフェクト）が異なる
写真を連続（ブラケット）で得る事が出来る。

私の場合、OLYMPUS機の使用機毎に、最大約20枚もの
アートフィルター・ブラケット機能を設定してあり、
これらの撮影結果から、撮影時には思いも寄らなかった
映像表現効果を、偶然的（アンコントローラブル）に
（又は、アドリブ的に）選別する事が出来る訳だ。

なお、撮影枚数は20倍に増える(1000回のシャッター
を切れば2万枚だ！）し、後編集での閲覧・選別時間も
物凄く増える。だが、そうまでしても「新たな表現」
を得る事は重要な事である。

「Hi-Fi」しか志向性を持たないアマチュア初級中級層
では絶対に理解（賛同）できない話だと思うが・・
そういう思考や発想を、初級中級層では「知らない」、
「試していない」事も、十分にありえる課題だと思って
いるので、一度、そういう方向性(Lo-Fi)を試してから、
物事を判断する事が重要であろう。

なにも「写真とは真を写すと書く」（＝「物事をあるが
ままに記録するのが写真だ」という、古い時代の概念）
という志向性を、何十年間も頑なに守る必然性は無い。
引き続き、様々な画像で、様々なパラメーター設定で
テスト中である。

そして、何も、このソフトはアンコントローラブルな
「Lo-Fi」映像だけが、期待する出力結果では無い。
画像のコントラストが低い場合で、S字カーブ補正を
行う事は、レタッチャー（画像編集（技能）者）の
常識であろう。
そういった処理も、本ソフトでは特定のカラーチャンネル
だけに対して行う事ができるので、Hi-Fi系の補正も
十分に行える。
なお、全チャンネル補正（いわゆる、Y：輝度補正）は、
あえて未搭載（普通の画像編集ソフトで簡便に実現可能）
だが、その機能を追加しようとすれば、たった数行のソフト
改変だけで実現できる。でも、そういう、ありきたりの機能
を作りたく無いから、完全自力でソフト開発を行っている
のであって、世の中に既にある他のモノには興味が無いのだ。

この「プログラミングシリーズ」の骨子は、世の中には無い
全くの新しいものを作る（創る）であって、他にあるもの
を模倣しているだけでは、「創造的な趣味」ではなく、
単なる「習い事」になってしまうからである。

全く新しいものを創造するのは、当然失敗もあるだろう。
本シリーズでは、新規開発したソフトの3割ないし5割が
実用的であれば「及第点だ」と考えている。

また、失敗したソフトも紹介する。”どんな事をやると
開発が失敗するのか？”、そういう「負のノウハウ」は、
技術の研究開発の上で、実は、とても重要な情報である。

まあつまり、皆、同じように考え、同じようなところで
行き詰って失敗する事は多々ある為、その失敗例を
学んでおくことは、無駄な研究時間を費やさない為にも、
あるいはその失敗を乗り越えて、解決手段に辿り着く上
でも、とても重要な事であるからだ。

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