关于bmp图片的压缩的宽和高的有关问题请问,大神和感兴趣的朋友请进
关于bmp图片的压缩的宽和高的问题请教,大神和感兴趣的朋友请进。
MFC应用 处理 BMP 格式文件
最近 接手某压缩算法核心部分的供学习使用,并进行完整实现。遇到了一点问题,菜鸟不知深浅,特来此取经。
No.1 处理bmp文件要考虑“宽高”是4的整倍数,否则要补齐。
No.2 补齐之前 非4倍数宽高的压缩的图片有问题,补齐之后一部分非4倍数的图片没出现问题,一部分有问题。
No.3 根据以上情况 求解释。(x+3)/4*4.。。
给大家上几张压缩处理的图片,压缩字符串保存在了txt文件中。
图片不能上传bmp文件且大小有限制,所以把原图和压缩后的bmp图,转换了jpg,大家凑合看。
1. 1023*767
原图
压缩后
2.337*433
原图
压缩后
------解决方案--------------------
宽需要补齐到4字节的倍数;
高不需要。
------解决方案--------------------
自己做bmp的缩放算法太麻烦了,有现成的gdi+的Graphics.DrawImage就可以了。
------解决方案--------------------
压缩肯定传递图像的像素宽度啊,所谓“补齐”只是要保证图像的每行扫描线占用的字节数是4的倍数,这并不改变图像的像素宽度。
------解决方案--------------------
不是宽度是4的倍数,而是字节数是4的倍数
例如宽为5的RGB图片,它每行像素占据的字节数不是(5+3)*3=24,而是5*3+1=16
------解决方案--------------------
1203是4n+3,(1203+1)*3等于1203*3+3
337是4n+1,(337+1)*3不等于337*3+1
建议楼主全面检查一下程序里所有计算每一行像素长度和偏移的地方
------解决方案--------------------
typedef struct tagBITMAPINFOHEADER{ // bmih
DWORD biSize;
LONG biWidth;
LONG biHeight;
WORD biPlanes;
WORD biBitCount //1,4,8,15,16,24,32
DWORD biCompression;
DWORD biSizeImage;
LONG biXPelsPerMeter;
LONG biYPelsPerMeter;
DWORD biClrUsed;
DWORD biClrImportant;
} BITMAPINFOHEADER;
BITMAPINFOHEADER bmiHeader;
....
int BitsPerPixel = bmiHeader.biBitCount ==15 ? bmiHeader.biBitCount :16;
int LineBytes = (BitsPerPixel *bmiHeader. biBitCount + 31) / 32 * 32 /8;
int height =abs(bmiHeader.biHeight);
if(BitsPerPixel == 24)
{
if( bmiHeader.biHeight< 0)//正向位图
{ //pixel[i][j].B = pBits + i* LineBytes + j*3;
//pixel[i][j].G = pBits + i* LineBytes + j*3 + 1;
//pixel[i][j].R = pBits + i* LineBytes + j*3 + 2;
}
else {//反向位图
//pixel[i][j].B = pBits + (height -i-1) * LineBytes + j*3;
//pixel[i][j].G = pBits + (height -i-1) * LineBytes + j*3 + 1;
MFC应用 处理 BMP 格式文件
最近 接手某压缩算法核心部分的供学习使用,并进行完整实现。遇到了一点问题,菜鸟不知深浅,特来此取经。
No.1 处理bmp文件要考虑“宽高”是4的整倍数,否则要补齐。
No.2 补齐之前 非4倍数宽高的压缩的图片有问题,补齐之后一部分非4倍数的图片没出现问题,一部分有问题。
No.3 根据以上情况 求解释。(x+3)/4*4.。。
给大家上几张压缩处理的图片,压缩字符串保存在了txt文件中。
图片不能上传bmp文件且大小有限制,所以把原图和压缩后的bmp图,转换了jpg,大家凑合看。
1. 1023*767
原图
压缩后
2.337*433
原图
压缩后
图片
压缩
bmp
C/C++
MFC
------解决方案--------------------
宽需要补齐到4字节的倍数;
高不需要。
------解决方案--------------------
自己做bmp的缩放算法太麻烦了,有现成的gdi+的Graphics.DrawImage就可以了。
------解决方案--------------------
压缩肯定传递图像的像素宽度啊,所谓“补齐”只是要保证图像的每行扫描线占用的字节数是4的倍数,这并不改变图像的像素宽度。
------解决方案--------------------
不是宽度是4的倍数,而是字节数是4的倍数
例如宽为5的RGB图片,它每行像素占据的字节数不是(5+3)*3=24,而是5*3+1=16
------解决方案--------------------
宽需要补齐到4字节的倍数;
高不需要。
恩,高不需要。但是对齐了,效果还是不一样,比如,24位bmp文件:(nWidht * 3 + 3) / 4 * 4.这样处理之后,第一类 1203*767的就正常了,337*433的就是第二类那样怪怪的。不知道是什么原因,是算法的问题,或者说压缩处理传参应该是原来的宽度还是处理之后的宽度。
压缩肯定传递图像的像素宽度啊,所谓“补齐”只是要保证图像的每行扫描线占用的字节数是4的倍数,这并不改变图像的像素宽度。
对啊,我觉得应该是图像数据可能存在错位的问题,但是处理 像素buffer的时候如何跳的妥当呢。这个压缩算法 是直接对 整个像素buffer进行处理,然后根据处理的 像素“字符串”进行保存。再然后根据需要对其还原。 不是宽度是4的倍数,而是字节数是4的倍数
例如宽为5的RGB图片,它每行像素占据的字节数不是(5+3)*3=24,而是5*3+1=16
是我知道,但是像素buffer中对齐后,还是会存在问题。
1203是4n+3,(1203+1)*3等于1203*3+3
337是4n+1,(337+1)*3不等于337*3+1
建议楼主全面检查一下程序里所有计算每一行像素长度和偏移的地方
------解决方案--------------------
typedef struct tagBITMAPINFOHEADER{ // bmih
DWORD biSize;
LONG biWidth;
LONG biHeight;
WORD biPlanes;
WORD biBitCount //1,4,8,15,16,24,32
DWORD biCompression;
DWORD biSizeImage;
LONG biXPelsPerMeter;
LONG biYPelsPerMeter;
DWORD biClrUsed;
DWORD biClrImportant;
} BITMAPINFOHEADER;
BITMAPINFOHEADER bmiHeader;
....
int BitsPerPixel = bmiHeader.biBitCount ==15 ? bmiHeader.biBitCount :16;
int LineBytes = (BitsPerPixel *bmiHeader. biBitCount + 31) / 32 * 32 /8;
int height =abs(bmiHeader.biHeight);
if(BitsPerPixel == 24)
{
if( bmiHeader.biHeight< 0)//正向位图
{ //pixel[i][j].B = pBits + i* LineBytes + j*3;
//pixel[i][j].G = pBits + i* LineBytes + j*3 + 1;
//pixel[i][j].R = pBits + i* LineBytes + j*3 + 2;
}
else {//反向位图
//pixel[i][j].B = pBits + (height -i-1) * LineBytes + j*3;
//pixel[i][j].G = pBits + (height -i-1) * LineBytes + j*3 + 1;