1. 认识Radiance RGBE：HDR图像的"瘦身专家"
第一次接触.hdr文件时，我盯着那张只有几MB大小的环境贴图百思不得其解——这么小的文件怎么能存储如此丰富的光照信息？直到拆解了RGBE格式才恍然大悟。这种诞生于1980年代的图像格式，就像个精明的会计，用8位整数就能记录下太阳直射（亮度可能超过100,000尼特）到月光照射（可能只有1尼特）的超宽动态范围。
核心原理其实很巧妙：把32位浮点数的RGB值压缩成4个8位字节（R、G、B三个颜色通道+E指数通道）。想象你记录宇宙飞船的飞行日志，直接记录具体位置需要大量数字，但如果记录"地球向东飞行3光年"，就能用很少的数据表达极大范围。RGBE的E通道就是这个"3光年"的指数部分，而RGB则是归一化后的尾数。
实际解析时，文件头会暴露关键信息。比如这个典型头：
#?RADIANCE FORMAT=32-bit_rle_rgbe EXPOSURE=1.0 -Y 1024 +X 2048第二行明确声明了RGBE格式，最后一行用"-Y +X"的奇特语法声明图像尺寸（这里表示2048x1024）。我曾遇到过解析失败的情况，后来发现是某些生成器会在尺寸行末尾漏掉换行符，导致解析器误读数据起始位置。
2. 从文件到显存：解码实战全流程
2.1 文件读取与内存布局优化
用C++实现解码器时，直接fopen读取会踩不少坑。实测发现最稳健的方式是：
std::ifstream file(filename, std::ios::binary); file.seekg(0, std::ios::end); size_t size = file.tellg(); file.seekg(0, std::ios::beg);先获取文件总大小可以快速验证文件完整性——一个2048x1024的未压缩RGBE文件应该是2048×1024×4=8,388,608字节。如果文件明显小于这个值，可能是RLE压缩过的（这时文件头会有"RLE"标识）。
内存布局对性能影响巨大。早期我简单用vector存储解码后的FP32数据，后来改用SoA（Structure of Arrays）布局：
struct HDRImage { std::vector<float> r_channel; std::vector<float> g_channel; std::vector<float> b_channel; int width, height; };这样在GPU上传时可以直接用glTexImage2D分别处理每个通道，避免了AoS（Array of Structures）布局的缓存命中问题。某次性能测试显示，在4K纹理上传时，SoA比传统交错布局快17%。
2.2 核心解码算法实现
RGBE转FP32的公式看似简单：
float scale = ldexp(1.0f, e - (128 + 8)); r = r * scale; g = g * scale; b = b * scale;但魔鬼在细节里。遇到过三个典型问题：
- 除零保护：当e=0时应该直接返回0，但某些老旧文件会有e=0但rgb非0的脏数据
- 范围检查：部分生成器会产生e>255的溢出值，需要clamp到合理范围
- 快速实现：用查表法替代ldexp能提升3倍速度（见下表对比）
| 方法 | 耗时(ms/4K图) | 指令数 |
|---|---|---|
| ldexp标准库 | 12.3 | 320M |
| 查表法 | 4.1 | 110M |
| SIMD优化 | 2.7 | 65M |
查表法的秘诀是预计算2^(n-136)的所有可能值（n∈[0,255]），虽然会多用256*4=1KB内存，但避免了昂贵的指数运算。
3. 现代渲染管线中的生存之道
3.1 与IBL管线的无缝衔接
在Unity中加载HDR环境贴图时，传统做法是：
Texture2D hdrTex = new Texture2D(width, height, TextureFormat.RGBAFloat, false); hdrTex.LoadRawTextureData(floatData);但更高效的方式是利用ComputeShader在GPU端直接解码：
// Compute Shader核心代码 float3 DecodeRGBE(uint4 rgbe) { float exponent = rgbe.a - 128.0 - 8.0; float scale = exp2(exponent); return float3(rgbe.rgb) * scale; }实测在RTX 3080上，GPU解码比CPU解码快40倍，而且省去了CPU→GPU的数据传输。不过要注意，某些移动GPU的浮点精度不足，可能需要改用half精度存储中间结果。
3.2 内存与显存的平衡术
RGBE最妙的地方在于运行时内存占用仅为FP32的25%。我曾处理过一个需要同时加载50张4K HDR贴图的建筑可视化项目，对比方案如下：
| 格式 | 内存占用 | 加载时间 | 渲染质量 |
|---|---|---|---|
| FP32 EXR | 6.4GB | 28s | 完美 |
| RGBE | 1.6GB | 9s | 轻微色带 |
| BC6H | 0.8GB | 3s | 块状瑕疵 |
最终采用混合方案：关键贴图用RGBE，次要贴图用BC6H压缩。这里有个技巧——用mipmap的层级控制质量，前4级用RGBE，后面用BC6H，这样在远处物体上几乎看不出区别。
4. 格式对比与未来演进
虽然RGBE已年近四十，但在某些场景仍不可替代。与新兴格式的对比：
| 特性 | RGBE | EXR | KTX2 |
|---|---|---|---|
| 动态范围 | 10^76 | 10^76 | 10^76 |
| 通道数 | 3 | 任意 | 任意 |
| 压缩率 | 4:1 | 2:1~10:1 | 4:1~20:1 |
| 硬件支持 | 无 | 部分 | 广泛 |
| 编解码速度 | 极快 | 慢 | 快 |
最近在Vulkan项目中发现，用KHR_texture_compression_astc_hdr扩展可以直接加载ASTC HDR纹理，其压缩率是RGBE的5倍。但修改现有管线时要注意：ASTC的色度抽样会改变颜色分布，在PBR材质中需要重新校准镜面反射的亮度阈值。
