SSE图像算法优化系列五:超高速指数模糊算法的实现和优化(10000*10000在100ms左右实现)。

      今天我们来花点时间再次谈谈一个模糊算法,一个超级简单但是又超级牛逼的算法,无论在效果上还是速度上都可以和Boxblur, stackblur或者是Gaussblur想媲美,效果上,比Boxblur来的更平滑,和Gaussblur相似,速度上,经过我的优化,在PC端比他们三个都要快一大截,而且基本不需占用额外的内存,实在是一个绝好的算法。

      算法的核心并不是我想到或者发明的,是一个朋友在github上挖掘到的,率属于Cairo这个2D图形库的开源代码,详见:

https://github.com/rubencarneiro/NUX/blob/master/NuxGraphics/CairoGraphics.cpp

       我们称之为Exponential blur(指数模糊)。

       提炼出这个模糊的核心部分算法主要是下面这个函数:

   static inline void _blurinner(guchar* pixel, gint* zR,gint* zG,gint* zB, gint* zA, gint alpha,gint aprec,gint zprec)
  {
    gint R, G, B, A;
    R = *pixel;
    G = *(pixel + 1);
    B = *(pixel + 2);
    A = *(pixel + 3);

    *zR += (alpha * ((R << zprec) - *zR)) >> aprec;
    *zG += (alpha * ((G << zprec) - *zG)) >> aprec;
    *zB += (alpha * ((B << zprec) - *zB)) >> aprec;
    *zA += (alpha * ((A << zprec) - *zA)) >> aprec;

    *pixel       = *zR >> zprec;
    *(pixel + 1) = *zG >> zprec;
    *(pixel + 2) = *zB >> zprec;
    *(pixel + 3) = *zA >> zprec;
  }

    其中Pixel就是我们要处理的像素,zR,zG,zB,zA是外部传入的一个累加值,alpha、aprec、zprec是由模糊半径radius生成的一些固定的系数。

  类似于高斯模糊或者StackBlur,算法也是属于行列分离的,行方向上,先用上述方式从左向右计算,然后在从右向左,接着进行列方向处理,先从上向下,然后在从下向上。当然,行列的计算也可以反过来。需要注意的是,每一步都是用之前处理过的数据进行的。

  在源代码中用以下两个函数实现以下过程:

     水平反向的处理:

  static inline void _blurrow(guchar* pixels,
                               gint    width,
                               gint    /* height */,  // TODO: This seems very strange. Why is height not used as it is in _blurcol() ?
                               gint    channels,
                               gint    line,
                               gint    alpha,
                               gint    aprec,
                               gint    zprec)
  {
    gint    zR;
    gint    zG;
    gint    zB;
    gint    zA;
    gint    index;
    guchar* scanline;

    scanline = &(pixels[line * width * channels]);

    zR = *scanline << zprec;
    zG = *(scanline + 1) << zprec;
    zB = *(scanline + 2) << zprec;
    zA = *(scanline + 3) << zprec;

    for (index = 0; index < width; index ++)
      _blurinner(&scanline[index * channels], &zR, &zG, &zB, &zA, alpha, aprec,
      zprec);

    for (index = width - 2; index >= 0; index--)
      _blurinner(&scanline[index * channels], &zR, &zG, &zB, &zA, alpha, aprec,
      zprec);
  }

  垂直方向的处理:

static inline void _blurcol(guchar* pixels,
                               gint    width,
                               gint    height,
                               gint    channels,
                               gint    x,
                               gint    alpha,
                               gint    aprec,
                               gint    zprec)
  {
    gint zR;
    gint zG;
    gint zB;
    gint zA;
    gint index;
    guchar* ptr;

    ptr = pixels;

    ptr += x * channels;

    zR = *((guchar*) ptr    ) << zprec;
    zG = *((guchar*) ptr + 1) << zprec;
    zB = *((guchar*) ptr + 2) << zprec;
    zA = *((guchar*) ptr + 3) << zprec;

    for (index = width; index < (height - 1) * width; index += width)
      _blurinner((guchar*) &ptr[index * channels], &zR, &zG, &zB, &zA, alpha,
      aprec, zprec);

    for (index = (height - 2) * width; index >= 0; index -= width)
      _blurinner((guchar*) &ptr[index * channels], &zR, &zG, &zB, &zA, alpha,
      aprec, zprec);
  }

 最终的模糊算法如下所示:

  // pixels   image-data
  // width    image-width
  // height   image-height
  // channels image-channels
  // in-place blur of image 'img' with kernel of approximate radius 'radius'
  // blurs with two sided exponential impulse response
  // aprec = precision of alpha parameter in fixed-point format 0.aprec
  // zprec = precision of state parameters zR,zG,zB and zA in fp format 8.zprecb  void _expblur(guchar* pixels,
                 gint    width,
                 gint    height,
                 gint    channels,
                 gint    radius,
                 gint    aprec,
                 gint    zprec)
  {
    gint alpha;
    gint row = 0;
    gint col = 0;

    if (radius < 1)
      return;

    // calculate the alpha such that 90% of 
    // the kernel is within the radius.
    // (Kernel extends to infinity)
    alpha = (gint) ((1 << aprec) * (1.0f - expf(-2.3f / (radius + 1.f))));

    for (; row < height; row++)
      _blurrow(pixels, width, height, channels, row, alpha, aprec, zprec);

    for (; col < width; col++)
      _blurcol(pixels, width, height, channels, col, alpha, aprec, zprec);

    return;
  }

  作为一个典型的应用,或者说尽量减少参数,常用的aprec取值为16,Zprec 取值为7。

     回顾下代码,整体过程中除了alpha参数的计算涉及到了浮点,其他部分都是整形的乘法和移位操作,因此可以想象,速度应该不慢,而且非常适合于手机端处理。同时注意到_blurrow和_blurcol函数循环明显相互之间是独立的,可以利用多线程并行处理,但是这个代码主要是专注于算法的表达,并没有过多的考虑更好的效率。

     另外一点,很明显,算法的耗时是和Radius参数没有任何关系的,也就是说这也是个O(1)算法。

  我们稍微对上述代码做个简化处理,对于灰度图,水平方向的代码可以表述如下:

for (int Y = 0; Y < Height; Y++)
{
    byte *LinePS = Src + Y * Stride;
    byte *LinePD = Dest + Y * Stride;
    int Sum = LinePS[0] << Zprec;
    for (int X = 0; X < Width; X++)      //  从左往右
    {
        Sum += (Alpha * ((LinePS[X] << Zprec) - Sum)) >> Aprec;
        LinePD[X] = Sum >> Zprec;
    }
    for (int X = Width - 1; X >= 0; X--)   //  从右到左
    {
        Sum += (Alpha * ((LinePD[X] << Zprec) - Sum)) >> Aprec;
        LinePD[X] = Sum >> Zprec;
    }
}

在 高斯模糊算法的全面优化过程分享(一) 中我们探讨过垂直方向处理算法一般不宜直接写,而应该用一个临时的行缓存进行处理,这样列方向的灰度图的处理代码类似下面的:

int *Buffer = (int *)malloc(Width * sizeof(int));
for (int X = 0; X < Width; X++)        Buffer[X] = Src[X] << Zprec;
for (int Y = 0; Y < Height; Y++)
{
    byte *LinePS = Src + Y * Stride;
    byte *LinePD = Dest + Y * Stride;
    for (int X = 0; X < Width; X++)        //  从上到下
    {
        Buffer[X] += (Alpha * ((LinePS[X] << Zprec) - Buffer[X])) >> Aprec;
        LinePD[X] = Buffer[X] >> Zprec;
    }
}
for (int Y = Height - 1; Y >= 0; Y--)      //  从下到上
{
    byte *LinePD = Dest + Y * Stride;
    for (int X = 0; X < Width; X++)
    {
        Buffer[X] += (Alpha * ((LinePD[X] << Zprec) - Buffer[X])) >> Aprec;
        LinePD[X] = Buffer[X] >> Zprec;
    }
}
free(Buffer);

修改为上述后,测试一个3000*2000的8位灰度图,耗时大约52ms(未使用多线程的),和普通的C语言实现的Boxblur时间差不多。

       除了线程外,这个时间是否还有改进的空间呢,我们先来看看列方向的优化。

   在列方向的  for (int X = 0; X < Width; X++) 循环内,我们注意到针对Buffer的每个元素的处理都是独立和相同的,很明显这样的过程是很容易使用SIMD指令优化的,但是循环体内部有一些是unsigned char类型的数据,为使用SIMD指令,需要转换为int类型较为方便,而最后保存时又需要重新处理为unsigned char类型的,这种来回转换的耗时和其他计算的提速能否来带来效益呢,我们进行了代码的编写,比如:

    for (int X = 0; X < Width; X++)        //  从上到下
    {
        Buffer[X] += (Alpha * ((LinePS[X] << Zprec) - Buffer[X])) >> Aprec;
        LinePD[X] = Buffer[X] >> Zprec;
    }

  这段代码可以用如下的SIMD指令代替:

int X = 0;
for (X = 0; X < Width - 8; X += 8)            
{
    //    将8个字节数存入到2个XMM寄存器中
    //    方案1:使用SSE4新增的_mm_cvtepu8_epi32的函数,优点是两行是独立的
    __m128i Dst1 = _mm_cvtepu8_epi32(_mm_cvtsi32_si128((*(int *)(LinePD + X + 0))));    //    _mm_cvtsi32_si128把参数中的32位整形数据移到XMM寄存器的最低32位,其他为清0。
    __m128i Dst2 = _mm_cvtepu8_epi32(_mm_cvtsi32_si128((*(int *)(LinePD + X + 4))));    //    _mm_cvtepu8_epi32将低32位的整形数的4个字节直接扩展到XMM的4个32位中去。
    __m128i Buf1 = _mm_loadu_si128((__m128i *)(Buffer + X + 0));
    __m128i Buf2 = _mm_loadu_si128((__m128i *)(Buffer + X + 4));
    Buf1 = _mm_add_epi32(_mm_srai_epi32(_mm_mullo_epi32(_mm_sub_epi32(_mm_slli_epi32(Dst1, Zprec), Buf1), Alpha128), Aprec), Buf1);
    Buf2 = _mm_add_epi32(_mm_srai_epi32(_mm_mullo_epi32(_mm_sub_epi32(_mm_slli_epi32(Dst2, Zprec), Buf2), Alpha128), Aprec), Buf2);
    _mm_storeu_si128((__m128i *)(Buffer + X + 0), Buf1);
    _mm_storeu_si128((__m128i *)(Buffer + X + 4), Buf2);
    _mm_storel_epi64((__m128i *)(LinePD + X), _mm_packus_epi16(_mm_packs_epi32(_mm_srai_epi32(Buf1, Zprec), _mm_srai_epi32(Buf2, Zprec)), Zero));
}
for (; X < Width; X++)        
{
    Buffer[X] += (Alpha * ((LinePD[X] << Zprec) - Buffer[X])) >> Aprec;
    LinePD[X] = Buffer[X] >> Zprec;
}

  原来的三四行代码一下子变成了几十行的代码,会不会变慢呢,其实不用担心,SIMD真的很强大,测试的结果是3000*2000的图耗时降低到42ms左右,而且垂直方向的耗时占比有原先的60%降低到了35%左右,现在的核心就是水平方向的耗时了。

     当图像不是灰度模式时,对于垂直方向的处理和灰度不会有区别,这是因为,只需要增加循环的长度就可以了。

     我们再来看看水平方向的优化,当图像是ARGB模式时,也就是原作者的代码,计算过程每隔四个字节就会重复,这种特性当然也适合SIMD指令,但是为了方便,必须得先将字节数据先转换为int类型的一个缓冲区中,之后从左到右的计算可以用如下的代码实现:

void ExpFromLeftToRight_OneLine_SSE(int *Data, int Length, int Radius, int Aprec, int Zprec, int Alpha)
{
    int *LinePD = Data;
    __m128i A = _mm_set1_epi32(Alpha);
    __m128i S1 = _mm_slli_epi32(_mm_load_si128((__m128i *)(LinePD)), Zprec);
    for (int X = 0; X < Length; X++, LinePD += 4)
    {
        S1 = _mm_add_epi32(S1, _mm_srai_epi32(_mm_mullo_epi32(_mm_sub_epi32(_mm_slli_epi32(_mm_load_si128((__m128i *)(LinePD)), Zprec), S1), A), Aprec));
        _mm_store_si128((__m128i *)(LinePD), _mm_srai_epi32(S1, Zprec));
    }
}

  在计算完成后结果也会在这个int类型的缓冲区中,之后再用SSE函数转换为int类型的。

      前后两次这种类型的转换的SSE实现速度非常快,实现之后的提速也非常明显,对3000*2000的32位图像耗时大约由150ms降低到50ms,提速很明显。

      但是对于24位怎么办呢,他的计算过程是3个字节重复的,无法直接利用SIMD的这种优化的方式的,同高斯模糊算法的全面优化过程分享(一) 一文类似,我们也是可以把24位的图像补一个Alpha通道然后再转换到int类型的缓冲区中,所以问题解决。

      最难的是灰度图,因为灰度图的计算过程是单字节重复的,正如上述代码所示,24位补一位的代价是多1个元素的计算,但是SIMD能一次性计算4个整形的算法,因此还是很划算的,如果灰度也这样玩,SIMD的提速和浪费的计算句完全抵消了,而且还增加了转换时间,肯定是不合适的,但是我们可以转变思路,一行内各个元素之间的计算是连续的,但是如果我把连续4行的数据混搭为一行,混搭成类似32位那种数据格式,不就是能直接使用32位的算法了吗,最后再拆解回去就OK了。

     比例来说,四行灰度数据如下

     A1 A2 A3 A4 A5 A6 A7......

     B1 B2 B3 B4 B5 B6 B7......

     C1 C2 C3 C4 C5 C6 C7......

     D1 D2 D3 D4 D5 D6 D7......

  混搭为:

     A1 B1 C1 D1 A2 B2 C2 D2 A3 B3 C3 D3 A4 B4 C4 D4 A5 B5 C5 D5 A6 B6 C6 D6 A7 B7 C7 D7.........

   如果直接使用普通C语言混搭,这个过程还是相当耗时的,当然也必须的用SSE实现,大家如果仔细看过我图像转置的SSE优化(支持8位、24位、32位),提速4-6倍一文的代码,这个过程实现也很容易。

 有的时候思路真的很重要。

在进行了上面的优化后,我曾自我满足过一段时间,因为他的时间已经在一定程度上超越了SSE优化版本的Boxblur,但是俗话说,处处留心皆学问、开卷有益。当某一天我注意到aprec的值为16加上>>aprec这个操作时,我们脑海中就崩出了一个很好的SSE指令:_mm_mulhi_epi16,你们看,一个int类型右移16位不就是取int类型的高16位吗,而在移16位的之前就是个乘法,也就是要进行(a*b)>>16,这个和_mm_mulhi_epi16指令的意思完全一致。 

但是使用_mm_mulhi_epi16指令前,我们应该确认下本场景能不能满足数据范围的需求,我们看看需要优化的那句代码

       (Alpha * ((LinePD[X] << Zprec) - Buffer[X])) >> Aprec

     经过测试,只有radius小于2时,这个alpha会大于short能表达的上限,而(LinePD[X] << Zprec) - Buffer[X])这句中LinePD[X]范围是[0,255],Zprec为7,两者相乘的范围不会超过32767,而Buffer[X]是个递归的量,只要第一次不超过32767,后面就不会超过,因此两者的差也不会小于short能表达的下限。所以说只要radius大于2,这个算式完全符合_mm_mulhi_epi16指令的需求。

由于_mm_mulhi_epi16一次性可以处理8个short类型,其他相应的SSE指令也同时更改为16位的话,理论上又会比用32位的SSE指令快一倍,更为重要的是,我们前期的int缓冲区也应该改为short类型的缓冲区,对于这种本身耗时就不太多的算法,LOAD和Store指令的耗时是非常值得注意,使用short类型时这个和内存打交道的效率又同步提高了。

     值得注意的是改为16位后,无论是32位、24位还是灰度的,写入到缓冲区的数据格式都会有相关的改变(其实还是有很多很多技巧我这里没有表达的)。

     最终:3000*2000的灰度图的执行时间为 7-8ms,提高了7倍左右。

     本文不分享最终优化的代码,请各位参考本文有关思路自行实现。

     一个测试比较工程:

http://files.cnblogs.com/files/Imageshop/SSE_Optimization_Demo.rar

上述界面里的算法都是经过了SSE优化的,最近一直在研究这方面的东西,又心得就会到这里来记录一下。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏MelonTeam专栏

视频编解码学习分享

要解决视频存储难、传输难的问题,综合考虑软硬件成本,最有效的办法应该是压缩视频体积!

1.3K14
来自专栏蜉蝣禅修之道

网络流算法Dinic的Python实现

964
来自专栏MasiMaro 的技术博文

Windows程序设计学习笔记(四)自绘控件与贴图的实现

Windows系统提供大量的控件供我们使用,但是系统提供的控件样式都是统一的,不管什么东西看久了自然会厌烦,为了使界面更加美观,添加一些新的东西我们需要自己绘制...

752
来自专栏顶级程序员

Caffe源码直播

0.预告 开源项目名称:Caffe—— deep learning framework 语言:C++ 时间:10月22日(周六)早11:00-12:00 参与方...

3928
来自专栏腾讯Bugly的专栏

WebP原理和Android支持现状介绍

1.背景 目前网络中图片仍然是占用流量较大的一部分,对于移动端更是如此,因此,如何在保证图片视觉不失真前提下缩小体积,对于节省带宽和电池电量十分重要。 然而目前...

5487
来自专栏专知

【读书笔记】基于知识库的问答:生成查询图进行语义分析

【导读】将DBPedia和Freebase这样的大规模知识库组织并存储在一个结构化的数据库,这已成为支持开放领域问题问答的重要资源。 KB-QA的大多数方法基于...

3197
来自专栏人工智能LeadAI

TensorFlow和Keras解决大数据量内存溢出问题

以前做的练手小项目导致新手产生一个惯性思维——读取训练集图片的时候把所有图读到内存中,然后分批训练。

1794
来自专栏QQ音乐技术团队的专栏

动态图片技术 : 历史、格式与性能

本文主要内容为动态图片的定义、发展历史与现状,动态图片相关的术语和概念,动态图片各主要格式,及简要对比,在 Android 平台对比 GIF 与 WebP 格式...

1780
来自专栏SDNLAB

SDN应用路由算法实现工具之Networkx

SDN(Software Defined Networking)是一种新型的网络架构,通过集中式的控制平面管理数据层面的转发等操作。网络的连通性是最基础的需求,...

2749
来自专栏智能算法

小波变换通俗解释版

从傅里叶变换到小波变换,并不是一个完全抽象的东西,可以讲得很形象。小波变换有着明确的物理意义,如果我们从它的提出时所面对的问题看起,可以整理出非常清晰的...

2856

扫码关注云+社区