SimuLook · 来自相机的笔记
降噪不是一根滑杆
富士自定义位里的大多数设置，只要看过两个例子就能猜出它存的是什么。色调类控制 存十分之一：−1 存成 −10，+2 存成 +20。锐度和色彩遵循同一条规则。色温按 Kelvin 存储。
降噪不是这样。
它实际存的是什么
下面是完整的对照表，上面一行是菜单里的高ISO降噪数值，下面一行是相机存下的内 容：
| 菜单 | +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。
这正是那种永远不会自己宣告的错误。你的照片回来时和配方说的略有不同，而任何地 方都不会报出一个问题。