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

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

身延線の EF10 8 (蔵出し画像)

 主に旧形国電の写真を撮っていましたが、フィルムの合間に電機の写真も撮っていました。もっとも当時はフィルムだったので、フィルム代を考えるとそうたくさん撮ることはできませんでした。今回のそのうちの数コマです。

 私が通っていた小学校は東海道本線のすぐわきにあり、当時はまだ東海道本線の貨物の先頭にさっそうと立っていた EF10 でしたが、写真を撮った頃になると東海道本線を追われ、身延線飯田線南部の貨物仕業に使われていました。本車は甲府機関区に移り、身延線のローカル貨物の牽引に使われていた EF10 8 です。リベットのついた初期型タイプでいかめしい姿をしています。なつかしさで撮った写真です。それもやがて戦後生まれの EF15 に置き換えられてしまいますが...

EF10 8 (甲) 1977.5 富士電車区

EF10 8 (甲) 1977.5 富士電車区

 三菱電機の製造銘板です。

EF10 8 (甲) 1977.5 富士電車区

 戦前電機らしいいかめしい台枠です。

本車の車歴です。

1934.10.15 三菱電機製造 → 使用開始  1934.10.26  国府津 → (1945.3 現在 水上) → (1955.3 現在 国府津) → 1971.4.28 甲府 → 廃車 1978.01.11 (甲府)

車歴は以下のサイトを参照しました。記して感謝いたします。但し甲府転属に関しては鉄道ファンの車輛の動きを参照しています。

失われた鉄道情景を求めて (iwana氏作成)
http://silkroad2000.web.fc2.com/rireki.htm データ参照元は鉄道ピクトリアル 178号

デンチュウの鉄道ページ
http://tnk-ko.a.la9.jp/gallery/ef10_index.html

GIMP 開発版 2.99.18 がリリース

 先日触れたように、ついに GIMP 開発版 2.99.18 が 2/21 にリリースされました。

www.gimp.org

主要な変更点は...

 (カラー) スペース・インベージョン (古い GIMP カラーモデルの移植)
    改良されたカラーアルゴリズム
    最初の非破壊編集のサポート (ただし部分的サポート)
    フォント処理の改善
    自動拡張レイヤー (レイヤー範囲を越えて描画するときに自動的にレイヤーが拡張)
    新しいスナップ オプション (レイヤーを「境界に合わせる (Snap to Bounding Boxes)」および「等距離に合わせる(Snap to Bounding Boxes)」)
    テーマ (テーマの体系の整理し直し)
    新しいウェルカム・ダイアログ
    ファイル形式のサポートの改善

DDS
GIF
HEIF and JPEG-XL
OpenEXR
PDF
PNG
PSD
PSP

新しくサポートされたファイル形式: Farbfeld, Esm Software PIX, HEJ2
新しいパレット形式のサポート: Swatchbooker

他です。

 

なお、3.00 リリースまで機能の追加は基本的に凍結されます。今回が3.00 前の最後の公式バージョンアップになるということです。

また、カラースペース・インベージョンのため、今回のリリースは 2.99 の中で最も不安定なモデルになる可能性があるので、バグ報告をお願いしたいと書かれています。

ダウンロードは以下から。

www.gimp.org

デジタルカメラで撮影から RGB データを得るまで (Aurélien Pierre 氏 ビデオ要約)

 かつて darktable のエンジニアでフィルミックrgb 等の開発者であった Aurélien Pierre 氏が光とカメラのダイナミックレンジに関して理解するための基本について解説したビデオがあります。

youtu.be これはカメラや画像処理の原理に関して理解するのに非常に有益ですが、英語で解説しているのでハードルが高いかもしれません。そこで以下、このビデオの要点を、私による補足も交えながら、かいつまんで紹介します。

 まず、私たちがものを見る光のダイナミックレンジですが、彼によれば 20EV 程度のダイナミックレンジを持っているといいます。それに対しデジタルカメラのセンサーは現代では、10 - 14EV、パソコン等のディスプレイは 8 - 10EV 程度、プリントアウトでは、5 - 7 EV 程度と狭くなっていきます。したがって、広いダイナミックレンジのシーンをどうより狭いデバイスに割り付ける (リマップする) かが問題になります。

 

バイスごとのダイナミックレンジの違い
(左端がブラックポイント、右端がホワイトポイント)

 例えばカメラの場合、絞りを広げたり絞ることで、人間の視覚の 20EV の一部分を切り取ってカメラのセンサーに割り付けます。露出を絞れば明るい部分だけを割り付け、露出を開ければ暗い部分のみ割り付けることになります。

カメラの絞りと、人の目に写った光景のカメラセンサーへのリマップの関係

 なお、この EV という単位ですが、次のようなことになります。まず、明るさと、人間の視覚の関係ですが、光源 (例えば蝋燭) の数を 1本から2本に、2本から4本に増やせば、物理的に光の量 (エネルギー量) も2倍、4倍と増えていきます。

 

光源と明るさの関係

 しかし、視覚の方は光のエネルギー量に比例しません。増えれば増えるほど光への感度が下がります。つまり、知覚的には、上の図のように光量に対して log2 のグラフ状に明るさを感じていきます。この log2 の光量の変化1段階分が 1EV となります。つまり光量が 1EV 上がると、物理的には 2乗分光量が増加するということです。

 

 以上までは明るさのみの説明であり、カラーについての説明が含まれていません。カラーとは光のスペクトラムに対し、人間がどのように感じるかの反応曲線に応じて感じられるものです。物理的に存在するものは光の波長のみで、光の3原色、R, G, B に相当するものは物理的に存在しません。あくまで人間がどう波長を知覚するかという問題になります。

 この光の三原色に対する人間の反応曲線を CIE の XYZ 色空間に対応するようにグラフ化すると下記のような図になります。

 

人間の光のスペクトラムに対する反応
(CIE XYZ色空間に合うよう標準化)
出典: Wikipedia "CIE 1931 Color Space"

 最も波長の短い光は青と、最も波長の長い光は赤と感じられ、その中間は緑と感じられます。但し、赤には、波長の長い部分だけではなく、短い部分にも感度があります。おそらくこの部分がマゼンタ (紫) と感じられる部分と思われます。

 ところでデジタルカメラのセンサーも R, G, B毎にデータを取得していますが、そのカーブは人間の反応曲線とは大幅に異なり、青に対する感度が大幅に低く、緑は高く、赤はさらに感度が高い曲線になっているようです。

 この画像センサーと人間の視覚のずれを埋めるため、センサーから得られた r, g,b 値に3 x 3 のマトリックスを掛けて、人間の反応曲線の結果に近づけるのが、カメラマトリックスです。

 darktable では、一般的なデジタルカメラに適合するマトリックスを適用するようですが、おそらくカメラのセンサーによって微妙な違いが違いがあるのではないかと思いますが..

 さらにベイヤーセンサーの場合、次のようなセンサー構造になっています。

 

ベイヤーセンサー
出典: Wikipedia ベイヤーセンサー

 1ピクセル当たり3原色が揃っているのではなく、1つの原色しかデータを取得しません。そして緑のセンサー2に対し、青と赤のセンサーが1ずつの割合で配置されています。このため、オリジナルの Raw データは緑色になってしまいます。これは Fuji の X-trans センサーでも同じです。ただ、青赤緑の配置の仕方がベイヤーとは異なります。

オリジナルの Rawセンサーデータ画像

 この緑のデータを、各ピクセル毎にrgbデータが揃った形で補間する作業をデモザイクと言います。上のようにベイヤーセンサーは赤青緑のモザイクがあるように見えますが、各ピクセル毎に rgb データを揃えるとモザイクが消えたように見えます。ですのでこの補間過程をデモザイクと言うのです。

-----

※日本では「Raw現像ソフト」と言いますが (英語では raw processing software)、この緑の画像から正常な色の画像を取得するデモザイク過程を現像に例えてこのような名前を付けています。

 なおかつて存在した CCD センサーカメラや販売終了になってしまった Sigma の foveon センサーのカメラは、最初から1ピクセル当たり rgb 揃ったデータを取得しますので、デモザイク過程がありません。Sigma の foeveon センサーのカメラが画質で高く評価される理由には、デモザイク過程がなく、センサーに写ったそのままの画像が得られることにあります。その一方で 1ピクセル当たり rgb の3つのデータを取得するためセンサーの発熱量が多く、現在でも ASP-C どまりでフルサイズのセンサーの開発に成功していません。

----

撮影から画像データが得られるまで

 それはともかく、カメラで撮影してセンサーでデータを得るまでの過程がハードウェア的なら、そのあと、Rawデータを得た後の過程はソフトウェア的過程になります。ただ、ハードウェア的過程で画像を劣化させる要素があります。センサーのノイズ、レンズの歪みやボケ、そして実風景での霧や霞の存在です。それらをなるべくその逆順にソフトウェア過程で補正していきます。

 デモザイク、マトリックス計算が終了すると、リニアな rgb データが得られます。

 ともあれ、リニアなRGB空間で必要な編集作業を行った後、非リニアなデータに変換しそこで必要な編集作業を行います。

 なお、一般的には次のようなトーンカーブを掛けます。

トーンカーブ

 これは何に対応しているかというと、上の、「光源と明るさの関係」の図にある人の知覚反応曲線に対応しています。人の知覚あるいは、フィルムではハイライトと、シャドウ域での諧調の圧縮が起こっているので、それを模しています。ともあれこのような変換はダイナミックレンジの狭いディスプレイを前提としており (SDR)、よりダイナミックレンジの広い出力が可能な HDR では使えません。

 

---

 なお、Aurélien Pierre 氏のビデオを改めてみて一点気になることがありました。TRC とカメラのベースカーブを一緒くたにして説明しているように思われるところがあります。

 TRC は本来はディスプレイの再生カーブの歪みに対応して、ディスプレイ上でリニアな画像を得られるべく、データに補正を掛けるカーブです。同時に、低ビット深度画像においても、人間の目に敏感なシャドウ~ミッド域の諧調数を多めに確保するという意味でも使われます。

 それに対して、カメラのベースカーブはリニアなディスプレイ上の画像においても、ハイライト域やブラックポイント近接域において諧調を圧縮して、ダイナミックレンジの低いディスプレイにおいて、人間の目に自然に見せるためのカーブであると思います。つまり、最終的には TRC + ベースカーブがかかるはずですが、それを一緒くたにしているようです。おそらく darktable 3.x 上では、トーンマッピングを行う際に TRC の適用とトーンカーブの適用を同時に行っているのでそうなっているものと思われますが、この2つは概念的に異なるものと理解しておくべきかと思います。これもネットの情報をざっと見ているだけでは非常にわかりにくいので要注意です。

 なお、TRC の説明に関しては、以下の記事をご覧ください。

yasuo-ssi.hatenablog.com

darktable で オリンパス / OM system の Raw埋め込みデータによるレンズ補正が可能に

f:id:yasuo_ssi:20211128195339p:plain

 darktable 4.6.x で今まで不可能だったオリンパス / OM System の、Raw 埋め込みメタデータを使ったレンズ補正が可能になりました (下図)。

レンズ補正で [埋め込みメタデータ] が選択可能に

 Ver. 4.4.x では富士のレンズに関してはメタデータを使ったレンズ補正が可能になっていましたが、Olympus では不可能でした。

 近年ミラーレス化に伴い、レンズ補正データを Raw データにメタデータとして埋め込み、純正ソフトなどではその埋め込まれたデータを基にレンズ補正を行うようになる傾向が広がっています。その理由については、以下の記事で記しておきました。

yasuo-ssi.hatenablog.com

 ところがこれには副作用があります。このようなデータを持つレンズに関しては Adobe からレンズ補正データファイルが提供されません。つまりソフトウェアメーカーは Raw ファイルからメタデータを読むためには、直接カメラメーカーと契約してレンズ補正データに関する情報を得なければならなったということです。

 ところが、そのような契約を行うとするとメーカーと秘密保持契約を結ばなければなりません。しかしフリーのオープンソースのソフトウェア (FOSS) はソースコードが公開されているため、原理的にメーカーと秘密保持契約を結ぶことができません。Adobe がミラーレスカメラのレンズ補正データファイルを提供しないのもそのせいかもしれません*1

 もっとも FOSS はレンズ補正データを得るのに、レンズファンというボランティアベースでレンズ補正データを提供しているライブラリに依存しています。従って、Raw ファイルから補正用メタデータが読めなくても、レンズファンにデータがあれば問題はありません。しかし、レンズファンはユーザからボランティアでそのレンズで撮影した画像データを提供してもらっってデータを作成しているので*2、新しいレンズが出てからデータが提供されるまでどうしてもタイムラグが発生します。

 これに対し、darktable は独自に Raw に埋め込まれた補正データを解析する試みが続けられ、Ver. 4.4.0 (2023.7リリース) でヨーロッパで人気の高い富士のカメラのメタデータが解析され、メタデータからレンズ補正データが読めるようになっていましたが、オリンパス m 4/3 陣営のデータはその時点では成功していませんでした。昨秋ようやく解析に成功し、Ver. 4.6.0 からオリンパスのカメラでもメタデータからの補正データの読み込みがサポートされたという訳です。

 なお、レンズの補正は、メタデータ、レンズファンデータ、手動の3つの中から選べるようになっています。

レンズ補正データの選択

 なお同じ m4/3 陣営でもパナソニックの方はダメなようです。なお、ほかに Raw 埋め込みデータをレンズ補正に使うようになって Adobe からレンズ補正ファイル (lcp ファイル) が提供されないカメラ用レンズとして、Sony αシリーズ、Nikon Z シリーズ、Canon R シリーズなどがあります。Sigma などのサードパーティのミラーレス用レンズに関しては提供される場合もされない場合もあるようです。これらに関してはやはり darktable では埋め込みデータの読み込みはできないようです。

 なお、カメラメーカーによってはメタデータに埋め込むデータを暗号化しているところもあるようなので、このまま FOSS では今後ともメタデータの読み取りができないカメラが出ると思います。

 

 なおご自分がお持ちでないカメラの Raw ファイルの対応状況を調べるには、以下に DP Review による Raw ファイルサンプルギャラリーがあります。

www.dpreview.com

 なお、これらのファイルは個人使用目的のみで、このファイルを使った結果をインターネット等にアップしてはいけません。

*1:但し、Adobe は独自にデータを作っているのではないかという推測もあります。NEFファイルをDNG形式に変換すると補正メタデータが一致しないというのです。

discuss.pixls.us  Glenn Bucher 氏は Adobe は lcp ファイルを提供しているわけでもないのに、なぜ NEF ファイルのデータを読まず独自の補正データを使うのか訳が分からないと述べてはいますが。

*2:以下の記事をご参照ください。

yasuo-ssi.hatenablog.com

ART / RawTherapee 機能紹介: ロック式カラーピッカー

f:id:yasuo_ssi:20210904211415j:plain

 ART (および RawTherapee) には、ロック式カラーピッカーが装備されており、複数箇所のピクセルの RGB 値を計測できるので便利です。編集画面の上部からロック式カラーピッカーのアイコンをクリックし、プレビュー画面上でクリックするだけで複数の計測点を配置できます。

ロック式カラーピッカー

 ここでの R, G, B 値の表示はホワイトポイントを 100 % ブラックポイントを 0% とする % で表示されます。但し上の表示では、知覚的 TRC が適用された値が表示されており、リニアな RGB 値が表示されていません。

 この値は実は出力カラープロファイルに基づいて表示されます。デフォルトの出力プロファイルは sRGB になっているので、sRGB での値が表示されています。これをリニアな値に直したい場合は、下記のように、カラータブの下のカラー・マネジメントの出力プロファイルをリニアなものに変えると (下記の例では Linear REC2020 を選んでいます) RGB の表示が、リニアに基づく値に変わります。

出力カラープロファイルをリニアなものに変えたところ

青梅線の最古参 クモハ40033 (一部蔵出し画像)

 自分がなぜ旧形国電ファンになったのかを思い返してみると、片野正巳さんが書かれた『陸蒸気からひかりまで』という1:150スケールで描かれた国鉄車輛イラスト集が思い当たります。当時の男の子たちのご多分に漏れず蒸気機関車が好きでした。とはいえ当時お子ちゃまで親に連れて行ってもらえないと遠出はできないうえ、蒸気機関車は関東付近ではほぼ一掃され、蒸気機関車が現役で動く姿見られたのは、かろうじて八高線D51 のさよなら運転と、鉄道100年の記念列車が高島貨物線で運転に間に合ったぐらいでした。小学校の同級生の中には、小学生なのに一人で遠出し、カメラを持って北海道まで写真を撮りに行く猛者もいましたが...

 しかし、蒸気機関車以外にも心惹かれたのがこのイラスト集に描かれた戦前の旧形国電の車輛群でした。やはり親に連れられて青梅鉄道公園に行くために青梅駅に来ると、片野さんのイラストで見慣れた電車がそのまままだ現役でいるのに気づきました。これが本車とその後ろにいるクモハ40039です。まだ戦前生まれの電車が現役でいる! と非常に感激しました。これが自分にとっての旧形国電ファンになった原点です。

クモハ40033 (西トタ) 1973.5 青梅

 後ろにオレンジの101系が見えますが、これは中央線からの直通車です。

 以下はその3年後、青梅線が新性能化されると聞いて、慌ててカメラを持って駈けつけて撮った写真です。京浜東北線から転属してきた103系がすでにスカイブルーの塗装のまま入線していました。上の写真では残っていた旧青梅電車区の車庫の建屋は既に撤去され、既に単に電留線になっていたと思います。後ろに青梅駅に駅舎が見えます。バラストが新しいのを見ると、おそらく103系の入線に合わせ車庫を撤去し、電留線の配置も見直されたのではないかと思われます。なお青梅電車区は1971年2月1日に検修業務を廃止し所属車輛を豊田区に移管しています。

 1973年時点では青梅線にいたクモハ40023は遠く宇部に行き、本車が青梅線用車輛の中では最古参になっていました。

クモハ40033 (西トタ) 1976.12 青梅

クモハ40033 (西トタ) 1976.12 青梅

 当時の青梅線は立川ー青梅間で日中1時間に3~4本程度の運転間隔だったでしょうか。それがコロナ禍前には、E233系 10輌編成で6本の運転になっていました。ただちょっと輸送量過剰気味だと思っていたら案の定コロナ禍で5本に減らされてしまいました。

 また、1970年代の青梅線は青梅から奥多摩方面へ、土日はハイカーでかなり満員になるぐらいの輸送量がありましたが、近年は激減しているようです。そのため長らく30分に1本の運転間隔が維持されてたものの、現在日中は1時間に1本程度の運転本数となってしまったようです。とはいえ、昨夏、青梅鉄道公園休園前に訪問した時には、意外に奥多摩行きに乗り込む外国人観光客が多いのに驚きました。丹波山村でかなりインバウンド観光に力を入れているためのようです。

それはともかく、本車の車歴です。

1934.3.30 日本車輛東京支店 製造 東鉄配置 (モハ40113) → 1936.4.1 改番 (モハ40033) → (1947.3.1 現在 東イケ) → (1954.10.1 現在 東ミツ) → (1956.12.1 現在 東カノ) → 1960.11.19 東オメ → 1971.2.1 西トタ  → 1978.11.17 西ナハ → 1980.12.25 廃車 (西ナハ)

 本車は1934年に日本車輛東京支店にてい製造され、東鉄に配置されました。配置区は分かりませんが、1947年時点で池袋区にいて、その後中央線に移動しています。ただ当時の中央線はクロハを除いて大半が20m 4扉車でしたので、下河原線や、他の車輛の検査・故障時のピンチヒッター、牽引車代用として主に使われたのではないでしょうか。現在では電車は編成単位で管理され、編成の車輛を入れ替えるということはほとんどありません。入れ替えるとしても工場でのみ行われていると思います。しかし当時は1輌単位で管理されていたため、電車区の中で検査、修理などで編成を入れ替えることが頻繁にありました。中間電動車が多かったので、牽引車の需要も大きかったものと思われます。

 そして、1960年に17m車が中心だった青梅・五日市線に移動します。当時の配置表を見ると20m 車はクモハ40 x 2 およびクハニ67のみ 20m 車でそれ以外は17m 車に統一されていました。青梅線でのクモハ40の1970年代の運用は、基本立川ー青梅・武蔵五日市間の朝夕の増結用に限定されていましたが、おそらく青梅線配置当初から同様の運用形態ではなかったかと推測されます。

 1977年に青梅・五日市線103系で新性能化されますが、そこで廃車にならず、牽引車代用として中原区に移ります。ひょっとすると新鶴見区の職員輸送用にも使われたかもしれませんが、分かりません。その後中原区で余生を過ごした後、1980年に廃車となりました。ずっと首都圏を離れずに過ごしました。

darktable 4.6.1 がリリース

f:id:yasuo_ssi:20211128195339p:plain

 昨年12月に darktable 4.6.0 が出ましたが、そのバグフィックス版が先ほどリリースされました。ダウンロードは以下のリンクから。

www.darktable.org

主な改善点は...

・Open CL 上でのパフォーマンスを改善

・インポートダイアログで、サブディレクトリの検索に長時間かかる場合検索を中断することが可能に

バグフィックスとしては...

再帰モードでのファイルインポートにおける問題を修正

・QOI イメージローダーのメモリーリークを修正

・RGBEイメージローダーのバグ修正

・回転&パースペクティブモジュールにおいてガイドラインが表示されなくなる問題の修正

等々

 

なお、先日報じたカラーイコライザーはまだ搭載されていないようです。