将[0,1]范围内的RGB值转换为高动态范围(EXR格式)
我只是需要一些澄清，如何正确地转换rgb像素值在范围0,1，以便在适当的范围内的HDR格式，如openEXR。
因此，我知道，例如，当使用低动态范围格式(如PNG或JPG，每个通道只有8位)时，您只需将每个rgb值乘以2^8-1 = 255，然后夹紧，使所有值都在0,255范围内。
OpenEXR和其他HDR格式使用半精度格式，每个通道16位。那么，我是否就像以前一样，把每个通道乘以2^16-1 = 65535，使我的新范围变成0,65535？
编辑
所以我试着做上面写的事情，但是当我试图在photoshop中显示openEXR文件时，它完全是白色的。似乎任何大于10左右的值都太亮了，无法让photoshop正确地显示出来，我觉得很奇怪。所以这看起来并不是正确的方法，除非照片商店的展示有问题。
回答 3
Stack Overflow用户
发布于 2014-08-09 12:18:08
我们同时处理三个相关但不同的问题。
第一个问题是range:是将通道作为值存储在范围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位浮点数(分别是C家族中的double和float )，但是16位浮点数几乎从来没有现成的。
半精度可以表示范围为65505,65504的值，精度为11位(略优于3位十进制数字)，同时也可以表示小到2^-14的值。但是，考虑到OpenEXR是一种HDR格式，您可能不会真正使用整个范围，因为选择数字编码是为了适应(极端)过曝光或曝光过低。也就是说，除非你的相机真的产生如此巨大的动态范围的值。
因此，您可能实际上不需要缩放您的频道值。但是，考虑到您已经以0，1中的值开始，您可能有单精度或双精度存储的浮点数字，您将不得不将它们转换为一半精度。取决于编程语言、库，甚至您使用的硬件平台，可能会有现成的解决方案，或者您可能需要自己做一些修改。作为一个起点，我只能为您提供这个DuckDuckGo搜索。
Stack Overflow用户
发布于 2014-08-13 21:05:18
我太累了，想都想不清楚，但这可能会帮你解决所有的问题。我用ImageMagick创建了三个OpenEXR图像，一个白色，一个黑色和一个红色，所有一个像素x1像素。
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以下是这些文件：
White.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 <.<Black.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 ...Red.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 00Stack Overflow用户
发布于 2021-06-03 16:58:57
简短的回答是，这可能不会给你一个有用的结果。
比较长的答案是，这种方法在图像处理方面做出了一些根本不“安全”的假设。
主要假设是，低动态范围值255表示HDR值为65535。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发送到显示器时可能会夹紧。当显示器打开像素时，它可能正在夹紧。...or任何一个步骤的夹紧、缩放和转换的组合(我知道，并不是所有这些组合实际上都是可能的，但关键是文件和眼球之间存在着大量的变化)。
将LDR值转换为HDR颜色空间(反之亦然)是一种非平凡的追求，它本身就是一门学科。根据您的应用程序，您可能需要做更多的研究，然后才能找到一个好的解决方案。
https://stackoverflow.com/questions/25145772
复制相似问题
腾讯云开发者
