这个好像没有啥对应的论文可以找到，在百度上搜索也能找到一些相关的资料，不过就直接是代码，可以看到其实来自于一个叫做DScaler的项目，在github上目前还能找到该项目的完整资料。
详见：https://github.com/JohnAdders/DScaler/tree/f7d92b76678e24422c48d4a956c0486ee042786d
其中含有FLT_GradualNoise.c文件，我们复制以下代码的注释部分对算法的解释：
This algorithm is very similar to what Andrew Dowsey came up with in his "Adaptive Temporal Averaging" for his DirectShow filter. The algorithms differ in 1) their block size, 2) their motion estimation(sum of absolute differences versus mean squared error), 3) The addition of a "high tail," in which areas which have changed a lot(but not too much) still cause a small amount of averaging with the previous rame, and 4) rounding.
The algorithm :
This filter gets the sum of absolute differences between a four pixel horizontal block in the current image and the same block in the preceding frame.This isn't the best local motion measure, but it's very fast due to the psadbw SSE instruction.
This difference measure is used to determine the kind of averaging which will be conducted.If it's more than the "noise reduction" parameter, motion is inferred.In that case, we just use the new pixel values.If it's less than the noise reduction, we use the ratio of(difference / noise reduction) to determine the weighting of the old and new values.
Somewhat more formally :
N = Sum_block(| oldByte - newByte | )
R = Noise Reduction parameter
M = (motion evidence) = 1 if N / R >= 1.2
0.999 if 1.2 > N / R >= 1
N / R otherwise
Result pixel = (bytewise)oldPixel * (1 - M) newPixel * M
Rounding has a very significant effect on the algorithm.In general, for computational reasons, values are rounded down.An important exception occurs when M > 0 and oldPixel != newPixel
but
oldPixel * (1 - M) newPixel * M
rounds to oldPixel.In that case, the Result pixel is rounded to one toward the newPixel value.This makes sure that very gradual variation is maintained.
针对这个算法，作者提供了相关的汇编代码，而且进行了非常详细的注释，但是这个汇编还不是普通的汇编，而是用的SIMD指令，因此，对于阅读来说就非常的困难了，我大概花了10天左右，理解其思路，并用更加容易东的Intrinsic进行了重写和优化。下面是一些编写时的疑惑和解读，共享下。
代码语言：javascript复制// 疑点1： 对于YUV数据，这个程序是如何处理的？
// 答复： 从原始的汇编代码看，他对YUV分量是同步处理的，并没有做特别的区分，前面说的四个像素，指的意思就是Y0 U0 Y1 V0 Y2 U1 Y3 V1这4个像素，不管是MMX指令还是SSE指令
// 他们的psadbw指令都是一次性执行八个字节数据的绝对值累加（SSE指令一次性执行2个8个字节的累加而已）。如果把这个算法换成RGB格式的数据，那范围要麻烦了，要拆分RGB到各个独立的分量了。
// 疑点2： 上面提及默认的Rounding是向下的，但是一般要求只要Src和Prev有差异，就至少要向新像素有1个像素的偏移，以保证视频的连续性，如何实现的。
// 答复： 程序里对数据进行了判断，如果Src和Prev不同，则设置偏移量至少是1（正1和负1都可以）,相同的话偏移量当然为0了。
// 另外，如果定点化后的偏移量大于65535，则设置偏移量为AbsDiff值，因为这个时候的由于程序移位计算的原因，直接算的值还会少1的。 (X * 65535) >> 16结果会为X - 1
// 疑点3： 程序是如何进行优化的？
// 答复： (1) 在原始的代码中，有这个0.999 if 1.2 > N / R >= 1，在作者提供的汇编代码中，对这部分做了处理，他是通过一些比较和移位来实现的，把NoiseMultiplier更改为65534了（N/R>=1,就已经设为65535了)
// 在本代码中，个人觉得这个判断毫无必要，0.999对结果的影响太小了，因此舍弃了，在作者提供的SSE和MMX代码中，这个也舍弃了。
// (2) 定点化，程序中N/R涉及到除法运算，为了减少这个，我们将整体扩大65536倍，然后再乘以AbsDiff，这个时候需要除以65536，这样可以利用_mm_mulhi_epu16来快速实现（不需要特别的移位指令了，也不需要转换到32位）
// 但是实际上，这里是有误差的，因为这个函数不能做到四舍五入，建议使用_mm_mulhrs_epi16代替。同时注意如果N/R * 65536如果大于65535了，就对于了原始算式中的M=1了 ,这个时候就把他直接限定为65535了（不需要转换到32位了）
// 举个例子，如果AbsDiff_Sum = 24，NoiseValue取值64，此时Multiplier的值为1024，则如果某个像素的newPixel - oldPixel = 10，则结果为 (24 * 1024 * 10) >> 16 = 3,但是实际的浮点为3.75，理论上应该取4更为合适。
// (3) oldPixel * (1 - M) newPixel * M经过整理可以变为 oldPixel (newPixel - oldPixel) * M, 此时配合newPixel - oldPixel的符号特性，可以使用_mm_adds_epu8和_mm_subs_epu8来实现最后的结果计算总的来说这个算法，还是利用历史帧的数据不断的来平均误差，减少视频的噪音的，但是其可以充分利用快速计算8个字节数据的累加值的指令_mm_sad_epu8，可以达到非常恐怖的计算效率和速度。
测试1280*720大小视频，去噪平均一帧约0.8ms，1920*1080视频一帧需要约1.8ms（均位YUV422格式视频）。
由于这里上传不了视频，有需要了解该算法效果的，可以单独联系我，我可以提供个测试DEMO（DEMO太大，无法上传），下面截两张图可以稍微看到区别。
