读取IplImage格式中的像素时,如不注意,会得到负数。原因详细分析如下:
double、long、unsigned、int、char类型数据所占字节数和机器字长及编译器有关系: 所以,int,long int,short int的宽度都可能随编译器而异。但有几条铁定的原则(ANSI/ISO制订的): 1 sizeof(short int)<=sizeof(int) 2 sizeof(int)<=sizeof(long int) 3 short int至少应为16位(2字节) 4 long int至少应为32位。 例如: 16位编译器 char :1个字节 char*(即指针变量): 2个字节 short int : 2个字节 int: 2个字节 unsigned int : 2个字节 float: 4个字节 double: 8个字节 long: 4个字节 long long: 8个字节 unsigned long: 4个字节
32位编译器
char :1个字节 char*(即指针变量): 4个字节(32位的寻址空间是2^32, 即32个bit,也就是4个字节。同理64位编译器) short int : 2个字节
int: 4个字节 unsigned int : 4个字节 float: 4个字节 double: 8个字节 long: 4个字节 long long: 8个字节 unsigned long: 4个字节 64位编译器 char :1个字节 char*(即指针变量): 8个字节 short int : 2个字节 int: 4个字节 unsigned int : 4个字节 float: 4个字节 double: 8个字节 long: 8个字节 long long: 8个字节 unsigned long: 8个字节
OpenCV中各种数据格式如下:
Member | Description |
IPL_DEPTH_SIGN | indicates if the value is signed |
IPL_DEPTH_1U | 1bit unsigned |
IPL_DEPTH_8U | 8bit unsigned (Byte) (uchar) |
IPL_DEPTH_16U | 16bit unsigned |
IPL_DEPTH_32F | 32bit float (Single) |
IPL_DEPTH_8S | 8bit signed |
IPL_DEPTH_16S | 16bit signed |
IPL_DEPTH_32S | 32bit signed |
IPL_DEPTH_64F | double |
以下转自:http://blog.csdn.net/huangkangying/article/details/6079157
以前在做图像处理的时候,一直不太在意这个问题,对图像每个像素点的灰度值,总是认为char也可,unsigned char也可。尽管它们都是8位,但是表示的数的范围却不相同:char: -128~127, unsigned char: 0~255。很明显,unsigned char才是正确的选择。
你可以这样定义:
1 struct { 2 char r; 3 char g; 4 char b; 5 }pixel_t; 6 也可以这样定义: 8 struct { 9 unsigned char r; 10 unsigned char g; 11 unsigned char b; 12 }pixel_ut;
如果你不用上面的定义对像素进行算术运算,而只是进行赋值操作,OK, 没问题。 但一旦进行算术运算,隐含的bug随之而来了。
考虑下面的情况: 2 struct pixel_t pix1; 3 struct pixel_t pix2; 4 struct pixel_ut pix3; 5 struct pixel_ut pix4; 6 7 int ans0, ans1; 8 9 pix1.r = 127; 10 pix2.r = 129; 11 12 pix3.r = 127; 13 pix4.r = 129; 14 15 ans0 = pix2.r - pix1.r; //ans0 = ? 16 17 ans1 = pix4.r - pix3.r; //ans1 = ? 如果你认为ans0与ans1的值会相等,那你就大错特错,他们不仅不等,而且两者相差甚远。 ans0 = -254; ans1 = 2; 原因在于: 当我们把129赋值给pix2.r时,由于pix2.r的类型是char,所以pix2.r的值并不是129,而是 -127。所以当我们进行运算时出错。
所以在读取图像数据时,需要加上(uchar*)进行限定。