学校では「プログラミング教育」が、2020年度から始まる、
との事であるが、これまでプログラミングは一部の技術者に
よる専門的で複雑な業務分野である為、一般の人達には、
何をどうしたら良いのかは、さっぱりわからないであろう。
だから、教師、塾講師、保護者等が、理解する事も教える
事も困難であり、各方面で色々と不安要素が大きいと思う。
しかし、学校で始まる「プログラミング教育」では、
初期の段階においては、論理的なフローチャートの考え方
（＝プログラミング思考）を学ぶだけだと思うので、
実際には、そう複雑であったり難解なものでは無いとは思う。
本記事は、そうした「プログラミング教育」に不安を
抱えている読者にも是非読んでいただきたいと思う。
以下には、実際にプログラムを作る過程が示されている。
が、本記事の主眼は「プログラミングのやり方」では無い。
ここでは、個人的に「やりたい事」があり、それを実現
する為に、コンピューター（ＰＣ）の力を借りるのだ。
つまり、私自身がやりたい事に適したソフト（アプリ）は
世の中に存在しない為、「そのソフトウェアを自作して
しまおう」という話だ。
したがって、主体はあくまで「自分がやりたい事の実現」
であり、その目的の為には「ソフトウェア」が必要だが、
それを作る為に「プログラミング」を行うのだ。
この流れにおいて「プログラミング」自体が「主体」に
なる事は有り得ない。
そして、上記は「非常に重要な事」である。
コンピューター等は、あくまで「道具」である。だから
人間のやりたい事を効率的に手助けするモノでしか無い。
コンピューターに、しっかりと、その仕事をしてもらう
為には、適切なプログラムが必須なのだ。
ここの「根幹」を理解していないと、「プログラミングを
する事」の方が「主目的だ」と、大きな勘違いをしてしまう。
が、そういう考え方では、絶対にプログラミングはできない。
何故ならば、プログラミングとは「やりたい事（仕様）が
最初から明確に決まっていないとならない」からだ。
（この考え方が「プログラミング思考」に繋がる）
多分、学校で「プログラミング教育」が始まったとしても、
この誤解は世間一般では解けず、仕様もちゃんと決めずに
プログラミングの手法や画面操作手順ばかりを習う、という
事になってしまわないか？と個人的には危惧している。
これまでも、例えば、世間一般での「カメラ教室」とか
「パソコン教室」であっても、明確な目的（例えば、自身が
撮りたい分野の写真があるとか、計算したいデータがある等）
とかが無い状態で、それらの教室に学びに行ったとしても
結局、”カメラの使い方”、”パソコンソフトの使い方”と
学ぶ本人のやりたい事とは、全然、方向性も次元も異なる
受講内容となってしまい、「何の役にも立たなかった」
というケースは多々あったのではなかろうか？
料理教室とかゴルフ教室、あらゆる分野でも同様かも知れない、
料理を作る事が最大の目的であるのに、包丁の種類や用法を
勉強したり、使うゴルフクラブの種類や用途を習ったりする。
まあ、それは「基礎知識」として、勿論「必修の内容」では
あるが、「みじん切り」の練習をしても「美味しいカレーが
作りたい」というニーズとは微妙に方向性が異なっている。
また、一部の人達は、そちらの「道具」の方の知識や性能に
はかりに目が行ってしまい、本来の「目的」を見失ってしまう。
カメラでも同様だ「撮りたい写真」が良くわかっていないのに、
画素数や連写性能の優れたカメラを買っても、何の意味も無い。
目的とか求める物、そういうものが無ければ、何を習っても
殆ど意味が無いし、当然、成果も何も出て来ない。
プログラミングも全く同様だ、目的と「要求仕様」が無ければ
絶対に何も作れないし、それに沿った思考力や創造性が
伴わなければ、いつまでも何ひとつ完成しない。
その事は絶対に理解しなくてはならない要素だと思う。
まず最初に「横浜写真」とは聞き慣れない言葉だと思うが、
これは、明治時代初期（1800年代後半）の写真技法である。
モノクロ（又はセピア色）フィルム（乾板）で撮影された
日本の風景や世俗的な写真に、顔料などで「絵師」が
彩色を施した「擬似カラー写真」である。
この彩色写真を、横浜等に来訪する外国人旅客に対して
「日本土産」として販売したところ、大人気を博したと聞く。
実物があるとわかり易いだろうが、勿論、希少な物なので
所有していない。ネット上等にある画像は著作権の扱いが
不明であるから引用はしない。
興味があれば「横浜写真 彩色」で画像検索して貰えれば、
多数の「横浜写真」が見れると思う。
横浜写真は、後年では「絵葉書」等に取って変わられている。
勿論、一々写真に彩色するのは非情に手間であるし、加えて
撮影（注：当時の撮影は困難で専門的技能が必要だった）や
彩色の為の技量も必要となるからだ。
まあ、一種の「工芸品」のような扱いであっただろう。
なので、明治初期の特定の期間でしか存在せず、希少な
写真（技法）である訳だ。
私は先年、この「横浜写真」を京都の博物館で見る機会が
あった。
すぐに「これは面白い！ 自分でも撮ってみたい」と
思ったのだが・・
さて、これをどう撮るか？ 今時のデジタルカメラでも
「横浜写真モード」などは、当然、搭載されていない。
エフェクトでの「色抽出」の機能を使ったとしても、単色が
残るだけであり、横浜写真のように様々には着色できない。
SONY機にある「ポスタリゼーション」エフェクトは原理的
には近いが、効能がまるで異なる。あるいは、PCを用いて
レタッチ（編集）ソフトを使えば、原理的には出来るのだが、
非常に手間がかかり、かつ高度な編集技能も必要とする事が
予想できる。
なので、
匠「え～い、面倒だ、横浜写真が自動的に出来る
画像処理ソフトを自作してしまおう！」
と思った次第である。
こういう発想にはなかなか至らないとは思うが、私は元々
C++やC#といったプログラミング言語を使ったソフトウェア
の開発（プログラミング）が出来る。
しかし「画像処理」を行うには、プログラミング知識や経験に
加えて、さらに、画像分野の専門的な知識が必要となるので、
一般的には、たとえ「プログラマー」の職種であっても、
「OpenCV」などの、出来合いの公開（汎用）ライブラリを
引用して、画像処理部を開発する事が普通である。
だが、「天邪鬼」の私である（汗）、そういう汎用品は
使いたく無いし、幸いにして、私もこの技術分野は
専門分野に近いものがあるので、昔から様々な画像処理
ルーチンを自作していて、現在ではOpenCVの基本機能の
ようなレベル(??)で様々な画像処理を可能とするライブラリ
を作り上げている。（実際には、膨大な量の自作画像処理
ソースコード群を持っている、という事だ）
これらのソースコードを組み合わせる事で、短時間で
容易にプログラミングが可能となる他、これらは
ソースコードであり、その中身の構造は、全て自分自身で
書いて内容を把握しているし、新規に必要な処理内容に
応じて改変が自在かつ容易だ。
で、この開発作業は、あくまで「趣味」の範疇である。
仕事でも無い限り、家でチマチマとプログラミング等は
やっていられない（汗）というのが本音の所ではあるが、
それでもまあ、前述のように「横浜写真」に興味が出て
きてしまったので、もう、やむを得ない。
時間のある週末にも、ちょっと2～3日かけて、このソフトを
自作する事にしようか・・
そういえば、2～3年前にも、趣味として「比較明合成」の
画像処理が行いたくて、加えて特殊な合成演算処理も試して
みたかったので、そうした画像処理ソフトウェアを自作して
いる（本ブログ記事で紹介済み）その時は1日程でソフトが
完成していたので、今回もさほど時間はかからないであろう。
だが、「横浜写真をどうやって作るのか？」
ここが最大のポイントとなる。
例えば「比較明合成」であれば、
「２枚の画像を用意し、各ピクセルにおいて、明るい方を
採用して、１枚の画像に合成する」
となり、極めて単純な計算処理だ。
ここの計算部自体のプログラミングは、FOR文とIF文により、
数行程度で実現できる。（勿論、他にも画像入出力系の
ルーチンが必要である）
で、こうした計算処理の手順や方法論を、「画像処理」の
技術分野においては、「アルゴリズム」と呼ぶ。
ちなみに、アルゴリズムと「フローチャート」は意味が異なり、
まあ、フローチャートも「計算の手順」の意味ではあるが、
それは、プログラミング思考、すなわち「論理的な思考」が
出来れば、なんとか考える事は出来るだろうが・・
アルゴリズムの場合は、対象とする計算処理分野の専門的な
知識が無いと、まず絶対に思いつく事は出来ない。
で、私が今回考案した横浜写真生成アルゴリズムは
以下の通りだ。
１）入力画像から、R（赤）、G（緑）、B（青）の
各色を適正な閾値範囲で抽出し、抽出した部分の
個別色画像を個々に保存しておく。
２）入力画像を、モノクロまたはセピア色に加工する。
３）抽出したR,G,Bの各画像を、絵の具のような色相に
変換し、モノクロ（またはセピア）画像の上に
順次加算合成（＝彩色）していく。
さてここで、どれくらいの範囲（色味の幅や濃さ）を抽出し、
また、どのような別の色味で彩色したら良いかは不明だ。
これらの値は、作る前からは決定できず、加えて、入力した
画像（写真）毎によっても、適正値が異なるかも知れない。
したがって、これらは可変の値（変数）となるだろう。
技術的には、こうした変数群を「パラメーター」と呼ぶ。
完全自動計算には出来ずに、パラメーターを調整しなければ
ならないので、ソフトには「GUI」が必要だ。
「GUI」とは、グラフィカル・ユーザー・インターフェース
の略語であり、つまりコンピューターを操作する人が
「画面上のボタンやダイヤルを、マウスやタッチパネルで
操作する」という構造や概念を指す。
この「GUI」は、Windowsパソコン向けでは「C#」という
プログラミング言語を使うと、比較的簡単に開発できる。
----
ちなみに、このように「こうであるから、これが必要だ」
という順次的で論理的な思考法も、プログラマーとしての
必須要件である。まあ当たり前の話ではあるが、こうした
思考法が出来ない人も、残念ながら世の中には沢山居る。
例えば、電車の切符を買う為に、列に並んでいるのだが、
自分の番が来るまで、目的地までの運賃も調べなければ
財布からお金も出していない人が居る、等である。
つまり、次に自分が何をするのかを全く考えていない訳だ。
「論理的思考」等と言うまでもなく、生活していく上で
当然の行動手順であるが、これが出来ない人が多数居て、
列の後ろで待っている人達から顰蹙を買ったりする。
「まさか？」と思うかも知れないが、今度、様々な場所で
良く観察してみると良い、自身の少し先の行動を全く考えて
いない人が、あまりに多くて、きっと驚く事であろう。
そして、この事もまたフローチャートであり、すなわち
「プログラミング思考」そのものである。
例えばロボットに切符を買わせようとしたら、目的地
を指定し、現在地から目的地までの路線と運賃を調べ、
列に並び、自分の番が来たら財布からお金を出して、
小銭を券売機に入れ、目的地の金額のボタンを押し、
切符と釣銭を取る、という一連の流れをフローチャート
としてプログラミングしなければならない。
これは、流行りのAI（人工知能）を用いても無理であり、
仮にAIであっても、この手順を「学習」させない限りは、
ロボットは切符を買う事が出来ない。
まあつまり学校の「プログラミング教育」とは、最初期の
段階では、このように何かの目的の為の「一連の行動の流れ」
を「フローチャート化していく事」を学んで考える筈だ。
上記の切符購入の処理でも、勿論様々な「想定外」が起こる、
小銭を持っていなかったり、券売機が釣銭切れになったり
目的地までの路線が運行していなかったり・・と。
それらの例外ケースまで想定してフローチャートを決めて
いく事が、優れたプログラマーの必須要件であり、それを
ちゃんと考えないと、ロボットは釣銭切れの券売機の前で
立ちすくんで「固まって」しまう。
こういう様々なケースを事前に想定・想像できない限りは、
残念ながらプログラマーになる事は出来ない。
これを作るには「Microsoft Visual Studio」という
「開発環境ソフト」を用いている。（簡易版ならば無料だ）
PC画面上に、ボタンやツマミなどを順次配置し、それが
できたら、それらのボタン等をマウスで押した時において
どういう動作をするかを決めて、そこをプログラミングする。
（注：このプログラミング方式は「イベント・ドリブン型」
と呼ばれていて、つまり、何かの操作（イベント）が発生
したら、それに応じた処理等を行う。例：所定のボタンを
押したら、ファイル読み込み用ダイアログを開く、等。
この方式は前述の「フローチャート（フロー駆動）型」の
順次実行される処理（計算）手順を記するプログラミング
手法とは、概念的に大きく異なっている）
画面の配置デザインは、およそ1～2時間程度で可能だ。
また、この規模であれば、動作部プログラミング（下図）は、
C#言語で、およそ2～3時間程度で出来るであろう。
熟練すれば、過去に作ったプログラムからコピー&ペースト
するなどで、さらに早くなるが、ビギナーのプログラマー
では、この10倍以上の時間は確実にかかる。何故ならば、
一々、そのソースコードの書き方を考えたり調べなくては
ならないし、出来たとしても、まず１発では思ったようには
動作しないからだ（＝デバッグが必須）
そもそもプログラミング作業時間は、その熟練度に応じて
大差が発生する（既存コードのコピペならば数秒で出来る
のに、自分で新たに全て書いていったら、数十分もかかる、
これは100倍以上の時間差だ）
ただ、自身で作ったコード以外のコピペは、その中身が
理解できていないだろうから、そういう作業を続けても
熟練度は上がっていかないので、要注意だ。
そしてさらに、プログラムの確認修正（デバッグ）作業は、
ソースコードを書く作業（コーディング）の10倍以上の
時間がかかるのも常識だ。
----
さて、GUI画面が出来たとして、次に問題となるのは
計算部分だ。
実は、C#言語では、画像をピクセル単位などで扱い、
様々な計算をする事が効率的には出来ない。よって、
C#言語だけで複雑な画像処理を行う事は困難である。
C#自体は、かなり簡単であるのに、この事がネックとなり、
世の中に複雑な画像処理が出来るC#ソフトは、殆ど無い。
（注：本件は、後日、これが比較的効率的に出来る
方法論を開発したので、今後、C#のみを中心として
画像処理を行うかも知れない）
で、私も、自由度が無いC#で複雑な画像処理ソフトを書く
事は好まない。よって今回、画像処理（計算）の部分は、
プログラミングの自由度が圧倒的に高い、C/C++言語を
使って別途開発しよう。（汎用画像処理ライブラリーを
使えばより簡単だが、前述のように、天邪鬼的な考えで
そういう物は使いたくないのと、中身を全て自分で考案
しないかぎり、技術の熟練度は上がっていかないからだ）
開発中の画面である（同じVisual Studioで開発可能）
前述の「OpenCV」とかの汎用画像処理ライブラリを、
自由に使いこなせる上級プログラマーであれば、この
計算部の開発は数時間程度で出来るであろう。
私の場合は、自作ソースコードを組み合わせて作ったが、
この部分の開発は、やはり同様に3時間程度かかっている。
ただし、画像の読み書きなどの基本的な処理も含めて、
全て自作コードであるからプログラムの総量は非常に大きい、
プログラム（コード）のファイル容量は43KB（半角文字で
およそ4万文字強）にも到達してしまった。
まあでも、本ブログでの各記事の文字容量は、たいてい
20KB（全角文字で、およそ1万字）なので、いつもそれ位の
文章量は書いている訳で、このソースコードの打ち込みも、
無茶苦茶しんどい作業という訳でも無い。（殆どが既存
コードの組み合わせだし・・）
・・が、問題なのは、前述の「計算アルゴリズム」である。
ここは、頭の中で考えた方法論が確実に動作する保証が無く、
プログラミングをしながら、修正や試行錯誤を施さなければ
ならない。
一般に、この作業が最も時間がかかり、また、アイデアの
質や、その実現性によっても完成時期が左右される。
この部分の良否で、作業全体の効率が10倍はおろか百倍から
千倍も差異が出る事も、プログラミング業務の特徴だ。
アルゴリズム開発は、時間を読む（スケジュールする）事は
できない（どちらかといえば「開発」ではなく「研究」だ）
だから、良い案がひらめいて、すぐ出来る場合もあれば、
何日、いや何ヶ月も何年もかかっても完成しない事もある。
今回、C#言語のGUIとC++言語の計算部は1日で完成したが、
アルゴリズムの調整に、さらに丸一日かかってしまった。
まあでも、普通、この手のソフトの開発には、恐らくは
2～3ヶ月はかかると予想できるので、2日間で出来れば
御の字だ。
ちなみに私の場合は、朝、半分起きている位の状態で、良い
アイデアが浮かぶ場合が多く、起きてすぐにプログラミング
すると、たいてい上手く動く。逆に長時間パソコン画面と
にらめっこしていると、集中力を欠いて、むしろミス（バグ）
が出やすくなってしまう。まあでも、このあたりは、それぞれ
個人差がある研究開発スタイルであろうが、誰においても
長時間の作業が効率的では無い事は確かだと思う。
（＝現代の企業プログラマー等は残業のしすぎだと思う、
時間をかければ良いプログラムが出来るという訳では無い）
さて、そうして出来上がったソフト「ヨコハマType1」が
以下だ。
ドラッグ＆ドロップすると、ここに表示される。
GUI画面右部は、パラメーターの調整セクション、
ここでR,G,Bの各色の抽出強度や彩色強度等を調整する。
加えて、原画をセピアとモノクロのどちらに変換するかの
切り替え機能もある。
それから、色抽出の際に抽出範囲を拡張するスライダーも
追加で設けてある、これは当初の仕様には無かったのだが、
実際に様々な画像を入力して実験すると、R,G,Bの各色が
綺麗な純色で無い場合、上手く抽出できない事が判明した。
これはまあ、近年のデジタルカメラにも同様な色抽出の
機能（エフェクト）が入っているが、デフォルトのまま
では、被写体によっては上手く抽出できない事と同じだ。
PENTAX機等の一部のデジカメでは、色の抽出強度を調整
できるのだが、他メーカーのカメラでは抽出パラメーター
が固定の場合も多々あり、そうなると、あまり有効な機能
では無い。
まあともかく、このスライダーと「曖昧色抽出」機能を
設けた結果、多くの被写体（写真）の条件でも色抽出が
上手くいく。
彩色部だが、明治時代の当時の顔料（絵の具）が、どんな
ものだかは良くわからない。
この部分ては、彩色の色味（彩度）の強さを数段階で調整
できるようにしておいた。彩色の色（色相）も調整できると
良かったのだが、「操作系」が煩雑になりすぎると思い、
そこは固定値（おおむね純色の顔料を想定）で計算した。
さて、パラメーター設定を行った後、計算ボタンを押すと
C++言語による画像処理プログラム（計算エンジン）の
EXEが、別途バックグラウンドで起動し、入力された画像に
対して設定した条件で、色抽出と彩色と再合成の計算を
自動的にシーケンシャル（連続・順次）に行う。
このC++言語のプログラムは、前述の「フローチャート」
方式であり、イベント・ドリブン方式では無い、つまり、
予め決められた（計算）処理手順が記述されている訳だ。
何故、わざわざ計算開始ボタンが必要なのか？と言うと、
この計算処理は複雑で非常に重く、高性能なPCを使ったと
しても10数秒もかかってしまう（注：入力画素数にも依存）
よって、パラメーターを調整後に即時計算させる訳には
いかないのだ。もしそうしたら、ちょっとツマミを調整する
たびに、毎回、10数秒も待たなくてはならない（汗）
市販の画像編集（レタッチ）ソフト等では、ここまで複雑な
画像処理を行う事はまず無い為、即時計算が可能であるから、
計算開始ボタンを別途設ける必要性は無いのだ。
でもまあ、計算部はC++言語で作ったので、これでも相当に
速いだろう。これをC#言語のままで作ったら、同じ処理が
出来たとしても、（標準的な関数だけを使っていたら）
数十倍の処理時間がかかってしまう。
また、汎用ライブラリ「OpenCV」で作れるかどうかは
疑問だ。ここでは画像のピクセル毎に、繊細で複雑な
計算処理を行っている。汎用のライブラリには、これに
相応する関数は無いので、いずれにしても計算処理部は
自分で考えて、１から作らなけばならない。
ちなみに、こういう知恵とか手間暇が非常にかかる為、
一般的に、計算アルゴリズムは「知的財産」となる。
すなわち、特許にも成り得る為、あまり簡単に内容を
公開したり、譲渡できるような類のものには成り得ない。
（本記事においては、「公知」の技術範囲で記載している、
このまま本記事の内容だけを読んで作る事は困難である）
また、作ったプログラム自体にも「著作権」が存在する、
他人のソースコードを無断で拝借して使う訳には行かない。
（公開されていて、かつ「著作権フリー」等と明示されて
いる場合を除く。ただ、その場合、正しく動作する保証も
無ければ、障害等が起きた場合の責任も問われない為、
一般的には重要なソフト開発では、他者のプログラムの
ソースコードを流用する事は有り得ない）
なお、本記事を参照して同じような機能のものを別途作る
のは自由だ、その場合は、著作権はその作者に帰属するが、
相当な工夫が必須である為、そう簡単には出来ないと思う。
---
さて、計算が終わると、GUI上には、自動的に処理結果の
画像が表示される。
緑と青が主体の出力画像となっている。
GUIには保存(COPY)機能を設けたので、単体の写真として
取り出してみよう。
写真のようだ（汗）
でも原理的にはこれで合っているし、デバッグ（修正）
も完了しているので、予め想定した「アルゴリズム」で、
問題なく正しく計算されている。
後は様々な画像を入力して、個々に試してみれば良い。
余談だが、プログラミングを含む「モノつくり」において、
既存（公開）ライブラリ等のベースとなるものが何も無いと
全くプログラミングが出来ない、という若手プログラマーが
増えているように思える。
これでは、プログラマーではなく、ビルダー（組み立て者）
であるようにも思ってしまう。
他の世の中の例を上げれば、「LEGO」（ブロック玩具）は、
昔であれば、四角や丸などの基本的なパーツに様々な色が
ついているだけのシンプルな物であり、それらをユーザー
（子供が主であろう）が、自在に創造して組み上げる事で
無限に遊ぶことができた。
（注：現在でも、そういうセットは販売されている）
勿論、出来上がった作品のクオリティは、現物には及ばない。
けど、「車だ、飛行機だ、お城だ！」と、（子供）自身の
「創造性」により「何でも作れる」という面白味があった。
私も、子供の頃は、そうやって色々な物を作って遊んだ訳で、
そこでは「リアリティ」とかは気にする事は無かった。
リアリティを求めるならば、別途「プラモデル」を買えば
良かった訳であり、それは自分の好きな形状に作る事は
難しいが、出来上がった作品のクオリティは勿論高くなる。
ところが近年のブロック玩具は、殆ど「プラモデル」と
同じだ。最初から出来上がるモノ、例えば「宇宙船」とかが
決まっていて、それを作るのに必要なパーツのみが入っている。
多少は変形させて、違う作品を作れるのかも知れないが、
最初から何を作るかのレール（設計図）が敷かれている訳で
あり、子供達が創造性を高める事が出来るようになれるか
少々疑問だ。まあ「分解・再組み立てが出来るプラモデル」
のようにブロック玩具が進歩して、今時の子供が、そういう
モノしか欲しがらないだろう事は、良く理解できる。
けど、そうやって育った子供達が今時のプログラマーに
なってしまい、まあ、コーディングのテクニックは持っては
いるものの、１から何かを作る創造性に欠けていたとしても
そこは、やむを得ない世情なのかも知れない。
すなわち、「プログラミングはアート」なのである。
「創造性」が必要となり、そこがとても重要なポイントだ。
だが、その事を理解しているプログラマーは少ない。
勿論、プログラミングに限らず、「写真」もアートである。
けど、一般のアマチュア層は、その事も全く理解できず、
「写真を勉強する」と言っても、著名な写真家の作品を見て、
それと同じ場所に行って同じ写真を撮ろうとしてしまう。
それでは「お手本が無いと何も出来ない習い事」となって
しまい、初級者のうちは、まあそれでもやむを得ないが
中級者レベルになったら、「お手本を見て撮る」などは、
有り得ない話だ。そこは是が非でも、自身の「作風」や
「個性」や「表現」を創造していかなくてはならない訳だ。
（逆に言えば、創造性が無く、単に「綺麗に撮れた写真」
を目指しているならば、いつまでも初級者のままである）
・・さて、余談が長くなった「横浜写真」の話に戻る。
明治初期の「横浜写真」は、勿論、人物は殆どが和装である。
これはまあ、実際には洋装が増えてきた時代だとは思うが、
横浜写真は外国人向けの「お土産」であるから、日本的な
風景、風情や風俗が無いと、商品にならないからだ。
ただ、本物の「横浜写真」と言えども、庶民の日常を
そのまま撮って彩色したようなものは殆ど無い模様だ。
いずれも、スタジオ等でセットを組んで、そこで意図を
持って人工的に環境を整えて撮影されたものらしい。
その事は、博物館の解説では「やらせ」と書いてあったが、
今時でそういう用語を使うと、なんだか悪い事をしている
ような印象もある（TV番組でのコンプライアンス違反とか）
もう少し柔らかい言葉を使えば「意図的に演出された写真」
であると言える。
で、むしろ、現代的視点からは、そういう「作画意図」やら
「主張」や「表現」の、はっきりとした写真は好ましい。
別に、写真とは、常に実際の状況を、そのまま撮らなければ
ならない、という訳では無いのだ。
博物館の説明版では、写真のその本質について理解していない
から、意図的な演出写真を「やらせ」と記載したのであろう。
そうした考え方は、写真家の土門拳氏が「絶対非演出」という
概念を持って、今から約70年も前に「演出写真」の植田正治氏
等と対立した事でも知られている。勿論、とんでも無く古い
時代の論争であり、現代とは、全く時代背景も世情も異なる。
まあ、両者の考え方は、学んで知っておくべきではあるが、
どちらかでなければならない事は全く無いし、特に現代に
おいて映像が「芸術」である事のみならず、「ビジネス」が
介在する場合には、当然「演出」の必要性が増す事であろう。
で、まあ、「横浜写真」自体が「商品」しかも、かなりの
利益のあった看板商品であるから、そこに日本的な演出を
加えて付加価値を上げる事は、不可欠であったのだろう。
また余談が長くなった、上写真であれば、背景に現代的な
風景などは写っていないし、着物自体もアンティーク品だ。
それと、赤、緑、青等の純色が万遍なく混じっている写真が、
この処理に向いているようにも思える。
さて、パラメーターを調整して自動計算をスタート、
結果は以下のようになった。
なお、「横浜写真」では、肌の部分は彩色していない
作品が多い模様であり、今回作ったアルゴリズムでも、
肌色には彩色しないように作ってある。
「アンティークな雰囲気」と「横浜写真」はマッチする
ように思えてきた。さらに、そうした写真を探してみよう。
女性をF0.95の超大口径レンズで柔らかく撮った写真だ。
実際の「横浜写真」では、彩色に加えて輪郭の書き込みを
行っているケースもある模様であり、輪郭線が不自然に
出すぎている場合がある。（でも、それが特徴だ）
まあでも、だからと言って、このソフトに「輪郭強調」の
処理アルゴリズムを加えるのは止めておこうか・・
それはむしろ写真を撮ったレンズ毎の特性等で、調整すれば
良いのかとも思う。
（ちなみに、2つ上の赤い橋の女性の写真は、「横浜写真」
処理により、若干だが元の画像より輪郭が強く出ている。
これの原因は不明だが恐らくは、セピア化処理で輪郭部が
黒く残っている所に彩色画像を重ねているからであろう。
だとすると、輪郭強調よりも、逆に、セピア化時に
「輪郭をボカす処理」が欲しいとも思われる。
だがまあ、前述のように、レンズ側の描写特性で調整した
方が、沢山の交換レンズを所有している私としては簡便だ）
「横浜写真」として悪くは無いが、気になる点としては
女性の背中の帯（注：「お太鼓」と呼ぶ）の、薄い緑色が
上手く抽出しきれておらず、抽出が出来無ければ、結果的に
代替の彩色処理もされていない状態だ。
この薄い緑色までを抽出するには、パラメーターをもっと
緩める（＝緑を良く拾う）ように改良しなければならないが、
その改良自体は容易ではあるものの、そうすると恐らくだが、
緑色を拾いすぎるようになってしまう。
きっと、画面内の他の部分からも、緑に近い部分が多数、
余計に抽出される。で、それを避けるのは容易では無い。
別の方法論として、マウス等で帯（お太鼓）の部分を
範囲指定して、そこだけから色抽出する事が考えられるが
そうなると、もう、高機能レタッチソフトで「画像編集」を
チマチマと手動でやっている状態と同じである。
そういう、手動の「画像編集」を、やりたく無いから、
自動の「画像処理」ソフトを開発した訳だ。
あくまで、やりたい事（目的）を達成する為の開発作業で
あるから、ここでソフトの機能アップを目論んでいたら、
「プログラミングをする事」が主目的に変わってしまう。
ここはエンジニア等が陥り易い課題だ、目的は「横浜写真を
簡単に生成したい」のであって、ソフトの機能を、あれこれ
と追加したり、こねくり廻してプログラミングをする事は、
今回の作業の目的でも何でもない。
でも、たいていの製品開発などでは、そうやって旧製品の
機能を上げることのみに注力してしまう。そういう状況では
まったくの新発想や創造性など、まず生まれて来ないだろう。
それと、ソフトを開発する為に使う時間を「（開発）工数」
と呼ぶ。これはすなわち、かかった手間であるが、ズバリ、
これは「費用」である。「コスト」と言い換えても勿論良い。
ビジネスの場合はもとより、たとえ趣味で行っていても、
学習の対象としても、費用対効果、つまり「コスパ」は
必ず意識する必要がある。
何ヶ月もかかってソフトを作って、実際にはほとんど使わない
のであれば、「コスパ」は極めて悪くなる。
たとえ完璧では無くても、目的がほぼ達成できるソフトを
極めて短時間で作って、あとはじっくり、それで目的とする
「横浜写真自動生成」を行えば良い、それが最もコスパの
良い時間配分（効率）となる訳だ。
完成品を長く使い込んだ状態で、必要な改良点が見えて
きたら、そのソフトを「バージョンアップ」すれば良い。
完成した物を全く使わないで、機能や性能をアップする事は
有り得ない。その事はソフトウェアに限らず、ハードウェア
も含め「モノづくり」の基本だ。
しかし、現代のデジタルカメラ等において、開発側がちゃんと
作った機材を使いこまずに、毎年のように数値性能だけを
アップしているような状況は多々見られる、それは決して
褒められた話では無いのだが・・
---
さて、今回の記事はこのあたりまでで。
「趣味」の範疇で、このレベルのソフトウェアを作る事は、
あまり一般的な話では無いとは思うが、「プログラミング」
とは、実際にどういう事をするのかの参考になれば幸いだ。