I have a picture 106x106. I use gluScaleImage Scale it to 128x128. I get a strange pictrue not similar to the orignal.
I try to use gulBuild2DMipmaps, the result is same as gluScaleImage.
I try to wirte some code myself to scale the picture, the result is same as above.
Who can help me?
Just try a picture like a rect brick with black boundary.
Please post some code so we can see whats going on. I have an idea, but don’t want to spill the beans until I’ve seen some code 
Also, please describe what you mean by “strange”. An image can appear strange in SO many different ways. And how much not similar is really “not similar”? Way off, or just slightly different?
It works. MS-DIB is 4 byte alignment. So set pixel alignment to 4. Everything works fine.
glPixelStorei(GL_UNPACK_ALIGNMENT, 4);
if(gluScaleImage(GL_BGR_EXT, m_Width, m_Height, GL_UNSIGNED_BYTE, m_pData,
nNewWidth, nNewHeight, GL_UNSIGNED_BYTE, pDataOut)==0) {
}
The default unpack alignment is actually 4. This makes me believe you change the unpack alignment somewhere in the code, but never restore it.
Personally, I think it’s bad practice to make a mess and let someone else clean it up. Once you’re done with your “non-default” unpack alignment, set it back immediately, or you will have problems that can be very difficult to find. I always try to make my code so that whenever a function/block is done, the states are the same as when the function/block was entered.
GL_UNPACK_ALIGNMENT 1 or 4
“glTexImage2D” always get right result.
That is a strange thing.
I have 2 picture:
One (GL_RGB) is construct in memory
unsigned char memImage[64][64][3];
Another (GL_BGR_EXT) is load from disk bmp file.
Why glTexImage2D always get right result?
Since in first case a pixel is 3 bytes, while in second case a pixel is 4 bytes.
My OS is MS-Windows 2000, use MS-OpenGL 1.1
The unpack alignment applies to rows, not the individual pixels.
If you set unpack alignment to 4, each new row of pixels must start on 4 byte boundary. If you have three byte pixels, that’s fine, cause they are stored sequential in memory (no padding), so the pixel transfer is efficient.
Because your texture is generally a power of two, it means that if the first row is sored on a 4 byte boudary, then so are all rows, so you can get away with an unpack alignment of 4. However, note that if you try to create a 2xn or 1xn (n is an arbitrary power of two), you will have a problem. If you have a two pixel wide texture, and the first row starts on 4 byte boundary, then every second row will start on 2 byte boundary, and your texture will not look correct. You therefore need to set unpack alignment to 2 (assuming the initial row is stored on 4 byte boundary). Similar if it’s only 1 pixel wide; only every fourth row will start on 4 byte boundary.
When dealing with textures, which must be a power of two, pixel alignment is generally no problem. Problems more often arise when you use glDrawPixels, which does not require power of two images.
You are right. Thank you.