GDI+、FFMPEG图像放大算法性能比较
最近在做link的时候要放大图片,使用了传说中gdi+最好的高质量双三次插值算法,然后在连续放大时就卡成幻灯片了。试了其他几个算法,发现卡顿情况有缓解,显示效果也没什么差别(也可能是我眼瘸,不过天天看mac的ios工程师看了也说没什么区别)。所以对GDI+中的9中插值算法做个性能比较。
测试方法:
使用的原图为1920*1080的24位jpg图片,分别用9中插值算法进行1.5、2、2.5、3、3.5、4、4.5、5、5.5、6倍的放大100次,比较时间(MS)。
机器配置:
intel i5-4440 3.1GHZ,只使用了一条线程进行运算。
结果如下:
\ | 1.5 | 2 | 2.5 | 3 | 3.5 | 4 | 4.5 | 5 | 5.5 | 6 |
---|---|---|---|---|---|---|---|---|---|---|
Invalid | 4281 | 6968 | 10438 | 14671 | 19734 | 25344 | 32000 | 39297 | 47313 | 55922 |
Default | 4250 | 6938 | 10421 | 14704 | 19703 | 25359 | 31985 | 39359 | 47234 | 56109 |
LowQuality | 4250 | 6938 | 10438 | 14656 | 19687 | 25422 | 31954 | 39281 | 47234 | 56062 |
HighQuality | 11015 | 16563 | 23344 | 30984 | 39813 | 49734 | 60703 | 72829 | 85750 | 100250 |
Bilinear | 4235 | 6984 | 10500 | 14672 | 19687 | 25437 | 31953 | 39250 | 47406 | 56265 |
Bicubic | 39531 | 69500 | 108234 | 155141 | 211031 | 275125 | 347859 | 428765 | 518937 | 617344 |
NearestNeighbor | 2500 | 3844 | 5609 | 7671 | 10109 | 13015 | 16266 | 19954 | 23781 | 28188 |
HighQualityBilinear | 11109 | 16375 | 22625 | 29657 | 37610 | 46782 | 56640 | 67313 | 79015 | 91828 |
HighQualityBicubic | 10985 | 16578 | 23281 | 31000 | 39687 | 49813 | 60828 | 72813 | 85891 | 100172 |
可以看到速度最快的是NearestNeighbor算法,平均下来基本上在3倍的时候一次放大就需要70ms,勉强还可以接受。最慢的是Bicubic算法,平均下来基本上在3倍的时候一次放大就需要1.5s,这已经完全无法接受了。
GDI+的性能让我大吃一惊,是微软实现的有问题呢,还是确实这么慢?所以我对ffmpeg中的11种算法做了同样条件下的测试。
结果如下:
\ | 1.5 | 2 | 2.5 | 3 | 3.5 | 4 | 4.5 | 5 | 5.5 | 6 |
---|---|---|---|---|---|---|---|---|---|---|
FAST_BILINEAR | 1625 | 2250 | 3156 | 4250 | 5484 | 6875 | 8531 | 10281 | 12250 | 14406 |
BILINEAR | 3843 | 5812 | 8656 | 12234 | 16312 | 21047 | 26390 | 32360 | 38907 | 46000 |
BICUBIC | 8016 | 12797 | 19531 | 27859 | 40500 | 49000 | 61859 | 76360 | 92406 | 108875 |
X | 3828 | 5781 | 8671 | 12188 | 16360 | 21078 | 26421 | 32359 | 38953 | 46047 |
POINT | 2609 | 3969 | 5844 | 8140 | 10797 | 13797 | 17250 | 21047 | 25266 | 29812 |
AREA | 3625 | 5781 | 8703 | 12219 | 16359 | 21047 | 26391 | 32375 | 38907 | 46015 |
BICUBLIN | 6015 | 10046 | 15312 | 21781 | 29359 | 38078 | 47953 | 58969 | 71234 | 84515 |
GAUSS | 7813 | 12734 | 19516 | 27844 | 37719 | 49453 | 61500 | 75906 | 91688 | 108859 |
SINC | 34828 | 58156 | 90625 | 128656 | 178625 | 229562 | 288485 | 350094 | 420625 | 509047 |
LANCZOS | 9984 | 17078 | 26312 | 37203 | 54109 | 65563 | 82313 | 101265 | 122344 | 144844 |
SPLINE | 15437 | 26516 | 40812 | 59109 | 77922 | 101812 | 127079 | 158031 | 190328 | 100172 |
从BICUBIC和BILINEAR的结果看来微软的算法实现确实有些问题。如果非常追求性能的话可以考虑用ffmpeg转换。