When we want to resize a bitmap and also the resulting bitmap to be of the highest possible quality, the Win32 AIP function StretchBlt() is not of much help. There are already articles about this task in the CodeGuru sections, but the proposed algorithms take considerable amount of memory when used on large bitmaps - with dimensions of several thousand pixels on each axis.
The function ScaleBitmap() uses an algorithm adjusted to use minimum additional memory and not sacrificing the overall performance. The prototype of the function is
HBITMAP ScaleBitmap(HBITMAP hBmp,
WORD wNewWidth,
WORD wNewHeight);
The only limitation is that both wNewWidth and wNewHeight should be greater or lesser than the dimensions of the original bitmap. The returned bitmap is compatible with the screen device context.
The code below, let's mark it as variant A, produces images of good quality, but because of the large number of floating point calculations it is not as fast as we want.
The main reserve for improving the performance of the routine is in the replacement of all floating-point calculations with integer ones. How could we do that without degradation of image quality?
Actually we don't need more than 3 or 4 digits after the decimal point to produce the same result - the result after all is just a byte [0..255]. The obvious solution is to replace all floating numbers with numbers with fixed decimal point. By example we should replace the number 0.00345 with 345 and also divide the final result by 100000.
OK - let's do it.
Oops!!! In the code we should multiply these fixed-point numbers. Because we are limited to 4-byte integer numbers for performance reasons (means –2,147,483,648 to 2,147,483,647), we can't use 4 digits after the decimal point, because 256 * 10000 * 10000 exceeds 4-byte integer range and somewhere we will get a silent overflow. It seems that we should use the available 3 digits and be happy with that.
This is not so bad, but who limits us to use just the powers of 10 to divide our fixed-point numbers. With the same success we can use the powers of 16, moreover the division by such a number equals to shifting right the number. Let's do some calculations. We have 4 bytes - that means 32 bits. We need 8 bits for the color values and the remaining of 24 bits leads us to decision to use 0x1000 (or 1 << 12) as the divisor for our fixed-point numbers. If the numbers are unsigned (and they are) we shouldn't have troubles with overflows.
As a result we will have about 3,6 valid decimal digits in our fixed-point numbers - it's closer to 4 digits than just 3 digits.
The second piece of code (variant B) uses this method to do all calculations with fixed-point integer numbers. This leads to obvious acceleration of the performance of code B compared to performance of code A, but how big is it?
The following table represents the performance gain of code B over code A on processing a 305x435 pixels image.
Result size / Original size 5% 10% 25% 50% 75% 100% 125% 150% 200% 300%
Performance gain 24% 25% 34% 52% 59% 73% 67% 71% 75% 76%
Considering that along with the calculations the code does also a lot of other work, we can conclude that the 4-byte integer calculations are 3 to 4 times faster than these with floating point numbers.
Variant A
//
// Smooth bitmap resize
//
// Ivaylo Byalkov, November 16, 2000
//
#include "stdafx.h"
#include
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
///////////////////////////////////////////////////////////
// helper function prototypes
static BITMAPINFO *PrepareRGBBitmapInfo(WORD wWidth, WORD wHeight);
static void ShrinkData(BYTE *pInBuff, WORD wWidth, WORD wHeight,
BYTE *pOutBuff, WORD wNewWidth, WORD wNewHeight);
static void EnlargeData(BYTE *pInBuff, WORD wWidth, WORD wHeight,
BYTE *pOutBuff, WORD wNewWidth, WORD wNewHeight);
///////////////////////////////////////////////////////////
// Main resize function
HBITMAP ScaleBitmap(HBITMAP hBmp, WORD wNewWidth, WORD wNewHeight)
{
BITMAP bmp;
::GetObject(hBmp, sizeof(BITMAP), &bmp);
// check for valid size
if ((bmp.bmWidth > wNewWidth
&& bmp.bmHeight < wNewHeight)
|| bmp.bmWidth < wNewWidth
&& bmp.bmHeight > wNewHeight))
return NULL;
HDC hDC = ::GetDC(NULL);
BITMAPINFO *pbi = PrepareRGBBitmapInfo((WORD)bmp.bmWidth,
(WORD)bmp.bmHeight);
BYTE *pData = new BYTE[pbi->bmiHeader.biSizeImage];
::GetDIBits(hDC,
hBmp,
0,
bmp.bmHeight,
pData,
pbi,
DIB_RGB_COLORS);
delete pbi;
pbi = PrepareRGBBitmapInfo(wNewWidth, wNewHeight);
BYTE *pData2 = new BYTE[pbi->bmiHeader.biSizeImage];
if(bmp.bmWidth >= wNewWidth
&& bmp.bmHeight >= wNewHeight)
ShrinkData(pData, (WORD)bmp.bmWidth, (WORD)bmp.bmHeight,
pData2, wNewWidth, wNewHeight);
else
EnlargeData(pData, (WORD)bmp.bmWidth, (WORD)bmp.bmHeight,
pData2, wNewWidth, wNewHeight);
delete pData;
HBITMAP hResBmp = ::CreateCompatibleBitmap(hDC,
wNewWidth,
wNewHeight);
::SetDIBits(hDC,
hResBmp,
0,
wNewHeight,
pData2,
pbi,
DIB_RGB_COLORS);
::ReleaseDC(NULL, hDC);
delete pbi;
delete pData2;
return hResBmp;
}
[返回] 计算机科学论坛 →
计算机技术与应用 → 『 C/C++编程思想 』 → Accelerated Smooth Bitmap Resizing
(订阅本版)
2007/5/22 11:49:00
新浪微博
Accelerated Smooth Bitmap Resizing