千古悬案，无人能解。

Devil

snhun: Re: 千古悬案，无人能解。


这小子纯属扯蛋的！
BMP哪来的 RGBA格式的？你家 BMP是4个字节一个像素的啊？

BMP顶多就是3个字节一个像素！

而且每换一行都要多出几个字节的[em17]

行要4字节对齐,大傻.

ricohcanon

感谢10楼和12楼的弟兄，因为你们间接或直接地纠正了9楼的错误。
8楼的兄弟，你可能还不太了解位图的相关知识，你的实验结果说明了非4字节倍数的一行与4字节倍数一行的差异，非4字节倍数的行需要补零，所以字节数自然会多，不过你可能没有仔细看过我对问题的描述，我再说一遍，我用的位图的行大小都是4的倍数，所以你实验的结果与我提出的问题毫无关系，再有，我那个笨蛋公式只是一种位图字节数计算公式的一个特例，不要大惊小怪的嘛，这个特例是：位图的像素是4字节，位图大小为256*256，为了方便大家看，我才这样写的嘛。
11楼的姐姐，你的意思是说14个字节的文件头结构为了对齐字节多加了2个字节吗？我一开始也是这么想的，可是后来发现不对啊，因为如果这样存储到磁盘的话，那不就把位图格式破坏了吗，而且我确实看了磁盘文件上位图的字节，14个字节的文件头后面紧跟着的就是40个字节的信息头，在这2者之间并没有多插入2个字节，也就是说不是16+40，多出的两个字节在文件末尾，而且即便是16+40的话，那也把位图格式的结构给破坏了，位图不能被读取了啊。不过还是要谢谢姐姐的参与。

再喊一句：这千古悬案就真的无人能解吗？？？

jrc96

调试过了.
TRACE(_T("  %d   %d\n"),sizeof(BITMAPFILEHEADER),sizeof(BITMAPINFOHEADER));
确实是BITMAPFILEHEADER==14 BITMAPINFOHEADER==40
像素数据位置是以BITMAPFILEHEADER::bfOffBits为准,
BITMAPINFOHEADER之后不一定马上紧跟着像素数据(RGB RGBA).

==========第二次修改===========
试了两个文件,发现BITMAPFILEHEADER::bfOffBits都是54的.
用Uedit32看,发现文件最后都是以00 00结束的.

Aming

BMP 有3.0 4.0 5.0的版本
5.0版本是有支援到 Alpha

BITMAPINFOHEADER 的大小?是要看dwSize??Q定

ricohcanon

我描述的问题没错吧，14楼的兄弟又帮着给证明了一下，感谢14楼。感谢15楼的参与。
现在的问题就是为什么文件末尾会比理论上多出2个字节？

bracelet

ricohcanon: Re:千古悬案，无人能解。

感谢10楼和12楼的弟兄，因为你们间接或直接地纠正了9楼的错误。
8楼的兄弟，你可能还不太了解位图的相关知...

虽然像素都字对其了，但是加上文件头后大小就不是字对其了，所以要补齐

需要字对其这是提高内存访问效率的需要

ricohcanon

本菜不敢苟同17楼的兄弟的说法，字节对齐是对于数据类型而言，要对齐也应该是针对文件头结构类型或者信息头结构类型，而整个位图并不是某一种预定义的数据类型。谢谢17楼的讨论。欢迎大家热烈讨论。

小小C

BMP的数据区每一行是可以用4整除的,你肯定在这里出现了问题

ricohcanon

博爵先生，这不是我的问题，不是说只有我一个人会产生这样的问题，大家都会有，你自己实验一下即知，14楼的兄弟自己已经实验过了，和我的一样。现在就是研究为什么会有这样的问题。

lingjingqiu

这年头挺标题党的。。。哈。