DDBOLG的专栏

   搞了一上午，还以为是程序并行处理造成的呢。顺序读入视频， for(;image = cvQueryFrame( pCapture );) {    //cvWaitKey(20);  cvShowImage("image",image);  levdetec.ProcessWithLev(image,400,100);  fg=levdetec.GetMask();  lev=levde

cvSetImageROI(result,resultrect);  cvMinMaxLoc(result, &min_val, &max_val,&min_loc,&max_loc, NULL );  center.x=min_loc.x-(int)objsize/2;center.y=min_loc.y-(int)objsize/2;  cvResetImageROI(result);有时

前几天帮朋友设计了一下算法，模拟了一下，感觉还可以。用了肤色分割、然后统计目标的特定位置的像素个数来识别指尖和一些指部动作。效果不错，还有些得意。今天看书，偶然想到其实算法有些绕弯子。直接使用手的外形，拟合成链码来判断就可以了。opencv少一个东西，统计二值图的连通区域的大小及个数。感觉比较有用。

用于自动跟踪讲课的教师以便录像。采用了初始化背景以自动识别目标，然后用匹配的方式跟踪目标，并动态更新目标。现在可以改进的方面：抗干扰，提速。存在的问题：目标大小的判定。现在只是固定目标大小。如果目标大小变化大的话，可能跟丢，不过加入移动速度的限制的话，应当可以克服。

前一段做的bus count，拿去深圳科学院测试，总体不错，但是暴露了一些算法上的问题。对于多人并行的分辨率并不好。最近作了一下算法试验，否定了几种方案，觉得问题出在乘客何时走出检测框的判定上。严格的多人并行也不难检测，难点就在不是完全并行，也没有分得很开。所以，走出的判定，既然认为是走出去了，就应把检测框放在边上，而不是全部。带来一个问题，一个人的走出可能和下一个人的走入重合。这种思路还没有利用

用opencv处理视频时的一个基本格式用了好久的opencv,写过很多程序,今天偶然看了一个很基本的例子,才发现原来这里也有金子。这段代码写的很完美。int main(int argc, char** argv){    IplImage* motion = 0;    CvCapture* capture = 0;        capture = cvCaptureFromAVI( "vide

今天发现一个问题，在一个lib里面，用cvNamedWindow和cvShowImage时，没有用cvWaitKey，结果显示有问题。觉得highgui的问题还是比较多的，像以前写MFC演示算法时，就发现有图像框的更新、响应等问题。所以，highgui只是用于简单的演示可以。

 

五一过节，玩了好几天，五四又过个生日，好爽的假期。老板在催，所以加班写代码。用了一下OpenCV的动态结构，CvSeq，发现很好用哦。检测到的目标保存在一个动态序列中，保存了目标的位置、大小、时间信息。在ccs环境下编译通过，又在windows下结合directshow测试了一下，发现几个小bug，其余运转正常。还需要一个智能背景重新学习的模块。以后再说吧。可今天板子拆，拿去作壳子了，只好改天

 对于单片的处理系统，程序的编译有不少不同，不可以用windows下对程序组织来考虑dsp的程序组织。作移植的话，一定要对dsp下程序的编译和运行有了解。比如，ccs中，子程序声明后就会分配空间，传结构会默认传结构的地址……这样，直接编译opencv，要想编译通过并不困难，但用仿真器调试的时候，基本上opencv的函数都通过不了，算法上问题不多，主要是程序结构上的。一定要对opencv函数

涉及到dsp的移植，所以研究了一下。cxswicher是用于intel处理器ipp优化的，编译时就不要了。cxerror必须要，但是其采用了多线程技术，所以要disable掉大多数代码。cxerror用到的多线程技术包括windows.h或pthread.h(linux下)，为什么要用呢？在多线程程序里，有第三种数据类型：线程数据（TSD: Thread-Specific Data）。它和全局变量

最近几天在考虑。把calloca改成malloc，大体上可以在ccs上编译通过。但有很多warning，问题主要是涉及void指针的类型转化，选择了不严格的编译方式可以去掉warning，但不知道能不能在板子上跑起来。cxcore可以编译通过了。前几天研究了一下师姐做的motorola DSP的uC/OS操作系统，收获蛮大，对硬件底层的实现有了一些理解。抽空总结一下。 

1，运动模板包括UpdateMotionHistory，CalcGlobalOrientation还有几个辅助函数。不晓得是谁提出的，想法很好，刚运动过的点由最大的值，较早运动过的点值为0。对于运动方向探测来说，应当是很优化的算法了。但实际中一般不需要这种复杂的方法，探测到的目标也不一定是这种由运动发生时刻得到的点。我觉得就是个很好的想法，实现了也蛮有趣，实际中不大用得到的。2，背景统计没啥好说得

Opencv论坛上的directshow代码是可以用的，可以识别多摄像头，速度64帧。用cvCaptureFromCAM，即vfw是10帧左右。用cvcam模块，测试结果是30帧左右。速度与摄像头也有一点关系，不大。在windows下，cvcam将被集成在highgui中的directshow代替，而linux下，不清楚了。这样的结果将是损害cvcam的跨平台特性。可见，软件要结合

书读百遍，其义自现。不知道是第几遍看这本书了，虽说是入门版，但收获颇多。速度很明显快多了，一个多小时，把cvcam，cxcore，highgui又看了一遍。1，highgui只是试验级的接口，只能用于windows，是用vfw技术，读摄像头很慢，有算法的情况下，大概7帧/s。cvcam未来将被淘汰，原因只是他被集成到highgui中，并使用dshow技术。 用dshow读cam，速度提高6倍。

不要相信windows下显示的图像，有欺骗性。对于float图像的处理有区别。二阶高斯微分，图像像素值在-2~2之间，可以显示，可能是自动进行了处理。而像素值在0~255之间的float图像，显示的却是全白。今天干了件傻事，用球形的模版去匹配眼球，听起来不错，还写了半天。最后发现，其实相当于腐蚀了一下，绕了个大弯子。郁闷。