[db:标题]

非局部均值滤波(Non Local Means）作为三大最常提起来的去燥和滤波算法之一（双边滤波、非局部均值、BM3D），也是有着很多的论文作为研究和比较的对象，但是也是有着致命的缺点，速度慢，严重的影响了算法的应用范围。目前在已有的文献中尚未看到在不对算法的本质原理上做更改的情况下，能取得实时的效果，本文呢，也不求得到这个目的，只是对现有的开放的资源上来取得更进一步的提升。 　　标准的NL-Means算法中，一般有三个参数，搜索半径SearchRadius，块半径PatchRadius，以及一个决定平滑程度的高斯函数参数Delta。在百度上能够搜索到的大部分文章所描述的提速算法都是使用积分图来提升NL-Means的速度，这也是目前来说唯一比较靠谱的优化技术，通过积分图，可以做到算法和块半径PatchRadius的大小基本无关，和Delta也无关，和SearchRadius成平方关系。 　　因此，在我们很多的严重的噪音图像中，SearchRadius至少需要取到7以上（涉及15*15= 225个领域范围）才有明显的效果，因此，这就相当于要计算225次全图的某种计算，即使是每次这种计算只需要1ms（通常，任何图像处理算法无法超越同等内存大小的memcpy的大小的），也需要225ms的，因此，确实比较感尴。 　　通过多线程方式可以适当对这个过程进行加速，毕竟每个像素点的处理相对来说还是独立的，但是，这个加速也收到物理核心的限制，就是8核的机器，满利用，也无法达到8倍的加速效果。 话说回来，这么大的计算量，用GPU也都是很吃力的。 　　目前使用积分图来记性NL-Means算法的比较好的文章也是大家常看的还是这一篇： 　　　　　非局部均值滤波（NL-means）算法的积分图加速原理与C++实现 　　其实积分图一直有个问题，可能很多搞图像的人都没有注意到，或者说这个问题可能对某些算法的影响还不是很大，不足有对大家注意到或者关注到，即积分图存在着一下2个方面的问题和缺点： 　　1、当图像较大时，积分图无法使用int类型来保存，我们必须选择能够容纳更大数据范围的数据类型来存储。 　　如果我们保存的是一副字节图像的积分图，考虑极端情况，每个图像的值都是255，则积分图像最多只可保存uint.Maxvalue / 255 = 16843009个像素，大约4100*4100大小的图像，一般来说，这个规模对于实际的应用来说是足够了。 　　但是我们在实际中用到的很多情况，不是直接的图像积分图，还常用的有平方积分图，即求图像平方值后的积分图，这个时候每一个元素的最大值达到了65025，极限情况下uint类型只可保存uint.Maxvalue / 255 =66051个元素的总和，只大概是指256*256个图像的大小了，已经远远的无法满足实际的应用需求。 　　因此，为了实现这个要求，我们必须选择能够容纳更大数据范围的数据类型，这里有三个选择：long long(int64) / float / double 　　第一个long long类型，即64位的整形数据，这个数据的表达范围已经完全够我们在图像中使用积分图了，而且保存的数据是非常准确的，特别是对于图像方面的数据来说（都是整形的），但是有个致命的问题： 速度相当相当的慢，特别是同样的计算和int类型比较的话，那真的不是一个档次上的。我一直不太理解，现在大部分都是64位系统，为什么对64位的数据的支持还是这么的弱。而且我们看大部分指令集优化的函数对64位整形的支持都比较少。因此，非常不建议使用这个类型。 　　第二个float类型。如果使用这个类型，保存的数据范围是没有什么大的问题的，我们在网络上看到的文章大部分也是使用这个类型来保存结果的。但是，我在实践中多次遇到用float类型得不到正确的结果的问题，后来发现核心的原因是float的计算精度严重不足，特别是对于积分图这种连续的加法的计算，累计误差会越来越严重，当计算量足够大时，就会出现明显的误差瑕疵。因此，这个数据类型从本质上来说，对积分图是不够安全的。 　　关于这一点，实际上已经有不少作者注意到了，我在博文：SSE图像算法优化系列十四：局部均方差及局部平方差算法的优化中也有提及。 　　第三个是double类型，这个类型也是64位的，因此，数据范围毫无问题，计算精度经过测试，也是没有什么问题的，而且，编译器和指令集的支持和优化做的都还很不错， 因此，个人认为这个数据类型是用来保存积分图最为合适的类型，但是有一个不友好的特点，计算速度慢，而且指令集对其能加速的空间有限。