8 个解决方案
#1
关注
#2
怎麽沒有人會嗎？我等得很急啊。
#3
由于BMP设定者认为数学坐标系更总要，所以DIB的扫描行是逆序存储的（相对于屏幕坐标系而言），即屏幕上的第一行是DIB位图数据的最后一行。
#4
用24位表示一个像素，所以三个字节可以表示1个像素。注意它的顺序是BGR，而不是传统的RGB。在内存的摆放形式如下：
字节 0 1 2 3 4 5 ...
像素 0 1
RGB B G R B G R
字节 0 1 2 3 4 5 ...
像素 0 1
RGB B G R B G R
#5
Thx
#6
我来给你详细一点的说明：
BMP一般是指BMP文件，它被加载进内存后有两种存放方式：
1、DIB位图（设备无关），它实际上就是BMP文件除去BMP文件头的复本，与BMP文件字节排列是一致的。对于DIB位图要通过其头部信息判断其字节排列方式，影响位图数据排列的主要有两个参数：
a、若高(Height)为正数，那么位图数据存放就是行倒序存放，即第一行是显示位图的最下一行的数据，若高为负数，则是正序，与我们视觉习惯是一致的。
b、颜色位数（BitCount），有1、4、8、24、32（Bmp5.0以上才有，实际上现在DIB也支持16位色的）多种，只有24位色的位图是正好RGB三个分量各占一个字节并连续存放的，但我们知道，数据在内存或文件中的排列大都是低位在前，高位在后的顺序，所以其在内存或文件中就摆放成了BGR了，如：一个字节数组读出一个24位的像素a(2)，则B=a(0)，G=a(1),R=a(2)，但若将其转换成Long型的颜色值，则需 Color=a(2)*65536+a(1)*256+a(0)
2、DDB位图（设备相关），它比DIB少了个头部信息，且它位图数据与显示数据是一致的，都是从上到下排列，更重要的是它的颜色位数由屏幕色深决定，如你的显示器颜色数设置的是16位色的话，那DDB就也是16位色，DDB与DIB每个像素中字节的排列是一样，只是DDB中存在的16位色比较特殊，16位色每像素占两字节，共16Bit，RGB在其中分配的方式也有两种：即565格式与555格式(32K色，很少见了)
常见的565格式排列顾名思意，就是从低到高为 B占5Bit，G占6Bit，R占5Bit，由于16位色，RGB每个分量都不是整个字节，而且G分量还是跨字节的，处理16色，需用到移位运算，这正是VB的空门，所以VB处理16位色DDB往往会很慢。
另外不管是DIB还是DDB，位图数据字节总数都是以每一行，做为一个计算基准的，每行字节数必须是4的整数倍，不足的用0补齐。
说了半天，我都是基于使用GDI对图片进行数组级运算而介绍的，若你对这些不了解，你可简单的使用Point或GetPixelV与SetPixelV画点，它们处理虽然很慢，但却能做到“位图无关性”（我自创的词^_^），像素排列总是从左到右，上到下，你只需把得到Long型值按R=(Value \ 65535），G=(Value \ 256 Mod 256）,B=(Value Mod 256）运算取出就行了。
BMP一般是指BMP文件，它被加载进内存后有两种存放方式：
1、DIB位图（设备无关），它实际上就是BMP文件除去BMP文件头的复本，与BMP文件字节排列是一致的。对于DIB位图要通过其头部信息判断其字节排列方式，影响位图数据排列的主要有两个参数：
a、若高(Height)为正数，那么位图数据存放就是行倒序存放，即第一行是显示位图的最下一行的数据，若高为负数，则是正序，与我们视觉习惯是一致的。
b、颜色位数（BitCount），有1、4、8、24、32（Bmp5.0以上才有，实际上现在DIB也支持16位色的）多种，只有24位色的位图是正好RGB三个分量各占一个字节并连续存放的，但我们知道，数据在内存或文件中的排列大都是低位在前，高位在后的顺序，所以其在内存或文件中就摆放成了BGR了，如：一个字节数组读出一个24位的像素a(2)，则B=a(0)，G=a(1),R=a(2)，但若将其转换成Long型的颜色值，则需 Color=a(2)*65536+a(1)*256+a(0)
2、DDB位图（设备相关），它比DIB少了个头部信息，且它位图数据与显示数据是一致的，都是从上到下排列，更重要的是它的颜色位数由屏幕色深决定，如你的显示器颜色数设置的是16位色的话，那DDB就也是16位色，DDB与DIB每个像素中字节的排列是一样，只是DDB中存在的16位色比较特殊，16位色每像素占两字节，共16Bit，RGB在其中分配的方式也有两种：即565格式与555格式(32K色，很少见了)
常见的565格式排列顾名思意，就是从低到高为 B占5Bit，G占6Bit，R占5Bit，由于16位色，RGB每个分量都不是整个字节，而且G分量还是跨字节的，处理16色，需用到移位运算，这正是VB的空门，所以VB处理16位色DDB往往会很慢。
另外不管是DIB还是DDB，位图数据字节总数都是以每一行，做为一个计算基准的，每行字节数必须是4的整数倍，不足的用0补齐。
说了半天，我都是基于使用GDI对图片进行数组级运算而介绍的，若你对这些不了解，你可简单的使用Point或GetPixelV与SetPixelV画点，它们处理虽然很慢，但却能做到“位图无关性”（我自创的词^_^），像素排列总是从左到右，上到下，你只需把得到Long型值按R=(Value \ 65535），G=(Value \ 256 Mod 256）,B=(Value Mod 256）运算取出就行了。
#7
http://www.3lsoft.com/download/info/498.htm
#8
BMP图像数据是从下到上保存的。
#1
关注
#2
怎麽沒有人會嗎？我等得很急啊。
#3
由于BMP设定者认为数学坐标系更总要，所以DIB的扫描行是逆序存储的（相对于屏幕坐标系而言），即屏幕上的第一行是DIB位图数据的最后一行。
#4
用24位表示一个像素，所以三个字节可以表示1个像素。注意它的顺序是BGR，而不是传统的RGB。在内存的摆放形式如下：
字节 0 1 2 3 4 5 ...
像素 0 1
RGB B G R B G R
字节 0 1 2 3 4 5 ...
像素 0 1
RGB B G R B G R
#5
Thx
#6
我来给你详细一点的说明：
BMP一般是指BMP文件，它被加载进内存后有两种存放方式：
1、DIB位图（设备无关），它实际上就是BMP文件除去BMP文件头的复本，与BMP文件字节排列是一致的。对于DIB位图要通过其头部信息判断其字节排列方式，影响位图数据排列的主要有两个参数：
a、若高(Height)为正数，那么位图数据存放就是行倒序存放，即第一行是显示位图的最下一行的数据，若高为负数，则是正序，与我们视觉习惯是一致的。
b、颜色位数（BitCount），有1、4、8、24、32（Bmp5.0以上才有，实际上现在DIB也支持16位色的）多种，只有24位色的位图是正好RGB三个分量各占一个字节并连续存放的，但我们知道，数据在内存或文件中的排列大都是低位在前，高位在后的顺序，所以其在内存或文件中就摆放成了BGR了，如：一个字节数组读出一个24位的像素a(2)，则B=a(0)，G=a(1),R=a(2)，但若将其转换成Long型的颜色值，则需 Color=a(2)*65536+a(1)*256+a(0)
2、DDB位图（设备相关），它比DIB少了个头部信息，且它位图数据与显示数据是一致的，都是从上到下排列，更重要的是它的颜色位数由屏幕色深决定，如你的显示器颜色数设置的是16位色的话，那DDB就也是16位色，DDB与DIB每个像素中字节的排列是一样，只是DDB中存在的16位色比较特殊，16位色每像素占两字节，共16Bit，RGB在其中分配的方式也有两种：即565格式与555格式(32K色，很少见了)
常见的565格式排列顾名思意，就是从低到高为 B占5Bit，G占6Bit，R占5Bit，由于16位色，RGB每个分量都不是整个字节，而且G分量还是跨字节的，处理16色，需用到移位运算，这正是VB的空门，所以VB处理16位色DDB往往会很慢。
另外不管是DIB还是DDB，位图数据字节总数都是以每一行，做为一个计算基准的，每行字节数必须是4的整数倍，不足的用0补齐。
说了半天，我都是基于使用GDI对图片进行数组级运算而介绍的，若你对这些不了解，你可简单的使用Point或GetPixelV与SetPixelV画点，它们处理虽然很慢，但却能做到“位图无关性”（我自创的词^_^），像素排列总是从左到右，上到下，你只需把得到Long型值按R=(Value \ 65535），G=(Value \ 256 Mod 256）,B=(Value Mod 256）运算取出就行了。
BMP一般是指BMP文件，它被加载进内存后有两种存放方式：
1、DIB位图（设备无关），它实际上就是BMP文件除去BMP文件头的复本，与BMP文件字节排列是一致的。对于DIB位图要通过其头部信息判断其字节排列方式，影响位图数据排列的主要有两个参数：
a、若高(Height)为正数，那么位图数据存放就是行倒序存放，即第一行是显示位图的最下一行的数据，若高为负数，则是正序，与我们视觉习惯是一致的。
b、颜色位数（BitCount），有1、4、8、24、32（Bmp5.0以上才有，实际上现在DIB也支持16位色的）多种，只有24位色的位图是正好RGB三个分量各占一个字节并连续存放的，但我们知道，数据在内存或文件中的排列大都是低位在前，高位在后的顺序，所以其在内存或文件中就摆放成了BGR了，如：一个字节数组读出一个24位的像素a(2)，则B=a(0)，G=a(1),R=a(2)，但若将其转换成Long型的颜色值，则需 Color=a(2)*65536+a(1)*256+a(0)
2、DDB位图（设备相关），它比DIB少了个头部信息，且它位图数据与显示数据是一致的，都是从上到下排列，更重要的是它的颜色位数由屏幕色深决定，如你的显示器颜色数设置的是16位色的话，那DDB就也是16位色，DDB与DIB每个像素中字节的排列是一样，只是DDB中存在的16位色比较特殊，16位色每像素占两字节，共16Bit，RGB在其中分配的方式也有两种：即565格式与555格式(32K色，很少见了)
常见的565格式排列顾名思意，就是从低到高为 B占5Bit，G占6Bit，R占5Bit，由于16位色，RGB每个分量都不是整个字节，而且G分量还是跨字节的，处理16色，需用到移位运算，这正是VB的空门，所以VB处理16位色DDB往往会很慢。
另外不管是DIB还是DDB，位图数据字节总数都是以每一行，做为一个计算基准的，每行字节数必须是4的整数倍，不足的用0补齐。
说了半天，我都是基于使用GDI对图片进行数组级运算而介绍的，若你对这些不了解，你可简单的使用Point或GetPixelV与SetPixelV画点，它们处理虽然很慢，但却能做到“位图无关性”（我自创的词^_^），像素排列总是从左到右，上到下，你只需把得到Long型值按R=(Value \ 65535），G=(Value \ 256 Mod 256）,B=(Value Mod 256）运算取出就行了。
#7
http://www.3lsoft.com/download/info/498.htm
#8
BMP图像数据是从下到上保存的。