「点描画」変換ソフトのプログラミング

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

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

こうした画像処理の方法論は、一般に「アルゴリズム」
（＝算法、計算手順）と呼ばれる。
本シリーズでは、過去に例の無い全く新しいアルゴリズム
を創造・創生する事を主眼としているので、例えば何処か
にあるサンプルのソースコード等をコピーして打ち込んだ
ものでは無い。

まあつまり、完全独自開発のプログラムであり、独自性を
高める為、画像処理のプログラム・ソースコードも、全て
１から自分自身で打ち込み、他にある画像処理ライブラリ
（OpenCV等）も一切使用せず、他者のソースコードも
引用しない、という厳しいルールとしている。

既に本シリーズでは、8種類の独自プログラムを完成
させていて、本記事は第9回目のプログラミングとなる。
で、今回の記事では、写真を19世紀末絵画の「点描画」
（点描/Stippling/視覚混合/点描法/等・・）のような
画像に自動変換するソフトウェアをプログラミングする
事としよう。






まずは、「点描画とは何か？」という話だが・・

点描以前の、19世紀後半（1870年代～1880年代頃）
における、フランスの「印象派」については、もう
説明の必要も無いであろう。

西洋絵画に詳しく無い人達であっても、一般常識として
「印象派」という名前（用語）は、必ず知っている筈
であるし、印象派の画家たちの絵画、例えば、
「モネ」（睡蓮、日傘の女）、「ドガ」（踊り子）、
「ルノワール」（舞踏会）、「マネ」（バーの女給、
オランピア）等の絵画（名作）は、誰でも必ず目にした
事がある筈だ。

印象派は、後に後期印象派（ポスト印象派）に変遷し
そこでも、「ゴッホ」「ゴーガン（ゴーギャン）」

「セザンヌ」等の巨匠の名前が連なる。

（参考：「ゴーガン」(Paul Gauguin：仏）は、

従前では「ゴーギャン」と呼ばれていたのだが、

近年の美術書等では、原語の発音に近い「ゴーガン」

と記される事が多くなってきている。

同様に、旧来の「グスタフ」という名前も、近代では

「ギュスターヴ」「ギュスタヴ」等と書かれる事も

あるが、これは画家の出身地や原語によりけりであり、

「ギュスターヴ・モロー」（Gustave：フランス）や、

「グスタフ・クリムト」(Gustav：独/オーストリア）

のように、画家それぞれで異なる記載法となっている）

ただし、こうした、後期（ポスト）印象派は、それを
ひとくくりに出来るような、ある一定の絵画様式（描き方、
画法、作風）がある訳ではなく、それぞれの後期印象派の
画家達は、個々に新しい画風を模索していた。
そんな時代、「スーラ」（Georges Seurat：仏
1859-1891年）という画家が現れた。
彼は、一部の印象派の画家達（モネ等）が進めていた
「筆触分割」（＝複数の色を個別に塗り、それを遠く
から見ると、色が混ざって見える（視覚混合）という
現象、またはその技法の事。
要は、絵の具を、パレット上やキャンバスの上で
混ぜると、「色」は必ず暗くなってしまう。
これを避け、複数の色を混ぜずに用い、絵の見た目の
明度を高める措置が「筆触分割」「視覚混合」な訳だ）
・・を、さらに発展させ、「点描」という技法を完成
させた。

1886年には「グランド・ジャット島の日曜日の午後」
を発表、この作品も超有名であり、誰でも見た事がある
だろう。（古い絵画なので、著作権はフリーであるが、
ここで掲載するのはやめておく、他人の作品だからだ）

スーラの点描技法は、世間一般にも大きな影響を与え、
彼の作品1つで、これに「新印象派」という名前が
新たにつけられたほどである。
（参考：他にも「点描法」を使った画家としては
ポール・シニャック（Paul Signac：仏）が著名だ。
シニャックも「新印象派」として分類されている）

ただ、誰が見てもわかると思うが「点描」は、とても
大変な技法である。「スーラ」は、物凄い理論家で
あった模様で、光学理論や色彩理論を勉強した上で
綿密に計算された絵画技法が「点描」だった。

この「点描」を習おうと弟子入り（？）した画家達も
あった模様だが、多分、あまりに面倒な技法なので
挫折したのではなかろうか？　確かそんな逸話を聞いた
事がある。

しかし、スーラは31歳という若さで、この世を去って
しまい、その総作品数は、さほど多くは無く、著名な
作品は数点のみだと思われる。

さて、スーラの点描法は、原色や補色を組み合わせた
複雑なスタイルで成り立っている。
今回のプログラミングにおいて、スーラのような点描法
を実現する為には、写真等の入力画像を色分解しないと
ならない。これをまともにやると、とても難しそうだ。

まず初期の案として、画像を三原色に分解し、それらを

隣接したピクセルに配置していくのはどうだろうか？

ここで「三原色」と言っても、「絵の具（色）の三原色」
（シアン、マゼンタ、イエロー。印刷用では黒を追加して
「CMYK」と呼ばれる）と、「光の三原色」（赤、緑、青
からなる、いわゆる「RGB」）の２種類が存在する。

この内、画像処理で一般的に用いるのは「光の三原色」
である。どちらの手法が本件の「点描」に適正なのか？
は、この段階では良くわからない・・
前述したように、印象派のモネや、点描法のスーラが
目指したものは、「絵の具を混ぜずに用いる事」であった
から、「色の三原色」を用いた方法論もあるかも知れない。
・・が、とりあえず「光の三原色」の手法を使ってみる。

では、画像のピクセルをRGBに分解し、それをピクセルの
周辺に、ばらまくようなアルゴリズムを考えてみよう。
プログラミング環境は、いつものようにMicrosoft Visual
Studioを使用。プログラミング言語はC#のみで行う。

色成分のピクセル周辺への、ばら撒きの方法だが、色々と
考える事は可能だ。だが、まずは最も単純に4ピクセルを

１つのブロックとし、ここに、RGBに分解した各単色を

隣接させる事とする。

1ピクセル余るが、ここは白、または平均色のいずれかを

選択できるように考えてみる。

白を選ぶと「フェルメール」や「伊藤若冲」が用いた
「ポワンティエ」（光を表現する際に白い点で描写する）
技法に近くなるかもしれない。
（注：実際には、あまりそうした効果は無かった・汗
「ポワンティエ」を目指すならば、画素単位では無く、
もっと大きい白色の塊を描かないとならないのであろう）

C#でのGUI画面で画像を読み込めるようにし、計算

（変換）開始ボタンを押すと、ピクセル毎の演算を行う

ようにソースコードをプログラミングしていく。

ここで前述のように、4ピクセルを1ブロックとして
色の分解を行うと、恐らくだが、処理結果の画像は、
一定間隔の「縞模様」が発生する可能性がある。

つまり、あまりに規則性の高い画像（処理）は、むしろ
不自然に見えてしまう訳だ。（≒写真の「モアレ」等）

そこで、色の分解後の配置座標を、「乱数」により
ばらつきを得る為の処理を加える。
上記ソースコードは、乱数を発生させ、その結果で
色の配置座標を乱数化する処置の部分である。

加えて、色を誇張（強調）する処理を加えてみよう。
これは、本シリーズの前回第8回記事の「野獣派」
生成ソフトで、色を強調する計算式を作ったので、
それをそのまま応用する。

再掲すれば・・
出力=((入力/(256/(N-S))+1)*(256/(N-S))
（ここで、Sは効果の強さ、Nは最大効果値。
　ただし、(N-S)は0以外である事→ゼロ割り防止）

となるのだが、上記式は、色味を純色に近づける
計算であり、今回は、ちょっとそれとは係数としての
使い方が異なるのだが、まあ、考え方は同様である。

こうして２時間もかからずに、プログラムが完成。

毎回プログラミングの記事で書いている事だが、こういう
作業は、やればやる程、慣れて来る事がまず１つ。そして
以前に（自分で）書いたプログラムを参照引用できるので、
それをコピー＆ペーストして繰り返せば、プログラミング
効率は、どんどんとあがって行く。
熟練者とビギナーでは、プログラムが出来るまでの時間は
100倍～1000倍にもおよぶ大差が発生する訳だ。
こうして出来上がったソフトが、「Seurat Ver. 0.90」
である。
「Seurat」は、勿論「スーラ」の名前から取っている。

Ver.（バージョン）は、このように、個人的に作る
「趣味のプログラム」では、いつもVer. 0.90から
始めるように決めている。
以降、もし何かプログラムの変更や機能追加がある場合、
Ver. 0.91,0.92・・と順次番号が進み、1.00の完成形
に至るまで、10回の修正猶予を持たせている訳だが、
まあ、たいていVer.0.92あたりまでで、もう飽きて
しまうので（汗） Ver. 1.00に至ったものは無い。

さて、画像処理の結果だが、上手く動作はしている
ものの、なんだか画像が「暗く」なってしまう。
まあ、それもそのはず、「光の三原色」として分解し、
それをピクセルの周辺に配置する事で、光の強さは
半分以下にパワーダウンしてしまう訳だ。

・・まあ、原理的にやむをえない、単体で画像を保存
できるようにして、これを一旦、レタッチソフトで
読み込み、画像を少し明るくしてから、処理例として
仕上げる事としよう。
なお、一々、画像を手動で編集しなくても、画像処理で
自動的に（輝度を）明るくする事は容易に可能だ。

もし、「毎回の手動編集が面倒だ」と（自身）で感じた
ならば、Ver. 0.91等で、自動輝度調整機能を追加
したら良い。

でも、まずは、この状態で使い物になるかどうか？を
判断しなくてはならず、仮に、使い物にならなければ、
その後のバージョンアップも、あり得ない話だ。
葉っぱの写真を画像処理中。

まだ、この時点では、どんな画像（写真）を入力したら
「点描」の絵画風として向いているかは不明である。
あれこれ、色々なジャンルの写真を入力して自動処理
してみよう。

上の処理では、「白ピクセル」を追加している、
ただ、やはり予想通り、画面に一定間隔でのパターンが
繰り返された場合、「縞模様」に見えるのは避けられない
模様である。

単体の画像として見てみよう。
やはり、見事なまでに縞模様が発生している。

（注：この縞模様の様子は、画像のビューワー上、
又はブラウザ表示上での拡大率によっても変化する。
試しに、ブログ閲覧環境において、拡大率（表示
倍率）を変えてみると、大きく画像の様相が変わる
ので、なかなか面白いかも知れない）

ちなみに、上の設定では「色の配置座標の乱数化」は
OFFにして実験をしている。

もしかすると、「配置座標の乱数化」は、必須の処理に
なるかも知れない。
まあ、そうであれば、その機能は常時ONとなるように
プログラムを改変してしまえば済む話だ。

とりあえずは、引き続き、様々な画像で試してみよう。
うん、なかなか悪くない。
やはり、被写体が単独ではっきりしているような写真
よりも、スーラの絵画のような「色々な色がある風景」
の方が点描には向いているのかも知れない。

さて、でも、プログラムを掛けた後で、画像の細かい
ところに、どう色が配置されているか？それを見たい
というニーズ（やりたい事）が出てきてしまった。
この為には、「画面拡大縮小」機能を追加しよう。

マウスで画面をクリックすると拡大または縮小となる。
これはマウスのホイールで、倍率を変えられるように
しよう。
拡大したら画像の一部しか見えないので、マウスで
これをドラッグすると、位置を変えられるようにする。

このプログラムは少々複雑だが、幸い、以前に同じ
仕組みを自分でプログラミングした経験がある。
それを探してコピーすれば出来上がるので簡単だ。

なお、C#は、イベント・ドリブン型の言語ではあるが
マウスのホイール操作で発生するイベントは、当初の
イベントリストには入っていない。

この為、自分でイベントを作って（追加して）あげる

必要がある。

それは、例えば、以下のように定義を書き・・
pictureBox2.MouseWheel+=
new System.Windows.Forms.MouseEventHandler
(pictureBox2_MouseWheel);

以下のように、イベントを受ければ良い。
private void pictureBox2_MouseWheel
(object sender, MouseEventArgs e)

これにより、画像の拡大・縮小・移動機能が実装された。
ただし、ちょっとバグを出してしまった（汗）

ここで、拡大縮小の対象として表示すべき画像は
画像処理を施した後の画像である。

だが、上記拡大縮小プログラムは、画像をファイルから
読み込んで処理をするように書いてあったので、
画像処理後の画像は、PCのメモリー上にしか無いから、
そのままでは動作しない。そこで、画像処理の直後に
これをテンポラリーファイルとして一時的に保存する。

これで、とりあえずは画像処理後の画像の拡大縮小処理
が出来るのだが、いったんこれ（拡大縮小）を終了して、
再度また拡大縮小すると、先のテンポラリーファイルが
プログラムで使用されているままなので、これを再度
作り直す事が出来なくなる。つまり、再度の拡大縮小
の操作で、プログラムが「落ちて」しまう（汗）

落ちないようにするには、一時ファイルを削除すれば
良いのだが、ここでも同様に、プログラムで現在使用
されているファイルを削除する事は出来ない。

ちょっと、ちゃんと考えて、リソース（使っている
資源）を、適切なタイミングで、解放してやらないと
ならないみたいだ。面倒なので、今回のバージョンでは
そこまでの処理はやらないでおこう。
まあつまり「連続拡大処理が出来ない」という制限つき
のプログラムになってしまった訳だ（汗）
このチューリップの写真は、「点描」というよりは、
織物とか絨毯、タペストリーのような風合い（雰囲気）
となる、まあ、これはこれで悪くない。

前回の「野獣派」生成ソフトの記事でも書いたが、
本来、「野獣派」（マティス、ブラック等の作風）を
生成している筈だったのが、あれこれと試していると
「ムンク」（表現主義、「叫び」が著名な作品）の
ような雰囲気になってしまっていた。

今回も例によって、「点描絵画を作る」と言いながらも
なんだか「タペストリー風加工」のソフトになって
しまっている（汗）
まあでも、そういうケースも多々ありうる、という事
が、こうした実践から見えてくる。

頭の中だけで考えているだけでは、わからない事も沢山
ある訳だ。自分で、手を動かし、試してみない事には
何も始まらない。

この効果が有益なのであれば、タペストリー絵画の名作
「貴婦人と一角獣（ユニコーン）」（注：6連作。
作者不詳、1500年頃にフランスで作られたとの事。
これは、表現意図の解釈が難しい作品としても著名だ。
アニメ/漫画等の「機動戦士ガンダムUC（ユニコーン）」
においても、序盤に重要なモチーフとして登場している）
・・風に写真加工をするソフトにしてしまえば良い訳だ。

で、どうやら、風景写真の方が点描処理に向いている模様
なので、引き続き、そういう写真で色々と実験してみよう。
なお、入力する写真は、ストレートに撮ったものだけに
限定している訳ではない。

カメラ側の機能で、色味を調整したり（例：モノクロや
セピア等）、あるいはエフェクト（画像加工）機能を
用いたものであっても、何でもありだ。

ただし、このソフトの画像処理アルゴリムは、光を三原色
に分解するものであるから、入力する写真が、モノクロや
セピアといった単色系の場合は、色の分解処理は上手く
いかない事は明白である。なので、そういう写真を選ぶ
事は避けておこう。
やはり、こういう何気ない風景が、点描絵画風になって
効果的だと思われる。

いつか、どこかで、スーラの「グランド・ジャット島の
日曜日の午後」の舞台となった、”人の集まる公園”の
ような風景を探して、それを写真に撮って、本ソフトで
加工して楽しんでみるとするか。（注：このソフトを
開発していたのは、コロナ禍での外出自粛中だった為、
人の集まる屋外の写真は、撮りようがなかった）

以前の本シリーズ記事の、どこかの回でも書いたが、
「画像処理を行う前提で、それに向く写真を撮る」
という発想は、現代のカメラマンの誰も（アマチュアから
職業写真家層に至るまで）持っていないに違いない。

であれば、ここもまた「誰もやった事が無い事」への
新たな挑戦である。

絵画の世界では、印象派やら野獣派やら、点描やらの
あらゆる絵画分野での「巨匠」は、それまで誰もやって
いなかった絵画スタイルを新たに創造・確立した事に
価値があった訳である。
まあ、それでこそ「アート」であろう。
人真似をしているだけでは、アートには成り得ない。

しかし、アマチュア写真家とか、あるいはエンジニアの
世界においても同様だが、その殆どは、過去にあった
事を模倣しているだけの世界観であろう。

だが、写真の世界では、それは「習い事」になってしまい、
有名写真家の作品とか、誰かのスタイルを真似るばかり
ではあるし、エンジニア（技術者）は、新しいカメラを
設計するかと言っても、前機種から画素数が上がったり
連写速度が上がった仕様を考えるだけであり、全くの
新しい発想のカメラなど、もう何も出て来ない状態だ。

それについて、何も疑問には持たないのだろうか？
今まで誰も試していない、新しい事をやりたいとは
思わないのだろうか？　

まあ、とは言え、この「プログラミング」シリーズ
記事であっても、その大半は、例えば、世の中に既に
存在する技術（例：ピーキング、ぐるぐるボケ）を、
自分なりの方法論で実現するとか・・
あるいは西洋画家の様式（スタイル）を（例：ロココ調、
野獣派、点描）を画像処理で実現するとか、ある意味、
模倣が多い事も確かだ（汗）

だけど、それなりに工夫はしているし、目指すところ
は、過去、誰も実現していなかった事であり、そういう
テーマも一部では実践している（例：横浜写真、擬似紅葉、
ボケ質解析、紅葉予測）
まあ、模倣という状態ではなく、ずいぶんと創造的では
ある、と思っている次第だ。
さて、上写真は被写界深度の浅い（背景がボケた）写真
であるが、どうも、こういう写真は、この「点描」処理
には向かず、パンフォーカス（ピントが全て合っている）
の写真の方が適正な模様だ。

ただし、前回の「野獣派生成ソフト」で用いた
「野獣派計算式（？）」を本ソフトにも入れてあるので
色強調の処理を掛けると、被写界深度外の（＝ボケた）
部分は、ちょっと、おどろおどろしい雰囲気になるので、
それを生かすならば、そういう写真を入力するのも有りだ。

まあ、色々な写真において処理を行う事で、さまざまな
効果が得られる、という事になるから、これはこれで
面白いと思う。

こちらは、パンフォーカスの写真、これはこれで良い。

もう少し柔らかく表現するような画像処理を加えれば、

（例：ソフト効果、あるいは周辺画素の平滑化処理）

印象（前期）の画家達が好んで用いたモチーフである

海辺や水辺での船やヨットのような絵画の雰囲気にも

近くなるかも知れない。

それを実現するには、画像処理アルゴリズムの追加は

勿論だが、加えて、そうした画像処理に向く写真を撮って

来て、それを入力する必要がある。

最後に、このソフトの弱点だが、入力する写真の画素数
（解像度）に応じて、効果が大きく変わってしまう。

ブログ掲載用に、数十万画素にまで縮小した写真で
あれば、点描処理効果ははっきり出るのだが、カメラで
撮ったままの、数百万～千数百万画素において、この
処理を掛けても、処理あたりの固定のブロックサイズが
小さい為に、殆ど効果が得られないのだ。

まあ、こういう状態を画像処理においては「カーネル
のサイズが合っていない」という風に呼ぶ事もある。
対策としては２通りあり、１つは画素数（解像度）に
応じて、カーネル（オペレーターとも呼ぶ）を可変に
する事。
もう１つは、自身で、画像を適切なサイズに縮小して
から処理を掛ける事である。

で、このソフトの場合は、可変カーネルとすると
アルゴリズムが複雑化してしまうので、後者での、
適正な画像縮小後に処理を掛けるのが望ましい。
市販ソフトだったら、そんな横着な事はできないが、
これは自分専用のソフトだ、中身のアルゴリズムに
合わせて入力画像を正規化（ノーマライズ）するのは
造作も無い。

まあ、つまり「靴に足を合わせる」というやり方だ。
（→通常、その例えは、「無理に物事を行う」とか
「本末転倒である」という意味で使われる）

さて、最後になるが、画像処理で点描化された
画像を、思い切り拡大してみてみよう。
黒い線は、元々の画像での何か暗い部分である。
他の部分は比較的均一な輝度で、光の三原色の
赤、緑、青に分解されている様子が良くわかる。
これはランダマイズモードで計算したものであり、
赤、緑、青の配置は、乱数パターンで決定されている。

最後に本ソフトの成否であるが、まあ「△」（不明）
としておこう。
処理はちゃんと動作しているが、この処理に合う
写真を探したり、新たに撮って来るのが面倒だ（汗）

まあ、世に無い全くの新しい事をやっているので、
常に全ての実験・研究が成功する訳ではない。
だいたい3割位が上手くいけば御の字だと思っている。

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