SimuLook · カメラからのノート
ハイライトとシャドウは0.5刻みで動く。私たちはそれを丸めて捨てていました
現行の富士フイルム機でハイライトを設定すると、ダイヤルは−1、0、+1とは動きません。 −1、−0.5、0、+0.5、+1と動きます。シャドウも同じです。トーン系の設定のうち、こ の二つだけが0.5刻みで動きます。
私たちのアプリは、これを整数で保存していました。その下流にあるすべての経路も同じ でした。
実際に何を失っていたか
較正に使っているカメラの七つのスロットのうち、三つが−0.5に設定されています。その スロットをアプリに読み込むと、値は入口の時点で丸められていました。保存される前、 公開される前、書き戻される前にです。
その影響は、最初に聞こえるより悪い形で積み上がります。
- カメラから読み取ったレシピが、カメラに入っていたレシピではありませんでした。 半段以内、というだけです。
- それを公開すれば、保存した人全員に丸められた版が渡ります。
- スロットへ書き戻せば、カメラはそれまで一度も持ったことのない値を保持することに なります。
- そのレシピを、実際に撮影に使った写真と照合すると、アプリは完全一致と報告します。 両側とも、丸められて一致させられているからです。
最後のものがいちばん悪い。写真を自分のライブラリと照合する目的は、違いを名指しす ることです。丸めは、実在する違いを偽りの確認に変えてしまいます。
コメントはすでにそこにあった
この丸めは、誰も気づかなかった見落としではありませんでした。すぐ上にコメントがあ り、モデルがトーンを整数で保存していること、現行機は0.5刻みを提供していること、そ してこれはカメラの制限ではなくアプリの制限であることが書かれていました。
誰かがそれを正しく書き留めて、先へ進みました。そのまま何か月も真実であり続けまし た。
これを書き残すのは、教訓が「型を確認しろ」ではないからです。コメントに書かれた既 知の制限は、固定された制限ではないということ。そしてコードベースは、放っておけば いくらでも、自分自身のバグの正確な説明を抱えたまま走り続けるということです。
修正が繊細になった理由
素直な直し方は、フィールドを小数にしてサーバーへ−0.5を書くことです。それをやると、 更新していない全員のアプリが壊れます。
出荷済みのバージョンは、このフィールドを整数として復号します。小数を渡されると、 劣化ではなく例外を投げます。しかもコミュニティのフィードは1ページを一つの配列とし て復号するので、0.5刻みのレシピが一つあるだけで、古いビルドのままの全ユーザーの 「発見」が空になります。レシピ一つで、全員のフィードです。
そこで値は二重に流れます。古いフィールドは、それらのクライアントがすでに読んでい る丸めた数値を、そのまま運びます。もう一つのフィールドが、カメラ自身の単位で正確 な値を運びます。カメラはトーンを10分の1単位で保存するので、−0.5は−5です。整数なの で、小数が往復で生き残るかという問題そのものを回避できます。
その約束は、コメントではなく二つのテストが保持しています。一方は現行アプリが書き 出したものを、古い契約の形をした構造体へ復号し、依然として整数が読めることを確認 します。もう一方は全フィールドを往復させるので、手書きのエンコーダーから漏れたプ ロパティがあれば、あなたの設定を静かに落とす代わりに、テストが落ちます。
下流もすべて追随させた
値が保たれるのは、経路上のどこもそれを再び丸めない場合だけです。
両方のエディターが0.5刻みになりました。整数刻みのエディターは、持ち主が開いた瞬間 にレシピを丸め直していたはずです。同じ喪失が、境界を一つ先へ送られるだけです。カ メラへの書き込み経路は正確な10分の1単位を送るので、同じ機体から読み取ったスロット へ書き戻せば、実際にそこにあったものが復元されます。読み戻しの検証は、浮動小数点 の誤差に対する許容を保ったまま、実在する半段の差は見逃しません。そして写真の照合 は、−0.5と0を差として報告し、それを名指しします。
なぜこれを書き残すのか
このアプリの主張は、あなたの設定について本当のことを伝える、というものだからです。 そして何か月ものあいだ、静かに半段ずれたことを伝えていました。
修正は入りました。公開済みの六つのレシピは、正確な値へ修正しました。ですが、正確 であると謳うアプリは、正確でなかったときにそれを言えなければなりません。言えない なら、その主張はただの宣伝文句です。
富士フイルムのフィルムシミュレーションレシピを読み取り、書き込むアプリ「SimuLook」の開発中に書いたものです。 対応カメラを見る · ほかのノートを読む