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

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

新緑カラーをBチャンネル再建法でどう再現するか - Bチャンネル再建法における新緑表現復元のための追加補正の考察(1)

f:id:yasuo_ssi:20210310145522j:plain

 本サイトでは、Bチャンネル再建法による不均等黄変ネガカラー写真の補正法についてお伝えしておりますが、Bチャンネル再建法の技法上の理由からくる必然的弱点として、GチャンネルとBチャンネルの値が接近するという副作用があります。

 この副作用の結果として、例えば新緑の鮮やかさの表現というのが苦手です。新緑は主として黄緑色ですが、これはRとG値が高くB値が低いという特徴があります。しかし、Bチャンネル補正法を掛けるとG値とB値が接近しますので、どうしても緑が青緑に寄ってしまいます。場合によると緑が深緑っぽくなり、新緑に見えない、ということになりがちです。

 これを追加補正する方法としては、既にご紹介しているように、緑の部分に色域指定を行って、黄緑の方向に補正を掛けるという方法もあります。また本サイトで提供しているツールとして、汎用色チャンネルマスク作成ツールを公開しております。このツールで緑色透過マスクを作成し、そのマスクが透過する範囲に対してG値とB値が離れるよう補正を掛けることで、緑を黄緑色っぽく持っていくわけです。

 とはいえ、新緑に補正にするにしても、本来新緑の色がどのようなRGB値を持っているのか分からないとどの程度補正したらよいのか分かりません。という訳で新緑の写真を撮ってきましたので、それぞれの場所のRGB値をレファレンスとして示しておきたいと思います。なおこの値はRawTherapeeのカラーピッカーを使いました。またRGB値は100%表記になっています。0-255の値に換算するにはこの値に2.55を掛けてください。また値はsRGB式知覚的ガンマ補正が掛かっていることを前提としています。なお、数字が見にくいときは、画像をクリックすると拡大するかと思います。

 まず、晴れの時の新緑の写真です。

f:id:yasuo_ssi:20210417183333j:plain

写真1

f:id:yasuo_ssi:20210417183357j:plain

写真2
続きを読む

ImageJ対応 汎用色チャンネルマスク画像作成 & Bチャンネル再建法追加補正ツールバグ修正

f:id:yasuo_ssi:20210310145522j:plain

お知らせ

 このツールの機能強化&バグ修正バージョンアップ版を2021.5.8に公開しました。こちらのページをご覧になりダウンロードしてください。なお新しいバージョン番号は Ver. 0.05 になります。

先日公開した、ImageJ対応 汎用色チャンネルマスク画像作成ツールですが、バグがありました。画像によっては最終的に形成されるマスクの画像が下記のようにぶれてしまうことを発見しました。

f:id:yasuo_ssi:20210411075937j:plain

ぶれたマスク画像

 この理由は、二値化マスク画像を作成するときに、画像周辺に長方形状に真っ白な部分が発生すると、その部分が切り取られてしまい、マスク画像自体のサイズが小さくなってしまうためのようです。そのため二値化マスク画像とグレースケールマスクを合成したときに、サイズが異なるため画像がぶれてしまうのです。これは本来API自体のバグではないかと思いますが... 一部の画像のみにこの問題が発生するので、今まで気づきませんでした。なお、これは追加補正用黄変部マスク作成ツールでも同様です。

f:id:yasuo_ssi:20210411081431j:plain

切り取られる範囲

 とりあえずこの問題を回避できるよう修正したものを以下からダウンロードできるようにしましたので、ご利用ください。なお、修正を機に汎用色チャンネルマスク作成ツールのファイル名を RGB channel mask maker に変更しました。

 

修正済み汎用色チャンネルマスク画像作成ツール

修正済み追加補正用黄変部マスク作成ツール

 

横須賀線 E217系 Y-1編成

 引退迫る横須賀・総武線E217系です。本系列は省電力・低コスト・短寿命を目標に作られた209系の近郊型に適用したいわば209系の近郊型バージョンと言えます。209系は登場時から側板ベコベコ、窓は一切開閉不能のいかにも安普請といういわばロクサン系の再来というべき車両でしたが、本系列は一部窓は開閉可能となり、側板ベコベコも、113系に準じて車体の幅を広げて裾を絞ったスタイルとなったためか少しはましになりました。本系列はJR東日本特有の4扉近郊型の元祖となった系列です。またパンタグラフは209系に引き続きひし形でありながらも寸詰まりのPS-28Aが採用されています。その一方で209系とは異なり丸っこい先頭となりましたが、このデザインはその後のJR東日本の車両には引き継がれず特異な存在となりました。丸っこい先頭デザインの電車車両は韓国でトングリ(丸い奴という意味)と言われてはやっていますが、その先駆は1999年の仁川地下鉄だと言われています。あるいはE217系が韓国のトングリ*1のヒントになったのかもしれません。ちなみに先頭形状は233系でちょっと進化しましたが、235系の形状はまた231系に並みに退化したように思われます。235系はドアホームから見られることだけを意識しており、走行している姿はあまりデザインに考慮されていないように思われます。

f:id:yasuo_ssi:20210409232441j:plain

PS-28Aパンタグラフ
(写真はモハE217-2028 / Y-1編成とは異なる)

 以下に写真を掲げるトップナンバー編成は、1994年に製作された先行量産車2編成のうち一つです。のちの量産車と先頭車の貫通路の形状が若干異なります。なお選考量産車のうち川崎重工製のもう一編成は、その後、のちの量産車に合わせて車体が載せ替えられましたので、本編成が原型を残す唯一の車両となりました。すでに先行量産車の登場から27年が経過しています。とはいえ当初209系以降の新系列の電車は、コストダウンを図り、耐用年数10年程度で作られるという話でしたので、それを考えれば予想外の長寿だったのかもしれません。もっとも制御装置は2007~13年にかけて全面更新されていますので、それによって延命させたとも考えられます。制御装置の耐用年数を考えれば寿命10年程度というのはその通りだったと言えるでしょう。川崎重工製のもう一本の先行量産車の車体載せ替え(1996年)もひょっとすると耐久性の問題があったのかもしれません。

東京寄

11号車

f:id:yasuo_ssi:20210407224418j:plain

クハE217-1 (横クラ)

*1:例えば以下のサイトをご参照ください。

easiarail.travel.coocan.jp

続きを読む

DCRaw Windows版ダウンロードサイトについて

 Linuxで使われるコマンドラインベースのRaw現像ソフトウェアであるDCRawですが、DCRawでないとできないことがありまして、Windows版を探していました。一つ見つかったのですが、ダウンロードしてみると、16bitバージョンということで、64bit Windows上では動かず。

 他に、Windows上でコンパイルする方法について、日本語で指南しているサイトがありました。

autla.com 大変ありがたい情報提供ですが、開発環境をインストールするところから始めるのは面倒だな... と横着心が...

 さらに探していると、ありました。DCRawのWindows 32, 64bit版バイナリーを提供しているサイトが! それがこちらです。

www.fastpictureviewer.com

 こちらは、Fast Picture Viewer Professionalという有料の画像ビューアを販売しているサイトですが、そのダウンロードリンクに DCRawのWin32, 64bit版がありました。Fast Picture VIewerの作者の方がコンパイルして無料で配布しているようです。

 

 

 

GIMPの色域指定選択の問題点を回避する... ImageJ対応 汎用色チャンネルマスク画像作成ツール公開

お知らせ

 このツールをバージョンアップして「相対RGB色マスク画像作成ツール」として新たに公開しました。以下のページをご覧ください。(2021.7.3)

ImageJ対応 相対RGB色マスク画像作成ツール 新バージョン公開 (輝度マスク作成機能追加)

yasuo-ssi.hatenablog.com 

 なお、ImageJのインストール方法自体については (但し Windows)、以下をご参照ください。(2022.1)

yasuo-ssi.hatenablog.com  ------------------------------

 このツールの機能強化&バグ修正バージョンアップ版を2021.5.8に公開しました。こちらのページをご覧ください。なお、このページのダウンロードリンクも修正済みです。なおバージョン番号は Ver. 0.05 になります。

※修正版のリンクが間違っていたのを修正しました (2021.6.10)。

 

 先週、Bチャンネル再建法 追加補正サポート用マスク作成ツールの使い勝手の悪いところを、プレビュー画面を見ながら閾値を設定できるよう対話型インターフェースを備えた形に改善して公開しました。

 それから、さらに考えて、これを黄色/青色部分補正マスク作成(つまりBチャンネルを使ったマスク作成)のためだけではなく、他の、RチャンネルやGチャンネルを使ったマスクも作成できるよう汎用化を考えました。つまり、R, G, Bそれぞれのチャンネルの画像を使ったマスク画像を作成できるように改良してみました。

 なぜこう考えたかというと、もともと、Bチャンネル再建法 追加補正サポート用マスク作成ツールは、Bチャンネル再建法で補正しきれない部分を、色域指定等のマスクを使って追加補正する代わりに、パラメータ入力で補正マスクを作成したほうがやりやすいのではないか、というところから出発したのでした。しかもGIMPは、色域指定を使って選択範囲を作ろうとすると時間がかかる場合があります。実際に私もこれで困っています。これがフルHD程度(横幅1920ピクセル程度)であれば、多少時間がかかる程度で終わるのですが、最近のデジタルカメラの標準である 6000 x 4000ピクセル以上の画像だと、選択範囲を作り終わるまで数分(指定範囲の形状によっては10分以上)待たされることがあります。境界を滑らかにしたり、ぼかすと少し待ち時間は短めにはなりますが... 範囲選択コマンドの実行が非常に遅かったりなかなか表示されない問題点はGIMPのリリースノートでも指摘されているので (原因は過剰に画像の書き換えを行っているせいではないかと書かれています)、開発陣は問題があるという点は認識しているようですが*1、いまだに改善されていません。

 でこの黄変部分補正マスクツールをBチャンネル以外の他のチャンネルにも適用可能にすると、色域指定と全く同じではありませんが、近いことができます。という訳で、大きなサイズの画像をGIMPで編集する際に、汎用色チャンネルマスク画像作成ツールは特に有効なのではないかと思います。 

*1:以下をご覧ください。

www.gimp.org

続きを読む

ImageJ / Python: 対話型ユーザインターフェースのお勉強 (ROI設定ダイアログ)

 再び、MRC分子生物学研究所で公開している、ImageJの対話的ダイアログのサンプルプログラムの紹介です。今日は、ROI (注目領域、選択範囲)を対話的に設定するダイアログです(Create a UI: open a window to edit the position and dimensions of an ROI)。画像を読み込んでサンプルプログラムを走らせますと次のようになります。

f:id:yasuo_ssi:20210326220127j:plain

ROI設定ダイアログ

 ボックスから数値を入れてROIを設定しても良いし、画面から直接マウスを操作してROIを設定しても良い (その場合は座標数値が自動的に入力ボックスに反映される)というものです。

 まず、例によってこのプログラムの構成を見ていきます。

続きを読む

ImageJ / Python: 対話型インターフェースのお勉強 (バックグラウンドスレッドで動かす)

 今回取り上げるのは「Managing UI-launched background tasks (ユーザインターフェースから起動するバックグラウンドタスクのマネージング)」というサンプルプログラムです。このプログラムは、前回と全く同様、プレビュー画面で画像を拡大したり縮小することができ、外見も変わりません。どこが違うかというと、バックグラウンドでプレビュー画面の制御を行う点です。画像の拡大・縮小プレビューぐらいだとさほどタスクの負荷は大きくありませんが、負荷の高いプレビューを行うと、プレビューの画像処理を行っている間、ユーザの入力を受け付けなくなります。これをユーザ入力と、プレビュー画面の作成を別々のタスクで行うことで、そのようなことをなくそうということのようです。

 ただこのサンプルプログラムはなかなか手ごわいです。Javaの知識とPythonの知識がかなり要求されます。前回のサンプルプログラムは、このチュートリアルに出てくるその前のサンプル群に比べて、いきなり30~40度の坂道になった感じですが、今回のプログラムは、さらにいきなり、6, 70度ある坂道を鎖を頼りに登るような難易度になっています。私の解釈もこれで正しいのか自信がありません。間違いがありましたらご指摘いただけると幸いです。

 まず、前回取り上げたサンプルプログラム今回のプログラムの大きな違いについて説明します。前回のプログラムは、イベントリスナーを継承した、ユーザが定義した、ScalingPreviewer というオブジェクトがプレビュー画面の拡大・縮小などの動作を行っていました。具体的には、

 

ユーザがユーザインターフェースを動かすイベントが発生

    ↓

イベントを受けて、ScalingPreviewer の adjustmentValueChangedメソッドもしくは、itemStateChanged メソッドが起動

    ↓

これらのメソッドが、scale メソッドを呼び出す

    ↓

scaleメソッドが、まず元の画像から拡大・縮小した画像データ (imageProcessor) を作成

    ↓

さらに作成した画像データをプレビュー画面である imagePlus オブジェクトに適用

 

あるいは、

 ダイアログボックスがキャンセルボタンを押されて終了するとき、ScalingPreviewer が resetメソッドを明示的に指定されて呼び出され、resetメソッドがプレビュー画面であるimagePlusオブジェクトにオリジナル画像(imageProcessor)を適用して終了する

のいずれかでした。

 今回取り上げるサンプルプログラムでは、adjustmentValueChanged、itemStateChangedが scaleメソッドを呼び出すまでは一緒ですが、scaleメソッドやresetメソッドは直接 imageProcessorやimagePlusを操作することはありません。scaleやresetはputStateメソッドを呼び出して、ScalingPreviewer コンストラクターで定義をしておいた、プロセスの状態を指示もしくは表示する self.stateリスト変数の内容を書き換えるだけです。

続きを読む