カメラのノイズと解像感
最近調達した FUJIFILM X-M1 と今まで主に使っていた RICOH GX-200 で風景を撮り比べてみた。どうやらノイズの少なさが解像感の向上に貢献しているらしい。
/*----------- -----------*/
武蔵野の夕陽
今回は「撮って出しJPEG」で撮り比べした。
上は GX-200 で撮った全景を 1/4 に縮小したものだ。この位のサイズで見るなら GX-200 も悪くない。
撮った後見比べていて気付いたのだが、左下の建物の屋上フェンスが解像度の限界付近の画質を見るのにちょうどいいテストパターンになっている。上の写真にピンク色の枠で示した部分だ。ピクセル等倍で切り出してみた。
撮影条件 | ||||||||||||||||||||||||||||||||||||||||
|
GX-200 はコントラストが高くカッチリしている。その一方 X-M1 はコントラストが若干低く、ソフトな印象である。多分これが原因なのだが、X-M1 で写した画像をカメラの液晶モニターで確認した時にピント合わせを失敗したかとドキッとしたことが何回かあった。
しかし GX-200 では同時に何かザワついた落ち着かない感じを受ける。フェンス左端から中央付近にかけてモアレないしは偽色が見られるからだろう。X-M1 の方はそのようなことは無い。詳しく見るためにフェンス左端付近をさらに拡大してみよう。
ピクセルの存在がはっきり分かるよう拡大の際に補間は行っていない。これを見て分かったのは、フェンスの模様は画像センサーのピクセルピッチで決まる解像度の限界にほぼ等しい、と言うことだ。フェンス左端では限界よりも粗いが、右端では限界を超える。画角が同じでセンサーのピクセル数が多い X-M1 の方が解像度の限界が若干高いが、この状況は同じである。この領域でも GX-200 のように高いコントラストを得ようとすれば偽色やモアレが発生する場合があっても仕方がないと言えるだろう。
また GX-200 の場合不規則なパターンがフェンス左端付近に生じている。どうやらこれが落ち着かない感じの本当の原因らしい。このように不規則なパターンはモアレなどでは説明できず、ノイズの影響と考えるのが妥当だろう。
ここで言う「ノイズの影響」は、光量が少なくて信号レベルが小さくなることによるS/N比の低下ではない。露出条件を見れば十分な光量があることが分かるが、それでも GX-200 で写した画像の空の部分にザラついた感じのノイズが認められる。GX-200 はセンサーの解像度の限界付近でも比較的高いコントラストが得られるチューニングが施されているので、なおさらノイズの影響を受けやすくなっている可能性が高い。
解像感を高めようとしてもノイズが多いと逆効果になる場合がある、と言えそうだ。これと似た内容の記事が「ようかんのあやしい実験ブログ」で見つかった。掲載画像を数値化して解析したら記事の内容を裏付ける結果が得られた、と言う実に興味深いものだ。
ようかん氏から記事にすることへの承諾が得られたので、ここに併せて紹介する。
なお私が X-M1 を調達するきっかけになったのがこのブログのいくつか前の記事である。
元画像は上のリンクをたどって見てほしい。コンポジット数の異なる横幅 120 ピクセルの帯状の画像が 8 枚横に並んだ画像である。上端から 161~280 ピクセルの範囲で各コンポジット数の画像を切り出し、モノクロ化して窓関数を適用したサンプルを準備する。
今回はハミング窓を使った。それぞれのサンプルについて2次元 FFT を行うと、元画像の配列と同じ 120x120 の2次元配列の形で空間周波数スペクトルが得られる。長くなるので数学的な詳細は省くが、平面上の空間周波数を測る場合に向き(角度)を意識する必要がある。つまり周波数が2次元ベクトルなので FFT の結果が2次元配列になるのだ。
空間周波数毎に全ての向きの周波数成分値の RMS を計算すると、空間周波数と画像強度、つまりコントラストの関係が得られる。これは全く劣化が無い場合の元画像の空間周波数分布に処理系全体の MTF を適用したものに相当する結果である。これを各サンプルについて計算し、まとめてプロットした。
FFT を行ったままだと空間周波数の単位は 120 ピクセルあたりの波数なので、CMOS センサーの長辺のピクセル数 / 長さ[mm] / 120[ピクセル]= 4896 / 23.6 / 120 を掛けて mm あたりの波数 [1/mm] に換算している。
このままでもコンポジット数の違いが分からなくもないが、ウェーブレット処理を行っていない n = 1 を基準にコントラストが何倍増加しているかを見たほうが違いが分かり易い。
この結果から言えるのは;
- 概ね空間周波数 65/mm 以下が有効な画像、それ以上がノイズと識別されている
- 「Noisy Limit」と表示した線がノイズが目立ち始める限界である
- n = 64 を超えてコンポジット数を増加させた場合もノイズ成分が減り続けている
- ノイズ成分が減っているにもかかわらず n = 100 以上で有効な画像のコントラストが上がっていないのは、これ以上ウェーブレット処理を強くすると不自然になるからではないかと考えられる (Unnatural Limit)
ただし有効画像とノイズ成分の境界や「Noisy Limit」および「Unnatural Limit」の位置は今回の条件固有である。元画像が変わればもちろん、同じ元画像でもサンプルを取る位置が変われば変わってしまう。ウェーブレット処理を行っていない n = 1 との比率を取っている事が変わってしまう一番の原因である可能性が強いので、一つ前のプロットを使えばもう少し普遍的な結論が得られるかもしれない。
ただ、いずれにせよ画像の空間周波数分布を見ながら RegiStax を使う訳ではないので、どんな結果が得られても直ちに何かの役に立つことは無さそうである。この種の分析に利用価値があるとしたら、ウェーブレット処理の自動化につなげられるような結果が得られた場合だろう。
レンズ系分解能との関係
地上写真を撮影した際に1段絞り込んでいるので収差の影響はある程度軽減されているはずだ。それでも無収差を前提に天体望遠鏡と同列に議論して良いものか怪しいが、一応確認しておこう。
| ||||||||||||||||||||
|
結果について論評する前に、レイリー限界について再確認しておきたい。レイリー限界は2つの点像が見分けられる範囲で最も近づいた状態だ。この場合の点像の中間の明るさを計算すると、点像の中心の約 1/2 になる。また中間の明るさがゼロになるのは点像がちょうどレイリー限界の2倍離れた場合で、これは光の回折が影響を表し始める状態である。これよりも点像が離れていれば回折の影響を無視しても大な誤差にはならないはずである。
このプロットの横軸は像面上の距離 x を光の波長 λ とレンズの F 値で割ったものだ。レイリー限界は x = 1.22λF と表されるが、この時の 1.22 に相当する値である。また例えば 波長 500nm、F2 の場合なら、横軸の数値はそのまま μm で表した像面上の距離になる。
ここで考えておく必要があるのが、いくつピクセルがあれば2つに分離された点像があることが分かるか、と言うこと。
2つだと分離された点像がそれぞれのピクセル上にある場合と、分離されていない大きな点像が2つのピクセルにまたがって存在する場合が見分けられない。これは中間の暗い部分の有無を検出することで区別できるので、最低3ピクセルあればOKだ。つまりピクセルピッチは点像間隔の 1/2 以下であることが必要になる。
デジタルカメラのピクセルピッチの説明で「レイリー限界よりも小さいのは無意味」と書かれているのを見かけることがあるが、これは「これより小さくても回折の影響でコントラストが次第に低下するから」と言う理由に基づくことになる。レイリー限界までは点像が分離できる立場を取るなら、ピクセルピッチの微細化はレイリー限界の 1/2 までは有効と書くべきだろう。この2倍の違いはある種のグレーゾーンとみなすのが適切なのかもしれない。
さて、先の表を見てまず気づくのは、GX-200 はもう少し絞り込んだ状態に合わせてチューニングされているのかもしれない、と言うこと。今回は F3.2 だったが、もっと絞り込んで例えば F11 だったとするとエアリーディスクの明るい中心部に 20 ピクセル以上入る計算になるから、偽色やモアレが出る心配は無さそうである。ただしノイズに関しては良くも悪くも影響無いはずだ。
GX-200 はレイリー限界とのグレーゾーンのピクセルサイズが大きい方の端に該当するが、「ようかんのあやしい実験ブログ」の月面写真は相対的にピクセルサイズが小さい方の端にあたっている。ここで注目に値するのは、ノイズとみなす空間周波数の下限 65/mm に該当する像面上のピッチがレイリー限界の 1.64 倍で、例のグレーゾーンの中に入っている事だ。空間周波数が 65/mm よりも高い成分は CMSO センサーに結像した画像にほとんど含まれていなかった可能性がある。RegiStax で処理する前に空間周波数 65/mm 以上の成分を取り除くような処理を行うともっと少ないスタック数で同じ結果が得られるかもしれない。RAW 画像を現像する際の設定で実現できれば手間が増えずに済むが、ざっと見た範囲ではディティールを捨てるような設定は無いようだ。バッチ的に多数の画像に一括でローパスフィルターを適用するプログラムは比較的簡単に作れるから、そのうち試してみたいと思うが、問題は素材の準備だ・・・。
再びノイズについて
比較的明るい画像で ISO 感度も低いのに問題になるようなノイズが発生するのを不審に思っていた。もしかしてと思って調べたら、ピクセルごとの感度のバラつきが原因でノイズなどの問題が発生するのは良く知られた事実らしい。構造上の特性から CMOS センサーで著しく、なかには「CMOS センサ特有」と書いている資料もある。
今回の地上風景の比較では CCD センサーを使っている GX-200 の方がノイズが目立つ結果になったが、これは X-M1 の画像処理エンジンが良くできているかららしい。別の被写体の場合だが、RAW ファイルをディフォルト設定の RAW FILE CONVERTER で処理した .tif ファイルの方が同時記録した JPEG ファイルよりも明らかにノイズが多いのだ。
センサーの感度のバラつきが原因ならフラット補正で解決できる可能性がある。光学系を含まないセンサーのみの補正で良いはずだ。オフセットのバラつきも問題になるのならダーク補正も必要だろう。RAW ファイルに適用するのが効果的だと思うが、現像して無圧縮の .tif を作って処理する方が道具の準備が簡単そうである。これもそのうち試してみたいと思う。
もしかして X-M1 の画像処理エンジンは JPEG 生成時にダーク/フラット補正に相当するような処理をしている? まさかとは思うが、技術的に不可能ではないから、無いとは言えない。
今回のまとめ
ノイズが多いのが原因で解像感が損なわれる場合がある。エッジが毛羽立ってしまうからだろう。エッジが滑らかな方が解像感が高い。
月面写真に最適なウェーブレット処理を行うためスタッキングによるノイズ低減が有効であることが実証された。月のような、天体写真ではかなり明るい被写体でもノイズ低減がこんなに効くのは意外だ。ピクセル毎の感度のバラつきによるノイズである可能性が考えられる。光学系の分解能を超える高周波成分を予めフィルターで取り除いてしまうのが有効かもしれない。
| 固定リンク
「携帯・デジカメ」カテゴリの記事
- カメラのファインダーについて考える(2016.02.29)
- 空間フィルターを使った天体写真の画質改善(2015.01.22)
- カメラのノイズと解像感(2015.01.09)
- docomo L-07C の時限爆弾 (空き容量消滅!)(2014.10.29)
- 今更・・・地デジに釣られた(2009.08.11)
「趣味」カテゴリの記事
- カメラのファインダーについて考える(2016.02.29)
- 空間フィルターを使った天体写真の画質改善(2015.01.22)
- 水星と金星のランデブー(2015.01.10)
- カメラのノイズと解像感(2015.01.09)
- Fujifilm X-M1 とそのアクセサリー(2014.12.14)
この記事へのコメントは終了しました。
コメント
記事の題材に取り上げていただきありがとうございます。
コンポジット済みの画像ではわかりませんが、ノイズの大きな要因は気流による画像の揺らぎだと思います。
コンポジット枚数が多いほどその揺らぎが平均化されますが、画像毎の誤差はボケとなって現れるので、RegistaxのWavelet変換処理でそれを取り除いているという感じです。
ご迷惑でなければ、解析の素材としてスタック前のRAWファイルを提供します。
ただ、ファイルサイズが合計6GB程になるので、受け渡し方法の検討が必要ですが…。、
投稿: ようかん | 2015年1月10日 (土) 07時52分
ようかん さん、こんにちは。
なるほど、大気の揺らぎの影響を除去する効果が大きいのですね。
確かに RegiStax で処理した仕上がり画像をいくら解析してもこれは分かりません。おっしゃる通りです。
RAW ファイルご提供のお申し出ありがとうござます。
受け渡し用に Google Drive を準備しました。回線によっては時間がかかる場合があると思いますが、利用できる手段の中でベストだと思います。
既にお持ち、または新たに取得した Gmail アカウントをコメントでご連絡ください。(当ブログのコメントは承認制にしていますので、他の方には非公開で連絡していただくことが可能です)
ご連絡いただいた Gmail アドレスにアップロード方法のご案内を送付したいと思います。
以上、よろしくお願いします。
投稿: エンジニア | 2015年1月10日 (土) 10時05分
Google Drive にファイルをアップロードしてみました。
下記のリンクでダウンロードできるでしょうか?
◆20141227_180835_X-M1_RAW.zip
https://drive.google.com/(省略)
X-M1のRAWファイルです。
SILKYPIX の現像パラメータも同梱されているので、フォルダ情報付きで展開してください。
このファイルをJPEGに現像してRegistaxで処理しています。
現像したファイルがあればお送りしたかったのですが、作業後に削除してしまいました。
◆20141227_Stacked_Data.zip
https://drive.google.com/(省略)
スタック数ごとに下記の3種のファイルが入っています。
・Registaxでスタック済みのファイル
20141227_180835_X-M1(n=*of*)-01_Stack.tif
X-M1のRAWファイルをJPEGに現像した後、Registaxでスタックしたファイルです。
n=(スタックした数)of(元ファイル数)
・RegistaxでWavelet処理したファイル
20141227_180835_X-M1(n=*of*)-02(RGB)_Wavelet.tif
スタックしたファイルにWavelet変換処理したファイルです。
・RegistaxのWavelet処理パラメータ
20141227_180835_X-M1(n=*of*)-02(RGB)_Wavelet.rwv
Wavelet変換処理のパラメータを保存したファイルです。
Registaxで読み込むことでパラメータを再現できます。
よろしくお願いします。
投稿: ようかん | 2015年1月11日 (日) 03時41分
ようかん さん、ありがとうございます。
なるほど、誰かにダウンロードしてもらうなら匿名でできるんですね。
勉強になりました。
ダウンロードし、一部のファイルを確認してOKでした。
zipファイルなので全部問題無くダウンロードできていると思います。
stack前画像 →(stack)→ stack済画像 →(wavelet)→ 仕上がり画像
上記過程で画質がどう変わるのか、この記事の方法で調べてみようと思っています。
少し時間がかかると思いますが、また記事にしますのでよろしくお願いします。
勝手ながら貴コメントのダウンロードリンクは一部修正して掲載いたしました。
ご了承ください。
投稿: エンジニア | 2015年1月11日 (日) 11時34分
無事にダウンロードできたようでよかったです。
Google Driveの共有設定はいったん解除しておきます。
もし、ファイルが必要になったらブログのゲストブックに連絡ください。
ファイルの数が膨大なので、解析にはかなり時間がかかると思いますが、結果は気長に、楽しみにお待ちしています。
投稿: ようかん | 2015年1月11日 (日) 18時53分