记录一个C++操作8位影像的一个bug

Bug描述

接到反馈，说我的程序输出影像有空洞，如图

arcmap上看白色的区域RGB对应的都是0，0，0

我想起代码中难道没有进行判断，对于8位影像，如果像素值为0，就将它置1，避免出现空洞情况。

代码核查

代码截图如下：

代码中本来就有了对8位值像素的判断，为何输出像素值还有0，这是不可能出现的事情。但是现在就是出现了。我以为是其他地方代码有问题，到处排查没有其他相关代码，最核心的地方就在这里。

修改验证

我只做了一个修改，将dstValue用int强转一下，验证代码如下：

dstValue=int(pow(dstValue,LightScale));

经过重新编译，测试验证，输出影像正常了，没有RGB都是0，0，0的问题了，最小都是1，1，1

分析

我修改的动机

为什么这么改，因为我仔细盘算了一下dstValue 是double类型，dstimg数组是unsigned char* 类型 ，所以我感觉是否这个dobule数据转到unsigned char出了问题，为啥会出现0，我怎么也想不到，只是为了验证是否这个问题。最后问题就这样解决了。

豆包分析原因

因为这个问题的确不知道为啥，想让豆包帮我分析。所以描述完问题后，她回到如下：

我的总结

其实豆包分析的很牵强，如果说是小于0，我用逻辑判断就已经置1了，但如果我置1了，为什么最终转换结果还是0。
另外豆包说是小概率事件发生了，为啥客户那边机器出现这个问题，我这边可以完全复现，所以这不是小概率事件，而是必然事件。
我自己的总结很可能是：我发布的是release版本程序，编译器的优化导致的double到unsigned char转换问题。另外用豆包推荐的代码建议也测试了，比较精简，输出影像也正常。
对我的收货：以后在数据类型转换的时候多留个心眼