經(jīng)常用到ffmpeg中的sws_scale來進行圖像縮放和格式轉(zhuǎn)換,該函數(shù)可以使用各種不同算法來對圖像進行處理。以前一直很懶,懶得測試和甄別應(yīng)該使用哪種算法,最近的工作時間,很多時候需要等待別人。忙里偷閑,對ffmpeg的這一組函數(shù)進行了一下封裝,順便測試了一下各種算法。
簡單說一下測試環(huán)境,我使用的是Dell的品牌機,i5的CPU。ffmpeg是2010年8月左右的當(dāng)時最新版本編譯而成,我使用的是其靜態(tài)庫版本。
首先,將一幅1920*1080的風(fēng)景圖像,縮放為400*300的24位RGB,下面的幀率,是指每秒鐘縮放并渲染的次數(shù)。(經(jīng)過我的測試,渲染的時間可以忽略不計,主要時間還是耗費在縮放算法上。)
算法 |
幀率 |
圖像主觀感受 |
SWS_FAST_BILINEAR |
228 |
圖像無明顯失真,感覺效果很不錯。 |
SWS_BILINEAR |
95 |
感覺也很不錯,比上一個算法邊緣平滑一些。 |
SWS_BICUBIC |
80 |
感覺差不多,比上上算法邊緣要平滑,比上一算法要銳利。 |
SWS_X |
91 |
與上一圖像,我看不出區(qū)別。 |
SWS_POINT |
427 |
細(xì)節(jié)比較銳利,圖像效果比上圖略差一點點。 |
SWS_AREA |
116 |
與上上算法,我看不出區(qū)別。 |
SWS_BICUBLIN |
87 |
同上。 |
SWS_GAUSS |
80 |
相對于上一算法,要平滑(也可以說是模糊)一些。 |
SWS_SINC |
30 |
相對于上一算法,細(xì)節(jié)要清晰一些。 |
SWS_LANCZOS |
70 |
相對于上一算法,要平滑(也可以說是模糊)一點點,幾乎無區(qū)別。 |
SWS_SPLINE |
47 |
和上一個算法,我看不出區(qū)別。 |
總評,以上各種算法,圖片縮小之后的效果似乎都不錯。如果不是對比著看,幾乎看不出縮放效果的好壞。上面所說的清晰(銳利)與平滑(模糊),是一種客觀感受,并非清晰就比平滑好,也非平滑比清晰好。其中的Point算法,效率之高,讓我震撼,但效果卻不差。此外,我對比過使用CImage的繪制時縮放,其幀率可到190,但效果慘不忍睹,顏色嚴(yán)重失真。
第二個試驗,將一幅1024*768的風(fēng)景圖像,放大到1920*1080,并進行渲染(此時的渲染時間,雖然不是忽略不計,但不超過5ms的渲染時間,不影響下面結(jié)論的相對準(zhǔn)確性)。
算法 |
幀率 |
圖像主觀感受 |
SWS_FAST_BILINEAR |
103 |
圖像無明顯失真,感覺效果很不錯。 |
SWS_BILINEAR |
100 |
和上圖看不出區(qū)別。 |
SWS_BICUBIC |
78 |
相對上圖,感覺細(xì)節(jié)清晰一點點。 |
SWS_X |
106 |
與上上圖無區(qū)別。 |
SWS_POINT |
112 |
邊緣有明顯鋸齒。 |
SWS_AREA |
114 |
邊緣有不明顯鋸齒。 |
SWS_BICUBLIN |
95 |
與上上上圖幾乎無區(qū)別。 |
SWS_GAUSS |
86 |
比上圖邊緣略微清楚一點。 |
SWS_SINC |
20 |
與上上圖無區(qū)別。 |
SWS_LANCZOS |
64 |
與上圖無區(qū)別。 |
SWS_SPLINE |
40 |
與上圖無區(qū)別。 |
總評,Point算法有明顯鋸齒,Area算法鋸齒要不明顯一點,其余各種算法,肉眼看來無明顯差異。此外,使用CImage進行渲染時縮放,幀率可達105,效果與Point相似。
個人建議,如果對圖像的縮放,要追求高效,比如說是視頻圖像的處理,在不明確是放大還是縮小時,直接使用SWS_FAST_BILINEAR算法即可。如果明確是要縮小并顯示,建議使用Point算法,如果是明確要放大并顯示,其實使用CImage的Strech更高效。
當(dāng)然,如果不計速度追求畫面質(zhì)量。在上面的算法中,選擇幀率最低的那個即可,畫面效果一般是最好的。
不過總的來說,ffmpeg的scale算法,速度還是非常快的,畢竟我選擇的素材可是高清的圖片。
(本想順便上傳一下圖片,但各組圖片差異其實非常小,恐怕上傳的時候格式轉(zhuǎn)換所造成的圖像細(xì)節(jié)丟失,已經(jīng)超過了各圖片本身的細(xì)節(jié)差異,因此此處不上傳圖片了。)
注:試驗了一下OpenCV的Resize效率,和上面相同的情況下,OpenCV在上面的放大試驗中,每秒可以進行52次,縮小試驗中,每秒可以進行458次。