bmp文件的像素数据实际有多少怎么判断！？

[春风醉]

bmp文件本身有大小，这个一目了然。按说减去文件头的两三个数据结构的所占字节应该就是像素数据的位置。
但我跟踪查看一些“BITMAPFILEHEADER”的“bfSize”里的数据明显小于这个结果。我不知道“bfSize”的数据是以什么为单位，是字节、还是双字节、四字节等等吧。但无论如何好像都与“文件大小减去文件头的两三个数据结构的所占字节”所得的大小不符。

这是怎么回事？应该怎么理解？？？

望高人指教。非常感谢！

[ArcRain]

http://www.cnblogs.com/lzlsky/archive/2012/08/16/2641698.html 可以参考看下别人的经验分享，会有所收获的。

[春风醉]

引用 1 楼 dream238 的回复:

http://www.cnblogs.com/lzlsky/archive/2012/08/16/2641698.html 可以参考看下别人的经验分享，会有所收获的。

这个材料我看了，但上面的记述有错误。而且关于我关心的部分并没有记录。 现实中，我发现有两种情况，一种情况就是这个值能对应算上，一种就是不能。我不确定这是怎么回事？因为按照BMP文件格式，是可以存储压缩数据的，但我目前看到的全是非压缩。所以，没法分辨。

[ArcRain]

引用 2 楼 cpx0971 的回复:

这个材料我看了，但上面的记述有错误。而且关于我关心的部分并没有记录。 现实中，我发现有两种情况，一种情况就是这个值能对应算上，一种就是不能。我不确定这是怎么回事？因为按照BMP文件格式，是可以存储压缩数据的，但我目前看到的全是非压缩。所以，没法分辨。

你说的那种压缩bmp，就是采用run-length encoding (RLE) 压缩算法来的，MSDN对这种格式有讲解，你可以再参考下：https://msdn.microsoft.com/en-us/library/windows/desktop/dd183383(v=vs.85).aspx 这种情况下，对bmp的文件头也有些要求，可参考：https://msdn.microsoft.com/en-us/library/windows/desktop/dd183386(v=vs.85).aspx

[春风醉]

引用 3 楼 dream238 的回复:

[quote=引用 2 楼 cpx0971 的回复:] 这个材料我看了，但上面的记述有错误。而且关于我关心的部分并没有记录。 现实中，我发现有两种情况，一种情况就是这个值能对应算上，一种就是不能。我不确定这是怎么回事？因为按照BMP文件格式，是可以存储压缩数据的，但我目前看到的全是非压缩。所以，没法分辨。

你说的那种压缩bmp，就是采用run-length encoding (RLE) 压缩算法来的，MSDN对这种格式有讲解，你可以再参考下：https://msdn.microsoft.com/en-us/library/windows/desktop/dd183383(v=vs.85).aspx 这种情况下，对bmp的文件头也有些要求，可参考：https://msdn.microsoft.com/en-us/library/windows/desktop/dd183386(v=vs.85).aspx[/quote] 关于我发现bfSize的大小与文件大小不符的情况，我跟踪看到BITMAPINFOHEADER的biCompression变量为零，先是并没压缩。但确实文件大小2250054字节，但bfSize却是562513。这文件并不是我修改过的。很奇怪，不知道是怎么回事。

[老灰狼]

引用 3 楼 dream238 的回复:

[quote=引用 2 楼 cpx0971 的回复:] 这个材料我看了，但上面的记述有错误。而且关于我关心的部分并没有记录。 现实中，我发现有两种情况，一种情况就是这个值能对应算上，一种就是不能。我不确定这是怎么回事？因为按照BMP文件格式，是可以存储压缩数据的，但我目前看到的全是非压缩。所以，没法分辨。

你说的那种压缩bmp，就是采用run-length encoding (RLE) 压缩算法来的，MSDN对这种格式有讲解，你可以再参考下：https://msdn.microsoft.com/en-us/library/windows/desktop/dd183383(v=vs.85).aspx 这种情况下，对bmp的文件头也有些要求，可参考：https://msdn.microsoft.com/en-us/library/windows/desktop/dd183386(v=vs.85).aspx[/quote] 你乘以4看看, RGBA格式 4字节代表一个像素

[春风醉]

引用 4 楼 cpx0971 的回复:

[quote=引用 3 楼 dream238 的回复:] [quote=引用 2 楼 cpx0971 的回复:] 这个材料我看了，但上面的记述有错误。而且关于我关心的部分并没有记录。 现实中，我发现有两种情况，一种情况就是这个值能对应算上，一种就是不能。我不确定这是怎么回事？因为按照BMP文件格式，是可以存储压缩数据的，但我目前看到的全是非压缩。所以，没法分辨。

你说的那种压缩bmp，就是采用run-length encoding (RLE) 压缩算法来的，MSDN对这种格式有讲解，你可以再参考下：https://msdn.microsoft.com/en-us/library/windows/desktop/dd183383(v=vs.85).aspx 这种情况下，对bmp的文件头也有些要求，可参考：https://msdn.microsoft.com/en-us/library/windows/desktop/dd183386(v=vs.85).aspx[/quote] 关于我发现bfSize的大小与文件大小不符的情况，我跟踪看到BITMAPINFOHEADER的biCompression变量为零，先是并没压缩。但确实文件大小2250054字节，但bfSize却是562513。这文件并不是我修改过的。很奇怪，不知道是怎么回事。[/quote] 我调试了一下，被你说中了。这种情况应该怎么总结规律呢！？

[春风醉]

引用 5 楼 qqfeng0908 的回复:

[quote=引用 3 楼 dream238 的回复:] [quote=引用 2 楼 cpx0971 的回复:] 这个材料我看了，但上面的记述有错误。而且关于我关心的部分并没有记录。 现实中，我发现有两种情况，一种情况就是这个值能对应算上，一种就是不能。我不确定这是怎么回事？因为按照BMP文件格式，是可以存储压缩数据的，但我目前看到的全是非压缩。所以，没法分辨。

你说的那种压缩bmp，就是采用run-length encoding (RLE) 压缩算法来的，MSDN对这种格式有讲解，你可以再参考下：https://msdn.microsoft.com/en-us/library/windows/desktop/dd183383(v=vs.85).aspx 这种情况下，对bmp的文件头也有些要求，可参考：https://msdn.microsoft.com/en-us/library/windows/desktop/dd183386(v=vs.85).aspx[/quote] 你乘以4看看, RGBA格式 4字节代表一个像素[/quote] 位图文件格式中，好像没有哪里记录这种情况吧！？有吗？望告知。感激不尽！

[老灰狼]

引用 3 楼 dream238 的回复:

[quote=引用 2 楼 cpx0971 的回复:] 这个材料我看了，但上面的记述有错误。而且关于我关心的部分并没有记录。 现实中，我发现有两种情况，一种情况就是这个值能对应算上，一种就是不能。我不确定这是怎么回事？因为按照BMP文件格式，是可以存储压缩数据的，但我目前看到的全是非压缩。所以，没法分辨。

你说的那种压缩bmp，就是采用run-length encoding (RLE) 压缩算法来的，MSDN对这种格式有讲解，你可以再参考下：https://msdn.microsoft.com/en-us/library/windows/desktop/dd183383(v=vs.85).aspx 这种情况下，对bmp的文件头也有些要求，可参考：https://msdn.microsoft.com/en-us/library/windows/desktop/dd183386(v=vs.85).aspx[/quote] 你乘以4看看, RGBA格式 4字节代表一个像素

引用 7 楼 cpx0971 的回复:

[quote=引用 5 楼 qqfeng0908 的回复:] [quote=引用 3 楼 dream238 的回复:] [quote=引用 2 楼 cpx0971 的回复:] 这个材料我看了，但上面的记述有错误。而且关于我关心的部分并没有记录。 现实中，我发现有两种情况，一种情况就是这个值能对应算上，一种就是不能。我不确定这是怎么回事？因为按照BMP文件格式，是可以存储压缩数据的，但我目前看到的全是非压缩。所以，没法分辨。

你说的那种压缩bmp，就是采用run-length encoding (RLE) 压缩算法来的，MSDN对这种格式有讲解，你可以再参考下：https://msdn.microsoft.com/en-us/library/windows/desktop/dd183383(v=vs.85).aspx 这种情况下，对bmp的文件头也有些要求，可参考：https://msdn.microsoft.com/en-us/library/windows/desktop/dd183386(v=vs.85).aspx[/quote] 你乘以4看看, RGBA格式 4字节代表一个像素[/quote] 位图文件格式中，好像没有哪里记录这种情况吧！？有吗？望告知。感激不尽！[/quote] 我瞎掰的, 可以的话, 你把文件分享下[e-mail],或者用hex编辑器发个图

[春风醉]

引用 8 楼 qqfeng0908 的回复:

[quote=引用 3 楼 dream238 的回复:] [quote=引用 2 楼 cpx0971 的回复:] 这个材料我看了，但上面的记述有错误。而且关于我关心的部分并没有记录。 现实中，我发现有两种情况，一种情况就是这个值能对应算上，一种就是不能。我不确定这是怎么回事？因为按照BMP文件格式，是可以存储压缩数据的，但我目前看到的全是非压缩。所以，没法分辨。

你说的那种压缩bmp，就是采用run-length encoding (RLE) 压缩算法来的，MSDN对这种格式有讲解，你可以再参考下：https://msdn.microsoft.com/en-us/library/windows/desktop/dd183383(v=vs.85).aspx 这种情况下，对bmp的文件头也有些要求，可参考：https://msdn.microsoft.com/en-us/library/windows/desktop/dd183386(v=vs.85).aspx[/quote] 你乘以4看看, RGBA格式 4字节代表一个像素

引用 7 楼 cpx0971 的回复:

[quote=引用 5 楼 qqfeng0908 的回复:] [quote=引用 3 楼 dream238 的回复:] [quote=引用 2 楼 cpx0971 的回复:] 这个材料我看了，但上面的记述有错误。而且关于我关心的部分并没有记录。 现实中，我发现有两种情况，一种情况就是这个值能对应算上，一种就是不能。我不确定这是怎么回事？因为按照BMP文件格式，是可以存储压缩数据的，但我目前看到的全是非压缩。所以，没法分辨。

你说的那种压缩bmp，就是采用run-length encoding (RLE) 压缩算法来的，MSDN对这种格式有讲解，你可以再参考下：https://msdn.microsoft.com/en-us/library/windows/desktop/dd183383(v=vs.85).aspx 这种情况下，对bmp的文件头也有些要求，可参考：https://msdn.microsoft.com/en-us/library/windows/desktop/dd183386(v=vs.85).aspx[/quote] 你乘以4看看, RGBA格式 4字节代表一个像素[/quote] 位图文件格式中，好像没有哪里记录这种情况吧！？有吗？望告知。感激不尽！[/quote] 我瞎掰的, 可以的话, 你把文件分享下[e-mail],或者用hex编辑器发个图[/quote] 邮件已经发了。麻烦帮我看看。谢谢了。希望有结果的话能尽快回复我。

[CyberLogix]

和位图的位数和格式有关， RGB24，RGB32, RGB16等， 长*宽*每像素占用的字节数

[春风醉]

引用 10 楼 OExpress 的回复:

和位图的位数和格式有关， RGB24，RGB32, RGB16等， 长*宽*每像素占用的字节数

位数在格式里有记录，长宽的像素也有记录，由此可以算出文件的长度。这个不是秘密。但如果文件长度与对应的记录域仍然对不上。又是怎么回事呢？ 我说的是这个问题。

[CyberLogix]

那就可以使文件头的记录不对，根据是实际书记计算得到正确的数值