省型旧形国電の残影を求めて

戦前型旧形国電および鉄道と変褪色フィルム写真を中心とした写真補正編集の話題を扱います。他のサイトでは得られない、筆者独自開発の写真補正ツールや補正技法についても情報提供しています。写真補正技法への質問はコメント欄へどうぞ

DP Review Nikon Zf 評

 Nikon Z6 MkIII が発表されたところで、いささか遅ればせの感もありますが... ただ、Z6 III への関心が、やはり Zf の評判を下敷きにしているようにも思いますので。というわけで、ちょっと前になりますが DP Rreview の Nikon Zf 評を紹介します。

www.dpreview.com-----------

・概要

 センサーは Z6II と同じ裏面照射型センサー。それに Z9 に搭載したものと同様の 3D トラッキングと9種類の対象認識を搭載したAF を採用。また Z9 で導入した高圧縮 Raw を採用。またコンテキスト対応のノイズ低減システムを採用し、ISO の最高値を204,800 まで上げる。また連写モードは Raw ファイルで秒速11枚、Jpeg モードで 14 ~ 15枚。手振れ防止は本体のみで 8 段。

・ファインダー

 3.68M ドットの電子ファインダーで同クラスでは普通。但し倍率は 0.8 倍でかなり見やすくなっている。

・背面モニタ

 2.1Mドットの液晶で、バリアングル式。Z8のようなチルト式のほうが良かった。

・バッテリー

 これも Nikon 中級機標準の EN-EL15c で 1回の充電で 360 ~ 380枚撮影可。

 

・つくりは非常に良く、デザイン面では、Nikon の Df がこうでであってほしかったとユーザが思ってきた理想のデザインを実現している。

・イメージクオリティは、一般的な24MP 裏面照射型CMOSが使われ、それから期待されるとおりに高い。基本ISO ではノイズはほとんど見られない。色づくりは標準的な Nikon カメラと同様。ノイズ低減は良く、Z6II と同等。

・カメラのハンドリングという点では多少難点がある。グリップがない古典的スタイルなので、意識的に左手でレンズを支える必要がある。

・操作性面では、同じクラスのカメラに比べてカスタマイズの余地が少なく Z6 II よりも余地が少なくなっている。またダイアル操作を取り入れているが、Nikon のエンジニアは他のダイアルのあるカメラを模倣しただけであり、十分その操作性を考えて取り入れているとは言えない。例えば ISO ダイアルを使うと Auto ISO 設定に戻すのが面倒になり却って不便になっている。

・AF は3Dトラッキングモードが導入され、Z6II や Z5 に比較して大幅に改善されている。特に対象認識による AF のパフォーマンスがよい。これはビデオモードでも有効で、Z8, Z9 のようなプロレベルまで行かないにせよ、ライバル機に十分に伍するだけの性能になっている。

・クラシックな外観にもかかわらず、ビデオカメラとしても非常に有能で、出てくる画像は非常に安定しており、また出力フォーマットにもフレキシビリティが高い。ローリングシャッター現象はリーズナブルな範囲にとどまるものの、優秀とは言えない。

Nikon Zf は操作性に癖があるが、熱心なフォトグラファーはそれらをうまく回避して失望するような写真を撮るようなことはないだろう

・Zf は、軽量なレンズでは操作性が良いが、レンズが重くなればなるほど操作性に難が出る。それにもかかわらず Nikon には軽量なレンズのラインナップが少ない。また Zf の操作性は絞りリングのあるレンズと親和性が高いにもかかわらず、Z レンズには絞りリングが省略されており操作性の一貫性がない。さらに良くないことに、Nikonサードパーティに対しこのギャップを埋めるようなレンズの発売を妨害していると言われている。

 これを考えると、イメージクオリティでは Zf は 富士の X-T シリーズをしのぐものの、軽量なレンズのラインナップ、操作の一貫性という点で富士の X-T シリーズに負ける。特に富士の X-Tシリーズに Sigma の iシリーズレンズの組み合わせには負けるかもしれない。

・Zf のスタイルには非常に共鳴し、このカメラを大好きになると思っていたが、数か月使ってみた結果、心ではゴールド賞と叫んでも、冷静に考えるとシルバー賞という結果となった。

---------

 以上を考えると、特にデザイン面で魅力的であり、また AF やビデオ面で Z6 II から大幅に進化していると言えます。また手振れ防止はクラストップクラスです。オリンパスOM-1 II に肉薄しています。

 一方、ダイアルの追加は単に美観的な意味ではなく、電池消費量の多いミラーレスで特に有効なはずなのに*1その操作性がよく考えられておらず、却って不便な側面も出ています。

 さらに、現在の Nikon のレンズ販売戦略とマッチせず、Zf にあう軽量で小型でかつ絞りリングのあるレンズに欠けています。この点、Canon EOS R50 と同じ轍を踏んでいます*2

 いま、Nikon重厚長大高価格路線に走っており、それで一応業績が回復しているようではありますが、個人的にはこの路線は、どうなのかと思います。特に小型に作れるはずのミラーレスでこれでは、ミラーレスのカメラを出す意味がないのではと非常に疑問です。少なくとも、Nikon Zf が生かせるような方向性を打ち出せないと、今後の Nikon に期待は持てないと個人的には思っていますが... Z シリーズに買い替えている顧客も、ミラーレスだから買い替えているのではなく、機能が進化したカメラが Z シリーズしかないから買い替えているのであり、その機能も必ずしもミラーレスで出す必然性はないということが問題かと思います。根本的にミラーレスならではの利点を生かしたカメラが今まで出ていなかったという点が問題だと思います。Zf のリリースを機にそのあたりを見直してほしいと思いますが...

 

 なお、DP Review から主要スタッフが移った PetaPixel ではプレビュー評しか載っていません。

petapixel.com こちらは概ね好評で、AF ジョイスティックの廃止もタッチスクリーンで十分代替可能と評価しています。AF に関しても暗い部分での合焦は Z8/9 を上回るとしています。手振れ補正は、他社とは異なり、画面の中心のみを基準とせずに動作し、特に広角で有効と高く評価しています。

 全般的に Zfc が単に Z50 に古い外観を持たせただけだったのに対し、本機は Z6 II より新しい機構やデザインを組み込んでおり、1983年のデザインに2023年の内容を盛り込んだカメラと評されています。

 かなり絶賛に近い内容です。

 なお、Z6 MkIII は日本円価格にして 40万円以上になっています。アメリカでの希望小売価格は $2500 程度で、Z6 Mk II とあまり変わらないようですが、日本円価格は、日本円の為替の急落で、2倍近くとなってしまいました。しかし、性能面ではZ6 Mk III は、 Zf をちょっとアップしたという感じだと思いますので、Zf のお買い得感は高まっていると思いますが...

*1:これについては、以下の記事をご参照ください。

yasuo-ssi.hatenablog.com

*2:

yasuo-ssi.hatenablog.com

Imagej / Python プログラミング Tips: ImageJ 符号なしから java 符号付 Byte データへの変換

 ImageJ の明るさを示す値は、8bit ByteProcessor および 24bit (8 x 3チャンネル) ColorProcessor では 0 -255, 16bit ShortProcessor では 0 - 65535 の正負符号なしデータ、32bit の FloatProcessor では正負符号付でもなしでもよく、値の範囲制限もありません。但し、FloatProcessor の場合、値範囲が 0.0 - 1.0 でない場合、メソッドによっては正しい答えが得られない場合がありますので、一般的には、0.0 - 1.0 の範囲で使うのが無難です。

 ところが ImageJ は Java で書かれているため、API によっては、Java の値形式でデータを与えなければならない場合があります。ところで Java の場合、値は原則正負符号付になります。例えばByte 形式では、-128 - 127 の範囲でなければなりません。この問題でプログラミングをやっていてはまりました。

 当初 ImageJ の 0 -255 の範囲のデータを Java の Byte データに変換するときに、そのまま 128 を引いて、 -128 - 127 の範囲に変換すればよいものと思っていました。つまり ImageJ の 0 だったブラックポイントを -128 に、255 だったホワイトポイントを 127 に割り付ければよいものと考えていました。ところがそれだと値が異常になってしまいます。散々いろいろ試した挙句、ようやくわかったことは、次のような変換が必要だということでした。
 つまり、ImageJ の 0 - 255 の範囲のうち、 0 - 127 までは、そのまま Java の Byte値の 0 - 127 に割り付ける一方、128 - 255 までの値は、Java Byte値のマイナス領域、つまり -128 - -1 の間に割り付ける必要があることが分かりました。シャドウ領域は正の値に、ハイライト域は負の値に割り付けるということになります。

ImageJ の符号なしと Java の符号付の対応関係

 なお、このことはいろいろ検索したのですが、まともに書かれた記述を見つけることはできませんでした。暗黙の了解なのかもしれません。16bit データについても同様なのかもしれませんが、確認していません。
 なぜこんな変な割り付けをするのかとも思いましたが、どうやらブラックポイントの扱いを簡単にするためのようです。ブラックポイントが 0 なら、掛けたり、割ったりしても 0 のままですが、-128 に割り付けると計算が面倒になります。それに顕微鏡画像では、ハイライト域はほとんどバックグラウンドの値で使う程度で、重要なデータはほとんどシャドウ域を使いますので、シャドウ域をそのまま使えるという利便性を取ったものと思われます。

 そこで、ImageJ の正負符号なし 8bit の値を Java の Byte データ用の値に変換する Python 用の関数を考えてみました。

def unsigned2signed(v):
    if v < 128:
        v2 = v
    else:
        v2 = v -256
    return v2

 これを使うとブラックポイントは 0 のままですが、ホワイトポイントは -1 に割りつきます。また中間グレー点は、128 あるいは -129 になります。なお、v には 256 以上の値が入らないことを前提としていますが、まじめにやるなら、何らかのエラー処理を加えたほうが良いでしょう。

 なお、Java の colorModel クラスを使うと、符号なしの 0 -255 を符号付の -128 - 127 に変換してくれるようですが、使い方をちゃんと理解していません。

 なお、この問題は Python ではなく Java でプログラミングをやっていても同じです。ImageJ オリジナルの API は符号なしの値を使いますが、JavaAPI を使うと符号付値を使いますので、同様の変換が必要になります。

 

------------

参考サイト

www.javatpoint.com

ImageJ 対応 sRGB TRC en / decoder Ver. 1.5

 昨年、ImageJ 上で sRGB (ならびにREC709) 式の知覚的なトーン再生カーブ (TRC) を掛けたり外したりするプラグインスクリプトを作成しました。

yasuo-ssi.hatenablog.com

 ただこのプラグイン、通常の TRC のかかった画像をデコードしてリニア画像に直すのは良いのですが、リニア画像に TRC をエンコードする際にちょっと手抜きがありました。

 リニア画像に対して sRGB 式の知覚的 TRC をエンコード / デコードするには以下のような計算を行います。

 エンコードの場合、元の画像の値が、ブラックポイントを 0.0 ホワイトポイントを 1.0 の 0.0 ~ 1.0 の範囲を取るとした場合、0.0 から 0.0031308 の範囲では元の値を 12.92 倍し、それより値の高い場合は、元の値に 1/2.4乗して (ガンマ 2.4)、そこで得られた値を 1.055 を乗じて、そこから 0.055 を引きます。

 デコードするときは逆に、0.0031308 を 12.92 倍した 0.04045 で分割し、それ以下の値については、12.92 で除するとともに、それを超える値は、一旦 0.055 を加え、さらに 1.055 で割り、さらにその値を 2.4 乗 (ガンマ 1/2.4) します。

 デコードでは問題がないのですが、エンコードの場合 v を元の明るさの値とすると、(v ^ (1/2.4) * 1.055) としたときに、1.055 を掛けた時に ImageJ の ImageProcessor の限界値を超える可能性があります(8bit, 16bit 画像の場合)。そこから 0.055 を引くと、ホワイトポイントに近いハイライトデータがクリップされる可能性があります。

 前のバージョンはこのハイライト部分のクリップをそのままにしていたのですが (ハイライト部分なので視覚的に鈍感ですので、まぁいいか、ということで)、今回まじめにクリップされないよう取り組みました。なお 32bit 画像では正しく動作しない可能性があります。

 簡単かと思っていたら、ちょっと予想外のところで引っかかってしまい、改修に結構時間がかかってしまいました。これについてはまた別稿として記事にしたいと思います。

 使い方は前のバージョンと変わりませんので、マニュアル的なところは上の前バージョンの記事をご参照ください。

 ダウンロード先はこちらから。

 実行例をお見せします。まず TRC がかかっているオリジナル画像から。

オリジナル画像

 TRC デコードを行い、リニア画像を作成します。

TRC デコード (リニア画像)

 リニア化した画像に再度 TRC エンコードを行います。

リニア化した画像を再度 TRC エンコード

 ヒストグラムを見ると再度元に戻っているのが分かります。

 

関西国電始源の1輌、41005を出力強化した阪和線 クモハ60153 (蔵出し画像)

 こちらは阪和線で活躍していたクモハ60153です。関西国電始源の元モハ41の1輌で、元番号は41005でした。残念ながら中間に挟まれていたので正面を撮ることはできませんでした。依然ご紹介したクハ55071 とコンビを組んでいました。

クモハ60153 (天オト) 1976.3 和歌山

クモハ60153 (天オト) 1976.3 鳳

クモハ60153 (天オト) 1976.3 鳳

 運転台運転士席側です。関西型通風機が見られます。

クモハ60153 (天オト) 1976.3

 客室内です。関東の車輛とは異なり、ニス塗りが維持されていました。

クモハ60153 (天オト) 1976.3

 運転台です。元々は半室運転台でしたが、全室に改造されています。

クモハ60153 (天オト) 1976.3

 運転台の拡張側。

クモハ60153 (天オト) 1976.3

 マスコンです。

クモハ60153 (天オト) 1976.3

クモハ60153 (天オト) 1976.3

 放送装置でしょうか。

本車の車歴です。

1932.10.29 日本車輛東京支店製造 → 1932.11.15 使用開始 大ヨト → 1944.7.13 座席撤去  → 1948.12.28 座席整備 → 1951.2.24 更新修繕I 吹田工  → 1953.6.1 改番 (モハ60153) → 1953.8.20 大アカ → 1953.8.30 大ミハ → 1954.3.26 大ヨト → 1957.7.11 更新修繕II 吹田工 → 1961.9.2 大アカ → 1963.10.30 天オト →  1977.7.14 廃車 (天オト)

 本車は生まれは東京です。おそらくこの時点までは電車製造で実績のある東京のメーカーに製造を任せていたものと思われます。しかし大阪に配置後はずっと大阪圏で使用されました。前回紹介したクモハ60073が関西生まれなのにずっと東京圏を離れず使用されたのと好対照です。大阪で最初に電化された城東・片町線用として使われました。なお、関西国電始源の電動車はモハ41は全車奇数向き、モハ40は偶数向きでした。大阪圏の3扉ロングシート車としては珍しくセミクロス化されませんでしたが、それはずっと城東・片町線で使用されたためです。1950年頃に城東線をなるべく4扉車に揃えるために、宮原区の4扉車改造車と淀川区の3扉ロングシート車が交換され、比較的少数の3扉車のみ片町線用として淀川区に残されたため、関西の3扉ロングシート車の残存率は少なかったのです。

 1953年までに出力強化改造されクモハ60に改番されましたが、1951年の更新修繕の際に出力強化された可能性が高いです。おそらく社型の阪和形を片町線などでも転用する計画があったため、それに合わせるため出力強化されたのではないかと思いますが、阪和形の電動車は自重が重かったため他線区での転用が難しく、転用は制御車のみにとどまったものと思われます*1。ただ制御車であっても国鉄制式制御車より自重が重かったので、やはり出力強化は必要と判断されたのかもしれません。

 改番後はあちらこちらを転々としましたが、状態が悪かったのではないでしょうか。そのためか、1957年には更新修繕II を受けます。運転台の全室化改造はその時施行されたのではないかと推定されます。その後、大阪環状線への101系の投入で、既存の4扉車が片町線に転用されたため、再度京阪神緩行線に出ますが、1963年からは輸送力増強のため阪和線に出てからそこが安住の地となり、新性能化まで使われました。

 なお、モハ41の若番車は、トップナンバー、41001 は戦災で廃車、41002 はクモハ51059 に改造されており、41003 はやはり戦災廃車、41004は以前紹介した60151です。

 

*1:クモハ60151 の記事をご参照ください。

yasuo-ssi.hatenablog.com

ImageJ / Python プログラミング Tips: Gamma 補正と setDisplayRange は必ずセットで使うべし

 以前、ImageJ で、sRGB 式の TRC をエンコード、デコードするプラグインスクリプトを公開しました。その中でちょっと手抜きをしていると書きましたが、今回その手抜きを止めて真面目に取り組むことにしました。ところがその修正作業で大はまり。

 まず sRGB 式 TRC のエンコード / デコード式は以下に出ています。

International Color Consortium (ICC) sRGB 仕様書
https://www.color.org/chardata/rgb/srgb.pdf

 もし、TRC がエンコードされている画像を、リニアにデコードする場合は以下の式に従います。

 L という添え字がついているのがリニアな値です。なお、上の式は誤植があり、R が縦に 3 つ並んでいますが、上から、R, G, B の間違いです。それはともかく、TRC のかかった R, G, B 値 (0.0 - 1.0 の範囲を取るとの前提) に 0.055 を足して、それを1.055 で割ったものを 2.4 上することで、リニアな RGB 値が求められます。

 しかし R, G, B の元の値がホワイトポイントに近い値だと、0.055 を足したときに、ImageJ 上で、8bit もしくは 16bit (byteProcessor, shortProcessor) だとデータクリッピングが起こる可能性があります。

 そこで一旦 32bit に直して計算し、その後、8 または 16bit に直そうとしましたが、なぜか異常に暗い画像になってしまいます。いろいろその理由をつかもうとやってみたのですが、理由がつかめませんでした。

 そこで、bit 深度を変えることなく、クリッピングが起こる可能性のある部分を一旦そうでない部分と分割し、計算を行ってから最後にもう一度合算し、最後に 2.4 上しようとしました。

 ところがなぜか変換後、シャドウ部のデータが消えてしまいます (ブラックポイントになってしまう)。これも理由がわからずさんざん検討したのですが、プログラムに間違いがあるとは思えません。

 数日さんざん悩んだ挙句、ふと気が付いて setDisplayRange の場所を確認しました。  

 以前以下にも書いておきましたが...

yasuo-ssi.hatenablog.com

yasuo-ssi.hatenablog.comこれらの記事に書いておいたように、setDisplayRange によるディスプレイ範囲の設定が計算に影響を与えます。

 で、当然そう書いた本人も分かっていますので、

imp.setDisplayRange(0.0, 65535.0)

などとと入れています。

 問題は setDisplayRange を実行した後、さらに imagePlus に対し計算を加えており、その後、その imagePlus に対し、

imp.getProcessor().gamma(2.4)

とやっていました。つまりディスプレイ範囲を設定した後、画像に対して足し算、引き算などの計算を加え、その後ガンマ補正を掛けているため、ガンマ補正前の画像計算の段階で、ディスプレイ範囲がずれてしまったのではないかと思われました。

そこで見直して、ディスプレイ範囲を設定するのをガンマ補正の直前に変更しました。

imp.setDisplayRange(0.0, 65535.0)
imp.getProcessor().gamma(2.4)

というような感じです。

 すると、ビンゴ。これを入れたことで正しく TRC がデコードされるようになりました。

 つまり、単に setDisplayRange をきちんと適用しましょう、だけではだめで、gamma 補正を掛ける直前に必ずディスプレイ範囲を設定しましょう、ということを確認する必要がある、ということです。gamma メソッドと setDisplayRange メソッドは共に手を取り合って並んでセットとして使う必要があるということが分かりました。

 

 なお、以前にも報告しましたが、ImageJ でガンマ補正などの計算が、16bit 画像 (shortProcessor) において、Ver. 1.53 → 1.54 で変わっています。ただ、それが、16bit 画像においてディスプレイ範囲を参照せずに変換していたのが (8bit 画像、byteProcessor と同じ挙動)、ディスプレイ範囲を参照して変換するように変わったのか、それとも、16bit 画像においても、それまで明示的に指示しない限りディスプレイ範囲が変わらなかったのが、32bit 画像のように計算によって自動的にディスプレイ範囲が変わるようになったためなのかは掴めていませんが(どうも後者のような気がします)、併せてご注意ください。

 

四半世紀前のネガがきれいにスキャンできない理由とその補正対策

 先日 X (元 Twitter) を見ていたら、褪色した京浜東北線 205 系の写真をアップされている方がおられました。その写真が以下のリンクにあります。おそらくカラーネガフィルムで撮影されたものと思われますが、ネガカラーフィルム褪色の非常に典型的なケースと思われますので、ちょっと話題として取り上げさせていただきます。

 

 京浜東北線には元々 205系 は少なく、それも 209 系の投入で徐々に他線区に転属し、最後までいたのが、1998年ということですので、少なくとも四半世紀経過したネガ、ということになります。

 ちょっとアドバイスさせていただきましたが、当ブログで皆様に見ていただいている通り、カラーネガ画像はブルーチャンネルから褪色が始まります。ネガ上ではその補色になりますので、つまりネガのイエロー染料が最も褪色しやすいということです。

 この画像の場合、青い帯が緑になっていて、空の青も冴えない一方で、横の保線用機器の黄色の色も冴えません。この画像から判断すると、ネガの褪色に伴い、ブルーチャンネルのダイナミックレンジの幅が狭くなっているためと考えられます。

 ひょっとすると、これは褪色が主原因ではない可能性もなくはありません。元々フィルムの R, G, B チャンネルの分布は印画紙に露光させたときに最適になるように調整されていますが、それは CMOS などのイメージセンサーの感度とうまく合いません。それをソフトウェア的に調整しなければなりませんが、その調整がうまくできていない可能性もあります。ただ、概ね、レッド、グリーンのレベルは適正と見られることからやはり褪色が主因のような気がします。同様なケースは、例えば以下のブログにも見られます。

www.backyrd.net これを見ると、ブログ主の方は、20年前に正常にスキャンできた画像を、20年後スキャンすると青が緑になると報告されておられることから、やはり結構良くある典型的な褪色のケースと考えるべきかと思われます。

 いずれにせよ、これらの画像は相対的に青い部分はもっとブルー値が高くあるべきである一方、青の補色である、相対的に黄色い部分はブルー値がもっと低くあるべきだということです。また若干マゼンタ被りもあるようです。

 

 フィルムスキャナやフィルム対応フラットヘッドスキャナで取り込む場合は、スキャナドライバーで R, G, B のダイナミックレンジの違いを自動で調整するものがありますので、フィルムスキャナによってはこの程度は問題なく自動的に補正してスキャンできる場合もありますが (但し画像によっては自動調整に失敗する可能性もある)、デジタルカメラを使ったフィルムスキャンではそのような機構はありませんので、自分で調整する必要があります。

 カメラでフィルムスキャンを行う場合は、ネガポジ反転の時に係数を調整できるはずですので、それである程度調整しますが、それと反転後のホワイトバランス調整を組み合わせます。ただそれでもうまくいかない場合があります。

yasuo-ssi.hatenablog.com

yasuo-ssi.hatenablog.com

 それ以外の方法としては、例えば、RGB トーンカーブや色レベル補正を組み合わせて調整することも考えられますが、これらは RGB の相対値ではなく絶対値に基づいて調整するので、調整が難しい場合があります。上の 205 系のケースも単純に RGB カーブや色レベル補正で、Bチャンネルのトーンカーブコントラストを高めてもうまくいきません。また RGB ヒストグラムの形態を見ても、画像によっては、B チャンネルのダイナミックレンジが下がっていることがよく分からないことがあります。これは絶対値レベルではなく相対値レベルでダイナミックレンジが下がっているためです。

 変褪色の原因は、光の問題ではなく、色素の変成のため、色の絶対値ベースではなく、相対値ベースで色を調整することが重要なのだと思われますが、既存の画像処理ソフトでは相対値ベースで色を調整するツールが意外に貧弱です。

 例えば、ART の場合、色相を使ったパラメータ指定マスクを使ったカラー/トーン補正が有効です。

ART パラメータ指定マスク (色相)

 上で、画像の青い部分を指定しています。これに以下のようなカラー/トーン補正のカラーホイールによる補正を併用します。

カラー/トーン補正のカラーホイール (標準 / 知覚的モード)

 上の青い部分の青みを増やしています。これを黄色い部分にも同様の編集を適用します。

 なお、ART の派生元 RawTherapee にもカラートーン補正はあり、同様の編集は一応できるのですが、ART のカラートーン補正はリニア RGB 空間で色変換を行うのに対し、RawTherapee は L*a*b* 空間で行うせいか、ART ほどきれいに補正できません。

 さらに、ART に拙作の相対色領域補正 CTL スクリプトを組み合わせて使いますと、このような画像の修復に有効な、相対的に青い部分のブルー値を上昇させ、相対的に黄色い部分のブルー値を下降させるというような補正編集がより簡単に (というのは筆者の主観?) できますので、ご関心のある方はお試しください。

yasuo-ssi.hatenablog.com

 本スクリプトでは、R, G, B の絶対値ではなく、相対値 (相対的にどれほど青い or 黄色いか) に基づいて補正領域を作成しますのでネガフィルム画像の色調補正に非常に便利です。また補正領域の調整も、非常に柔軟にできます。

ART + 相対色領域補正 CTL スクリプトで相対的に青い領域を析出中

 また、同様の編集を GIMP 等で行うためのマスクを作る以下の様なツールも公開しています。最初に下記のツールを開発し、それを ART に適合するように移植したのが上のツールです。このようなマスクを作るツールを開発しないと、GIMP ではちょっと編集がやりにくいです。というのは、GIMP の既存のツールでは、類似色の選択を使うか、色相・彩度モジュールを使うかということになりますが、色相・彩度モジュールでは色相の変更しかサポートしておらず、また類似色を使った選択範囲は、GIMP に限りませんが画像によってはうまくいかない場合があります*1

yasuo-ssi.hatenablog.com

 なお、darktable ですと、カラーゾーンモジュールを使いますが、細かくマスクを掛けて制御する必要があり、ART よりは面倒な感じです。

darktable カラーゾーン

 Photoshop の場合は特定色域の選択を使いますが、色域ごとに選択される範囲が固定している点が使いづらいです。拙作の ART 用の相対色領域補正 CTL スクリプト の方がはるかに柔軟な調整ができます。

 

 ちょっと典型的な事例ですので、自分にとっての備忘録を兼ねて紹介させていただきました。

 なお、さらに褪色がひどくなると、本ブログで補正方法を解説しているような、青チャンネルが不均等に黄変した画像になることがあります。そのような画像は X で流れてくる鉄道写真にも非常にたくさん見られます。このような現象は、湿度が低く、かつグラシン紙のフィルムスリーブが一般的な欧米ではほとんど見られませんので、ポリエチレン製のフィルムスリーブをグラシン紙のものに変えたり、除湿剤を使うなどの保管対策を行うことが望ましいです。

 

*1:その理由については以下に考察を書きました。

yasuo-ssi.hatenablog.com

GIMP 3.0 のリリース他

 X (旧 Twitter) に流れてきた情報によると、GIMP の新メジャーバージョンアップ、3.0 のリリースは当初本年5月頃を目指すとされていましたが、現在のところ 2か月以内のリリースを目指しているそうです。

 

 また現行版、Ver. 2.10.38 に関しては GTK2 の複数のバージョンの混乱から一部バグが出ており、2.10.38 Rev.1 のアップデートが予定されているとのことです。