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

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

darktable - シーン参照ワークフロー超入門 (Ver. 3.4.0 準拠)

f:id:yasuo_ssi:20211128195339p:plain

 GUI対応のフリーウェアのRaw現像ソフトの代表としては、 RawTherapeeと、darktableが挙げられると思います。個人的にはフィルム・シミュレーション機能が良くてRawTherapeeを愛用していますが、ユーザ・インターフェースが難しいと敬遠される方も多いようです。darktableは、比較的ユーザ・インターフェースがよりLightroomに近くてシンプルということで、こちらを好まれる方もいらっしゃるでしょう。しかし残念ながら2020.8.10の3.2.1へのバージョンアップから日本語サポートがなくなってしまいました。これでお困りの方も多いと思います。そこで、前回negadoctor 機能の使い方を書いたついでに、最新版 darktable3.4 の簡単なチュートリアルを書いてみたいと思います。

 なお、darktableはVer. 3.0以降、シーン参照ワークフローというのを特徴として強く打ち出しています。ただし、現在でもデフォルト設定は従来通りディスプレイ参照ワークフローとなっています。ところで、このシーン参照ワークフローとディスプレイ参照ワークフローの違いは何でしょうか? darktable3.4のマニュアルによると、シーン参照ワークフローは大半の画像処理を知覚的ガンマ補正(sRGBガンマ補正カーブ)が掛かっていないリニアな色空間で行い、画像データにガンマ補正を掛けて処理するのは、画像処理の最後の最小限にとどめるのに対し (他ソフトでは、リニアワークフローとも言われているものです)、ディスプレイ参照ワークフローでは逆に、大半の画像処理をガンマ補正のかかった非リニアな色空間で行うという違いです。因みに私たちが普段コンピュータ上で扱う大半の画像は知覚的ガンマ補正が掛かった非リニアです。デジタルカメラの画像は未現像のRaw画像はリニア、カメラ内現像されたJpeg画像は非リニアです。また、LightroomやLuminarなど市販の現像ソフトの大半は、おそらく現像処理の多くの部分を非リニアで行っていると思います。

 では、大半の画像が非リニアなのに、現像処理をリニアで行うと何が良いかというと、処理速度が速く、また意図せずに色の統合性を失うことがなく、色ずれが起こりにくい、というようなメリットがあります。この辺りについては、私が以前書いたガンマ補正に関する記事をご参照ください。またdarktableの主要プログラマーである、Aurélien PIERRE氏は、従来の非リニア処理(L*a*b*)は、ダイナミックレンジが広がった現代のデジタルカメラには不適であると論じています*1。近年普及が進んでいるHDR処理ソフトも、中間処理過程では、一旦画像データをリニアに直して計算を行い、最後の出力の際に非リニアに戻すということをやっていると思います。

*1:次の記事をご参照ください。

pixls.us

続きを読む

夜の和菓子屋

 今日、夜に親の家の近くを通ったところ、住宅街の真ん中に和菓子屋があるのを発見。以前は今一つお客さんが入っていなさそうなラーメン屋さんだったのですが、和菓子屋に変わっているのに気づきました。照明の雰囲気が良かったので思わずカメラ(Nikon D5500)で撮りました。撮ったときは、背面の液晶で確認すると、見た目よりも青白く明るくなって今一つ雰囲気が出ていなかったのですが、家に帰って見てみるとまずまずの写り。それでも若干Raw現像ソフトで色温度を上げ調整してみました。RawTherapeeでRaw現像 & ノイズ低減を行い、ニュートラルプロファイルでをつかってREC2020リニアのTIFFで保存したものを、darktableに持っていき最終調整をやってみました (もちろん、最後はweb用に非リニアsRGBで出力しています)。とりあえず今日は時間がなくて入らなかったのですが、次回は何か買ってみたいと思います。味の方も建物の雰囲気に合っていると良いのですが...

f:id:yasuo_ssi:20210221223905j:plain

 

フリーのGIMP用褪色ポジフィルム復元プラグインを発見

 以前、赤色化した褪色ポジフィルムはどの程度復元可能かというのをVuescanや、スキャナドライバ付属のDigital ROCを使ってお見せしたことがあります。ただ、これらはいずれも有料のツールです(スキャナドライバはスキャナを買えば付属しますが...)。しかも現在 Digital ROCは入手できなくなっています。スキャナでもDigital ROCをドライバに組み込んでいるものは、現在市販されていません。

 しかし、フリーウェアでこれらに匹敵するか場合によっては上回りそうなツールを発見しました。Geoff Daniell氏が作成したGIMP用のプラグイン、およびPyhtonスクリプトです。WindowsおよびAndroid用のバイナリーもあります。多分日本人でこれに気づいている人は誰もいないのではないかと思います。因みに、GIMP Scripts.netには掲載されていません。

 これらをダウンロードできるのは以下のサイトからです。

www.lionhouse.plus.com このページの、Software for restoring faded photographs というリンクをクリックしてください。

 また、下記からもダウンロードできますが、本家とはリビジョンが微妙に異なりコードも冗長です。

github.com

 GIMPプラグインは Restore1, Restore2, Restore3 と三種類ありますが、Restore2と3は基本的に同じアルゴリズムを使っており、Restore1のみが異なったアルゴリズムを使っています。

続きを読む

日光線のクモハ107-1, クハ106-1 (1991.9)

 さて、昔の写真をスキャンしたら出てきた写真です。撮影したのは1991年9月上旬で、奥鬼怒に行った帰り、残った青春18きっぷ消費のため日光線経由で帰った時に撮影しました。青春18きっぷが残っていなければ東武で帰っていたでしょう。ちょうど日光線日光駅のホームに立つとクモハ107, 106のトップナンバーが入線していましたので、写真を撮っておきました。

 旧型国電ではありませんが、もはやクモハ107, 106も歴史の一コマとなってしまいましたし、日光線のNをあしらった初期の塗装も記憶の中の存在となってしまいましたので、ここで蔵出し公開します。クモハ107-1に禁煙車のステッカーが貼ってあるのも懐かしいです。

 ちなみに日光線にはかつてスカ色のクモハ41の一党がいたはずですが、撮り損ねてしまいました。クモハ41の一党が165系にとって代わられ、さらに2扉車で乗降が不便だったため、107系の導入となったようです。しかし2013年3月のダイヤ改正205系の導入となり廃車となりました。

f:id:yasuo_ssi:20210112224226j:plain

クモハ107-1 (東ヤマ)

f:id:yasuo_ssi:20210112224314j:plain

クハ106-1 (東ヤマ)

 この当時 (というか1960年代以降) の日光線は、東武にお客をすっかり取られ、観光客の姿も少なくガラガラでした。しかし、数年前にやはり青春18切符を使って久しぶりに日光を訪れた際には、外国人観光客呼び込みキャンペーンもあって外国人観光客で非常に混雑しており、非常に驚いた覚えがあります。ジャパンレールパスを使って、新幹線から日光線に乗り継ぐのが、外国人観光客にとっての日光訪問のメインルートになっていたのでしょう。

 おそらくまた今回のコロナ禍で、元の姿に戻っていると思いますが...

 ちなみにWikipediaの情報によりますと、本編成は1988.5.19に大船工場で製造され、2013.6.5付廃車となっているようです。配置は継続して小山電車区(→小山車両センター)でした。車令25年での廃車ですのでちょっと早すぎるような気もしますが...

 

黄変フィルム Bチャンネル再建補正法プラグインアップデート版正式公開

f:id:yasuo_ssi:20210310145522j:plain


 今年1月から、黄変フィルム Bチャンネル再建補正法に使う、ImageJおよびGIMPプラグインを徐々にアップデートしてきましたが、今回これを正式に公開します。ダウンロードリンクはこちらです。黄変フィルム補正法の解説ページも、今回のバージョンに合わせて書き換える予定です。バージョンアップ内容は以下の通りです。

 なお、このプラグイン・ソフトウェアを使用していただくにあたって、仮にこれを使った上でどのような損害があったとしても一切無補償であることに同意したうえで、自己責任で使用されるものとします。また不具合等がありましたら、コメント欄にお知らせいただければ幸いです。できる限り対応したいと思います。

  なお、Photoshop用のツールは用意していませんが、もちろんPhotoshopでもImageJで作成した素材ファイルから補正編集作業ができます。Photoshopでの編集作業についてはこちらをご参照ください。

 

■ImageJ用プラグイン

f:id:yasuo_ssi:20210207100909j:plain

図1 ImageJ用プラグイン パラメータ入力ダイアログ

・16bit版と8bit版を統合する(1/2バージョンアップ)とともに、画像のbit精度を自動判定するようにした(今回)。
 [上図 Image bit depth 項目]

・前景補正レイヤー用マスク画像の閾値を 128 と 48から選択するようにした
 [上図 Foreground Mask Threshold 項目]
 ※ 48 は元画像がリニアの場合に選択 (通常は128)

・背景補正レイヤー用マスク画像の閾値を調節できるようにした
 [上図 Background Mask Threshold 項目] (1/2バージョンアップ内容)
 ※なお、元画像がリニアの場合は 48 前後が適切

・背景補正レイヤー用マスク画像の明るさを調節できるようにした
 [上図 Background Lightness 項目] (1/2バージョンアップ内容)

・暗部補正レイヤー用画像の閾値を調節できるようにした
 [上図 Dark part Threshold 項目] (1/2バージョンアップ内容)

・周辺補正レイヤー用画像の閾値を調節できるようにした
 [上図 Periphery Adjst Threshold 項目]

・作業用ウィンドウを表示するかどうかを選べるようにした。
  [上図 Show working windows 項目] 

 

続きを読む

Signed TIFF / Unsigned TIFF とは? - 画像ファイルフォーマット

 英語で書かれた画像処理関連のサイトを見ていると、画像形式の中に、Signed 16-bit TIFF / Unsigned 16-bit TIFF という言葉が出てきます。

 あるいは、以下のページはImageJのマニュアルの日本語訳ですが、ImageJが直接サポートしないデータ読み込みの説明で、16ビット符号化整数 (signed integer)、16ビット非符号化整数 (unsigned integer) というような用語が出てきます。

seesaawiki.jp

 ここで符号化、非符号化と訳されている signed / unsigned とはどういう意味でしょうか?

 ここでいう、signed されたデータとは、0 を中心に+と-の値をとるデータ、unsigned とは正の値しかとらないデータ、という意味です。

 TIFFファイルの場合、8ビット精度の場合 unsignedしかありませんが(つまり明るさの値は 0~255の範囲のみ)、16bit, 32bitでは、signed と unsigned の両方を取る可能性があるようです。当然、16ビットで signedなら、明るさの値として、-32,768~+32,768 までを取る可能性があり、unsignedなら 0~65535 までの値をとる可能性がある、ということです。通常は unsigned が多いと思いますが...

  なお、ImageJ説明書日本語訳のように、日本語で「符号化」と訳してしまうと、「符号化」という言葉は、画像ファイルが圧縮 (符号化 / encoded) されてる、という意味で使われる場合がありますので、signed 16-bit TIFF を符号化16bit TIFFなどと訳されてしまいますと、圧縮されたTIFFファイルと誤解しかねませんが、そういう意味ではありません。ご注意ください !! この場合は「符号化」というよりは「正負符号つき / 正負符号なし」(つまりデータに + と - という符号が付くという意味)と訳したほうがまだましかと思います。encodedは「符号化」、signedは「正負符号つき」と訳し分けるべきでしょう。

 この情報について日本語で書かれた説明は、ネット上に見当たらないようなので、ここに記しておきます .... と書いたところで、bingで検索すると TIFFではありませんが、C言語の数値の扱いに関する要注意点ということで、signed, unsignedに関して記されたブログ記事がいくつか見つかりますね。googleだと 「signed, unsigned TIFF」と検索掛けると日本語のページは出てこないのですが...

 

ImageJ / Python: Jython でunicode 文字列を printすると...

 これも個人的備忘録です。

 ImageJ上でJythonを使ってunicode文字列(このケースは日本語を含むファイル名)をprintで出力しようとすると... ログコンソールがUnicode文字に対応していないので次のような表記になります。

f:id:yasuo_ssi:20201229201937j:plain

文字列の頭に「u'」が付きますが、これはUnicode文字列を示します。

 ImageJ上のJythonでの日本語処理は、基本、以下の和歌山大学のサイトで説明されているPython2.7系の日本語処理に準じます。

web.wakayama-u.ac.jp