GIMPのオンラインディスカッションに、以下のような議論がありました。
この中で、GIMP 2.99 の Python-Fu の仕様はまだまだ大きな変更がある見込みであるとの指摘がなされています。実際、以前GimpFu Version 3 が結構いい線まで行っているという報告を上げましたが、その後の GIMP 2.99.x のアップデートで状況が後退してしまっています。
GIMP 2.10用のPythonによるプラグイン・スクリプトの書き換え作業に着手するのには、当分待つ必要があるようです。
ちなみに、上のオンラインディスカッションのメインテーマですが、Flatpak で GIMP をインストールすれば、Python-Fu が予め有効化されますので、苦労しなくて済みます。
次に、Bチャンネル再建法適用時に、周辺褪色補正を行う際の注意点について申し述べます。
ネガカラーフィルムでは経年劣化すると、画像周辺部のBチャンネルが、値が高いほうに褪色し、周辺部のBチャンネルのテクスチャ情報が失われる場合があります。Bチャンネルの値が高いほうに褪色しますので、見た目では青っぽくなります。
例えば前回お示しした画像では、オレンジで囲んだ部分がそれに該当します。
この部分については、周辺補正レイヤー (**** _G+R.tif の名前の付くレイヤー) で補正しますが、マニュアルで書いたように、周辺補正レイヤーにかかるマスクに対して不必要な部分を黒塗りする編集を行います。
ところで、これ以外に近景補正レイヤーのマスクも編集を行ったほうばよいです。厳密に言えば、Type2マスクまたはType4マスク (オリジナル画像のピクセルが補正画像より青いピクセルを活かすマスク) がかかっている場合、こちらの周辺褪色部分に関しても編集します。具体的には周辺部のマスクが黒くなっている部分を白塗りします。
というのは、近景補正レイヤーにオリジナル画像のピクセルが補正画像より青いピクセルに関しては補正を無効化するマスクがかかっています。これは、黄変補正によって過剰にBチャンネルとGチャンネルの値の近接が起こらないようにするためです。しかし、この場合青い褪色部分がそのまま活かされてしまいます。もちろん、周辺補正レイヤーで上書きしますが、100%不透明で上書きするとはかぎりません。場合によると、濃度調整のため不透明度を下げなければいけないかもしれません。そうなると、青変褪色部分が悪影響を与えることになります。したがって、この場合、その部分のオリジナルの青いピクセルを活かすマスクを無効化する必要があります。そのため白塗りするのです。
先ほど(現地時間では昨日付け)、ARTのバージョン1.18.1がリリースされました。ダウンロードは以下から。
変更内容は、いくつかの点で、RawTherapeeに比べて、ARTの動作がかなり遅いという指摘に対する対応、およびバグフィックスが中心です。詳細は以下からご覧ください。
今まで、黄変ネガ写真補正の参考として、補正事例を紹介してきましたが、これからは、個別のケースに応じた補正テクニックの紹介を行ってみたいと思います。
今回のテーマは、もともと黄色い部分をどう扱うか、です。Bチャンネル再建法では黄変した部分の黄色味を消したり弱める補正を行います。しかし当然ながら科学的に黄変したのか元々黄色いのかを区別することはできません。従って黄色い部分は一律黄色味を消す処理を行うことになります。
例えば、下記の事例ですが...
空が黄変しています。それと同時に駅の手すりや遮断機は元々黄色いです。これに対し、Bチャンネル再建法ツールを使って素材ファイルを作成したときに、近景補正レイヤー用マスクは以下のようになります。
それを編集せずにRGB合成を掛けると下記のようになります(遠景補正レイヤー不使用)。
空の黄色味は消えていますが、同時に駅の手すりや遮断機の黄色も、黄色味が減ってオレンジに寄ってしまいました。黄色味を減らす補正を行っているのですから当然なのですが...
そこで近景補正レイヤーのマスクを下記のように編集します。
もともと黄色い部分を黒で塗りつぶし、その部分だけ補正を無効にし、黄色味を回復させる編集を行っています。それとともに、周辺の青変褪色部の補正無効化を取り消すために(つまり補正を有効化させる)、こちらは逆に白で塗りつぶしています。
この時、マスク画像を直接見ながら黄色い部分を塗りつぶすより、下記のように、マスク画像を隠しながらマスク編集モードにして、手摺部分などを自由範囲指定を使って指定し、塗潰しを実行すると、編集がしやすいかもしれません。
このような編集を加えたうえで、RGB合成を行うと、下記のように手摺や遮断機の黄色に補正が適用されず、元の黄色のままになります。
なお、以上のような編集を行う場合、黄色い部分の形が複雑だとちょっと編集が面倒です。その場合は、一旦相対RGB色マスク作成ツールを使って、以下のように、黄色を除外するマスク画像別途作ってみます。
この画像をGIMP上にレイヤーとして読み込み、必要な黄色が除外されている部分だけを切り取り、マスクに貼り付けると、比較的簡単に複雑な形状の黄色部分をマスク上黒く塗りつぶすことができると思います。
先日、本ツールをバージョンアップしたばかりで申し訳ありませんが、マイナーバージョンアップを行います。今回のバージョンアップ内容は、ノービスモードで緑保護オプションをチェックした際に (つまり Type4 マスクを作成した場合)、同時に Type2 マスクも出力するようにした点です。ダウンロードはこちらから。
この理由ですが、前回のバージョンアップで以下のように書きました。
「なお、緑部分の補正抑制効果を強化したため、空の黄変など、補正を抑制したくない部分も、緑保護オプションを使うと、抑制される副作用が出る場合がありますが、これについては、当面、マスクの編集 (補正を抑制したくない部分を白塗りにする) で対応をお願いいたします」
ただし、一点問題点に気づきました。というのは Type4マスク、つまり、青の保護と緑の保護を併用した場合、青の保護部分(Type2)と緑の保護部分(Type4)の切り分けが難しい場合があるため、マスクの編集が難しくなる可能性がある点です。
例えば以下のサンプルですが...
近景補正レイヤー用のType4マスクを作ると以下のようになります。
ところが緑の保護オフだと以下のようになります。
上の２枚を比較すると、緑保護の機能が強化されたために、空や、電車の車体の上半部など、保護しなくても良い部分も保護されてしまっていることが分かります。しかし、マニュアルで空や車体の保護を解除するために白塗りをしようとすると、困難に直面します。
というのは、以下の丸を付けたような部分は、青の保護部分と緑の保護部分が連続してしまっており、手作業では切り分けが難しいからです。そのためマニュアルで不必要な部分を白塗りするのは非常に難しくなります。
このような場合、Type2 マスク画像も別途出力し、適宜切り貼り編集を行えば、編集が容易になります。下図は、空の部分の緑保護を無効化したいので、GIMPに読み込んだ Type2 マスク画像上で自由範囲選択指定を行っています。
この範囲指定部分をコピーして、Type4 マスクに貼り付けます。
このようにすることでマニュアルでは切り分けが難しく編集が難しい画像でも、マスク編集が比較的容易になります。
というわけで、Type4 マスクを指定した場合、同時にType2マスクを出力するよう変更しました。なお、同時に作られる Type2 マスク画像は、GIMP読み込みプラグインでは自動で読み込まれませんので、必要なら手動でレイヤーとして読み込んでください。ファイル名は、*******_R+128(Type2).tif です。
----------------------
なお、本記事で紹介した写真補正技法やソフトウェア (Plug-in) は個人的用途および非営利目的であれば自由に使っていただいて構いませんが、本技法を使って何らかの成果 (編集した写真等) を公表する場合は、本記事で紹介した技法を使った旨クレジットをつけて公表していただくことをお願いします。
また、本ソフトウェアは現状のまま提供されるものし、作者はこれを使ったことによるいかなる損害補償等にも応じられないことを了解の上使っていただくものとします。
但し、もしソフトウェアのバグがありましたら、ご連絡いただければなるべく改善するよう努めたいと思います。
営利・営業目的で使用される方は別途ご相談下さい。
また、私の作成したPlug-inも自由に改変して使用していただいて構いませんが、その成果を公表する場合はご一報下さい (公表しない場合は特に連絡は必要ありません)。またその改良した結果を私の方で自由に利用させていただくこともご了承下さい。
----------------------
昨年のお正月にノートパソコンにUbuntuをインストールしてみたところ、あっさりインストールできてしまいました。Microsoft Officeが使えないなど部分的に不便なところはありますが、Wineのおかげもあり思った以上に快適に使えています。そこでデスクトップにもインストールしてみようと試したところ、見事にはまりました。
結局最大の鬼門はネットワークアダプタの問題でした。ノートパソコンはパナソニックのLet's noteでしたがこちらはあっさりWi-fiアダプタを認識。intel製チップだからでしょうか? そもそもWi-fiアダプタが認識しなくても、ノートなので、ルータに有線で接続すれば問題ありません。
しかしデスクトップはルータから離れており、Wi-fiアダプタでつなぐしかありません。ところがデスクトップで使っていたWi-fiアダプタ (TP-Link ARCHER T2U Nano [AC600]) がデフォルトで認識していません。ドライバが用意されていないのです。ネットで情報を調べると、ソースからビルドする必要があるらしいということが分かったので別のPCで git clone してソースをデスクトップに持っていきました。
ところが、デスクトップはデフォルトで git も make も dkms も使えません。これではドライバをビルドできません。これらをネットワークからダウンロードしてインストールする必要がありますが、そもそもネットワークにつながっていなのですから手も足も出ないだるまさん状態です。
デスクトップパソコンのある場所からルータも遠いので優先でつなぐのもなんだしと困って、サイドネットで検索すると、オフラインでインストールメディアから開発ツールをインストールする方法があるらしいことが分かりました。ubuntuのインストールメディアをCDROMとしてマウントすればできそうな感じです。そこで何か所か日本語で書かれたサイトを参考に試してみたのですが....
Ubuntuの22.04のインストールメディアは、従来のバージョンよりかなり仕様が変わっているようです。インターフェースも20.04から大きく変わっています。そのせいか情報が古くてうまくいきません。
英語の情報も探せばうまくいくかもしれませんが、さんざんあれでもないこれでもないとやって疲れたので、結局10mの有線ケーブルを準備して接続して git や make dkms をインストールしようとすると、/media/cdrom にディスクを入れろと文句を言ってきます。どうもネットワークからツールをインストールできないようになってしまったようです。これもいろいろやれば何とか解決できるかもしれませんが、私のLinuxに対するスキル不足もあり、面倒になったので、最初からインストールし直してしまいました。有線でインストールすると、今までの苦労は何だっと思うぐらい何のトラブルもなくあっさりインストールできてしまいました。これで結局丸一日潰れてしまいました。
Linux 熟達者以外は、面倒でも有線LANケーブルを用意するか、最初からドライバが対応しているLANアダプタを準備してインストールしたほうが、結局時間を無駄にしなくて済みます。安いLANケーブルなら10mでも1000円しませんし、Ubuntuですぐ認識されそうなLANアダプタも1000円しません。
でも、Ubuntuのインストールの際、最小限の開発ツールをインストールできるオプションをつけてくれるといいんですけれどね。それにインストールメディアも、USBメモリを使うことが一般化していると思いますのでメディア容量の限界もそんなに気にしなくてよいはずなのですが...
因みに TP Link の Nano ですが最終的に、以下のドライバをビルドして問題なく使えました。
なおネットでは TP Link の TL-WN725N だとすぐ使えるという情報があります(試していません)。また、もうちょっと古い情報でいくつかの国内メーカーの製品の中ですぐ使えるものがあるという情報もあります。ただ、こちらはいずれも2.4MHzしか対応していません。5MHz対応のUSB対応Wi-fiアダプターですぐ使えるものがあるという情報は見当たりません。おそらく内蔵タイプのintel Wi-fiアダプタチップ以外に5MHz対応ですぐ使えるものはないと思われます。インストールのために買うならUbuntuインストール専用と割り切ったほうが良いです。それを考えると、万一に備えるという意味では、長いLANケーブルを買っておくほうがより使い道があって良いかもしれません。しかも常用しないのですからカテゴリー5でも問題ありません。1階から2階に引き回す場合でも、20mあれば普通の家では十分ではないでしょうか。30m超えるとさすがに一番安くても さすがに千円台の大台に乗りますし、40mだと4000円近くになりますが...
またやや古いのですがこんな記事もありました。
あと、Wi-Fiアダプタの機種に直接関連する訳ではありませんが、以下のような記事もありました。
今まで、ImageJ上で、画像を表示させたウィンドウを一番前に表示させるために、 IJ.selectWindow というのを使っていました。これは、
IJ.selectWindow("ウィンドウタイトル")
を指定すると、指定したウィンドウをアクティブにして一番前に表示させるというコマンドです(なお、頭に、 from ij import IJ による IJ のインポートが必要です)。
ところが Linux 上でうまく働いてくれません。アクティブにはなるのですが、一番前に表示してくれません。
他に何かコマンドはないかと探すと、WindowsManager にあるようです( WindowManager (ImageJ API) ) 。setWindow というメソッドです。しかし、引数が、java.awt.Frame win もしくは java.awt.Window win とあります。しかしどうやって java.awt.Window 形式の引数を取得すればいいのか... と困りました。探してみると、ImagePlus に getWindow というメソッドがあることが分かりました( ImagePlus (ImageJ API) )。"Returns the ImageWindow that is being used to display this image." とあります。どうもこれで行けそうです。つまりImagePlus に対し、それが対応するウィンドウを getWindow で取得すれば良さそうです。結果的に次のようなコードを使いました。
from ij import IJ, ImagePlus
from ij import WindowManager as WM
：
WM.setWindow(imp.getWindow())
ところで、これで指定しても、Linux 上では、アクティブになっても前に来てくれません。どうもこれは Linux 上の JRE 自体において、Windowの順番指定が無効であるようです。
どうも、Java (ImageJ) が一番確実に動くのが Windows、 次が Mac OS X で、Linux はその次になるようです。マルチプラットフォームで開発しようとする場合、そのあたりを頭に置いておく必要がありそうです。
