DoG (Difference of Gaussians) を使えば、
モアレ低減に 幾許かの 貢献が出来そう と書いたので、
この辺りを少し追補します。
そう、スクリプト書き です。
DoG (Difference of Gaussians) で描かれる線分は、
指定値２値を適正にすれば、
エッジそのものでは無く、エッジの内側にある事が多い様です。
つまり、一見、均一に見える部分で、ノイズ成分になり得る範囲を表しているのでしょう。
実際に、多くの画像で試した訳では無いので、確証はありませんが、
少なく共、縮小時の線分がモアレ的になる画像では、その傾向が認められます。
ですから、目視で、不愉快な部分を、ひとつずつ、選択範囲作成する事に較べれば、
一度に、選択範囲を作れる事になる訳です。
但し、微細な選択範囲拡大が必須になりますが。
そして、其処には、見た目を左右していない部分も含まれるのですが、
これを除外する作業と、そのまま縮小プロセスに進んだ作業とで、
結果に於いて、大きな差異は無さそうです。
そもそも、問題箇所（モアレ状）は、原画の同じ色域にあるとは限らないので、
手作業の場合、嫌になって来る場合すらあったのですから。
それに較べれば、相当な 時間短縮 精度アップ に繋がると思っています。
これが、写真加工 縮小の落とし穴 ２ 参考：引用のみ で書いた、
「 これで 選択範囲作成が 楽 出来そうです 」の概要です。
手動で、画像操作し、芳しい手応えが得られたので、
ウキウキとした心持ちで、スクリプトを書き出しました。
でも、でも、 敵も然るもの引っ掻くもの！。
いやぁ、難しいですね。
単純化して、全て自動化する事も可能でしょうが、
どうも、すっきりしないのです。
その原因は、
ノイズ成分の近傍にエッジ成分があって、
微妙な匙加減で、細部の印象が虚ろって行って仕舞う事です。
そうです。 途中に手作業の部分を残し、試行錯誤を繰り返した方が良さそうなのです。
私の知識では、自前の UI に試行錯誤プロセスを事前実行しフィードバック表示させるのは無理です。
プロセスを中断し、手作業に移行させ、再び戻すのが 精一杯 です。
オマケに、縮小前の大きな画像を分解させて、影響を最低限にしたいと思っているので、
処理は重く、動作が鈍いのです！。
更に、事後、再挑戦の時にも、楽したいですから、
課題は山積み！ の様相です。
選択範囲作成は元画像の広大なエリアで行い、結果は縮小後のサイズで見たい ... 。
はい。 頻繁に、画像サイズの変更が起こるのですね。
Gtk Message、Parasite、pdb の各 Function(Procedure) そして 既成のスクリプト を総動員しての挑戦です。
差し当たり、形にはなっていますが、
まだまだ、不十分です。 洗練されてはいません。
気が向けば、画面推移を GIF Animeation したいのですが、
如何せん、サイズも大きく、長いので ... 。 さて、どうしたもんか？。
0 件のコメント:
コメントを投稿