图像自己主动測试框架
2017-07-26 20:21
190 查看
近期在做关于 Kinect 的项目。因为须要用到图像匹配相关的算法,从网上看到有大量的论文,一时之间也不知道哪些才是适合我的。于是乎我想到应该对这些方法进行试验,从而找到适合我的好方法。可是。问题来了,这么多的算法。一个一个的做实验,不现实啊。
经过深思熟虑,我下定决心要写一个自己主动的框架,利用这个框架来加速我的试验速度。这个框架定义了三个基类:ImageGen、SkinDetect、Action。
ImageGen:自己主动的生成待检測的图像,接口例如以下:
operator() 函数与 getImage() 功能应该是一致的,主要就是获得图像,为了方便与其他的类进行交互,这里生成的图像格式应该是:BGR 的,然后其他的检測方法假设利用的是其他的图片格式,则能够做适当的转换。reset() 重置指针。又一次获取图像。
这所以定义这个类是由于想到扩展的问题。这样不管图像来自何方,仅仅要符合该接口标准就能够使用该框架了。
SkinDetect:图像检測类,这个类主要完毕的功能是检測图像。因为我的试验是有关肤色检測的,所以这个类就跟肤色检測相关了,假设为了扩展,能够进一步抽象,成为更主要的类:ImageDetect...,接口例如以下:
之所以定义了 goods_counts 主要是由于这次实验跟商品也有关系,因此就把它放进基类了。值得注意的是,还定义了静态常量:BG_VALUE、SKIN_VALUE、GOODS_VALUE,这是由于我把图像分成了三部分:皮肤、商品、背景。不同的部分相应不同的颜色。
Action:动作类,这个类的功能主要是当检測返回 true 的时候运行对应的动作,接口例如以下:
最后一个类是:JudgerFrameWork,该类引用上面的类进行自己主动化的检測,例如以下:
设置这套框架前前后后改动了 N 次,主要是由于接口那里难以控制。有时候非常难协调功能的分配。
此外。假设设置的太过抽象,则又添加了开发的复杂度,假设抽象度不够。则又不利于扩展。
不禁感叹:开发大有学问在。接口设计功夫深!
经过深思熟虑,我下定决心要写一个自己主动的框架,利用这个框架来加速我的试验速度。这个框架定义了三个基类:ImageGen、SkinDetect、Action。
ImageGen:自己主动的生成待检測的图像,接口例如以下:
class ImageGen{ public: virtual IplImage* operator()() = 0; virtual IplImage* getImage() = 0; virtual void reset() = 0; };
operator() 函数与 getImage() 功能应该是一致的,主要就是获得图像,为了方便与其他的类进行交互,这里生成的图像格式应该是:BGR 的,然后其他的检測方法假设利用的是其他的图片格式,则能够做适当的转换。reset() 重置指针。又一次获取图像。
这所以定义这个类是由于想到扩展的问题。这样不管图像来自何方,仅仅要符合该接口标准就能够使用该框架了。
SkinDetect:图像检測类,这个类主要完毕的功能是检測图像。因为我的试验是有关肤色检測的,所以这个类就跟肤色检測相关了,假设为了扩展,能够进一步抽象,成为更主要的类:ImageDetect...,接口例如以下:
class SkinDetect{ public: SkinDetect() : _skin_counts(0) , _goods_counts(0) {} // src 与 res 的 row 和 col 一致, src 的格式一律为 BGR // 结果存放在 res 中 virtual bool detected( IplImage* src, IplImage* res ) = 0; // 參数字符串化,这样有助于推断当前的參数值。 virtual std::string toString() = 0; virtual ~SkinDetect() {} size_t getSkinCounts() { return _skin_counts; } size_t getGoodsCounts(){ return _goods_counts; } // 结果图像中的灰度值含义: static const int BG_VALUE = 0; // 背景灰度值 static const int SKIN_VALUE = 255; // 皮肤灰度值 static const int GOODS_VALUE = 100; // 商品灰度值 protected: size_t _skin_counts; size_t _goods_counts; };///@~
之所以定义了 goods_counts 主要是由于这次实验跟商品也有关系,因此就把它放进基类了。值得注意的是,还定义了静态常量:BG_VALUE、SKIN_VALUE、GOODS_VALUE,这是由于我把图像分成了三部分:皮肤、商品、背景。不同的部分相应不同的颜色。
Action:动作类,这个类的功能主要是当检測返回 true 的时候运行对应的动作,接口例如以下:
/*********************************************** * 当推断符合条件的时候调用该类的方法进行处理 ***********************************************/ class Action{ public: virtual void operator()(IplImage* src, IplImage* res) = 0; virtual ~Action(){}; };仅仅有一个公共接口:operator(),第一个參数为原图像,第二个參数为检測结果。
最后一个类是:JudgerFrameWork,该类引用上面的类进行自己主动化的检測,例如以下:
class JudgerFrameWork{ public: JudgerFrameWork( ImageGen& img_gen, SkinDetect& skin_detect, Action& action ) : _img_gen(img_gen) , _skin_detect(skin_detect) , _action(action) {} void start() { for( IplImage* image = _img_gen.getImage(); image != NULL; image = _img_gen.getImage() ) { IplImage* res = cvCreateImage( cvGetSize(image), IPL_DEPTH_8U, 1 ); if( _skin_detect.detected( image, res ) ) { _action( image, res ); std::cout << "goods count:" << _skin_detect.getGoodsCounts() << std::endl; std::cout << "skins count:" << _skin_detect.getSkinCounts() << std::endl; } } } private: ImageGen& _img_gen; SkinDetect& _skin_detect; Action& _action; };所须要做的事情主要是创建对应的对象,然后构造 JudgerFrameWork 对象。当构造完对象后,仅仅需调用函数:start() 就可以完毕全部的动作了。
设置这套框架前前后后改动了 N 次,主要是由于接口那里难以控制。有时候非常难协调功能的分配。
此外。假设设置的太过抽象,则又添加了开发的复杂度,假设抽象度不够。则又不利于扩展。
不禁感叹:开发大有学问在。接口设计功夫深!
相关文章推荐
- Robot Framework自己主动化測试框架之我见
- Windows环境搭建Web自己主动化測试框架Watir(基于Ruby)
- 带有机器人框架的.NET自己主动化測试
- MAC中在eclipse luna上搭建移动平台自己主动化測试框架(UIAutomator/Appium/Robotium/MonkeyRunner)关键点记录
- CodedUI自己主动化測试及脱离VS独立执行
- Maven实现Web应用集成測试自己主动化 -- 測试自己主动化(WebTest Maven Plugin)
- SWTBOK測试实践系列(5) -- 项目中使用手动和自己主动化的策略
- 致网友Wonderfei的一封信(怎样选择自己主动化框架的几点拙见)
- RFC2889转发性能測试用例设计和自己主动化脚本实现
- 逐步转向自己主动化測试
- Android自己主动化測试之Monkeyrunner用法及实例
- 【測试技术交流群】自己主动化|性能測试技术交流群
- Android 自己主动化測试之------ Monkey工具
- Android自己主动化測试之Monkeyrunner用法及实例
- 移动測试技术保护源码!解码全球首款移动端白盒測试工具ThreadingTest (文章转自己主动点科技)
- android uiautomator自己主动化測试
- 敏捷自己主动化測试 (黑盒单元測试)
- Android自己主动化測试之Monkeyrunner用法及实例
- Android自己主动化測试之Monkeyrunner用法及实例
- ant整合junit自己主动化測试