我只需要澄清一下如何正确地将 [0,1] 范围内的 rgb 像素值转换为像 openEXR 这样的 HDR 格式的正确范围。
所以我知道，例如，当使用每个通道只有 8 位的 PNG 或 JPG 等低动态范围格式时，您只需将每个 rgb 值乘以 2^8-1 = 255 并钳制，以便所有值都范围 [0, 255]。
OpenEXR 和其他 HDR 格式使用每通道 16 位的半精度格式。那么我是否只是做和以前一样的事情，并将每个通道乘以 2^16-1 = 65535，以便我的新范围变为 [0, 65535]？
编辑
所以我尝试做我上面写的但是当我尝试在photoshop中显示openEXR文件时它是完全白色的。似乎任何大于 10 左右的值都太亮，以至于 Photoshop 无法正常显示，我觉得这很奇怪。因此，除非 Photoshop 显示出现问题，否则这似乎不是正确的方法。
我们同时处理三个相关但不同的问题。
第一个问题是范围问题：通道是否存储为 [0, 1] 或 [0, 255] 或 [0, 65535] 范围内的值。缩放（乘法和可能的钳位）是将一个范围转换为另一个范围的方法。
第二个问题是原始样本大小：您使用多少位来存储值。这不一定是范围大小的二进制对数。例如，如果您的范围是 [0, 255]，您可以将值存储在 8 位中，其中最低有效位表示增量 1，或存储在 6 位中，其中最低有效位表示增量 4，或者存储在 10 位中，其中最低有效位表示 0.25 的增量。事实上，正如我们将在下一期中看到的，增量不必固定。
第三个也是最后一个问题是编码问题：定点或浮点。当我们说我们将 [0, 255] 的值存储在 8 位中或将 [0, 65535] 的值存储在 16 位中时，我们通常指的是整数编码（固定点的一种特殊情况，其中最低有效位表示固定增量 1 ）。但是，当值存储在 [0, 1] 范围内时，无论原始样本大小如何，这通常意味着浮点存储（其中大多数位用于存储有效位，而保留一些位来存储与最低有效位相关的增量）。当我们谈到“半精度”、“单精度”、“双精度”、“扩展精度”等时，我们也总是指浮点编码。
所以这里有一个问题：OpenEXR 使用浮点编码，其格式不是大多数编程语言内置的。大多数现代语言只有 64 位浮点数，如果它们提供其他任何东西，通常是 32 位浮点数（分别double在floatC 系列中），但 16 位浮点数几乎从不开箱即用。
半精度可以表示 [-65505, 65504] 范围内的值，精度为 11 位（略好于 3 位十进制数字），同时还能够表示小至 2^-14 的值。但是，鉴于 OpenEXR 是一种 HDR 格式，您可能不会真正期望使用整个范围，因为选择数字编码是为了适应（极端）过度曝光或曝光不足。也就是说，除非您的相机实际上产生了如此巨大的动态值范围。
因此，您实际上可能不需要缩放通道值。但是，鉴于您已经从 [0, 1] 中的值开始，您可能将浮点数存储为单精度或双精度，您必须将它们转码为半精度。根据您使用的编程语言、库甚至硬件平台，可能会有现成的解决方案，或者您可能需要自己做一些小技巧。作为起点，我只能为您提供这个 DuckDuckGo 搜索。
我太累了，无法直接思考，但这可能会帮助您解决所有问题。我使用 ImageMagick 创建了三张 OpenEXR 图像，一张白色、一张黑色和一张红色，都是 1 像素 x 1 像素。
convert -size 1x1! xc:white white.exr
convert -size 1x1! xc:black black.exr
convert -size 1x1! xc:red red.exr
然后我把它们全部转储了：
xxd white.exr > white.txt
xxd black.exr > black.txt
xxd red.exr > red.txt
以下是文件：
白色.txt
0000000: 762f 3101 0200 0000 6368 616e 6e65 6c73 v/1.....channels
0000010: 0063 686c 6973 7400 4900 0000 4100 0100 .chlist.I...A...
0000020: 0000 0000 0000 0100 0000 0100 0000 4200 ..............B.
0000030: 0100 0000 0000 0000 0100 0000 0100 0000 ................
0000040: 4700 0100 0000 0000 0000 0100 0000 0100 G...............
0000050: 0000 5200 0100 0000 0000 0000 0100 0000 ..R.............
0000060: 0100 0000 0063 6f6d 7072 6573 7369 6f6e .....compression
0000070: 0063 6f6d 7072 6573 7369 6f6e 0001 0000 .compression....
0000080: 0000 6461 7461 5769 6e64 6f77 0062 6f78 ..dataWindow.box
0000090: 3269 0010 0000 0000 0000 0000 0000 0000 2i..............
00000a0: 0000 0000 0000 0064 6973 706c 6179 5769 .......displayWi
00000b0: 6e64 6f77 0062 6f78 3269 0010 0000 0000 ndow.box2i......
00000c0: 0000 0000 0000 0000 0000 0000 0000 006c ...............l
00000d0: 696e 654f 7264 6572 006c 696e 654f 7264 ineOrder.lineOrd
00000e0: 6572 0001 0000 0000 7069 7865 6c41 7370 er......pixelAsp
00000f0: 6563 7452 6174 696f 0066 6c6f 6174 0004 ectRatio.float..
0000100: 0000 0000 0080 3f73 6372 6565 6e57 696e ......?screenWin
0000110: 646f 7743 656e 7465 7200 7632 6600 0800 dowCenter.v2f...
0000120: 0000 0000 0000 0000 0000 7363 7265 656e ..........screen
0000130: 5769 6e64 6f77 5769 6474 6800 666c 6f61 WindowWidth.floa
0000140: 7400 0400 0000 0000 803f 0053 0100 0000 t........?.S....
0000150: 0000 0000 0000 0008 0000 0000 3c00 3c00 ............<.<.
0000160: 3c00 3c <.<
黑色.txt
0000000: 762f 3101 0200 0000 6368 616e 6e65 6c73 v/1.....channels
0000010: 0063 686c 6973 7400 4900 0000 4100 0100 .chlist.I...A...
0000020: 0000 0000 0000 0100 0000 0100 0000 4200 ..............B.
0000030: 0100 0000 0000 0000 0100 0000 0100 0000 ................
0000040: 4700 0100 0000 0000 0000 0100 0000 0100 G...............
0000050: 0000 5200 0100 0000 0000 0000 0100 0000 ..R.............
0000060: 0100 0000 0063 6f6d 7072 6573 7369 6f6e .....compression
0000070: 0063 6f6d 7072 6573 7369 6f6e 0001 0000 .compression....
0000080: 0000 6461 7461 5769 6e64 6f77 0062 6f78 ..dataWindow.box
0000090: 3269 0010 0000 0000 0000 0000 0000 0000 2i..............
00000a0: 0000 0000 0000 0064 6973 706c 6179 5769 .......displayWi
00000b0: 6e64 6f77 0062 6f78 3269 0010 0000 0000 ndow.box2i......
00000c0: 0000 0000 0000 0000 0000 0000 0000 006c ...............l
00000d0: 696e 654f 7264 6572 006c 696e 654f 7264 ineOrder.lineOrd
00000e0: 6572 0001 0000 0000 7069 7865 6c41 7370 er......pixelAsp
00000f0: 6563 7452 6174 696f 0066 6c6f 6174 0004 ectRatio.float..
0000100: 0000 0000 0080 3f73 6372 6565 6e57 696e ......?screenWin
0000110: 646f 7743 656e 7465 7200 7632 6600 0800 dowCenter.v2f...
0000120: 0000 0000 0000 0000 0000 7363 7265 656e ..........screen
0000130: 5769 6e64 6f77 5769 6474 6800 666c 6f61 WindowWidth.floa
0000140: 7400 0400 0000 0000 803f 0053 0100 0000 t........?.S....
0000150: 0000 0000 0000 0008 0000 0000 3c00 0000 ............<...
0000160: 0000 00 ...
红.txt
0000000: 762f 3101 0200 0000 6368 616e 6e65 6c73 v/1.....channels
0000010: 0063 686c 6973 7400 4900 0000 4100 0100 .chlist.I...A...
0000020: 0000 0000 0000 0100 0000 0100 0000 4200 ..............B.
0000030: 0100 0000 0000 0000 0100 0000 0100 0000 ................
0000040: 4700 0100 0000 0000 0000 0100 0000 0100 G...............
0000050: 0000 5200 0100 0000 0000 0000 0100 0000 ..R.............
0000060: 0100 0000 0063 6f6d 7072 6573 7369 6f6e .....compression
0000070: 0063 6f6d 7072 6573 7369 6f6e 0001 0000 .compression....
0000080: 0000 6461 7461 5769 6e64 6f77 0062 6f78 ..dataWindow.box
0000090: 3269 0010 0000 0000 0000 0000 0000 0000 2i..............
00000a0: 0000 0000 0000 0064 6973 706c 6179 5769 .......displayWi
00000b0: 6e64 6f77 0062 6f78 3269 0010 0000 0000 ndow.box2i......
00000c0: 0000 0000 0000 0000 0000 0000 0000 006c ...............l
00000d0: 696e 654f 7264 6572 006c 696e 654f 7264 ineOrder.lineOrd
00000e0: 6572 0001 0000 0000 7069 7865 6c41 7370 er......pixelAsp
00000f0: 6563 7452 6174 696f 0066 6c6f 6174 0004 ectRatio.float..
0000100: 0000 0000 0080 3f73 6372 6565 6e57 696e ......?screenWin
0000110: 646f 7743 656e 7465 7200 7632 6600 0800 dowCenter.v2f...
0000120: 0000 0000 0000 0000 0000 7363 7265 656e ..........screen
0000130: 5769 6e64 6f77 5769 6474 6800 666c 6f61 WindowWidth.floa
0000140: 7400 0400 0000 0000 803f 0053 0100 0000 t........?.S....
0000150: 0000 0000 0000 0008 0000 0000 3c00 0000 ............<...
0000160: 0000 3c ..<
diff white.txt black.txt
22,23c22,23
< 0000150: 0000 0000 0000 0008 0000 0000 3c00 3c00 ............<.<.
< 0000160: 3c00 3c <.<
---
> 0000150: 0000 0000 0000 0008 0000 0000 3c00 0000 ............<...
> 0000160: 0000 00
简短的回答是，这可能不会给你一个有用的结果。
中等长度的答案是，这种方法做出了许多关于图像处理根本不“安全”的假设。
主要假设是 255 的低动态范围值表示 65535 的 HDR 值。HDR 打算解决的主要问题是必须将现实世界的信号压缩到有限的范围内。想象一下直接拍摄太阳的数码照片：该光强度的输入值远远大于任何成像软件支持的值，因此必须以某种方式对其进行压缩。使用 LDR，太阳圆盘的中心和它周围的大部分光晕都将被钳制到 255。使用 HDR，你仍然在钳制，但只能到 65535。如果你有一个真实世界的信号，它给出的值如下200、255、300 和 100,000，然后将其限制为 255，这应该是有道理的，您不能简单地将 255 缩放到 65535 并获得合理的结果。255 可能已从 256、300 或 100000 中钳位；那里' 没办法知道。（这是对成像的彻底过度简化，但它应该足以特别理解这种限制）。
第二个假设是您在显示器上看到的内容与图像中的值有关。图像中 0 - 65535 的值范围必须在您的显示器上显示，这几乎肯定限于 sRGB 光谱 (255)。最有可能的是，如果您只是将 0-255 缩放到 0-65535，那么 99% 的范围都在 255 以上。因此，无论您的图像中有多少信息，很容易将所有信息剪裁为“白色”。 "
此外，根据 Photoshop（或 GPU 驱动程序或操作系统或显示面板）如何将您的 HDR 65535 转换为 sRGB，它很可能再次被限制为 255，或者可能“愚蠢”缩放，或者可能缩放“聪明地”或它们的任何组合。如果 Photoshop 将您的图像显示为纯白色，则您必须确认该过程中的多个步骤，以确定“谁”正在转换您的颜色值以及如何转换。Photoshop 可能会在发送到操作系统之前进行钳制。操作系统可能会在发送到 GPU 之前进行钳制。GPU 在发送到显示器时可能会卡住。打开像素时，显示器可能会钳位。...或在任何这些步骤中进行任何夹紧、缩放和转换的组合（我知道，
将 LDR 值转换为 HDR 色彩空间（反之亦然）是一项不平凡的追求，它本身就是一门学科。根据您的应用，您可能需要进行大量研究才能找到好的解决方案。