OpenCV里IplImage的widthStep参数

OpenCV里IplImage的widthStep参数昨儿在Moto写程序时遇到的问题.当时是要切人脸图片,比较谨慎,做完了想看一下切的效果就写了个程序显示出来,结果很令人诧异,就试了六幅图结果有五幅完全不对头,都产生了错位,每行错开一点,最后看不出来是人脸了…这下烦了,要是自己写的那个切割工具出问题的话,那眼花缭乱的切了两个多小时的工作都白费了,没办法,找原因吧.又仔细的切了几幅,还是不行,奇怪的是有个别图像显示是正确的.其实工作很简单,就是从一幅

大家好,又见面了,我是你们的朋友全栈君。

昨儿在Moto写程序时遇到的问题.当时是要切人脸图片,比较谨慎,做完了想看一下切的效果就写了个程序显示出来,结果很令人诧异,就试了六幅图结果有五幅完全不对头,都产生了错位,每行错开一点,最后看不出来是人脸了…这下烦了,要是自己写的那个切割工具出问题的话,那眼花缭乱的切了两个多小时的工作都白费了,没办法,找原因吧.又仔细的切了几幅,还是不行,奇怪的是有个别图像显示是正确的.其实工作很简单,就是从一幅图片里切割出指定的若干区域而已.于是试了一下每次都切固定大小的区域,100*100,没问题,又正确了,再变回动态大小区域,问题又来了…按理说这个大小对我的代码应该没影响…不经意的看了一下每次切的大小,发现切偶数大小rect时时正确的,奇数大小的rect则显示错误,忽然想到貌似IplImage里面有一个widthStep参数,看OpenCV文档里的例程貌似人家用过这个参数,马上去查,定义是“size of aligned image row in bytes ”,想起来了,当时就对这个参数不理解,这个size不就应该等于*->width x *->nchannels x *->depth么,为什么还要定义出来?做个实验,分别取宽度为奇偶的图片,读这个widthStep参数,果然,偶数的话跟上面计算一样,奇数就会多出一些,那就不难理解为什么会产生错位了.一般对于奇数的width会填充一个RGB,也就是3bytes.那么现在要对IplImage图像数据进行操作,就要按行取(IplImage的imageData是按照BGRBGRBGR按行存储的),然后每一行顺加一个widthStep了,不能傻傻的按照width x height的二维数组来计算了…

小小一个参数困扰了我一个小时,看来以后对这些细节要很小心,要不是比较谨慎检查一下结果,拿这些图像去训练,就等于拿一坨垃圾去做冷面…馋冷面了,在家就吃了三回…还要注意的就是,用到象OpenCV这种库的时候,一定养成先看示例程序的习惯,当时仔细看的话就没这事儿了…毕竟示例是标准的用法,我们是学习.

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请联系我们举报,一经查实,本站将立刻删除。

发布者:全栈程序员-站长,转载请注明出处:https://javaforall.net/139943.html原文链接:https://javaforall.net

(0)
全栈程序员-站长的头像全栈程序员-站长


相关推荐

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

关注全栈程序员社区公众号