SimuLook · カメラからのノート

ノイズ低減はスライダーではありません

富士フイルムのカスタムスロットに入っている設定の多くは、例を二つ見れば推測できる ものを保存しています。トーン系は10分の1単位です。−1は−10、+2は+20として保存されま す。シャープネスとカラーも同じ規則に従います。色温度はケルビン値のまま保存されま す。

高感度ノイズ低減は、そうではありません。

実際に保存されている値

表の全体です。メニューの値と、カメラが保持している値の対応：

メニュー +4 +3 +2 +1 0 −1 −2 −3 −4
保存値 20480 24576 0 4096 8192 12288 16384 28672 32768

下の行を読めば、問題は明らかです。線形ではありません。単調ですらありません。+2の 値はゼロで、他のどの項目より小さい。+3の値は+2、+1、0より大きいのに、−3より小さい。

数式はありません。これはルックアップテーブルであり、ルックアップテーブルを作る唯 一の方法は、全項目を観測することです。

なぜこれほど時間がかかったのか

確かめるための当たり前の方法が、機能しないからです。

自然な実験は、同じコマを異なるノイズ低減の設定で現像し、どの描写がどの保存値に対 応するかを見ることです。描写を比較するには数値が要りますが、そこで手が伸びる数値 がファイルサイズです。ノイズ低減が強いほど画は滑らかになり、JPEGは小さくなる。

理屈は通っていて、測定としては役に立ちません。JPEGのサイズは、画面に何が写ってい るかに支配されるからです。露出のわずかな違いや、撮影の合間に揺れた葉が、設定によ る差を簡単に飲み込みます。ファイルサイズで表を並べた結果、自信を持って間違った順 序が出てきました。

うまくいったのは、この設定が実際に変えているものを測ることでした。細部のエネルギ ー、つまり画面全体での隣接画素どうしの差です。ノイズ低減が取り去るのはそれなので、 数えるべきものもそれです。ファイルサイズがノイズしか返さなかったところで、こちら はきれいな順序を返しました。

表の両端は、メニューの−4と+4で撮影した写真によって固定されています。両極の値は、 中間からの推定ではありません。

上限を超えると巻き戻る

保存値を32768より大きくしても、挙動は上へ伸びません。回り込んで、メニューのゼロに あたる8192と同じ振る舞いをします。つまりこれは、上に余地のある尺度ではありません。 九つの値からなる閉じた集合であり、その外側の値は「より強い設定」ではなく「別の設 定」です。

ツールが補間すべきでない、十分な理由です。九つのどれでもないノイズ低減の位置を求 められたとき、正しい答えは最も近い値へ丸めることではなく、拒否することです。この 形の表において「最も近い」は、意味のある概念ではないからです。私たちの実装は拒否 します。

同じ九つの数値に、別の人も辿り着いていた

作業を終えたずっとあとになって、同じプロトコルのコミュニティによる文書 を見つけました。別のカメラでのUSBキャプチャから、独立に導かれたものです。

そのノイズ低減の表は、順序の入れ替わっている値も含めて、九つすべてが私たちのもの と一致していました。別々の試み、別のカメラ、別の方法、同じ奇妙な並び。

これはもっとも有用な種類の裏づけであり、同時に少し痛みます。始める前に先行資料を 探していれば、何週間も節約できました。このプロジェクトでは、同じ教訓をすでに二度 学んでいます。二度では足りなかったようです。

写真を撮る人にとって、これが問題になる場面

たいていは問題になりません。ダイヤルを回せば、カメラは正しいことをします。

問題になるのは、あなたとカメラのあいだにソフトウェアが入るときです。メニューの数 値をそのままこのプロパティに書き込むアプリは、あなたが指定していないノイズ低減を 設定し、カメラはそれを文句なしに受け付けます。ゼロとして書かれたゼロは、ゼロでは ありません。+2です。

この種の誤りは、決して自分から名乗り出ません。写真がレシピの記述とわずかに違う仕 上がりで返ってきて、どこにも問題は報告されないのです。

富士フイルムのフィルムシミュレーションレシピを読み取り、書き込むアプリ「SimuLook」の開発中に書いたものです。 対応カメラを見る · ほかのノートを読む