さて、紅葉シーズンを間近に控え、「何処に行こうか?」
と、ソワソワと計画を練っている人も多いかも知れない
今日この頃の季節である。
ただまあ、近年では(私が嫌っている)「一極集中化現象」
によって、著名な紅葉の名所や観光地は何処へ行っても
非常に混雑している。じっくりと写真を撮れ無いどころか、
ただ紅葉見物で歩いているだけでも、なんだか興醒めだ。
無理に写真を撮ろうとしても、「そこをどけ!」などと言う
カメラマンの風上にも置け無い、レベルもモラルも極めて低い
超ビギナーが多数居て、下手をすれば大喧嘩になってしまう。
私の場合は、駅の観光チラシやTV番組、情報誌等で紹介された
スポットには絶対に近寄らないようにしている。
つまりそれらは、多数の人達がその情報を目にする為、
当然ながら「受動的な人達」は、そこに一極集中してしまう。
で、私は、そうしたマス(大量)メディア情報を「逆情報」と
して利用する訳だ。
実際に私が行く場所は、そうした一般的情報に載らない場所
である。そして、有名処などは、たいてい過去に行った事の
ある場所ばかりだ、少し前の時代に行って、「良かった」と
思っても、久しぶりに訪れてみたら、既に有名になってしまい
観光客だらけで、ちっとも楽しめなかった、という経験も
何度かあるので、ますます有名な紅葉名所等には近寄る気が
しない。
しかし、たまたま紅葉の時期に忙しくて、紅葉見物など
行く気がしなかったり、行けなかったりする事もあるだろう。
あるいは、ひねくれた方法論では、あえて紅葉の前などに
名所に行って、「ここが紅葉したら、さぞかし綺麗だろう」
などと想像をめぐらせる人も居るだろう。
そこで、今回の発想だが、「紅葉では無い写真を撮って
それが、あたかも紅葉のような写真に変換できたら、
面白いのでは無いだろうか?」というアイデアである。
本シリーズ記事は、「プログラミング」を行う主旨である、
独自のアイデアを、パソコン上で自動的に計算する為の
「アルゴリズム」を独自に考察し、その(画像)処理を
実現する、という作業を行う。
まあでも、この処理自体は、専用ソフトを作らない迄も、
実は昔から「編集作業」でやっていた。
例えば、上写真だが、これはパソコン用の高機能な
レタッチ(画像編集)ソフトを駆使し、手動で色々と
編集作業を行う事で、ごく普通の初秋の風景を紅葉の
時期の写真のように修正したものである。
だが、これは、滅茶苦茶手間がかかる編集作業だ、
正直言うと、あまりやりたくない。業務上でポスターや
チラシを作るとか、そういう目的や理由が無いかぎり
趣味の範疇では、とてもやっていられない作業だ(汗)
---
さて、今回の記事は、コンピューターのプログラミングの
話である。
今年の正月に「横浜写真」を生成するソフトをプログミング
する記事を書いたが、まあ、そのシリーズ続編である。
つまり、今回は「紅葉写真」を自動的に生成するソフトを
作ってしまおう、という話だ。
この(自動)画像処理を「擬似紅葉」と呼ぶ事にする。
まあ、レタッチソフトによる、手作業ほどの厳密性は
無くても良い。だいたいだが、写真が紅葉風になったら
それで良いし、あるいは、そうした「素質」のある写真を
簡単な操作で見つける事ができれば、業務用等で必要ならば
そこからさらに手作業で、ちゃんとした画像編集をすれば
良い訳だ。
そういう意味では、「スクリーニング」ができるソフト
とした方が良いかも知れない。
英語のスクリーニング(screening)には、いくつかの意味
があるが、ここでは「選別する、ふるいわける」という
意味で用いている。
パソコン界では、通常、フォルダー等に多数存在する
ファイル群の中から、条件に合うものを抜き出す場合等に
用いる、やや専門的な用語だ。(「検索」というよりも
インテリジェントな要素が大きい、すなわち「判別」だ)
つまり、ここでは「多数の画像に連続的に”擬似紅葉”
処理をかけて、結果を見て、気にいったものを選ぶ」という
事(フローチャート)になる。
だが、残念ながら、この案は実現できない事がわかった。
画像編集ソフトによる予備実験では、個々の画像毎に、
個別に上手くパラメーター(設定要素とその値)等を調整
しないと、なかなか上手く全自動では処理ができないのだ。
であれば、もう、単体の1枚づつの画像を取り込んで、それを
簡単な「GUI」(グラフィカル・ユーザー・インターフェース)
を用いて、マウス等でパラメーターを画像に適するように調整し
「擬似紅葉」処理を行って、出来上がった画像が気に入れば
そのまま保存、気に入らなければ、パラメーターを再度調整
して、また擬似紅葉処理を行えれば良い。
(注:どうやっても上手くいかずに諦める画像もあるだろう)
まあ、これが、今回のソフトの基本的な「フローチャート」
となる。
前記事「横浜写真生成ソフト」のところでも述べたが、
プログラミングを行う前には、きっちりと「要求仕様」を
決めなければならない。それが無いと始まらないのだ。
ビギナーのプログラマー(またはパソコン初心者)では
パソコンの前に座って、いきなりプログラミング開発環境
を開いて、おもむろにプログラム(ソースコード)を書こう
とする人が多いが、そんなやりかたでは、そこから先は
1歩たりとも進む事はできない。何をどう作るかが明確に
決まっていない状態では、何もできるはずも無い。
そんな状態は、料理で言えば、いきなり玉ねぎを微塵切り
にしてから「さあ、何の料理を作ろうか?」と考えるような
ものである。勿論順番が完全に逆であり、作る料理が決まって
から、その手順を考えて、調理を始めるのだ。
(あるいは、他にある「レシピ」を参考にしないと、料理を
何ひとつ作れない、という情けない人達もずいぶんと増えて
いる様子だ)
さて、という事で本来はプログラミングの前に「仕様書」を
書かなければならないのだが、今回もまた完全な趣味の範囲
でのプログラミング開発なので、仕様書作成は省略する事と
した。(注:業務上の開発では、勿論省略は不可だ)
その代わりだが、作り始める前に一週間ほど、仕様を頭の
中で熟考する事とした。
これはまあ、将棋で言うところの「目隠し将棋」「脳内将棋」
のようなものだ、有段者等になれば、目の前に将棋盤や駒が
無くても、「2六歩」「8四歩」・・などの棋譜により、
頭の中で、その局面を構成する事が可能である。
私も将棋は有段者クラスなので、これは一応出来る。
プログラミングにおける「脳内仕様書」は、やはり有段者
クラスで無いと難しいであろう、つまり中級クラス以上の
プログラマー(エンジニア)で無いかぎり、仕様書はちゃんと
作る事が望ましい。
なお、仕様書上で、画面のGUIを決める際、ワードやパワポ
でそれを書いていくと、とても面倒な場合がある。
そういう場合、C#言語などの開発環境を立ち上げて、
そこで実際にGUI設計を仮で行い、出来上がった画面を
コピーして仕様書とする場合も有り得る。
その試作品的なGUIソフトは、仕様書が出来た時点で捨てて
しまっても、あまり惜しく無い。1時間ほどでその作業は
出来るだろうからだ。
あるいは、「せっかく作ったのだから勿体無い」と、思う
ならば、その試作品にさらに手を入れて、そこから本番の
開発に移行する事も可能である。
まあ今回も、頭の中で考えた仕様が実現できるか?の検証
も含めて、試作品を最初に作る事とした、そこで上手く
いかないようならば、再度練り直しするか、あるいは上手く
いきそうならば、そこから手を入れて実用品の完成を
目指せば良い訳だ。
これが、「擬似紅葉」ソフト「Autumn」のC#言語による
試作中の画面。
なんとか上手く行けそうなので、このまま本番開発に
移行する事とした。
なお1点注意点であるが、Microsoft社製の開発環境
「Visual Studio」(注:無償版を含め、様々なバージョン
あり)で、こうしたプログラムの一式は「プロジェクト」と
呼ばれている。
プロジェクトを作り始める際、その名称(名前)を決める
のであるが、実は、これを後になって変更するのは、少々
手間である。
ここで気をつけなければならないのは、プロジェクト名を
間違って入力した場合だ。修正が面倒なので、後で気づくと
「あちゃ~」となってしまう(汗)
もう1つ、たとえばこれを試作版として廃棄したりする
場合だ、廃棄するといっても、本番用の参考にするだろうから
試作品を完全に消去する事は出来ない。だが、同じ名前の
プロジェクトを作れないため、本番用では別のプロジェクト名
が必要となる、それを見越して試作版は「TEST」などの名前に
してしまうと、その名称をそのまま本番用には使えない。
なので本番用は、試作品名称にTYPE1とかⅡとかをつける
必要が出てくる。
だから最初に出てきた製品が、バーションⅡになる事も、
まあ、有りうるといえば有りうる訳だ。
たとえば、アニメ「機動戦士ガンダム」でも、ジオン軍の
最初に実戦投入された量産型モビルスーツは「ザクⅡ」
(MS-06)であり、それ以前の「ザク」(MS-05、旧ザク)
は、初代アニメ中では殆ど出てこず、まあ試作品のような
扱いであったのだ。
アニメ「ガンダム」のシナリオは、「開発」の実情に
詳しい人が加わっている模様であり、こうした細かい設定が
開発業務における「リアリズム」として伝わってくる。
だから、ガンダムに登場する兵器エンジニアの人達の
名セリフなども色々ある訳だ。
「足なんて飾りです、偉い人にはそれがわからんのです」や
「無茶だ! 特性が殺されてしまっている」などは、
エンジニアの素直な心境を表すセリフとして興味深い。
さて、余談はともかく「擬似紅葉」のプログラミングである。
様々な画像を入力して、個々に処理する必要があるから、
GUIはなるべく簡単なものでなくてはならない。
つまり、ここで細かい沢山の画像処理パラメーターを全て
外に出してユーザー(といっても自分だが)に調整させる
ようにしてはならない、という事である。
ところが、こういう「何を残して、何を削るか」という
割り切りが、多くのエンジニアにおいては、出来ないのだ。
だから、「あの機能も欲しい、この機能も入れておかなくちゃ、
これの調整はどうするのだ?」と、ボタンやスライダーやら
メニューだらけの、とてつもなく複雑なソフト仕様になって
しまうのだ。
そういう風に機能が肥大化すると、その開発も時間がかかる。
時間のかかる開発は、「コスト」面では好ましく無い、と
以前の「横浜写真」開発の記事にも書いた通りである。
そして実際にも機能肥大の仕様となると、いつまでも開発が
進まず、途中で断念してしまったようなエンジニアも多数
見てきている。
また、カメラ開発等でも同様だ、実際に写真を撮る行為に
精通せずにカメラを作っていると、そうした「操作系」
(まあつまりGUIと、ほぼ同じだ)についての仕様設計が
出来ない。なので、様々な追加機能を全て同列に扱って
メニューの奥深くに押し込んでしまう為、とてつもなく
使い難いカメラが出来上がってしまう。そして残念ながら
現代の高機能一眼レフやミラーレス機は、殆ど全てが
そういった好ましく無い仕様(操作系)である。
さて、では、仕様の「割り切り」だが、まあここは
カン(経験則)を使うしか無い、このあたりは、実際に
多数のソフトを使ったり、作ったりしないとわからないし
そして大変なのは、まったくの新規の概念や機能を実現する
際には、そういう過去の経験則が、直接的には役に立たない
事である。だから、単に経験値ではなく、センスや感性等の
要素も必要となるのだ。
「プログラミング(や開発作業)は、アートである」と、
横浜写真の記事でも書いたが、新しい事を実現するには、
創造性のみならず様々な経験や感覚値も大きく要求される。
エンジニアには「論理性」が必須の能力であるが、そうした
「論理性」と、このような「感覚値」は一般的には両立が
難しい。だから、現代においては、仕事の分業化も非常に
進んでいる。もう現代では、昔のように、個人での優れた
開発者・研究者や発明家等は、がなかなか出にくい状況だ。
・・さて、ここでのポイントは「どのように擬似紅葉を
実現するか?」である、だけど、ここは公開はしずらい
横浜写真の記事でも書いたが、こういうことは、高度な
「知的財産」であるからだ。
昭和の時代であれば、「情報と水はタダで手に入る」と
皆が思っていたが、現代では「それらは貴重なものである」
という認識も常識となり、当然ながら対価を払って入手する
ものである。
今の時代になっても観光地等で「どうやったら行けますか?」
などと聞いてくる人達が多いが、「スマホを持っているならば
自分で調べろよ」と思ってしまうし、そういう計画なり事前の
調査を何もしないで観光に来る等が、そもそも信じられない。
「いきあたりばったりの観光も面白い」という点は、理解は
出来なくは無いが、それにしても、その度が過ぎれば無意味
であるし、その結果として、ほんの5分も歩けば到着できる
場所なのに、「行き方がわからないからタクシーを使う」
という人達が極めて多く、混雑する観光地が、さらにそれで
混雑してしまい、一般交通にも甚大な影響が出てしまう程だ。
さて、苦言はともかく、擬似紅葉の心臓部の方法論、つまり
「アルゴリズム」は、すでに頭の中では3通りほど考えて
あったので、それを順次プログラミングしていくだけである。
旧来、こうした複雑な画像処理は「C#言語では実現が難しい」
という風に思っていて、その為、わざわざ計算部(エンジン)
を別途C++言語で作っていた。
まあ、事実その通りなのではあるが、近年になって、あまり
複雑な処理でなければ、なんとかC#言語の範囲でも可能。
という手法がわかってきたので、徐々にではあるが、
C#のみの画像処理ルーチンを蓄積し始めている。
なお、「横浜写真」の記事でも書いたが、私は汎用画像処理
ライブラリ(Open CV)等は使用せず、すべて自力でソース
コードを打ち込んだものを使っている。
それにはいくつもの理由があるが、最も重要な点のみを
あげておけば、「中身が分からないものを使っていても
全く勉強にはならず、スキルアップが出来ない」という
事である。
ソフトウェア開発に限らず、これはあらゆる分野で同様だ、
たとえば料理においても、どこかにあるレシピ通りの材料や
分量で作っていたら、まあ食べられるモノは出来上がる
だろうが、料理の腕前は上がっては行かない。
そして「写真」でも同様であろう、いつまでも露出の原理とか
カメラの機能や効能などが全くわからないままで、たた単に
高価で高性能なカメラやレンズの性能に頼って撮っている
だけでは、まあ、たまたま綺麗な写真が撮れる事もあろうが
それでは何十年写真を撮っていても、永久にビギナーのままだ。
そして、アマチュア層では、そういう人達がほぼ全てであるので、
もう本当に情けない状況だと思っている。
どのジャンルにおいても、自身で知識や技能を高めて行こう
と思わない限りは、だらだらと続けていても何も意味は無い。
さて、これで「擬似紅葉」ソフトが、仮完成した、
ここまで約4時間の作業である。
ただ、これはまだ仮であり、実際に使ってみて、問題点を
洗い出し、そこを改良しないと完成には至らない。
まず最初に気づいたところは、「パラメーターの調整が
難しい」、という点である。これはまあ、操作系を向上
させる為に、スライダーの数を2つにまで絞ってあって、
それ以外の、およそ6~8程度のパラメーターは内部で
設定した固定値、または演算(計算)により弾き出される
ような仕様にしたからである。
だから、表面に出ているこの2つのスライダーで、上手く
調整できないのであれば、内部的なパラメーターを変更する
必要がある。ここはさらに微調整を続けて行こう。
もう1つの課題は、画面全体の処理だと、たとえば人物
の服なども、その色によっては擬似紅葉化されてしまう。
という点である。
こちらがその例、女性の服の帯の部分の緑色に反応して
そこも「擬似紅葉」になってしまっている(汗)
だが、そうなるだろう事は、事前に予測済みであった。
従前に、高機能レタッチ(画像編集)ソフトを用いて
擬似紅葉を手作業で作っていた際にも、マウスで人物の
範囲を綺麗に囲んで(注:これはとても手間がかかる)
その範囲を反転し(=人物以外とする)、そこに対して
擬似紅葉に相当するカラー修正処理をやっていた訳だ。
よって、本ソフトにも「人物を範囲外とする」という
機能をつければよい、ただし前述のように、マウス等で
チマチマと人物の輪郭を囲んでいくのは、大変手間の
かかる作業であり、作業のみならず、そういう機能を
プログラミング(実装)する事も、とても大変である。
よくまあ、市販レタッチソフトは、そうした機能を色々と
搭載しているものだ、と感心するが、まあ、それは
そういう(高額な)商品であるから、手間隙をかけて
ちゃんと作っているのであろう。
この「擬似紅葉」ソフトを作るのに、(あるいは使うのに)
そこまでの手間暇(コスト)はかけれない。
休日の1日しか、予定している工数は無いのだ。
ではどうするか? ここはもう単純に「矩形範囲選択」
機能を追加しよう。
これが「矩形選択」機能。マウスで始点と終点を選べば
そこに矩形範囲が生成される。この囲まれた部分には
「擬似紅葉処理」を行わない。
ただ、簡単そうに見えて、結構難しい処理である。
それは画像上に四角の枠を描く事が課題なのでは無い、
そんな事は、C#(.NET Framework)のグラフィック関数を
使えば、1行で実現できてしまう。
問題点は、ここでの「座標」の処理である。
ここに表示している元画像の画素数はまちまちである。
これもC#の機能(プロパティ)で、どんな画素数でも
きっちりと大きさを揃えて表示されるように出来るのだが、
ではマウスで選んだ位置は、実際の画像上では、どこの
座標に相当するのか? ここの計算式を考察しなければ
ならない。ここは面倒だが、やるしか無い(まあ結果的に
10行程で実現できる計算処理であった)
そして、もう1つ、マウスで座標選択中(Mouse Move)の
最中にも、この枠は表示され続け、クリックで確定する
ようにするのだが、その際、元の画像の範囲外にマウスが
動いたらどうなるのか? ここも常時その判断が必要だ。
考えたあげく、後者の問題(画像範囲外)は、無視する
事とした。これの処理を実装するのは、とても大変そう
だからである。市販のソフトでは、そういう手抜きは
許されないが、このソフトは私しか使わないし、あるいは
他人に使ってもらう事も一切想定していない。
であれば、ここで座標が範囲外となると、「ソフトが飛ぶ」
(これは、不自然なデータが入って来て、コンピューターが
計算できなくなったり、エラーとなったり、あるいは致命的な
異常処理や暴走を起こす等)事は覚悟の上で、気をつけて
慎重に使うとしよう。
この矩形範囲(外)指定の実現により、上手く問題点を回避
できた。が、これでさらに約1時間を費やしてしまった。
さて、後、残るは、パラメーターの微調整である。
例えば、上写真では川面の青もみじの反射まで擬似紅葉化
されてしまっているが、これはパラメーターを微調整して
できるだけそうならないようにしなければならない。
さらに課題はある・・
どうも「擬似紅葉化」での色味が地味なように思える。
ただ、実際の紅葉も、一般的に頭の中で想像するような、
真っ赤な派手な色味ではない、そういう印象があるのは
ポスター等の商業写真でも、必ずレタッチ(編集、修正)
が行われているからである。
ポスターを見て「綺麗だから」と、その名所に足を
運んだとしても、実際にはポスターほどの綺麗さは
無かったりする。がっかりしたり、あるいは腹が立って
仮に関係者などに詰め寄ったとしても、「ああ、それは
以前の写真ですね、今年は色味があまり良く無い模様で、
すみませんねえ・・」で片付けられてしまうだろう。
(私はそんな事は言わないが、シニア層等では関係者等
に文句を言う事は日常茶飯事である模様だ)
まあ、紅葉の名所に限らず、様々な観光ポスターなどは、
ほぼ100%色々と手を加えられて出来上がっている。
だから、「実際には有り得ない合成された風景」なども
いくらでも存在しているのだ。これは、2000年頃から
デジタル写真の編集技術が一般的になってからにおいては
もう「常識」の類である、まあ、観光ポスターがあくまで
「雰囲気」である事は、もう誰もが知っていて当然だ。
なお、ここ数年の紅葉名所案内等は特に酷い。私は逆情報
(混雑する場所に行かない為に)を目的として駅でパンフ
を貰って来たが、HDR処理を始め、画像編集で、こねくり
回したウソの風景写真ばかりで、あきれてしまった。
「これを見て、紅葉名所に行きたいと思うのだろうか?」
「この風景写真が加工しまくっているものだと、誰も
気づかないのだろうか?」
と、ますます、そんな場所に近寄りたいとも思わない。
で、余談が長くなったが、この「擬似紅葉」ソフトでは、
そうした印象・想像による「記憶色」を再現するのか?、
はたまた、実際の紅葉風景に近いリアリズムを求めるのか?
そこが問題になるのだが、でもまあ、これについては、
その画像によりけりであろう。
きっちりと、その「記憶色」に近い被写体は、まあ
「もみじ」くらいしか無い訳であって、実際の紅葉時期
になったとしても、常緑樹などはいくらでもある。
すると、無闇に常に紅葉の色を濃くする訳にもいかず、
被写体状況によって、そこは切り替える必要があるだろう。
そこで追加したのが「エンハンス」機能である。
これは、「擬似紅葉」の色味を、少しだけ派手にする。
あまりやりすぎると、以前の「横浜写真」のように不自然
な彩色になってしまう(注:その「横浜写真」は、あえて
不自然な彩色とする事に価値があるので、それで良い)
だから「擬似紅葉」を強調すると言っても、ほんの少し
だけで良い。
機能追加と、パラメーターの微調整を行い、さらに
1時間が経過、合計6時間で、ほぼこのソフトが完成した。
まあ、良好に動作している。
本ソフトの目的としては、これで十分である。
簡易版ソフトとは言え、操作系ではあまり手を抜いて
おらず、「ドラッグ&ドロップ」機能や、プリセット
パラメーター機能、「クリップポード」へのコピー
機能等、素早く操作する為の機能は搭載してある。
他はパラメーターの微調整以外は、今後の改良も不要だ。
もし機能追加等をするとなると、例えばフォルダー内の
全画像を連続処理(スクリーニング)するとか、あまり
必要でも無い余計な機能の搭載の検討になってしまう。
そういう「無駄な改良」は、エンジニアが陥り易い
一種の「罠」だと思う。
現在ある製品(ソフトやハード)に、さらに(偏った意味
での)「付加価値」をつけようとして、無駄な機能を
色々とつけてしまうのだ。
例えば、カメラ等の成熟商品では、いくらでもそれがある。
新製品では、何らかの新機能をつけないと、ユーザー層が
興味を持たず、納得もしない為に、実際には不要と言える
機能が、どんどんと搭載され続ける。
まあ、それだけであれば良いのだが、その結果として、
価格が上がったり(高付加価値化による値上げ)または
非常に使い難くなってしまう(高機能化による操作系悪化の
課題)
もうだから、そういう類の無駄な機能の追加は、ユーザー側
が望んでいない事だし、それが「付加価値だ」と言われても
ただ単に反発するだけの状態に繋がってしまう。
現代のカメラ市場が縮退しているのは、スマホの台頭だけが
原因なのでは無い、「欲しいと思えるカメラが1台も無い」事
が最大の原因なのだ。その証拠に、マニア層、上級層や職業
写真家層等では、最新鋭カメラで武装している人は殆ど居ない。
そうした、「高価なだけ」の高付加価値カメラでは無くても
旧機種等であっても、何も問題なく写真は撮れるからだ。
余談はともかく、本ソフトは「擬似紅葉を簡単に実現する」
事が最大の目的である。プログラミングでの小細工や工夫や
機能追加は、目的とする方向とは完全に異なっているのだ。
残る課題は・・ まあ、紅葉の発色をどう捉えるかで
あろう。前述のように、人間が思っている「記憶色」と
実際の紅葉色とは違うと思うので、そこが難しいのだが、
すでに搭載してある「エンハンス」(強調)モードを用いて、
それがONの場合には「派手な記憶色」、OFFとすれば
「実際に近い地味な紅葉色」とすれば良い。
そのパラメーター調整は、必要であれば、今後また時間を
かけて調整していけば良いだろう。
他の課題は、色抽出側である。上写真では人物の奥の
道の部分の一部が、べったりと擬似紅葉に変換されて
しまっている。これは原画での、その部分が、青もみじ
の反射などで、そういう色味になっているからでもあり、
また、これは大口径中望遠レンズで撮った写真であるから、
ボケ量が非常に大きく、そのボケ質の状況にも影響されて
いるかも知れない。
一般的な風景写真のように、広角から準広角レンズで
絞り込んでパンフォーカス状態にしたような写真では
無いのだ。逆に言えばパンフォーカス写真を入力すると、
また別の課題も出てくるかも知れない。
すべての写真に対して完璧に動作するような自動化処理は
たとえ「擬似紅葉」ではなくても、たいていの画像処理で
同様に困難であろう。また、こういう事は、たとえ流行の
「AI」(人工知能)を用いても、決して上手く行かない。
ソフトの開発では、地道に、オーソドックスな方法論を
積み上げていくしか無い訳だし、そこに手抜きをしたり
深層学習(ディープラーニング、AIの一種)で楽をしよう
としても、まず上手く行かない。
物事の基本原理がわかっていない限り、そのあたりの解決
手段は、何も思いつくはずが無いのだ。
それから、写真そのものの撮り方も重要だ。
例えば、前述の「矩形範囲指定」処理だけでも、擬似紅葉
化において、服がその周辺の構図と干渉しないのであれば
編集作業はとても楽になる。けど、もし矩形ではなくて
マウスの自在曲線で人物を切り抜く必要性がある構図に
してしまうと、後編集の「コスト」(手間)が、数十倍
にもなってしまうのだ。
だから、撮影時に、後の手動画像編集、あるいは、後の
自動画像処理の事まで考えて、問題にならない構図を
選ばなくてはならなくなる。
まあ、こういうことはポスター写真の専門家などでは
「切り抜きしやすい構図」なども意識しているとは思うが、
一般アマチュア層では皆無であろう、つまり誰も、後の
画像編集や画像処理の事など、何も考えずに写真を撮って
いる訳だ。
今(現代)は、まあ、それでも良いとは思うが、もう少し
だけ時間が進み、未来となったら、写真等はパーソナル
(個人)のレベルで加工して使うのが、当たり前の文化
となるだろう。既にスマホの世界では、若い女性等は
写真を撮ったままではなく、様々に加工して楽しんだり
あるいは、バーチャルな世界に溶け込む為に、それを
行っている(つまり、実際の顔などを公開したく無い、
又は、いわゆる「盛る」事で実際よりも良く見られたい)
カメラマンも銀塩時代からデジタルに変わったばかりの
2000年代では、「撮ったまま使うのが写真だ」などと
古い考え方の人達が大半、という残念な状況であったが、
そこからもう10数年が経過している。
いつまでも「撮ったままが王道」などと言っていたら
どんどんと時代に取り残されるばかりである。
画像編集(画像処理)を意識した写真撮影技法、など
ある意味当然の話に将来にはなるかも知れないのだ。
---
さて、今回の記事はこのあたりまでで。
例によって、「趣味」の範疇で、こうしたソフトウェアを
作る事は、あまり一般的な話では無いとは思われるが、
まあ、そろそろ来年から学校での「プログラミング教育」
も始まる頃合いであるし、色々な意味で本記事が参考に
なれば幸いである。