车牌识别

1

noreply@blogger.com (Unknown) — Fri, 17 Feb 2017 12:17:00 +0800

noreply@blogger.com (Unknown) — Wed, 26 Oct 2011 23:04:00 +0800

车号定位识别与可信度估计.PDF

图像五值化与基于三值图像的车牌识别

noreply@blogger.com (Unknown) — Mon, 3 Jan 2011 13:45:00 +0800

"图像五值化与基于三值图像的车牌识别.pdf", 欢迎大家下载分享！http://sinaurl.cn/hbCNwA

作者为车牌识别QQ群管理员@yulaohui，引用请注明原出处。

SURF综述[转]

noreply@blogger.com (Unknown) — Wed, 17 Nov 2010 18:38:00 +0800

转自http://blog.sina.com.cn/s/blog_62f65fdc0100lqb4.html

SURF特点：

1.使用积分图像完成图像卷积（相关）操作;

2，使用Hessian矩阵检测特征值；

3，使用基于分布的描述符（局部信息）。

兴趣点检测相关研究：

1998 Lindberg介绍自动尺度选择的概念，允许检测图像中的兴趣点在它们的特征尺度上。他实验了Hessian矩阵的行列式和Laplacian(和矩阵的迹一致)检测团状结构。

1998 Lowe提出用DOG近似LOG。

2001 Mikolajczyk 和Schmid 重新定义了这个方法，名为Harris-Laplace和Hessian-Laplace。使用Harris或Hessian矩阵的行列式来选择特征点的闻之，使用Laplacian选择尺度。

此外Mikolajczyk（2005，2006）还做了一些算子的比较工作。从中可知：基于Hessian检测器比基于Harris检测器更稳定，重复检测性更好。此外，使用Hessian矩阵的行列式比使用它的迹更有优势。同时也发现使用类似于DOG的近似方法可以提高速度但只损失很小的精度。

描述符的相关研究:

图像特征点的描述符一个共同点是表达了兴趣点邻域内小尺度的特征分布。使得描述符的描述性更好，识别性更高。SIFT的特点正是掌握了空间域亮度模式的大量信息（基于直方图方法：8个方向的箱格，4*4像素）。描述了特征点邻域内点的梯度方向信息，共128维。

PCA-SIFT：36维，匹配速度更快，但区分度下降，并且延长了特征的计算时间。

GLOH：区分度更高但是数据压缩花销时间太长。

2006 Grabner使用积分图像近似SIFT。可以达到和我们同样的速度。但是相比SIFT质量有所下降。（为SURF提供了重要信息积分图像）。

匹配算法：BBF（k-d tree）,balltrees, vocabulary trees, locality sensitine hashing.本文补充提出了，使用Hessian矩阵的迹来显著提高匹配速度。在低维描述符下，任何算法的匹配速度都很快。

二．兴趣点检测。

使用HESSIAN矩阵的近似检测兴趣点。使用积分图像加快计算。

2001 Viola and Jones 提出积分图像的概念。

1998 Simard 提出的盒形计算框架使用积分图像。

本文的创新点：

使用近似的Hessian矩阵来求特征点。DOG近似LOG，盒形滤波近似不同的二次微分。

在3*3*3的邻域范围内寻找Hessian矩阵的行列式最大值。9*9盒形滤波器相当于方差1.2的高斯函数。

图像尺度的改变是通过改变盒形滤波器尺寸实现的。尺度空间的分组时，相邻组首尺度滤波器大小之差相差2倍。如第一二组差6，则二三组差12.为了减少计算时间，第一组采样间隔1像素，第二组2像素，以此倍增。

特征点的精确定位即实现亚像素描述，通过LOWE文章中提出的泰勒级数展开，可求得。

三．特征点描述与匹配

本文提出的是，建立一阶Haar小波在x和y上的响应的分布（局部信息整合），使用积分图像提高计算速度，并且只有64维。使用Laplacian（迹）的符号来索引特征点，方便匹配。

小波变换的重要用途是图像压缩。在图像识别等应用中主要应用于人脸识别和行人识别。

2002 haar-like features

2001 矩形特征与Adaboost（一种级联滤波器，识别）VIOL

1998 a general frame work for object detection

1997 pedestrian detction using wavelet template

3.1方向赋值

选定一个6S（尺度）的圆，对每个像素计算边长为4S的Haar小波。使用原点在特征点，方差2s的高斯函数为权重函数。计算60度滑动窗内的像素在x和y方向的小波模的和。滑动窗以5度为一步转动，选择出圆内模值最大的向量，它的方向即为主方向。

基于Haar小波响应总和的描述符。选取以特征点为中心边长为20S的正方形区域，其中正方形的边和特征点的主方向向量垂直。（不同尺度的图像特征点选取的正方形边长不同）。将5*5的局部正方形投影到4*4的的子图中。每个描述符有4*4个子图组成。用方差为3.3S的高斯函数产生权重系数，减小离特征点远的像素的比重。

匹配时可使用Hessian矩阵的迹的符号，提供额外匹配信息，加快匹配速度。结合Kd-tree.

程序实现：

在opencv实现的函数里，圆形区域用方形区域替代。在计算描述符的方形中边长是20*20，实际选取时是21*21，以特征点为中心。另外由于矩形特征计算的缘故，边缘部分的几个像素不计算。如果起始盒形滤波器的边长为9，则距离边界四个像素以内的点才可以计算。

应用程序与MFC规则DLL共享MFC DLL（或MFC扩展DLL）资源模块句柄的切换

noreply@blogger.com (Unknown) — Thu, 11 Nov 2010 14:20:00 +0800

产生这个问题的根源在于应用程序与MFC规则DLL共享MFC DLL（或MFC扩展DLL）的程序总是默认使用EXE的资源，我们必须进行资源模块句柄的切换，其实现方法有三：

方法一在DLL接口函数中使用：

AFX_MANAGE_STATE(AfxGetStaticModuleState());

我们将DLL中的接口函数ShowDlg改为：

void ShowDlg(void)

{

//方法1:在函数开始处变更，在函数结束时恢复

//将AFX_MANAGE_STATE(AfxGetStaticModuleState());作为接口函数的第一//条语句进行模块状态切换

AFX_MANAGE_STATE(AfxGetStaticModuleState());

CDialog dlg(IDD_DLL_DIALOG);//打开ID为2000的对话框

dlg.DoModal();

}

这次我们再点击EXE程序中的"调用DLL"按钮，弹出的是DLL中的如图13的对话框！嘿嘿，弹出了正确的对话框资源。

AfxGetStaticModuleState是一个函数，其原型为：

AFX_MODULE_STATE* AFXAPI AfxGetStaticModuleState( );

该函数的功能是在栈上（这意味着其作用域是局部的）创建一个AFX_MODULE_STATE类（模块全局数据也就是模块状态）的实例，对其进行设置，并将其指针pModuleState返回。

AFX_MODULE_STATE类的原型如下：

// AFX_MODULE_STATE (global data for a module)

class AFX_MODULE_STATE : public CNoTrackObject

{

public:

#ifdef _AFXDLL

AFX_MODULE_STATE(BOOL bDLL, WNDPROC pfnAfxWndProc, DWORD dwVersion);

AFX_MODULE_STATE(BOOL bDLL, WNDPROC pfnAfxWndProc, DWORD dwVersion,BOOL bSystem);

#else

AFX_MODULE_STATE(BOOL bDLL);

MFC规则DLL的创建与使用技巧[转]

noreply@blogger.com (Unknown) — Thu, 11 Nov 2010 14:17:00 +0800

第4节我们对非MFC DLL进行了介绍，这一节将详细地讲述MFC规则DLL的创建与使用技巧。

5. MFC规则DLL

5.1 概述

MFC规则DLL的概念体现在两方面：

（1）它是MFC的

“是MFC的”意味着可以在这种DLL的内部使用MFC；

（2）它是规则的

“是规则的”意味着它不同于MFC扩展DLL，在MFC规则DLL的内部虽然可以使用MFC，但是其与应用程序的接口不能是MFC。而MFC扩展DLL与应用程序的接口可以是MFC，可以从MFC扩展DLL中导出一个MFC类的派生类。

Regular DLL能够被所有支持DLL技术的语言所编写的应用程序调用，当然也包括使用MFC的应用程序。在这种动态连接库中，包含一个从CWinApp继承下来的类，DllMain函数则由MFC自动提供。

Regular DLL分为两类：

（1）静态链接到MFC 的规则DLL

静态链接到MFC的规则DLL与MFC库（包括MFC扩展 DLL）静态链接，将MFC库的代码直接生成在.dll文件中。在调用这种DLL的接口时，MFC使用DLL的资源。因此，在静态链接到MFC 的规则DLL中不需要进行模块状态的切换。

使用这种方法生成的规则DLL其程序较大，也可能包含重复的代码。

（2）动态链接到MFC 的规则DLL

动态链接到MFC 的规则DLL 可以和使用它的可执行文件同时动态链接到 MFC DLL 和任何MFC扩展 DLL。在使用了MFC共享库的时候，默认情况下，MFC使用主应用程序的资源句柄来加载资源模板。这样，当DLL和应用程序中存在相同ID的资源时（即所谓的资源重复问题），系统可能不能获得正确的资源。因此，对于共享MFC DLL的规则DLL，我们必须进行模块切换以使得MFC能够找到正确的资源模板。

我们可以在Visual C++中设置MFC规则DLL是静态链接到MFC DLL还是动态链接到MFC DLL。如图8，依次选择Visual C++的project -> Settings -> General菜单或选项，在Microsoft Foundation Classes中进行设置。

图8 设置动态/静态链接MFC DLL

5.2 MFC规则DLL的创建

我们来一步步讲述使用MFC向导创建MFC规则DLL的过程，首先新建一个project，如图9，选择project的类型为MFC AppWizard(dll)。点击OK进入如图10所示的对话框。

图9 MFC DLL工程的创建

图10所示对话框中的1区选择MFC DLL的类别。

2区选择是否支持automation（自动化）技术， automation 允许用户在一个应用程序中操纵另外一个应用程序或组件。例如，我们可以在应用程序中利用 Microsoft Word 或Microsoft Excel的工具，而这种使用对用户而言是透明的。自动化技术可以大大简化和加快应用程序的开发。

3区选择是否支持Windows Sockets，当选择此项目时，应用程序能在 TCP/IP 网络上进行通信。 CWinApp派生类的InitInstance成员函数会初始化通讯端的支持，同时工程中的StdAfx.h文件会自动include <AfxSock.h>头文件。

添加socket通讯支持后的InitInstance成员函数如下：

BOOL CRegularDllSocketApp::InitInstance()

{

if (!AfxSocketInit())

{

AfxMessageBox(IDP_SOCKETS_INIT_FAILED);

return FALSE;

}

return TRUE;

}

4区选择是否由MFC向导自动在源代码中添加注释，一般我们选择“Yes,please”。

图10 MFC DLL的创建选项

5.3 一个简单的MFC规则DLL

这个DLL的例子（属于静态链接到MFC 的规则DLL）中提供了一个如图11所示的对话框。

图11 MFC规则DLL例子

在DLL中添加对话框的方式与在MFC应用程序中是一样的。在图11所示DLL中的对话框的Hello按钮上点击时将MessageBox一个“Hello,pconline的网友”对话框，下面是相关的文件及源代码，其中删除了MFC向导自动生成的绝大多数注释:

第一组文件：CWinApp继承类的声明与实现

// RegularDll.h : main header file for the REGULARDLL DLL

#if !defined(AFX_REGULARDLL_H__3E9CB22B_588B_4388_B778_B3416ADB79B3__INCLUDED_)

#define AFX_REGULARDLL_H__3E9CB22B_588B_4388_B778_B3416ADB79B3__INCLUDED_

#if _MSC_VER > 1000

#pragma once

开源OCR引擎Tesseract 3.0发布支持中文

noreply@blogger.com (Unknown) — Wed, 6 Oct 2010 19:08:00 +0800

知名的开源OCR引擎Tesseract 3.0版本日前发布，可以在项目网站下载：http://code.google.com/p/tesseract-ocr。对中国用户来说，一个好消息是新版本支持中文。

Tesseract是Ray Smith于1985到1995年间在惠普布里斯托实验室开发的一个OCR引擎，曾经在1995 UNLV精确度测试中名列前茅。但1996年后基本停止了开发。2006年，Google邀请Smith加盟，重启该项目。目前项目的许可证是Apache 2.0。

该项目目前支持Windows、Linux和Mac OS等主流平台。但作为一个引擎，它只提供核心功能，没有界面。

有兴趣参加该项目的同学，可以加入：http://groups.google.com/group/tesseract-dev/，或者与Smith联系.

关于字符编码，你所需要知道的

noreply@blogger.com (Unknown) — Sat, 19 Jun 2010 21:23:00 +0800

关于字符编码，你所需要知道的

字符编码的问题看似很小，经常被技术人员忽视，但是很容易导致一些莫名其妙的问题。这里总结了一下字符编码的一些普及性的知识，希望对大家有所帮助。

还是得从ASCII码说起

说到字符编码，不得不说ASCII码的简史。计算机一开始发明的时候是用来解决数字计算的问题，后来人们发现，计算机还可以做更多的事，例如文本处理。但由于计算机只识"数"，因此人们必须告诉计算机哪个数字来代表哪个特定字符，例如65代表字母'A'，66代表字母'B'，以此类推。但是计算机之间字符-数字的对应关系必须得一致，否则就会造成同一段数字在不同计算机上显示出来的字符不一样。因此美国国家标准协会ANSI制定了一个标准，规定了常用字符的集合以及每个字符对应的编号，这就是ASCII字符集（Character Set），也称ASCII码。

当时的计算机普遍使用8比特字节作为最小的存储和处理单元，加之当时用到的字符也很少，26个大小写英文字母还有数字再加上其他常用符号，也不到100个，因此使用7个比特位就可以高效的存储和处理ASCII码，剩下最高位1比特被用作一些通讯系统的奇偶校验。

注意，字节代表系统能够处理的最小单位，不一定是8比特。只是现代计算机的事实标准就是用8比特来代表一个字节。在很多技术规格文献中，为了避免产生歧义，更倾向于使用8位组（Octet）而不是字节（Byte）这个术语来强调8个比特的二进制流。下文中为了便于理解，我会延用大家熟悉的"字节"这个概念。

ASCII字符集由95个可打印字符（0x20-0x7E）和33个控制字符（0x00-0x19，0x7F）组成。可打印字符用于显示在输出设备上，例如荧屏或者打印纸上，控制字符用于向计算机发出一些特殊指令，例如0x07会让计算机发出哔的一声，0x00通常用于指示字符串的结束，0x0D和0x0A用于指示打印机的打印针头退到行首（回车）并移到下一行（换行）。

那时候的字符编解码系统非常简单，就是简单的查表过程。例如将字符序列编码为二进制流写入存储设备，只需要在ASCII字符集中依次找到字符对应的字节，然后直接将该字节写入存储设备即可。解码二进制流的过程也是类似。

OEM字符集的衍生

当计算机开始发展起来的时候，人们逐渐发现，ASCII字符集里那可怜的128个字符已经不能再满足他们的需求了。人们就在想，一个字节能够表示的数字（编号）有256个，而ASCII字符只用到了0x00~0x7F，也就是占用了前128个，后面128个数字不用白不用，因此很多人打起了后面这128个数字的主意。可是问题在于，很多人同时有这样的想法，但是大家对于0x80-0xFF这后面的128个数字分别对应什么样的字符，却有各自的想法。这就导致了当时销往世界各地的机器上出现了大量各式各样的OEM字符集。

下面这张表是IBM-PC机推出的其中一个OEM字符集，字符集的前128个字符和ASCII字符集的基本一致（为什么说基本一致呢，是因为前32个控制字符在某些情况下会被IBM-PC机当作可打印字符解释），后面128个字符空间加入了一些欧洲国家用到的重音字符，以及一些用于画线条画的字符。

事实上，大部分OEM字符集是兼容ASCII字符集的，也就是说，大家对于0x00~0x7F这个范围的解释基本是相同的，而对于后半部分0x80~0xFF的解释却不一定相同。甚至有时候同样的字符在不同OEM字符集中对应的字节也是不同的。

不同的OEM字符集导致人们无法跨机器交流各种文档。例如职员甲发了一封简历résumés给职员乙，结果职员乙看到的却是rsums，因为é字符在职员甲机器上的OEM字符集中对应的字节是0x82，而在职员乙的机器上，由于使用的OEM字符集不同，对0x82字节解码后得到的字符却是。

多字节字符集（MBCS）和中文字符集

上面我们提到的字符集都是基于单字节编码，也就是说，一个字节翻译成一个字符。这对于拉丁语系国家来说可能没有什么问题，因为他们通过扩展第8个比特，就可以得到256个字符了，足够用了。但是对于亚洲国家来说，256个字符是远远不够用的。因此这些国家的人为了用上电脑，又要保持和ASCII字符集的兼容，就发明了多字节编码方式，相应的字符集就称为多字节字符集。例如中国使用的就是双字节字符集编码（DBCS，Double Byte Character Set）。

对于单字节字符集来说，代码页中只需要有一张码表即可，上面记录着256个数字代表的字符。程序只需要做简单的查表操作就可以完成编解码的过程。

代码页是字符集编码的具体实现，你可以把他理解为一张"字符-字节"映射表，通过查表实现"字符-字节"的翻译。下面会有更详细的描述。

而对于多字节字符集，代码页中通常会有很多码表。那么程序怎么知道该使用哪张码表去解码二进制流呢？答案是，根据第一个字节来选择不同的码表进行解析。

例如目前最常用的中文字符集GB2312，涵盖了所有简体字符以及一部分其他字符；GBK（K代表扩展的意思）则在GB2312的基础上加入了对繁体字符等其他非简体字符（GB18030字符集不是双字节字符集，我们在讲Unicode的时候会提到）。这两个字符集的字符都是使用1-2个字节来表示。Windows系统采用936代码页来实现对GBK字符集的编解码。在解析字节流的时候，如果遇到字节的最高位是0的话，那么就使用936代码页中的第1张码表进行解码，这就和单字节字符集的编解码方式一致了。

当字节的高位是1的时候，确切的说，当第一个字节位于0x81–0xFE之间时，根据第一个字节不同找到代码页中的相应的码表，例如当第一个字节是0x81，那么对应936中的下面这张码表：

（关于936代码页中完整的码表信息，参见MSDN：http://msdn.microsoft.com/en-us/library/cc194913%28v=MSDN.10%29.aspx.）

按照936代码页的码表，当程序遇到连续字节流0x81 0x40的时候，就会解码为"丂"字符。

ANSI标准、国家标准、ISO标准

不同ASCII衍生字符集的出现，让文档交流变得非常困难，因此各种组织都陆续进行了标准化流程。例如美国ANSI组织制定了ANSI标准字符编码（注意，我们现在通常说到ANSI编码，通常指的是平台的默认编码，例如英文操作系统中是ISO-8859-1，中文系统是GBK），ISO组织制定的各种ISO标准字符编码，还有各国也会制定一些国家标准字符集，例如中国的GBK，GB2312和GB18030。

操作系统在发布的时候，通常会往机器里预装这些标准的字符集还有平台专用的字符集，这样只要你的文档是使用标准字符集编写的，通用性就比较高了。例如你用GB2312字符集编写的文档，在中国大陆内的任何机器上都能正确显示。同时，我们也可以在一台机器上阅读多个国家不同语言的文档了，前提是本机必须安装该文档使用的字符集。

Unicode的出现

虽然通过使用不同字符集，我们可以在一台机器上查阅不同语言的文档，但是我们仍然无法解决一个问题：在一份文档中显示所有字符。为了解决这个问题，我们需要一个全人类达成共识的巨大的字符集，这就是Unicode字符集。

Unicode字符集概述

Unicode字符集涵盖了目前人类使用的所有字符，并为每个字符进行统一编号，分配唯一的字符码（Code Point）。Unicode字符集将所有字符按照使用上的频繁度划分为17个层面（Plane），每个层面上有2¹⁶=65536个字符码空间。

其中第0个层面BMP，基本涵盖了当今世界用到的所有字符。其他的层面要么是用来表示一些远古时期的文字，要么是留作扩展。我们平常用到的Unicode字符，一般都是位于BMP层面上的。目前Unicode字符集中尚有大量字符空间未使用。

编码系统的变化

在Unicode出现之前，所有的字符集都是和具体编码方案绑定在一起的，都是直接将字符和最终字节流绑定死了，例如ASCII编码系统规定使用7比特来编码ASCII字符集；GB2312以及GBK字符集，限定了使用最多2个字节来编码所有字符，并且规定了字节序。这样的编码系统通常用简单的查表，也就是通过代码页就可以直接将字符映射为存储设备上的字节流了。例如下面这个例子：

这种方式的缺点在于，字符和字节流之间耦合得太紧密了，从而限定了字符集的扩展能力。假设以后火星人入住地球了，要往现有字符集中加入火星文就变得很难甚至不可能了，而且很容易破坏现有的编码规则。

因此Unicode在设计上考虑到了这一点，将字符集和字符编码方案分离开。

也就是说，虽然每个字符在Unicode字符集中都能找到唯一确定的编号（字符码，又称Unicode码），但是决定最终字节流的却是具体的字符编码。例如同样是对Unicode字符"A"进行编码，UTF-8字符编码得到的字节流是0x41，而UTF-16（大端模式）得到的是0x00 0x41。

常见的Unicode编码

UCS-2/UTF-16

如果要我们来实现Unicode字符集中BMP字符的编码方案，我们会怎么实现？由于BMP层面上有2¹⁶=65536个字符码，因此我们只需要两个字节就可以完全表示这所有的字符了。

举个例子，"中"的Unicode字符码是0x4E2D(01001110 00101101)，那么我们可以编码为01001110 00101101（大端）或者00101101 01001110 （小端）。

UCS-2和UTF-16对于BMP层面的字符均是使用2个字节来表示，并且编码得到的结果完全一致。不同之处在于，UCS-2最初设计的时候只考虑到BMP字符，因此使用固定2个字节长度，也就是说，他无法表示Unicode其他层面上的字符，而UTF-16为了解除这个限制，支持Unicode全字符集的编解码，采用了变长编码，最少使用2个字节，如果要编码BMP以外的字符，则需要4个字节结对，这里就不讨论那么远，有兴趣可以参考维基百科：UTF-16/UCS-2。

Windows从NT时代开始就采用了UTF-16编码，很多流行的编程平台，例如.Net，Java，Qt还有Mac下的Cocoa等都是使用UTF-16作为基础的字符编码。例如代码中的字符串，在内存中相应的字节流就是用UTF-16编码过的。

UTF-8

UTF-8应该是目前应用最广泛的一种Unicode编码方案。由于UCS-2/UTF-16对于ASCII字符使用两个字节进行编码，存储和处理效率相对低下，并且由于ASCII字符经过UTF-16编码后得到的两个字节，高字节始终是0x00，很多C语言的函数都将此字节视为字符串末尾从而导致无法正确解析文本。因此一开始推出的时候遭到很多西方国家的抵触，大大影响了Unicode的推行。后来聪明的人们发明了UTF-8编码，解决了这个问题。

UTF-8编码方案采用1-4个字节来编码字符，方法其实也非常简单。

（上图中的x代表Unicode码的低8位，y代表高8位）

对于ASCII字符的编码使用单字节，和ASCII编码一摸一样，这样所有原先使用ASCII编解码的文档就可以直接转到UTF-8编码了。对于其他字符，则使用2-4个字节来表示，其中，首字节前置1的数目代表正确解析所需要的字节数，剩余字节的高2位始终是10。例如首字节是1110yyyy，前置有3个1，说明正确解析总共需要3个字节，需要和后面2个以10开头的字节结合才能正确解析得到字符。

关于UTF-8的更多信息，参考维基百科：UTF-8。

GB18030

任何能够将Unicode字符映射为字节流的编码都属于Unicode编码。中国的GB18030编码，覆盖了Unicode所有的字符，因此也算是一种Unicode编码。只不过他的编码方式并不像UTF-8或者UTF-16一样，将Unicode字符的编号通过一定的规则进行转换，而只能通过查表的手段进行编码。

关于GB18030的更多信息，参考：GB18030。

Unicode相关的常见问题

Unicode是两个字节吗？

Unicode只是定义了一个庞大的、全球通用的字符集，并为每个字符规定了唯一确定的编号，具体存储为什么样的字节流，取决于字符编码方案。推荐的Unicode编码是UTF-16和UTF-8。

带签名的UTF-8指的是什么意思？

带签名指的是字节流以BOM标记开始。很多软件会"智能"的探测当前字节流使用的字符编码，这种探测过程出于效率考虑，通常会提取字节流前面若干个字节，看看是否符合某些常见字符编码的编码规则。由于UTF-8和ASCII编码对于纯英文的编码是一样的，无法区分开来，因此通过在字节流最前面添加BOM标记可以告诉软件，当前使用的是Unicode编码，判别成功率就十分准确了。但是需要注意，不是所有软件或者程序都能正确处理BOM标记，例如PHP就不会检测BOM标记，直接把它当普通字节流解析了。因此如果你的PHP文件是采用带BOM标记的UTF-8进行编码的，那么有可能会出现问题。

Unicode编码和以前的字符集编码有什么区别？

早期字符编码、字符集和代码页等概念都是表达同一个意思。例如GB2312字符集、GB2312编码，936代码页，实际上说的是同个东西。但是对于Unicode则不同，Unicode字符集只是定义了字符的集合和唯一编号，Unicode编码，则是对UTF-8、UCS-2/UTF-16等具体编码方案的统称而已，并不是具体的编码方案。所以当需要用到字符编码的时候，你可以写gb2312，codepage936，utf-8，utf-16，但请不要写unicode（看过别人在网页的meta标签里头写charset=unicode，有感而发）。

乱码问题

乱码指的是程序显示出来的字符文本无法用任何语言去解读。一般情况下会包含大量?或者�。乱码问题是所有计算机用户或多或少会遇到的问题。造成乱码的原因就是因为使用了错误的字符编码去解码字节流，因此当我们在思考任何跟文本显示有关的问题时，请时刻保持清醒：当前使用的字符编码是什么。只有这样，我们才能正确分析和处理乱码问题。

例如最常见的网页乱码问题。如果你是网站技术人员，遇到这样的问题，需要检查以下原因：

服务器返回的响应头Content-Type没有指明字符编码
网页内是否使用META HTTP-EQUIV标签指定了字符编码
网页文件本身存储时使用的字符编码和网页声明的字符编码是否一致

注意，网页解析的过程如果使用的字符编码不正确，还可能会导致脚本或者样式表出错。具体细节可以参考我以前写过的文章：文档字符集导致的脚本错误和Asp.Net页面的编码问题。

不久前看到某技术论坛有人反馈，WinForm程序使用Clipboard类的GetData方法去访问剪切板中的HTML内容时会出现乱码的问题，我估计也是由于WinForm在获取HTML文本的时候没有用对正确的字符编码导致的。Windows剪贴板只支持UTF-8编码，也就是说你传入的文本都会被UTF-8编解码。这样一来，只要两个程序都是调用Windows剪切板API编程的话，那么复制粘贴的过程中不会出现乱码。除非一方在获取到剪贴板数据之后使用了错误的字符编码进行解码，才会得到乱码（我做了简单的WinForm剪切板编程实验，发现GetData使用的是系统默认编码，而不是UTF-8编码）。

关于乱码中出现?或者�，这里需要额外提一下，当程序使用特定字符编码解析字节流的时候，一旦遇到无法解析的字节流时，就会用?或者�来替代。因此，一旦你最终解析得到的文本包含这样的字符，而你又无法得到原始字节流的时候，说明正确的信息已经彻底丢失了，尝试任何字符编码都无法从这样的字符文本中还原出正确的信息来。

必要的术语解释

字符集（Character Set），字面上的理解就是字符的集合，例如ASCII字符集，定义了128个字符；GB2312定义了7445个字符。而计算机系统中提到的字符集准确来说，指的是已编号的字符的有序集合（不一定是连续）。

字符码（Code Point）指的就是字符集中每个字符的数字编号。例如ASCII字符集用0-127这连续的128个数字分别表示128个字符；GBK字符集使用区位码的方式为每个字符编号，首先定义一个94X94的矩阵，行称为"区"，列称为"位"，然后将所有国标汉字放入矩阵当中，这样每个汉字就可以用唯一的"区位"码来标识了。例如"中"字被放到54区第48位，因此字符码就是5448。而Unicode中将字符集按照一定的类别划分到0~16这17个层面（Planes）中，每个层面中拥有2¹⁶=65536个字符码，因此Unicode总共拥有的字符码，也即是Unicode的字符空间总共有17*65536=1114112。

编码的过程是将字符转换成字节流。

解码的过程是将字节流解析为字符。

字符编码（Character Encoding）是将字符集中的字符码映射为字节流的一种具体实现方案。例如ASCII字符编码规定使用单字节中低位的7个比特去编码所有的字符。例如'A'的编号是65，用单字节表示就是0x41，因此写入存储设备的时候就是b'01000001'。GBK编码则是将区位码（GBK的字符码）中的区码和位码的分别加上0xA0（160）的偏移（之所以要加上这样的偏移，主要是为了和ASCII码兼容），例如刚刚提到的"中"字，区位码是5448，十六进制是0x3630，区码和位码分别加上0xA0的偏移之后就得到0xD6D0，这就是"中"字的GBK编码结果。

代码页（Code Page）一种字符编码具体形式。早期字符相对少，因此通常会使用类似表格的形式将字符直接映射为字节流，然后通过查表的方式来实现字符的编解码。现代操作系统沿用了这种方式。例如Windows使用936代码页、Mac系统使用EUC-CN代码页实现GBK字符集的编码，名字虽然不一样，但对于同一汉字的编码肯定是一样的。

大小端的说法源自《格列佛游记》。我们知道，鸡蛋通常一端大一端小，小人国的人们对于剥蛋壳时应从哪一端开始剥起有着不一样的看法。同样，计算机界对于传输多字节字（由多个字节来共同表示一个数据类型）时，是先传高位字节（大端）还是先传低位字节（小端）也有着不一样的看法，这就是计算机里头大小端模式的由来了。无论是写文件还是网络传输，实际上都是往流设备进行写操作的过程，而且这个写操作是从流的低地址向高地址开始写（这很符合人的习惯），对于多字节字来说，如果先写入高位字节，则称作大端模式。反之则称作小端模式。也就是说，大端模式下，字节序和流设备的地址顺序是相反的，而小端模式则是相同的。一般网络协议都采用大端模式进行传输。

——Kevin Yang

参考链接：

noreply@blogger.com (Unknown) — Thu, 29 Apr 2010 18:58:00 +0800

Contextual Models for Object Detection Using Boosted Random Fields.pdf

面试前需考虑的25个问题-褪墨

noreply@blogger.com (Unknown) — Wed, 14 Apr 2010 08:36:00 +0800

褪墨|关于时间管理、个人提升和演讲技巧。欢迎浏览http://www.mifengtd.cn/，查看更多好文章～

面试前需考虑的25个问题

Thu, 08 Apr 2010 09:29:03 +0800

我曾经在The Simple Dollar上提到自己过去曾组织了大量面试工作。虽然我招聘的通常是技术类职位，但实际问到的问题（因此是有实际价值的）都是无关技术的。一个好的面试问题能使应聘者的本性显露出来――诚实，可信，反应敏锐等等。

长期以来，我收集了一些自己在面试中总会用到的问题，这里整理出25个最有价值的，附带一两个把每个问题回答好的技巧或怎么会把它弄糟的案例。希望这个总结能为面试官和应聘者提供一些有洞见的参考，若你能轻而易举回答所有问题，面试就不必担心了。最后，我将给出一份核对清单作为"家庭作业"给每个即将面临重要面试的应聘者。

首先，愚蠢地回答愚蠢的问题。

工作面试中有许多问题非常愚蠢，而且都有显而易见的答案。"你最大的弱点是什么？"这个问题从来不可能得到一个诚实的答案，而且多数时候只会招致一些例如"我是工作狂！"的虚伪回答。面试官问这些问题是因为这些都是"应该"被问的，但他们通常不会从中得到任何有效信息。"你认为自己成功吗？"，答案总是肯定的；"你具有团队精神吗？"答案也总是肯定的；"你打算在这儿工作多久？"答案总是长期；"工作和薪水何者更重要？"，答案总是工作比薪水更重要。

识别一个无聊的问题很简单――你是不是能很容易地给出一个放之四海皆准之而又无关痛痒的答案？如果是的，别为这问题费神，把精力放在解决具有实际意义的问题上。

1. 介绍你自己

这个问题基本是为了让应聘者放松，同时也给我自己判断他们谈吐的机会。这是一个在一切面试中都需要准备的问题，所以你需要有一个固定的答案。走进面试室前在头脑中对这个问题要有个清晰的答案。"最佳"答案要能使你充分展现自己与众不同之处，以使自己在众多应聘者中脱颖而出。列出自己的四五项最大特点，用三十秒陈述出来。

2. 谈谈你对我们的了解

这个问题直接考察了面试者是否做了准备功课。一个能讲出公司大量信息的面试者也许是出乎意料的，但连基本情况都不了解的人多数会被淘汰――那不是我们要的人。换言之，面试前，了解你将应聘的那个机构。

3. 什么使你区别于其他应聘者

面试官通常基于简历已经得到了这个问题的答案，但这是你真正自我推销的时候。多数面试官都会坐在一旁看你把自己推销得如何。偶尔惊喜是好的，但也可能显得狡猾――如果某些内容应该在简历上出现，却为什么未出现？你该知道自己简历的精华何在，然后将它们列出。

4. 描述你应聘的职位

这也是一道"作业"题，但通过应聘者当场给出的见解也能掌握一些信息。最佳准备是阅读职位描述并用自己的语言对自己复述出来，以便在面试时流利应答。

5. 为何对此职位感兴趣

这个问题实际上有些像一个小把戏，因为这是对第二个问题（你对公司的了解）以及第四个问题（描述你应聘的职位）的回问。这样问是因为它有助于判断：人们是轻率作答（像是"因为我就是合适人选"），还是考虑之后诚恳作答。对这个问题可以事先准备好一个程述式的答案――大致上，只要给出一些这个公司和职位吸引你的理由以及它们为何吸引你。

6. 这个职位的哪一方面使你感到最不适

多数人认为这个问题会涉及淘汰，但通常它并非如此。这其实是个诚实问题。没有人会对某项工作的每个方面都满意――这不是我们的天性。工作地点？工作时间？同事？公司规模太大？太小？诚实在此很重要――我希望听到一个感到不适的诚恳理由（尤其是真正从对公司的观察中得来），而不是一句没有任何不适的陈词滥调。好的回答可以是"我从未在如此大规模的公司工作过"，或"在协作文化上我听说了一些奇怪的方面"、或"在起步阶段工作使我感到紧张"等。

7. 上一份工作中你最大的成功是什么？
8. 上一份工作中你最大的失败是什么？

这两个问题通常可以组成一组，但重要的是后者。最好的应聘者应该承认自己有过过失（他们诚实而敢于承认错误）并从中吸取了教训，这是一项无比重要的美德。

9. 说说你先前最好的上司
10. 说说你先前最糟的上司

这两个问题能直接试探出面试者适合于何种管理风格以及会如何管理他人。假设我就职于一个管理松散而需要自我驱动的机构，这种情况下，我希望听到的回答是"最佳"老板是万事不插手的，或者"最糟"老板是事事盯紧的。相反，若我在等级森严的机构，我希望听到的恰恰相反――"最佳"老板提供有强度的引导和交流，或"最糟"老板是让应聘者无所适从的。最佳办法是尽可能诚实应答――面试官会对协作文化有很好的认识，坦率地说，如果你侥幸进入了一家公司而并不匹配那里的文化，适应和取得成功将会很艰难。这些问题也可以以"你倾向于何种管理模式"的方式提问。

其他技巧：突出论及所有老板的优点，绝不要把面试变成一场针对任何人的批判会。最糟的老板会有一些小毛病而且都是处于对你的期望而不是有人格缺陷。面试中抱怨别人只会使你自己显得恶劣，所以别上当了。

11. 说说你曾遇到的最困难的项目

面试官通常不真正关注项目具体是什么，其实质是看看你是否经历过真正的困难并如何克服它。对大多数人而言，这并不是最大的成功或失败，而是将失败方面转化为成功的方面。

12. 对这个领域的未来趋势有何看法

这个问题对一些领域有用――技术类或领导岗位――对其他一些则没用。这个问题有用没用在你应聘的特定工作类型中是显而易见的。如果有用，答案的准备很简单――只要花上半小时阅读相关领域的一些博客文章你就能汲取所需信息。

13. 去年中是否在与这项工作有关要求方面学到了新的东西/提升了自己

这是一个很容易让人无所适从的问题，多少人就是想不出答案。最佳应对方式其实就是总是花一些时间以任何方式提升自己的技能。写写开源代码、实践一下当主持人、上上课等，如果你每年都投入经历提升自己，不但会有一份漂亮的简历，当然这个问题也就不算什么了。

14. 说说你梦想中的职业

绝不要说这项工作，绝不要说另一项具体的工作。这两种回答都实在糟糕――前者树起了警旗而后者说明你无心恋战。回答应该紧贴一些具体的特质――讲讲你梦想中工作的一些方面。可以的话其中一些应该契合你要应聘的单位，但不要完全契合是最好的。

15. 之前工作中遇到过严重冲突吗？它是如何解决的？

这个问题需要诚实，同时需意识到任何事物的矛盾都包含两方面。它同样可能会让那些不厚道的人开始抱怨前任雇主，以至于给面试官留下坏印象。最好的回答方式通常包括描述事实，但同时注意事件的两方面，而且你从中学会了从他人的角度考虑问题。

16. 从上份工作中学到了什么

虽然列出一些技术上的技能，尤其如果你的工作是很技术性的，那很好，但涉及一些非技术性内容很重要。"在多数时候单独工作后，我学到了怎样在一个团队中工作"，像这样的回答就很好。任何工作中都可以学到些什么，面试官期待你能从上一份工作中学到些什么以助于你胜任新的工作。

17. 上份工作为何离职

多数时候，这是在考察一个稳定的性格。强有力且具体的回答，无论具体理由如何都是好的。"我想继续前进" 不算一个强有力的理由。裁员是个好理由，同样寻找一些特殊的新挑战也是好理由（但想要接受的挑战得要有特点）。在此，应该淡化对前任工作的具体描述，因为这样会很容易陷入对之前职位的抱怨之中。

18. 对上个工作岗位提一个可行的建议

虽然答案会很大程度上牵涉到上任工作的特殊性质，但其实那些特殊性质并不重要。最重要的是你确实给出了建议并使它富有成果，最好再加上一些成功的故事。这样做显得你也会对新职位有同样贡献，来提升整个机构。在这个问题上没有答案并不是大缺陷，不会是一个决定"生死"的问题。

19. 有被辞退过吗？说说这一经历

显而易见，能说"没有"最好，但答案是"有"其实也不会被一片否决。事实上，"有"也能转化为积极因素――这是表明你虽有过过错但从中学到了有价值的教训的良好途径。在这个问题上要诚实，无论如何别埋怨让你走人的人。即使对于发生的事感到气愤，也要带有敬意地提到他们。

20. 解雇过别人吗？说说这一经历

这个问题基本是考察你对人是否有宽容之心。回答时务必谨慎――这绝不是一个简单的选择题或经历叙述，而关系到你的去留。也别埋怨被你解雇的人――尽可能用理由冷静地回答。

21. 同时还在应征其他工作吗？

这是一个相关诚实的问题，我期待听到"是的"，但太想迎合我胃口的人回答说"没有"。最佳回答方式是"是的，就像你们还在面试其他人那样。我们都在寻求最佳选择。"如果你的答案是"没有"，那么这么说――"没有，其实我对现在的工作是满意的，但是你们提供的这个职位有些非常吸引我的地方驱使我来这儿应聘。 "然后列举出那些吸引你的地方。

22. 你认为这个职位的报酬应当如何

很多人可能会感到惊奇，这通常并非在协商工资。多数时候，面试你的人都不负责你能得到的工资。这个问题通常是一个现实的考量――如果招清洁工，他们想要80K美元工资，那你大概会立即把应聘书投进垃圾箱；同样，一个高技能的程序员只把自己卖到30k美元也是在敲警钟。好的回答通常要靠谱或稍稍高于实际而不是低得过分或高得疯狂。我在面试前都会了解好要价，然后在回答中多加30%。

23. 自认为五年后自己在职业中发展如何

这是个有点"垃圾"的问题，但就某些方面说它可以筛选出那些具有主观能动性的人。回答类似于"我将在我应聘的岗位中取得成功"的人既不够积极也不够诚实。我宁可得到包括提升或成为企业家――强大的机构之繁荣有赖于做事主动的人。对面试者来说唯一的问题是一些公司――通常是小公司――并不需要做事主动的人而且特别害怕那些梦想成为企业家的人。因此如果对企业文化不熟悉，谈及升职通常是最安全的。但我个人欣赏在面试中谈到企业家的人――那意味他们对成功怀有热情的那类人。

24. 你的长远目标是什么――比如，从事这项事业十五年后？

这是一个迟来的好问题，因为它能帮你判断面试者是否是长远计划者。因为有长远计划的人通常有一个良好而成熟的思维状态，而且会始终绷紧弦努力工作，胜于没有长远计划的人。

25. 对这项工作还有何疑问？

是，你确实该对这项工作有疑问，没有问题意味着你并未真正对这个职位产生兴趣。因此，面试者必须把在面试前准备的一些问题作为一项任务来对待。大多数面试官都乐于回答一切问题――只要确保你的问题是理智的就行。

准备功课!

以下功课在任何面试前都需要准备，以帮助你应对上述绝大多数问题。

准备十分简洁的自我描述：以便在任何面试中都可以用。最好的技巧是提到自己与众不同甚至独一无二的地方，同时兼顾不突出或（最坏的话）中庸之处――保留自己的缺陷，除非它和一个重要的优点有关联。连续的三十秒陈述即可。
研究公司：通过访问他们的网页了解他们究竟做些什么。最好阅读公司近些年的年度报告和它在维基上的描述（如果它足够大），或者用Google搜索公司名字和地点（如果是小公司）。如果它处于起步阶段，找尽可能多的资料，如果相关资料实在太少，就别再多花精力了。
研究职位：认真阅读招聘启事，对任何不懂之处都要查阅。如果还不甚熟悉，你还必须让自己深入阅读招聘启事以让自己清楚这一领域的重要信息何在――从博客和新闻网页开始是不错的选择。你还应该在生活范围附近调查一下类似工作，以对这类工作的常规起步工资心中有数。
了解自己适合这一职位的原因：收集你能找到的公司信息和招聘启事，将它们与自己的技能作对照。这样做五份，它们在面试中会有奇效。同时，找出至少一项自己对公司或职位不满之处然后思考为什么这使你不满。
不断努力提升工作技能：参与能使你提高相关领域关键技能的活动。任职人际关系领域吗？加入一个主持人协会；任职行政助理吗？加入为某个机构服务的志愿工作，以不同方式锻炼你的能力（同样适用于从事贸易者）；任职程序员吗？那就为一项开源项目作点贡献。
在头脑中储备一些对应聘职位的问题：当你进入面试室。这能给人一个强烈的印象，说明你确实对那个职位感兴趣，这将大有益处。各类问题都可以，但最好涉及工作中的协作文化和特定技术。
千万不要抱怨之前的工作：如果先前的工作中确实有让你懊恼之处，花些时间试着想想它的积极方面。要知道面试时先前工作至少在某种程度上会被提及，因此准备好不带消极情绪谈论它，寻找积极因素，同时尽可能冷静陈述离职理由。
诚实：首当其冲。如果你在面试时编造了什么还出了错，面试官会把你的应聘书投进垃圾箱。你只要做的是，集中于自己本身具有的优点上，如果把它们都在面试中陈述出来，这已经就是那个机构喜欢你的那些因素。别浪费时间捏造东西来说。

原文：25 Questions to Think About Before Your Next Job Interview � The Simple Dollar

译者：Sylvia（GTD翻译小组核心成员）

开源的车牌识别工程

noreply@blogger.com (Unknown) — Sun, 21 Mar 2010 17:47:00 +0800

与大家共享，网上找到的C#写的开源车牌识别工程。
建在google code 上
地址是： http://code.google.com/p/lprbuaa/

给出的工程简介：

LicensePlateRecognition

base on GraphicsEngine.

而 GraphicsEngine.是：

“一个简单的数字图像处理引擎，提供各种基本图像处理算法、连通域分析和内存管理。API为两层结构，并在不断完善中。来自北京航空航天大学机械工程及自动化学院。张以成”

截图：

低效能人士的七个坏习惯-褪墨

noreply@blogger.com (Unknown) — Mon, 15 Mar 2010 21:33:00 +0800

来自"褪墨"的最新文章，

低效能人士的七个坏习惯

Sun, 14 Mar 2010 12:44:00 +0800

是否真有幸福并非取决于天性，而是取决于人的习惯。褪墨上曾分享过哈佛大学企业管理硕士，杨百翰大学博士史蒂芬・柯维（Stephen R.Covey）的《高效能人士的七个习惯》上几篇文章：《学会积极主动》和《要是第一》，而本文将列举七个低效能人士的坏习惯。欢迎大家参加褪墨号召的《一个月培养一个好习惯》活动！

缺席

也许你曾经听过伍迪·艾伦所说的这句话："百分之八十的成功来自于出席。"更多的出席——这是在生活中保证更多成功要做的最重要也是最简单的事情之一。例如，如果想要改善自己的健康状况，最有效的事情就是每天按时出现在健身房里，无论是天气是多么不好、你是多么不想出门、你是多么的繁忙，只要你能坚持在积极性不高的时候能出席健身房，你就会开始改善健康，而不是每天躺在沙发上幻想自己的身体忽然变得更健康了。如果你想提高写作水平或绘画水平，你就要经常练习。如果你想交更多的朋友，就需要出席更多的活动。学会出席，积极主动的参与，这将使你的生活受益匪浅。

拖拖拉拉

我最喜欢的三种摆脱拖拉情况的方法，列举如下：

在一天的最开始就完成那些最重要的工作。早上良好的开始会让你一天都保持高昂的情绪和积极的动力。这通常会使你这一天都十分高效。
一项的一项去完成。想想，你如何吃掉一头大象呢？不要打算一口吃成胖子，这会使你感到过多负担以至于产生拖延的念头。把一项工作分为若干可付诸于行动的小步骤，然后仅仅关注第一步直到把它完成，接下来再继续下一步。
说服自己。我发现这种向导型调整十分有效。我时常花上一段时间躺在床上反复默念"在这几天里我都会十分高效"之后，我就觉得自己又有动力，又有激情地开始工作了。

拓展阅读：《防止拖延的积极步骤》

做无关紧要的事情

除了拖拖拉拉以外，另外一个容易陷入的不良习惯就是深陷无关紧要的事情之中。为了提高效率你也许需要某种时间管理方法。比如这套极为简单的时间管理方法，使用80/20法则。80/20法则，也就是我们通常所熟悉的帕累托法则，认为80%的收获源自20%的努力。所以为求高效，你应该将大部分精力集中在那些极少数重要的事情上。你只需按优先顺序写下这一天你需要做的三件最重要的事情，然后从头做起。即使你只能完成其中的一件事，你仍然完成了今天最重要的事情。也许你也会偏爱其他诸如GTD等方法，不过无论你如何组织工作，最关键的还是寻找那些最重要的工作，这样你就不必花费几天，几个星期甚至几个月的时间去忙于那些并不是很重要的事情。如果这些事情无关紧要，那么即使你快速的完成它们也是没有多大用处的。

拓展阅读：《放置大石头的艺术：让你的效率翻倍》

多虑

因为多虑而使我们很少采取行动，陷于无穷的分析之中只会使虚度光阴。行动之前加以思考是没有错的，做一些调查研究，制定一个计划，探究可能存在的积极以及不利因素。但是强制性地反复思考就会成为另外一种浪费时间的做法了。在尝试之前你没有必要去从每一个角度检查每一件事情。而且你也不可以等到一个最完美的时间再去做事，因为这样的时间从来不会出现。如果你继续这样思考就只会使自己陷的越来越深，从而使采取行动变得越来越难。相反，虽然思考在一定程度上对你有所帮助，但你现在需要做的就只是停止思考，然后去做那些你应该做的事情。

凡事过于消极

当你凡事都从消极方面考虑时，你的积极性就会被大大打击。你会发现到处都是问题和错误，而这些问题和错误可能是本不存在的，所以不要抓住细节不放。当你从一个消极角度看问题时，每次你都可能找出十个借口来逃避问题，因此你几乎一事无成。你向任何愿意倾听的人诉苦（也许很多人并不想听），抱怨你的工作，生活和领导有多么的差劲。其实，你的生活取决于你如何看待这个世界。对此的一个解决方法就是了解消极方面的限度，认识到你的消极思考并不是这个世界的真实写照。然后不妨尝试一些其他的角度。举例来说，你可以尝试着培养一下凡事从更为积极和乐观的角度思考的习惯，这会对你大有帮助。通过这种方式，你也许就会开始尝试这种积极性的挑战。这并不容易，然而如果你接受了这种挑战，连续7天都只从积极方面思考，ä �就会突然意识到你看问题的角度和想法是如此深刻地影响着你对世界的理解和你所得到的成果。

拓展阅读：《如何打破消极思维模式》

固执己见，与世隔绝

我们很难去承认自己的想法不是最佳选择，因此我们通常过于执着自己的想法，变得闭目塞听，而这会让你很难取得进步。在这种情况下，即使认真思考改变人生的可能性都会变得很难。显然，解决方法之一就是打开心胸，开阔视野，从他人和自己的错误中汲取教训，从书籍等资源中获取知识。与任何事一样，这事说起来容易做起来难。正如前面所说，对此我的建议就是认识到你的知识领域毕竟是有限的，而你做事的方式也会存在不足。那么不妨就尝试一下新事物吧。而我的另一条建议就是，阅读一下埃克哈特·托利的《新天地》，特别是有关Ego的章节。正如托利所建议的，如果你不再像Ego那样思考，你就会更加容易接受新思想，抛弃那些已经无用的旧思想。另外我想要补充说明的就是：不要迷信书本，也不要盲目追求新的信息，否则你就会成为一个沉迷于自我帮助的人。在行动中运用那些新信息和你学到的事情，然后加以尝试。

持续信息过剩

信息过剩并不是说你过多的阅读，我所指的是所有输入信息的过剩。如果你让所有的信息都涌进大脑，这当然会导致难于清晰思考，因为刺激源太多了。以下就是这种习惯可能会存在的弊端：

你所接受的一些信息也许会是消极的。媒体和周围环境会因种种原因提供一种消极的信息。如果你没有根据需要对信息加以选择，也许你就会陷入消极之中，从而影响到你的所思，所感，所为。
这会使你急于追赶当今发生的事情。每时每刻都有十几件事同时发生，想要追赶上它们几乎是不可能的事情。你的生活会因此充满压力。
如果你持续被信息轰炸，并且还试图将所有信息分类，那么你将很难做出决定并采取行动。就我个人而言，如果我得到过多的信息，就会造成某种形式上的瘫痪。如果你已被这种习惯所困，终日急于忙碌在一些非重要的事情上。为了可以集中精力，清晰思考并付诸行动，你就需要在吸取信息时更有选择性。当你工作时尽可能的避免那些分散注意力的事物，如关掉电话，断开网络，关上大门。久而久之，你就会发现，当你没有每隔五分钟就被打扰一次，没有机会因浏览RSS-feeds或喜爱的网站而拖延时，居然可以完成这么多的事情。我并不是建议你们停止阅读所有的博客或报纸，但是一定要清楚哪些是你真正想要阅读的，哪些只是用来打发时间的。学会拥有一扇心灵之门，关上它而去关注更为重要的事情，这样你就没有必要陷入那些来自周围环境的 ��极情绪。要知道，如果周围的所有人都在拖延或者焦急的忙于各种非重要的事情时，你会很容易被这种情绪所影响的。

原文：7 Habits of Highly Ineffective People – The Positivity Blog

如下实现，用CString时，是肯定会造成内存泄露

noreply@blogger.com (Unknown) — Mon, 15 Mar 2010 10:53:00 +0800

如下实现，用CString时，是肯定会造成内存泄露:

DWORD __stdcall ThreadProc(LPVOID pContext)

{

CString strTest = "abcd";

MessageBox(strTest);

......

ExitThread(0);

return NULL;

}

按说一般局部变量是分配在stack上的，不会内存泄漏；

但是这个Cstring类型的变量就特殊了，“该管理器从进程堆（在 ATL 中）或 CRT 堆（在 MFC 中）分配内存。”既然分配在堆上，那就要回收。默认是到了该变量生存期结束的时候有管理器回收，但是如果你强行 ExitThread(0); 或者exit(0)，让该线程“不得好死”，自然就内存泄漏……

车牌识别博客订阅地址

noreply@blogger.com (Unknown) — Thu, 4 Mar 2010 20:19:00 +0800

车牌识别博客订阅地址

http://feeds.feedburner.com/vlpr-lpr

车牌识别中一种新的直接基于彩色图像的二值化简化方法[转]

noreply@blogger.com (Unknown) — Mon, 1 Mar 2010 08:33:00 +0800

转自 http://goo.gl/oSjO

车牌识别包括预处理、定位、字符分割和字符识别等几部分。在本文中，我们仅讨论预处理的二值化过程。二值化的好坏决定着车牌识别的精度。事实上，要提高车牌识别精度必须要有好的二值化方法。本文提出了一种新的直接基于彩色图像的二值化方法。

车牌识别，一直存在两种思路。一是将彩色图像灰度化，然后二值化等等；二是直接基于彩色图像。

由于直接基于彩色图像的方法大都未取得很好的效果，因此，造成灰度化、二值化成为目前车牌识别的主流。但是，采用灰度化的方法，有个根本的问题就是，灰度化是有损的。灰度化难在阈值选取。尽管没有理论证明，车牌识别的精度很难超过90%，这或许就与阈值的选取有关。

要跳出阈值选取的怪圈，我认为车牌识别就还是应该回到彩色模式上来。其实，彩色图像为什么要灰度化？其依据是彩色图像需要占用大量的处理时间。老师上课的时候是这样在讲，教科书上也是这样在写。

从广泛的意义上讲，彩色图像确实会占用大量的处理时间，但是，针对车牌识别而言，我们可以找到一种非常简单的方法。通过这种方法，彩色图像会被极大地简化，就是说可以简化到无需考虑处理时间的占用问题。

注意，我说的是简化。就是说，我们要通过简化的方法，达到通过灰度化实现二值化同样的目标，即将彩色图像直接简化成二值化图像，简化过程不使用灰度化方法，仅通过空间映射方式。这样做的好处是什么呢？它克服了灰度化的有损性，最大限度地保持了图像的原貌。传统的方法经灰度化后得到的二值化结果，已经完全丧失原有的色彩信息，而新的通过空间映射的方法，同样得到了二值化图像，但是，图像中每个像素的原色彩信息依然保留着。

直接基于彩色图像的二值化简化，其核心思想是通过：黄色 =（红色＋绿色）/ 2 ，依此将红、绿、蓝三原色构成的色彩空间映射到由黄、蓝两种颜色构成的色彩空间；映射后的色彩值有黑色、蓝色、灰色、黄色和白色五种。具体的简化过程如下：

1、建立公式：黄色 =（红色＋绿色）/ 2 ，取值0..255。

2、建立公式：灰度 =（黄色＋蓝色）/ 2 ，取值0..255。

3、将黄色和蓝色都大于187的视同白色。

4、将黄色和蓝色都小于153的视同黑色。

5、去除白色和黑色剩下的中间色中，如果黄色＜0.9×蓝色（意味着颜色偏蓝），则需进一步进行蓝色细分；如果蓝色＜0.9×黄色（意味着颜色偏黄），则需进一步进行黄色细分；否则则需进一步进行灰色细分。

6、蓝色细分：如果黄色＜0.8×蓝色，说明颜色中蓝色成分明显多于黄色成分，视同蓝色；否则，如果灰度＜187，视同蓝色，反之视同灰色。

7、黄色细分：如果蓝色＜0.8×黄色，说明颜色中黄色成分明显多于蓝色成分，视同黄色；否则，如果灰度＞153，视同黄色，反之视同灰色。

8、灰色细分：如果灰度＜153，视同黑色；如果灰度＞187，视同白色，否则视同灰色。

经过空间映射，现在的空间由黑色、蓝色、灰色、黄色和白色五种颜色构成。显然，这个空间仍然可以被看成是彩色空间，它包括中国车牌所需要的各种底色和字符色（红字需要再特殊处理一下），所有色彩信息都没有丢失。注意，这里有灰色，它正好解决了对“脏”车牌的识别。

进一步我们可以将黑色和蓝色统一归并为蓝色，黄色和白色统一归并为黄色。灰色可根据底色视同蓝色或黄色。这样我们就完成了直接基于彩色图像的二值化简化。

上述直接基于彩色图像的二值化简化方法，最关键的是把空间简化了，把RGB三维空间简化成YB二维，然后，继续简化成直线，再继续简化成五个值，最后简化成二值，节省了计算时间。它与其他的彩色模式的差异在哪里呢？其他的彩色模式大都没有降低维数，减少计算量，即尽管采用了彩色模式，但是最后还是要回到灰度化上面去。这是不对的。

实际应用时，参数会略有调整，测试请到 http://www.yulaohui.com/color5_2/ 。

Tag标签: 车牌识别,图像识别

汽车牌照识别技术的研究与实现

noreply@blogger.com (Unknown) — Mon, 21 Dec 2009 11:12:00 +0800

汽车牌照识别技术的研究与实现.nh

noreply@blogger.com (Unknown) — Mon, 21 Dec 2009 11:05:00 +0800

基于t混合模型和Greedy EM算法的彩色图像分割.pdf

浅谈C++中内存泄漏的检测

noreply@blogger.com (Unknown) — Fri, 30 Oct 2009 22:22:00 +0800

http://blog.csdn.net/phinecos/archive/2009/10/29/4745720.aspx

首先我们需要知道程序有没有内存泄露，然后定位到底是哪行代码出现内存泄露了，这样才能将其修复。

最简单的方法当然是借助于专业的检测工具，比较有名如BoundsCheck,功能非常强大，相信做C++开发的人都离不开它。此外就是不使用任何工具，而是自己来实现对内存泄露的监控，分如下两种情况：

一. 在 MFC 中检测内存泄漏

假如是用MFC的程序的话，很简单。默认的就有内存泄露检测的功能。

我们用VS2005生成了一个MFC的对话框的程序,发现他可以自动的检测内存泄露.不用我们做任何特殊的操作. 仔细观察,发现在每个CPP文件中,都有下面的代码:

#ifdef _DEBUG
#define new DEBUG_NEW
#endif

DEBUG_NEW 这个宏定义在afx.h文件中，就是它帮助我们定位内存泄漏。

在含有以上代码的cpp文件中分配内存后假如没有删除，那么停止程序的时候，VisualStudio的Output窗口就会显示如下的信息了：

Detected memory leaks!
Dumping objects ->
d:\code\mfctest\mfctest.cpp(80) : {157} normal block at 0x003AF170, 4 bytes long.
Data: < > 00 00 00 00
Object dump complete.

在Output窗口双击粗体字那一行，那么IDE就会打开该文件，定位到该行，很容易看出是哪出现了内存泄露。

二．检测纯C++的程序内存泄露

我试了下用VisualStudio建立的Win32 Console Application和Win32 Project项目，结果都不能检测出内存泄露。

下面一步一步来把程序的内存泄露检测的机制建立起来。

首先，我们需要知道C运行库的Debug版本提供了许多检测功能，使得我们更容易的Debug程序。在MSDN中有专门的章节讲这个，叫做Debug Routines，建议大家先看看里面的内容吧。

我们会用到里面很重要的几个函数。其中最重要的是 _CrtDumpMemoryLeaks();自己看MSDN里的帮助吧。使用这个函数，需要包含头文件crtdbg.h

该函数只在Debug版本才有用，当在调试器下运行程序时，_CrtDumpMemoryLeaks 将在“Output(输出)”窗口中显示内存泄漏信息.写段代码试验一下吧，如下：

检测内存泄露版本一：

#include "stdafx.h"
#include <crtdbg.h>
int _tmain(int argc, _TCHAR* argv[])
{
    int* p = new int();
    _CrtDumpMemoryLeaks();
    return 0;
}

运行后，在Output（输出）窗口，显示了如下的信息：

Detected memory leaks!
Dumping objects ->
{112} normal block at 0x003AA770, 4 bytes long.
Data: < > 00 00 00 00
Object dump complete.

但是这个只是告诉我们程序有内存泄露，到底在哪泄露了一眼看不出来啊。

　　看我们的检测内存泄露版本二：

#include "stdafx.h"
#ifdef _DEBUG
#define DEBUG_CLIENTBLOCK   new( _CLIENT_BLOCK, __FILE__, __LINE__)
#else
#define DEBUG_CLIENTBLOCK
#endif
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
#ifdef _DEBUG
#define new DEBUG_CLIENTBLOCK
#endif
int _tmain(int argc, _TCHAR* argv[])
{
    int* p = new int();
    _CrtDumpMemoryLeaks();
    return 0;
}

该程序定义了几个宏，通过宏将Debug版本下的new给替换了，新的new记录下了调用new时的文件名和代码行.运行后，可以看到如下的结果：

Detected memory leaks!
Dumping objects ->
d:\code\consoletest\consoletest.cpp(21) : {112} client block at 0x003A38B0, subtype 0, 4 bytes long.
Data: < > 00 00 00 00
Object dump complete.

呵呵，已经和MFC程序的效果一样了，但是等一等。看下如下的代码吧：

int _tmain(int argc, _TCHAR* argv[])
{
    int* p = new int();
    _CrtDumpMemoryLeaks();
    delete p;
    return 0;
}

运行后可以发现我们删除了指针，但是它仍然报内存泄露。所以可以想象，每调用一次new，程序内部都会将该调用记录下来，类似于有个数组记录，假如delete了，那么就将其从数组中删除，而_CrtDumpMemoryLeaks()就是把这个数组当前的状态打印出来。

所以除了在必要的时候Dump出内存信息外，最重要的就是在程序退出的时候需要掉用一次_CrtDumpMemoryLeaks();

假如程序有不止一个出口，那么我们就需要在多个地方都调用该函数。

更进一步，假如程序在类的析构函数里删除指针，怎么办？例如：

#include "stdafx.h"
#ifdef _DEBUG
#define DEBUG_CLIENTBLOCK   new( _CLIENT_BLOCK, __FILE__, __LINE__)
#else
#define DEBUG_CLIENTBLOCK
#endif
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
#ifdef _DEBUG
#define new DEBUG_CLIENTBLOCK
#endif
class Test
{
public:
    Test()      {   _p = new int();     }
    ~Test()     {   delete _p;          }
    int* _p;
};
int _tmain(int argc, _TCHAR* argv[])
{
    int* p = new int();
    delete p;
    Test t;
    _CrtDumpMemoryLeaks();
    return 0;
}

可以看到析构函数在程序退出的时候才调用，明明没有内存泄露，但是这样的写法还是报了。

如何改进呢,看检测内存泄露版本三：

#include "stdafx.h"
#ifdef _DEBUG
#define DEBUG_CLIENTBLOCK   new( _CLIENT_BLOCK, __FILE__, __LINE__)
#else
#define DEBUG_CLIENTBLOCK
#endif
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
#ifdef _DEBUG
#define new DEBUG_CLIENTBLOCK
#endif
class Test
{
public:
    Test()      {   _p = new int();     }
    ~Test()     {   delete _p;          }
    int* _p;
};
int _tmain(int argc, _TCHAR* argv[])
{
    _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
    int* p = new int();
    delete p;
    Test t;
    return 0;
}

_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );该语句在程序退出时自动调用 _CrtDumpMemoryLeaks。必须同时设置 _CRTDBG_ALLOC_MEM_DF 和 _CRTDBG_LEAK_CHECK_DF.

这样，该版本已经达到了MFC一样的效果了,但是我觉得光这样还不够，因为我们只是在Output窗口中输出信息，对开发人员的提醒还不明显，经常会被遗漏，而且很多人就算发现了内存泄露，但是不好修复，不会严重影响到程序外在表现，都不会修复。怎么样能让开发人员主动的修复内存泄露的问题呢？记得曾经和人配合写程序，我的函数参数有要求，不能为空，但是别人老是传空值，没办法了，只好在函数开始验证函数参数，给他assert住，这样程序运行时老是不停的弹出assert，调试程序那个烦压，最后其他程序员烦了，就把这个问题给改好了，输入参数就正确了。所以我觉得咱要让程序员主动去做一件事，首先要让他觉得做这个事是能减轻自己负担，让自己工作轻松的。呵呵，那咱们也这样，当程序退出时，检测到内存泄露就让程序提示出来。

看检测内存泄露版本四：

#include "stdafx.h"
#include <assert.h>
#ifdef _DEBUG
#define DEBUG_CLIENTBLOCK   new( _CLIENT_BLOCK, __FILE__, __LINE__)
#else
#define DEBUG_CLIENTBLOCK
#endif
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
#ifdef _DEBUG
#define new DEBUG_CLIENTBLOCK
#endif
void Exit()
{
    int i = _CrtDumpMemoryLeaks();
    assert( i == 0);
}
int _tmain(int argc, _TCHAR* argv[])
{
    atexit(Exit);
    int* p = new int();
    return 0;
}

该版本会在程序退出时检查内存泄露，假如存在就会弹出提示对话框.

atexit(Exit);设置了在程序退出时执行Exit()函数。Exit()函数中,假如存在内存泄露，_CrtDumpMemoryLeaks()会返回非0值，就会被assert住了。

到这个版本已经达到可以使用的程度了。但是我们还可以做些改进，因为真要准确的检测到代码中所有的内存泄露，需要把代码中的#define……拷贝到所有使用new的文件中。不可能每个文件都拷贝这么多代码，所以我们可以将他提取出来，放在一个文件中，比如我是放在KDetectMemoryLeak.h中，该文件内容如下：

#pragma once
#ifdef _DEBUG
#define DEBUG_CLIENTBLOCK new( _CLIENT_BLOCK, __FILE__, __LINE__)
#else
#define DEBUG_CLIENTBLOCK
#endif
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
#ifdef _DEBUG
#define new DEBUG_CLIENTBLOCK
#endif

然后将KDetectMemoryLeak.h包含在项目的通用文件中，例如用VS建的项目就将其包含在stdafx.h中。或者我自己建的一个Common.h文件中，该文件包含一些通用的，基本所有文件都会用到的代码。

A Visual C++ Exception FAQ

noreply@blogger.com (Unknown) — Wed, 9 Sep 2009 08:30:00 +0800

A Visual C++ Exception FAQ

Copyright © 2001-2007 Doug Harrison (http://members.cox.net/doug_web/eh.htm)

This document answers some common questions concerning catch(...) and exceptions in general as implemented by Visual C++. It's structured mainly as a conversation, in which one question and answer leads to the next, so you'll get the most out of it if you read it as a whole. To give you a quick idea of what I'm going to talk about, the questions are:

Q1	I wrote the following, and I don't understand why catch(...) doesn't catch the Win32 structured exception in a release build, or in general, when compiling with optimizations (e.g. /O1 or /O2).
Q2	I also wrote the code above, and I don't understand why the Win32 structured exception (SE) is caught in a debug build or when I compile with /EHa. Also, I sometimes find that catch(...) catches SEs even in release builds when I use /GX. Isn't catch(...) supposed to catch only C++ exceptions?
Q3	So what are the consequences of catching Win32 Structured Exceptions (SEs) in catch(...) ?
Q4	What about _set_se_translator?
Q5	How do I deal with all this?
Q6	How do I safely use _com_error, std::exception, and other non-MFC exception classes in MFC programs?

This document applies to Visual C++ 5 through Visual C++ .NET 2003 and beyond. The upcoming Visual C++ 2005 release, known also as "Whidbey", corrects one of the problems discussed below, and this partly affects questions Q1, Q2, and Q5, which are updated accordingly. The remaining questions and answers apply in full to Visual C++ 5 and later.

Q1. I wrote the following, and I don't understand why catch(...) doesn't catch the Win32 structured exception in a release build, or in general, when compiling with optimizations (e.g. /O1 or /O2).

#include <stdio.h>

int main()
{
   try
   {
     int* p = 0;
     *p = 0; // Cause access violation
   }
   catch (...)
   {
      puts("Caught access violation");
     }
   return 0;
}

A. In Visual C++5 through Visual C++ .NET 2003, you're compiling with /GX or /EHs, which enables the compiler's synchronous exception model. This model is defined to catch only exceptions resulting from a C++ throw statement, and there is no such statement in the above. If you were to examine the assembly language emitted for this program, you would find the compiler has optimized all the exception handling machinery out of the function, because the optimizer can determine the tried code cannot throw a C++ exception. This is a great optimization! It's especially appreciated when writing template code. Unfortunately, there is a bug that causes catch(...) to catch Win32 structured exceptions in some scenarios, which leads to the next question.

Q2. I also wrote the code above, and I don't understand why the Win32 structured exception (SE) is caught in a debug build or when I compile with /EHa. Also, I sometimes find that catch(...) catches SEs even in release builds when I use /GX. Isn't catch(...) supposed to catch only C++ exceptions?

A. According to Stroustrup, C++ exception handling (EH) is not intended to handle signals or other low-level, OS-specific events such as arithmetic exceptions. Win32 Structured Exceptions (SEs) clearly fall into this category, and it should not be possible to catch SEs in catch(...). However, the C++ Standard doesn't specifically forbid this, and because anytime you raise an SE you invoke undefined behavior, it's "legal" for catch(...) to catch SEs, in a very technical sense, because the C++ Standard imposes no requirements on the behavior of a program that does something undefined, such as dereferencing a NULL pointer. That said, while it may seem convenient to catch truly everything in catch(...), catching SEs there is the source of numerous problems. Before discussing why I say that, let's consider how Visual C++ is documented to behave.

Visual C++ 5 and later define two EH models, called synchronous and asynchronous. The model chosen is determined by the /EH command line option. /EHs specifies the synchronous model, while /EHa specifies the asynchronous model. There is also /GX, which is defined by default for MFC and other AppWizard applications. /GX is equivalent to /EHsc, so it selects the synchronous model. (The c indicates that extern "C" functions do not throw exceptions.) The VC++ documentation defines the asynchronous model as follows:

In previous versions of Visual C++, the C++ exception handling mechanism supported asynchronous (hardware) exceptions by default. Under the asynchronous model, the compiler assumes any instruction may generate an exception.

Under the asynchronous model, catch(...) catches SEs, and you must use /EHa if this is what you really want. You must also use /EHa if you're expecting to catch SEs that have been translated into C++ exceptions with the help of _set_se_translator(). (See Q4.)

The synchronous model is described as follows:

With the new synchronous exception model, now the default, exceptions can be thrown only with a throw statement. Therefore, the compiler can assume that exceptions happen only at a throw statement or at a function call. This model allows the compiler to eliminate the mechanics of tracking the lifetime of certain unwindable objects, and to significantly reduce the code size, if the objects' lifetimes do not overlap a function call or a throw statement.

The synchronous model is intended to provide C++ EH as Stroustrup intended, but unfortunately, in Visual C++ 5 through Visual C++ .NET 2003, it doesn't behave exactly as documented, and it's still possible to catch SEs in catch(...) if you compile without optimizations, or you compile with optimizations, and the optimizer is unable to determine the tried code cannot throw a C++ exception. For example, in VC5, if the tried code calls a function, the optimizer assumes it can throw, while in VC6, the function may need to live in another translation unit (source file) to cause the optimizer to be pessimistic. Visual C++ .NET 2005 at last corrects this problem for the synchronous model.

Q3. So what are the consequences of catching Win32 Structured Exceptions (SEs) in catch(...) ?

A. In order to answer this question, we first need to discuss what C++ exceptions and SEs represent. According to Stroustrup, C++ exception handling is error handling. For example, failure to acquire a resource such as memory or running out of disk space while writing to a file is an error that is often best reported by throwing an exception, especially when the resource is normally expected to be available. This greatly simplifies code by eliminating the need to check function return codes, and it helps you centralize error handling. This sort of error can occur in a correctly written program, and that is what C++ EH is intended to address.

On the other hand, SEs typically represent program bugs. Everyone is familiar with access violations resulting from dereferencing NULL pointers. The hardware detects this and traps, and Windows turns the hardware event into an SE. In general, SEs represent programmer errors, and correctly written programs have no such errors. SEs are also used in the normal operation of the system. For example, it's possible to use VirtualAlloc() to reserve a region of your address space and dynamically commit pages as a program accesses uncommitted memory and causes page faults. The program catches the SE in an __except clause, commits the memory, and resumes execution with the instruction that caused the fault. This should be invisible to C++ EH, which should not be able to interfere with it.

C++ exceptions and Win32 structured exceptions represent very different things. Problems caused by homogenizing them in catch(...) include the following.

If catch(...) is able to catch SEs, it's impossible to write the following with any confidence:

// Begin exception-free code ... Update critical data structure // End exception-free code
If the critical code has a bug that results in an SE, an outer catch(...) block may catch the SE, creating a completely unanticipated program state. The program may hobble along, further corrupting its state. If you're lucky, a subsequent uncaught SE will bring the program down before it does any serious damage, but debugging the problem may be much more difficult than if catch(...) hadn't swallowed the initial SE, because the secondary SE may occur in code far removed from the source of the actual bug. The OS will report the uncaught secondary SE and give you the opportunity to debug it, but it will lead you to the source of this SE, not the source of the actual problem.
Code such as the following becomes suspect:

try { TheFastButResourceHungryWay(); } catch (...) { TheSlowButSureWay(); } If a program bug or compiler code generation bug causes an access violation in the tried function, your discovery of the bug is hindered by catch(...) swallowing the SE. The only manifestation of the bug may be an inexplicable slowness, which may not be apparent in your testing, while if catch(...) hadn't caught the SE, you certainly would have discovered the bug while testing. (OS error boxes are pretty hard to miss!)
The normal operation of the system is impaired. For example, the MFC CPropertySheet::DoModal() documentation describes a scenario in which you should not use catch(...). The exception raised by the DebugBreak API can be caught by catch(...), rendering DebugBreak useless. Also, if you're using __try/__except to handle SEs properly, you may have trouble if an interior catch(...) is present, even if it rethrows. You almost certainly will have trouble if your SE handler resumes execution with the faulting instruction. You may find the catch(...) block was entered and local variables destroyed, which is very bad if execution is resumed in its complementary try block. And if that try block subsequently throws a C++ exception, you may find yourself in an infinite loop with your SE filter function.
Application frameworks are taking a chance if they guard your code with catch(...), which they normally should do. For example, MFC does not use catch(...), and as a result, an uncaught C++ exception terminates an MFC application.

Q4. What about _set_se_translator?

A. _set_se_translator is a function used to register another function which translates Win32 structured exceptions into true C++ exceptions. It allows you to partially avoid the catch(...) problems described in Q3 by writing the following, where se_t is the type of object thrown by the translator function:

catch (se_t) { throw; }
catch (...) { ... }

This is not a great workaround, because it's easy to forget to augment every catch(...) as shown above, and you would have to establish a translator in every thread you create that runs code which uses this method, because SE handlers are attributes of a thread, and calling _set_se_translator in one thread has no effect on other threads. Also, the translator function isn't inherited by new threads; thus, _set_se_translator has no effect on threads created after it's called. Besides being difficult and error-prone to implement, this workaround can't account for code you didn't write and can't modify, and this can be an issue for library users.

Finally, the documentation does not make it clear that to use _set_se_translator reliably, you must select the asynchronous EH model discussed in Q2, and that tends to bloat your object code. If you don't do this, your code is subject to the optimization discussed in Q1.

Q5. How do I deal with all this?

A. When using Visual C++ 5 through Visual C++ .NET 2003, the best course is to avoid catch(...) whenever possible. If you must use catch(...), be aware of all the issues described in the preceding questions. If you're using Visual C++ .NET 2005, the /EHs option behaves as documented, the synchronous model works correctly, and you don't have to worry about catch(...) catching SEs.

Q6. How do I safely use _com_error, std::exception, and other non-MFC exception classes in MFC programs?

A. MFC was designed before Visual C++ supported C++ exception handling. The original MFC implementation was based on macros such as TRY and CATCH and used setjmp and longjmp to simulate C++ exception handling. To simplify this initial implementation, MFC threw pointers to CException objects and pointers to objects of classes derived from CException, and CException* was the only exception type supported by early versions of MFC. Though MFC was updated to use C++ exceptions in Visual C++ 2.0, it was never made aware of other exception types, and the MFC source code continues to use the macros, which are now defined in terms of C++ EH. For example, MFC defines CATCH_ALL in terms of:

catch (CException* e)

Clearly, this doesn't catch all exceptions if the tried code uses the C++ Standard Library, compiler COM support, or other libraries that define their own exception types. MFC does not itself use any exception type other than CException*, but in many places, it wraps your code as follows:

TRY
{
   // Call your code
}
CATCH_ALL(e)
{
   // Clean up and perhaps report the error to the user
}
END_CATCH_ALL

For example, an MFC WindowProc is guarded this way, because exceptions aren't allowed to cross Windows message boundaries. However, CATCH_ALL catches only MFC exceptions, and if you fail to catch a non-MFC exception yourself, your program will be terminated due to an uncaught exception. Even if you do catch the exception yourself, where you catch it is still very important, because there are a number of functions within MFC that expect to catch all exceptions so they can clean up or return an error code to the caller through a normal function return statement. Now, if the try blocks within these functions call into your code, and you don't translate non-MFC exceptions into MFC exceptions right then and there, you allow non-MFC exceptions to propagate through MFC code that expects to catch everything, and as just described, it can't, and it doesn't. You may end up skipping some important clean-up code, and even though you catch your non-MFC exception at some outer level, it may be too late. This suggests the following rule of thumb:

Never allow a non-MFC exception to pass through MFC code

At a minimum, this means protecting every message handler that could exit via a non-MFC exception with try/catch. Now, if a message handler can't do anything about an exception, and you want it to be reported to the user, it's often appropriate for the handler to exit via an exception, because MFC will present the user with a nice message box describing the error, provided it can catch it. To achieve this result, you need to translate non-MFC exceptions into MFC exceptions. Macros can help here. For example, consider the code sketched below:

class MfcGenericException : public CException
{
public:

   // CException overrides
   BOOL GetErrorMessage(
         LPTSTR lpszError,
         UINT nMaxError,
         PUINT pnHelpContext = 0)
     {
      ASSERT(lpszError != 0);
      ASSERT(nMaxError != 0);
      if (pnHelpContext != 0)
         *pnHelpContext = 0;
      _tcsncpy(lpszError, m_msg, nMaxError-1);
      lpszError[nMaxError-1] = 0;
        return *lpszError != 0;
   }

protected:

   explicit MfcGenericException(const CString& msg)
   :  m_msg(msg)
   {
   }

private:

   CString m_msg;
};

class MfcStdException : public MfcGenericException
  {
public:

   static MfcStdException* Create(const std::exception& ex)
   {
      return new MfcStdException(ex);
   }

private:

   explicit MfcStdException(const std::exception& ex)
     : MfcGenericException(ex.what())
   {
   }
};

#define MFC_STD_EH_PROLOGUE try {
#define MFC_STD_EH_EPILOGUE \
      } catch (std::exception& ex) { throw MfcStdException::Create(ex); }

The code above defines a class, MfcGenericException, which is derived from MFC's CException, and which serves as the base class for MfcStdException and other non-MFC exception types. (We need this base class because MFC does not provide a generic exception type that encapsulates a message string.) The macros at the bottom are intended to surround your message handlers and other code called from MFC that can throw non-MFC exceptions. You use it like this:

void MyWnd::OnMyCommand()
{
MFC_STD_EH_PROLOGUE

   ... your code which can throw std::exception

MFC_STD_EH_EPILOGUE
}

Together, the macros guard your code in a try block, and the MFC_STD_EH_EPILOGUE macro translates std::exception into something MFC can catch, in this case, MfcStdException. Note that MfcStdException has a private constructor and defines a static Create function, and the latter provides the only way to create an MfcStdException. It ensures the exception object is created on the heap, which we must do, because each object maintains state information in the form of its error message. We can't simply throw a pointer to a static instance, as AfxThrowMemoryException does, because that wouldn't be thread-safe due to our state information, and it's also possible to throw and catch an exception while handling another, which is ultimately rethrown, and that would tend to overwrite the first message. We can't take any shortcuts here! Whoever catches our exception is responsible for calling its Delete member function, inherited from CException. This function will delete the MfcStdException object, and it's good to disallow mistakes such as throwing a pointer to a local object by preventing the creation of local objects altogether.

Using a technique such as the above is essential to creating MFC programs which are robust in the presence of heterogeneous exception types. It's much easier than writing explicit try/catch blocks, and it allows exceptions to propagate to whoever can best handle them. In fact, explicit try/catch blocks are relatively rare in well-designed programs, because the code is written in such a way that the automatic stack unwinding and local variable destruction does the right thing. Consequently, the final step of handling an exception often amounts to simply letting the user know something went wrong, and by translating your non-MFC exceptions into MFC exceptions, MFC can handle that just fine.

Comments

To comment on this page, please send email to dsh@mvps.org.

简单有效的图像去雾技术

noreply@blogger.com (Unknown) — Thu, 13 Aug 2009 19:12:00 +0800

标签：微软亚洲研究院图像去雾 cvpr 最佳论文研究心得论文背后故事

分类：技术

作者：何恺明

那是2009年4月24日的早上，我收到了一封不同寻常的email。发信人是CVPR 2009的主席们，他们说我的文章获得了CVPR 2009的最佳论文奖(Best Paper Award)。我反复阅读这封邮件以确认我没有理解错误。这真是一件令人难以置信的事情。

北京灰霾照片的去雾结果

CVPR的中文名是计算机视觉与模式识别会议，是计算机视觉领域最顶尖的国际会议之一。今年的CVPR共收到约1450篇投稿，其中393篇文章被接收，接收率为26%。只有一篇文章被选为今年的最佳论文。这是CVPR创立 25年以来首次由中国人获得这个奖项。这篇文章是我在微软亚洲研究院形象计算组实习的时候完成的，也是我个人真正意义上写的第一篇论文。

简单有效的图像去雾技术

这篇论文研究的问题是图像的去雾技术，它可以还原图像的颜色和能见度，同时也能利用雾的浓度来估计物体的距离，这些在计算机视觉上都有重要应用（例如三维重建，物体识别）。但是之前人们还没找到简单有效的方法来达到这个目的。在这篇论文里，我们找到了一个非常简单的，甚至说令人惊讶统计规律，并提出了有效的去雾方法。

与之前的方法不同，我们把注意力放到了无雾图像的统计特征上。我们发现，在无雾图像中，每一个局部区域都很有可能会有阴影，或者是纯颜色的东西，又或者是黑色的东西。因此，每一个局部区域都很有可能有至少一个颜色通道会有很低的值。我们把这个统计规律叫做Dark Channel Prior。直观来说，Dark Channel Prior认为每一个局部区域都总有一些很暗的东西。这个规律很简单，但在我们研究的去雾问题上却是本质的基本规律。

由于雾总是灰白色的，因此一旦图像受到雾的影响，那么这些本来应该很暗的东西就会变得灰白。不仅如此，根据物理上雾的形成公式，我们还能根据这些东西的灰白程度来判断雾的浓度。因此，我们提出的Dark Channel Prior能很有效地去除雾的影响，同时利用物的浓度来估算物体的距离。

电脑游戏带来的灵感

这个想法的产生来自于两个偶然的观察。

第一个观察来自一个3D游戏。这个游戏有很多带有雾的场景，但这些场景都是虚构的不实在的东西。计算机生成的3D图像会与自然图像的统计规律有很大区别，但人的视觉系统却仍然能感觉到虚拟图像中存在的雾。这让我相信，人的视觉系统一定有一种有效的机制来感知有雾的图像，而且这种机制一定与现存的去雾方法不一样。前人提出的去雾方法都把重点放在图像的对比度上，但虚拟场景和现实场景在对比度上的统计规律会很不一样。人的视觉系统仍然能够感知虚拟场景中的雾，说明除了对比度以外，人眼一定还在利用别的东西来感知雾。所以我觉得，这个问题里一定有人们未曾发现的更接近本质的东西。

第二个观察来自对前人的去雾方法的研究。之前最有效的去雾方法是Fattal在2008年的Siggraph文章《Single Image Dehazing》中提出来的，这篇文章是我们首要超越的目标。这篇文章里给出的比较结果中，我发现一种叫做Dark Object Subtraction的方法有时候会有更好的效果。这种方法利用了全图最暗的点来去除全局均匀的雾。如果雾的确是均匀的，这种方法就会更有效。其缺点在于它无法处理不均匀的雾，而这却正是去雾问题中的难点。因此自然的想法就是局部利用Dark Object Subtraction处理图像。而恰巧这样做并不需要利用对比度，说明它与之前的方法有了本质的区别。让人吃惊的是，在大量的实验中，我发现这么简单的想法，其效果却非常好。

但我们论文中最重要的观点却形成在我动笔写文章之后。在文章的前几稿中，我在形象计算组的mentor孙剑一直追问我，我们的方法能成功的本质原因是什么，背后有什么我们没有充分理解透彻的“真知灼见”。尽管我们有很简单的方法，也有很漂亮的实验结果，但我们却无法让人对这种方法的有效性感到信服。这是因为我们还讲不出个道理来。带着这个问题，我又回到了实验和观察之中。我发现，既然大量实验结果证实局部做Dark Object Subtraction的做法是成功的，那么就说明去雾之后的图像的每个局部的确是有暗的物体存在的。也就是说，在这个方法成功的背后，其实有一个关于无雾图像的统计规律。我的mentor孙剑让我去先去研究一个无雾图像的数据库。通过大量的实验，我们发现这个统计规律是客观存在的。这就是我们所提出的 Dark Channel Prior。

这是我写的第一篇论文

2007年，我从清华大学基础科学班本科毕业，之后就读于香港中文大学。在基础科学班的主修课程是数学和物理，因此在本科阶段，我并没有系统地学习过计算机方面的相关知识。出于兴趣，我选修了计算机图形和图像方面的一些相关课程。但是在进入微软亚洲研究院实习的初期，这些基础课程远远不足以应付我面对的研究工作。背景知识的缺乏使我在入门的路上举步维艰。在阅读文章的时候，我常常都不知道哪些是大家都在用的方法，哪些才是作者的贡献。对我来说，我看见的每一样东西都是新的。

在面试的时候，我的导师汤晓鸥就跟我说过，他并不在意我没有相关的背景知识，因为所有相关的东西都是可以学的。在进入微软亚洲研究院实习的头一年里，我在mentor孙剑的指导下做过几个不同的课题，虽然都没有成功，但从中学习了不少知识。其中我花了大量时间研究的image matting问题 (半透明物体边界提取)，就对这次的文章有很大帮助。在刚开始研究去雾的时候，我就发现雾的方程和matting的方程非常相似，而我之前所研究的 matting框架可以给去雾带来帮助。利用这个框架，我只需要寻找一个能局部估算雾的浓度的方法就行了。这个框架使得我能专心的寻找这样的方法并且最后提出了Dark Channel Prior。

纽约、北京灰霾照片的去雾结果

即使有了想法和实验结果，第一次写文章也使我觉得非常困难。我经常陷入自己和自己吵架的角色当中。在每一段话写好之后，我常常会质问自己事情到底是不是这样的，这其中有没有漏洞。我也会问自己，如果我是评委，或者是读者，那么我能看懂这篇文章吗，我怎么写才能让思路更加流畅。就在这样的挣扎中，一稿通常要写好几天。而即使是这样，起初的几稿也远没能让孙剑满意。一开始，他只在文章的结构、思路和观点的提出上给我建议，而不去具体修改我的文章。于是我又回去继续和自己吵架。但每当我把自己说服了，孙剑还是总能提出新的质疑。就在这样的循环中，终于有一天孙剑说文章已经写得不错了，他才开始具体的修改。正是这样的苛刻要求，才会有后来高质量的文章。

大道之行在于简

我们这篇文章的三个审稿人都给出了最高的评分。他们认为我们的方法简单而有效。其中一位评委说，Dark Channel Prior的想法听起来很不可思议，但我们却证明了其真实性。另一位评委认为很少有文章能够用如此简单的方法使实验结果获得如此大的提升。还有一位评委甚至亲自实现了我们的方法并确认其可行。孙剑说阅读这样的评审结果是一件让人快乐的事情。而汤老师认为，这篇文章的成功在于三个方面。第一，方法非常简单；第二，对于一个很困难的问题，给出了很好的结果；第三，发现了一个基本的自然规律并且应用在实际的问题中。在迈阿密的演讲结束后，观众也给予了很高的评价。他们跟我说，这是这次CVPR上最有趣的一个演讲。

一位与会的研究员说，最好的idea，往往就是那些看起来很简单，但说出来大家都会觉得怎么没有人想到过的idea。而我们的idea正好就符合了这一点。我们论文摘要的第一句话是这么说的，“我们提出了一个简单而有效的方法”。或许，这就是对我们这次工作最好的概括——简单的，就是美的。

作者介绍

何恺明:微软亚洲研究院视觉计算组实习生，现就读于香港中文大学讯息工程多媒体实验室，本科毕业于清华大学基础科学班。他是2006年微软小学者奖获得者，2003年广东省高考状元

广东：卡口系统年内启用可快速识别套牌车

noreply@blogger.com (Unknown) — Wed, 12 Aug 2009 21:12:00 +0800

http://news.QQ.com　 2009年08月10日13:38 　金羊网-羊城晚报　　

　　本报讯记者崔朝阳报道：广东省公安厅近日在对省人大代表的建议答复中表示，可快速发现、识别和截查套牌车的卡口系统有望年内在广东全省范围投入使用，为加大对套牌车的打击力度，公安厅还拟提请省人大常委会修订《广东省道路交通安全条例》，加大对查处套牌车的处罚力度。

今年初的省“两会”期间，陈进德等6名省人大代表提交建议指出，套牌车难发现、难查处、轻处罚，全省交警系统没有形成有效的联动措施，是套牌车层出不穷的重要原因。

　　省公安厅表示，针对目前对套牌车处罚过轻，公安厅目前正会同省政府法制办开展调研，拟在年内提请省人大常委会修改道路交通安全条例，增加限制违法行为人人身自由（拘留）、加大罚款额度、没收违法车辆、追究刑事责任等条款，增加违法人违法成本。

　　此外，对套牌车，广东已建立全省范围的套牌车黑名单库，将套牌车号码都录入库中，部署全省警力查询。具有号牌识别功能、一旦发现盗抢机动车或假号牌车自动报警的卡口系统，预计年内可投入使用。

　　代表在建议中还提出，应增加车牌科技含量，让真牌不易被仿造，假牌更易被识别。对此，公安厅表示，该厅还在研发电子车牌，未来的电子车牌中将置入电子芯片，建立车牌电子身份认证系统，确保车辆唯一性，从源头上根除套牌车。

　　记者今晨从省公安厅交管局了解到，由于车牌制作涉及国家统一标准问题，公安厅已就此上报国家相关部门，目前还在等待批复。

利用OpenCV进行图像连接

noreply@blogger.com (Unknown) — Mon, 10 Aug 2009 21:58:00 +0800

#include <cv.h>

#include <highgui.h>

#include <stdlib.h>

/* プロトタイプ宣言 */

IplImage *combine_image (int num, IplImage ** tmp);

/* メイン関数 */

int

main (int argc, char **argv)

{

int i, img_num;

IplImage **img;

IplImage *combined_img;

// (1)コマンド引数で指定された画像を全て読み込む

if (argc < 2) {

return 1;

}

else {

img_num = argc - 1;

img = (IplImage **) cvAlloc (sizeof (IplImage *) * img_num);

for (i = 0; i < img_num; i++) {

img[i] = cvLoadImage (argv[i + 1], CV_LOAD_IMAGE_COLOR);

if (img[i] == 0)

return -1;

}

// (2)画像を連結する

combined_img = combine_image (img_num, img);

cvNamedWindow ("Image", CV_WINDOW_AUTOSIZE);

cvShowImage ("Image", combined_img);

cvWaitKey (0);

cvDestroyWindow ("Image");

cvReleaseImage (&combined_img);

for (i = 0; i < img_num; i++) {

cvReleaseImage (&img[i]);

}

cvFree (&img);

return 0;

}

/* 画像を連結する関数 */

IplImage *

combine_image (int num, IplImage ** tmp)

{

int i;

int width = 0, height = 0;

IplImage *cimg;

CvRect roi = cvRect (0, 0, 0, 0);

// (3)与えられた各画像から，連結後の幅と高さを求める

for (i = 0; i < num; i++) {

width += tmp[i]->width;

height = height < tmp[i]->height ? tmp[i]->height : height;

}

cimg = cvCreateImage (cvSize (width, height), IPL_DEPTH_8U, 3);

cvZero (cimg);

// (4)ROIを利用して各画像をコピーする

for (i = 0; i < num; i++) {

roi.width = tmp[i]->width;

roi.height = tmp[i]->height;

cvSetImageROI (cimg, roi);

cvCopy (tmp[i], cimg);

roi.x += roi.width;

}

cvResetImageROI (cimg);

return cimg;

}

// (1)コマンド引数で指定された画像を全て読み込む

コマンド引数で指定された画像を全て，カラー画像として読み込む．そのなかに1つでも読み込めない画像がある場合には終了する．

// (2)画像を連結する

あらかめ定義した関数combined_img()を呼び出して，画像を横方向に連結する．この例では単純に画像の上辺を揃えて横方向に連結を行うだけであるが，画像を折り返して連結したり，さらにいわゆる「矩形パッキング問題」をの解を求めることで無駄な領域が小さくなるように連結することもできる．また，このサンプルでは連結する関数combined_image()に画像のポインタの配列を渡しているが，可変引数を利用（stdarg.h）して，combine_image()を次のように定義する方法もある．

IplImage*

combine_image(int num, ...)

{

va_list list;

int i;

int width = 0, height = 0;

IplImage *tmp[num];

IplImage *cimg;

CvRect roi = cvRect(0, 0, 0, 0);

va_start(list, num);

for(i=0; iwidth;

height = height < tmp[i]->height ? tmp[i]->height : height;

}

va_end(list);

cimg = cvCreateImage(cvSize(width, height), IPL_DEPTH_8U, 3);

cvZero(cimg);

for(i=0; iwidth;

roi.height = tmp[i]->height;

cvSetImageROI(cimg, roi);

cvCopy(tmp[i], cimg);

roi.x += roi.width;

}

cvResetImageROI(cimg);

return cimg;

}

车牌识别 - Ask.com Search

noreply@blogger.com (Unknown) — Wed, 1 Jul 2009 15:28:00 +0800

http://www.ask.com/web?q=%E8%BD%A6%E7%89%8C%E8%AF%86%E5%88%AB&search=search&qsrc=0&o=0&l=dir

车辆牌照相似字符识别研究

noreply@blogger.com (Unknown) — Fri, 15 May 2009 09:03:00 +0800

来源于网络，引用请注明出处

车辆牌照相似字符识别研究.pdf

为何美国没有史玉柱而中国没有乔布斯

noreply@blogger.com (Unknown) — Tue, 12 May 2009 20:51:00 +0800

　　1.变脸 Face Off

　　2.超我 Superego

　　3.小王国与大盗

　　4.羊驼

作者：申音《创业家》杂志前执行主编

时光倒流20年。

那是1989，柏林墙倒塌的时刻。整个世界都在关心着冷战的终结、民主的胜利、意识形态的巨变。

但有两个家伙根本不关心政治。

一个是34岁的史蒂夫。乔布斯，这位"硅谷金童"的人生正处于低谷。在被自己参与缔造的苹果电脑公司赶出来后，他为了复仇创办的Next和低价买下的 Pixar都处于入不敷出、岌岌可危的境地。这位昔日全美最富有的人之一（远远超过那时的比尔。盖茨），私人财产只剩下2500万美元。

而另一个是27岁的史玉柱。刚刚硕士毕业的他瘦得可以被风吹倒。跟那个年代大多数的热血学子们相比，史玉柱没有狂热的政治理想，他一心想的是如何找梯子登上商业舞台。

20年的跌宕过后，乔布斯和史玉柱已分别成为各自国家商界的标志性人物。而当年关心政治的人们如今只关心经济了。

不过，还没有人去认真地比较一下乔布斯和史玉柱。更没有人去思考：为什么美国没有史玉柱，中国没有乔布斯？

这其实是一件很有意思的事情。

精彩摘录：

・两人还是洞悉人性的营销天才。只不过一个靠发掘人性的美好赚钱，而另一个利用人性的弱点来抢金。

・两个理想主义的青年，一个变成了真正的商业梦想家，为了创造未来他不惜调动一切资源。而另一个人转变为纯粹而现实的商人，精确地计算着自己的付出与回报，不再做那些费力不讨好的事。

・中国并不缺乏伟大的商人，比如胡雪岩、张謇、卢作孚，但他们死了，人们如今只记得一些轶事；而熊彼得定义的企业家过去了，他们还能留下激动人心的产品和伟大的公司。

・美国梦的真正含义是什么？是给一个理想主义者提供梦想成真的舞台。那么中国梦呢？是不是逼着一个理想主义者向现实妥协，最终自己成为这个环境的一部分，才能成功？

　变脸 Face Off

　　在我看来，乔布斯和史玉柱的人生经历就像是同一个剧本大纲拍出的两部电影，只不过更换了不同的导演和时空场景。

　　两人都是本国知识青年里的佼佼者，脑子好使还天不怕地不怕，早早投身高科技领域创业，并在三十岁左右就达到了事业的第一次高峰。

　　1983年，年仅28岁的乔布斯登上了《时代》周刊的封面，他被看成是"个人电脑的真正发明者"。1992年，在一个国内十大城市万名青年的问卷调查中，史玉柱名列"最受崇拜的青年人物"第二位，第一名是比尔。盖茨。

　　两人都习惯于蔑视陈规、特立独行，带着点邪性的"范"，一个永远的黑色套头衫配牛仔裤，而另一个光头红白运动衣。

　　他俩都有着与生俱来的商业敏感，是真正的跨界高手。乔布斯在PC、音乐、电影、手机等多个领域都证明了自己的能力，而史玉柱则在软件、房地产、保健品、金融投资、网游等战场纵横驰骋。

　　两人都是执着的完美主义者，都能把一个产品做到惊天地泣鬼神。卖了10年的脑白金仍是中国最畅销的保健品，而iPod则占据了数字音乐播放器市场的70%.此外，两人还是洞悉人性的营销天才。只不过一个靠发掘人性的美好赚钱，而另一个利用人性的弱点来抢金。

　　或许是因为成功来得太过迅速，他们先后导演过自毁式的高速坠落，幡然醒悟之后，又表现出惊人的自我纠错能力，并重新勾画一条不断向上的弧线。

　　曾经有那么一段时间，史玉柱看起来就要成为中国的"乔布斯"。从1989年起，他每一年都要推出一款自主开发的产品，从M-6401桌面排版软件、M-6402文字处理软件到巨人汉卡，再到巨人中文手写电脑、巨人财务软件等等。巨人飞快地成长为一个年产值10亿、利润数千万的高科技集团公司，其年度销售商大会更成为全国规模最大的电脑盛会。

　　几乎与此同时，乔布斯只剩下几千万美元的现金，和两个面临着裁员重组的问题公司，他完全可能成为美国版的"史玉柱"，比如在加州搞房地产，去拉斯维加斯开赌场，到中东倒腾石油，或者变成一个精明的股权投资人。但他什么都没有干，只是继续掏自己和别人的腰包来支持两个长期赔钱的公司，固执地等着它们出现转机。

　　某种程度上，乔布斯是幸运的。在美国，他的理想主义总能找到合适的欣赏者，所以他可以咬牙不向现实妥协。像罗斯。佩罗这样的前辈创业家愿意签出支票，并与其分担风险。迪斯尼这样的大公司也同意投资给小公司Pixar，让其制作动画长片并参与分成。

　　而史玉柱之所以蜕变成今天的史玉柱，是因为他发现，做软件公司为他意外地赢得了名声，而在中国，名声就意味着许多新的机会。

　　在邓小平南巡讲话之后，史玉柱恰逢其时地被媒体和政府发现。很快，他被评为"中国十大改革风云人物"、"广东省十大优秀科技企业家"等，获得了珠海市第二届科技进步特殊贡献奖，一位总把裤带提到胸下的最高领导视察后题词说"中国就应该做巨人"。

　　你可以不关心政治，但政治会来关心你。

　　为了支持这个"高科技楷模"，当地政府以不到当时市价1/4的价格给了史玉柱一块市中心地皮盖楼（350/平米地价，2007年珠海的平均地价已经是 3500/平米）。而在若干位更高层领导的直接鼓励下，他把计划一改再改，从原来的自用变成了商用，从最早的19层变成72层（全中国第一高楼），预算从 2亿变成了12亿元。

　　单纯软件业务的回报根本不足以支撑这样高的资金投入，于是史玉柱中断了技术创新，开始卖楼花、运作保健品、搞服装，杀入更加暴利的行业。最后因为由于工程拖期、宏观环境的恶化，导致整个公司的资金链断裂，巨人大厦从此沦为中国最著名的"烂尾楼"，直到今天。

　　有意思的是，1998年，背负着2亿巨债的史玉柱想要东山再起。他又算了一笔账，搞软件虽然利润很高，但市场相对有限，如果要还清2亿元，估计要10年；保健品不仅市场大而且刚起步，做脑白金最多5年（实际上只用了3年）。

　　事实证明，他的选择居然又是对的。

　超我 Superego

　　一个人的性格，会成为他今后命运方向的指针吗？

　　乔布斯，一个私生子，在中产阶级养父母的宠爱下长大，自卑与自大的双重人格。他的理想主义是与强烈的领地意识、以及咄咄逼人的攻击性混合在一起的。

　　乔布斯早年的密友、曾经一起吸毒、一起去印度朝圣的丹尼尔。科特克说："史蒂夫心中总是装着他的苹果电脑。从更深层次上分析，他的成功是由于其内心总有一种深切的不安全感，正是这种不安全感使他必须出去闯荡以证明自己存在的价值。另外，由于他从小就知道自己是被收养的孩子，他的行为并不被大多数人理解……"

　　就像《星球大战》中安纳金天行者。这种内心深处的"原力"，与加州的硅片、晶体管结合起来，苹果公司诞生了。正如伊甸园里蛇诱惑亚当和夏娃吃下的那个苹果，甜美而带有一点"邪恶"。

　　事实上，在苹果电脑早期的发展中，沃兹的技术、马库拉的资本运作、斯科特的管理和乔布斯的远见几乎一样重要，但作为公司董事局主席，乔布斯的个人魅力，让他轻易成为了公众关注的中心，并几乎独享了上市成功后的光环。

　　随着创业伙伴们因为各种原因一个个隐退，他越来越认为自己才是"点石成金"的超级人物，可以将个人凌驾于公司之上。硅谷最著名的投资人之一、当时苹果的董事会成员阿瑟。洛克回忆说："那时，乔布斯刚愎自用，满脑子主意，肆意而为，毫不考虑公司的前途。"

　　按照佛洛依德的理论分析，乔布斯的自我（ego）逐渐被本我（id）所控制，他被原力的黑暗面所吸引，并一步步走向公司的对立面，终于被董事会放逐。

　　而那个来自安徽小镇怀远，独自闯荡大城市的青年同样拥有着强大的内心世界，激励他的是一种英雄主义情结。

　　事实上，史玉柱出生的环境里根本连个晶体管都找不到，当乔布斯和沃兹开始组装第一台计算机的时候，他还只能对着《十万个为什么》自制土炸药。更不用说预判到"一人一台电脑"的产业未来呢？

　　对于以嬉皮士自居的乔布斯而言，电脑恰好是能帮助他释放旺盛的Libido（欲望）的媒介罢了，但对于史玉柱来说，电脑则是帮助他改变命运的唯一工具。否则他只能像刘震云小说《单位》里的大学生小林一样，过着按部就班的生活。

　　1984年，在乔布斯策划的那则著名广告里，苹果的女模特挥锤砸烂了"Big Brother老大哥"。在PC世界里，谁都知道"老大哥"就是IBM. 1990年，身高1米80、体重不到120斤的史玉柱给自己的新公司起了一个非常响亮的名字――"巨人"，他宣布，巨人要成为中国的IBM，东方的巨人。

　　这很容易让人联想起2000多年前的刘邦，他在见到秦皇车驾时的感叹，"大丈夫当如是也"。而另一个叛逆者项羽，说的是"彼可取而代之"。

　　这种自我赋予又被外界不断强化的使命感贯穿了史玉柱创业的前半程。熟读毛选，青年楷模，大跃进式的增长目标，军事化的企业管理，为自己为城市树立一座固化的丰碑……

　　终于有一天，这些使命变成了他再也承受不起的包袱，庞大的"巨人"分崩离析。三年后，在经历了对人性和坏境的彻底反思，一次次自杀的念头和被追杀的恐惧之后，一个完全理性的、成熟的、内心更强大的史玉柱回来了。

　　他彻底放弃了珠海时期的企业文化"做中国的IBM"，"这是非常害人的一个空想，制定了一个很虚的目标。它在鼓励什么，鼓励大家搞大跃进、搞浮夸，让大家心里面很浮躁，对于现实没有什么帮助，现在我就不搞那个宏伟的目标了，我觉得实用最关键。"

　　新的文化很直白，"说到做到、只认功劳、严己宽人、敢担责任、艰苦奋斗。"这是在黄山太平湖，柳传志教给他的。

　　史玉柱不再把自己当成一个"知识分子"，他坦言"胆子越来越小"，"只做好商人必须做的事情"。在一个只有"锦上添花"没有"雪中送炭"的现实环境里，他找到了正确的生存策略。让企业永远保持充沛的现金流，负债率低于30%；只做高利润率又不跟政府沾边的生意（这样的生意常常处于灰色地带）；既然银行不肯借钱，就干脆参股银行；及时把公司变现，玩资本财技（上海健特借壳、巨人上市融资近10亿美金）；跟有合法伤害权的媒体保持恰当的距离又给予充分的好处。唯一遗憾地是，他对创新不再有兴趣。

　　乔布斯在"荒野"中被放逐的时间更长。尽管他的坏脾气改变有限，但他学会了宽容和谦卑，知道怎么信任和授权给优秀的人，比如Pixar总裁约翰。拉赛特，乔纳森。埃弗。这个设计白色马桶的英国人，后来在苹果公司担当设计副总裁。他学会了合作与开放，让微软入股，用英特尔的芯片，建立了 iPhone开放平台。

　　人们的第一次成功往往根源于欲望和运气，而第二次乃至更多的成功则需要智慧和自控。

　　无论乔布斯还是史玉柱，最终都通过克制本我，实现了自我超越（Superego），这才是他们真正的魅力所在……

　　不同在于，两个理想主义的青年，一个变成了真正的商业梦想家，为了创造未来他不惜调动一切资源。而另一个人转变为纯粹而现实的商人，精确地计算着自己的付出与回报，不再做哪些费力不讨好的事。

小王国与大盗

　　其实，道德感与一个人的成功并无太大关系。

　　在硅谷，与乔布斯的天才同样闻名的是他的傲慢自负、喜怒无常、抠门小气、巧取豪夺、冷漠无情。前时代周刊的记者，日后红杉投资的大佬迈克。莫里茨，曾把在乔布斯威权统治下的苹果称之为"小王国"（Little Kindom），这是一个非常准确的描述。

　　专制带来效率，难得乔布斯的个人品味和商业直觉又皆属一流。不过，如果乔布斯生在中国的话，一个传统意义上的"臣民社会"而非"公民社会"里，他的自大会惯坏他，人们会完全屈服于他的权威，听从他的指令，直到他最终把公司毁灭，就像牟其中、唐万新、孙宏斌这些人一样。

　　但他生在美国，民主社会和资本主义机制里有种天生的"对冲"力量。董事会、股东大会、机构投资者像一道道紧箍咒约束着他。默认的游戏规则是，只要你有能力做大公司的价值，就算你是个暴君也无妨；反之，等待你的就是自动下台或者政变逼宫。

　　在中国，大多数民营企业和其创始人的命运，缠绕得太紧密了。权力的垄断和资本的垄断密不可分。我们没有发明出一套"防火墙"的制度，能将创始人的个人行为、个人信用与企业分离开。

　　于是，考察企业家自身的道德品质，变成了一件无比严肃又异常困难的事情。

　　相比大多数国内同行，史玉柱，堪称私德无缺。他信守承诺、有情有义、高度放权、慷慨分利，在公司破产之后，其核心团队成员仍不离不弃，甚至拿自己的钱来补贴公司。而他二次创业成功后，主动还债两亿的壮举，也足以表率。

　　在后来的巨人集团内部，史玉柱甚至成功地创造了一个"民主管理"的小环境。他成立了七人执委会，任何决策都必须多数票才能通过。除了核心产品，日常人财物管理全部放手，文秘出身的总裁刘伟，事实上已扮演了CEO的角色。

　　在《庄子。外篇》中，大盗盗跖（传说是贤人柳下惠的弟弟）与他的徒弟谈论"盗亦有道"。跖曰："夫妄意室中之藏，圣也。入先，勇也。出后，义也。知可否，智也。分均，仁也。五者不备而能成大盗者，天下未之有也。"

　　五者皆备的史玉柱，在现实的商业世界里扮演一个"Big Brother"的角色，通过排山倒海的营销攻势，淹没一切反对声音。居高临下地制订规则，利用消费者的无知、贪婪和权力欲，还有既懒惰而又想过瘾的心理，设计出各种圈钱的工具（详见《南方周末》的文章《系统》）。

　　史玉柱直言，"商业是什么？商业的本质就是在法律法规许可范围内获取最大利益。我是一个商人，做的事情就是在不危害社会的前提下为企业赚取更多利润。要一个商人又要赚钱又要宣扬道德，那不是商人，而是慈善家。"

　　而视道德为无物、几乎从未在慈善事业上捐出一毛钱的乔布斯，从iMac、iPod到iPhone，他所推动的一切都是在迎合"YOU"这个消费者主权的时代。过去唯我独尊、四面树敌的苹果，开始走向一种新的理念：用户要的不是技术，甚至不是电脑，而是利益的最大化和体验的最优化。

　　他不再把苹果视作一家电脑公司，归根结底，"我们骨子里就是一家消费品公司，你的生死存亡掌握在消费者的手中。他们才是我们关注的对象。我们觉得自己的工作就是对整个用户体验负责。如果表现不及格，那就是我们的错。错就一个字。"

　　这是不是"民主"精神在商业里的最好体现？

　羊驼

　　1995年，史玉柱名列《福布斯》中国百富榜第8位，当时他是唯一一个搞高科技的企业家。

　　2009年，史玉柱仍然是《新财富》500富人榜中，排名最高的与新经济有关的富豪。在他后面的是李彦宏、马化腾、施正荣等。

　　看《枪炮、病菌与钢铁――人类社会的命运》一书，美国生物历史学家贾雷德。戴蒙德谈到了一个有趣的问题：为什么14种被驯化的大型哺乳动物有13种来自欧亚大陆，为什么欧亚大陆的牛、马、绵羊、山羊、猪，而不是南美洲的羊驼，成为最终广泛分布于全世界的牲畜？

　　他的答案是环境。最主要的原因是，欧亚大陆由于其广大的面积和生态的多样性，拥有最多的可驯化的候补动物。而这些驯化动物又促进了欧亚大陆民族的繁荣，进而帮助后者征服全世界，而这些动物跟随着征服者遍及其它大陆。

　　在商业世界里，存在着相似的问题。在过去100年中，为什么以美国为首的少数4-5个国家，而不是剩下的100多个国家，集中产生了几乎所有对社会进步至关重要的创新？几乎定义了这个星球所有成功的商业模式？

　　史玉柱和乔布斯，两个同样具有商业天赋，且性格背景相似的创业者，最终一个变成垃圾商品的成功贩卖者，而另一个成为这个星球上最具创造力的企业家。

　　当乔布斯在斯坦福的演讲"Stay hungry，Stay foolish"可以影响全世界青年的时候，史玉柱在《赢在中国》里的语录却只能供本土创业者琢磨。

　　每个社会里都可以孕育出潜在的商业天才。而真正的商业天才，在任何环境下都有可能成功的。

　　但在某些环境中成长出来的商业，就像南美安第斯高原的羊驼。看着很可爱很善良，经济价值很高，但是却无法大规模的繁衍和推广。

　　美国梦的真正含义是什么？是给一个理想主义者提供梦想成真的舞台。那么中国梦呢？是不是逼着一个理想主义者向现实妥协，最终自己成为这个环境的一部分，才能成功？

　　"当巨人一步步成长壮大的时候，我最喜欢看的是有关成功者的书，当巨人跌倒之后，我看的全是失败者的书，希望能从中找出站起来的力量。"史玉柱说。

　　在2000年CCTV的一次《对话》节目中，史玉柱谈到了所谓"理想的状态，就是说今后市场经济发育到一定时候，法制环境建立，然后就是政企脱钩，我最希望的是一个什么样的环境：就是一个政府包括国家领导人，省级领导人，包括地方领导人，他做他的事，我们企业做我们企业的事。就等于你这个领导人你定游戏规则，然后我们这些人就按你游戏规则做事。最好是不要有什么太多的接触，我就是这个意思。巨人大厦这个问题上，不管哪一级的领导人没有任何的责任，责任全是我的。"

　　当一个人把所有的问题都归咎于内因的时候，是因为他意识到自己改变不了外在环境，能改变的只有自己。

　　其实近代以来，中国并不缺乏伟大的商人，比如胡雪岩、张謇、卢作孚，但他们死了，人们如今只记得一些轶事；而熊彼得定义的企业家过去了，他们还能留下激动人心的产品和伟大的公司。

　　今天，中国可能是唯一一个创业热情甚至比美国更高的国家。各级政府鼓励"以创业带动就业"，启动创业板，政府成立风险投资基金。这些都是好事。但必须承认，我们仍然是一个缺少知识产权保护，国家垄断资源和与之相关的分配权，资本更青睐与权力结合而非知识，优秀的年轻人希望跻身公务员之列的社会。

　　哪些被乔布斯所激励的创业者们，最终会不会变成为史玉柱的信徒呢？

　　这是一个问题。

车牌识别

1

图像五值化与基于三值图像的车牌识别

SURF综述[转]

应用程序与MFC规则DLL共享MFC DLL（或MFC扩展DLL）资源模块句柄的切换

MFC规则DLL的创建与使用技巧[转]

开源OCR引擎Tesseract 3.0发布 支持中文

关于字符编码，你所需要知道的

关于字符编码，你所需要知道的

还是得从ASCII码说起

OEM字符集的衍生

多字节字符集（MBCS）和中文字符集

ANSI标准、国家标准、ISO标准

Unicode的出现

Unicode字符集概述

编码系统的变化

常见的Unicode编码

Unicode相关的常见问题

乱码问题

必要的术语解释

面试前需考虑的25个问题-褪墨

面试前需考虑的25个问题

Thu, 08 Apr 2010 09:29:03 +0800

准备功课!

开源的车牌识别工程

LicensePlateRecognition

低效能人士的七个坏习惯-褪墨

低效能人士的七个坏习惯

Sun, 14 Mar 2010 12:44:00 +0800

缺席

拖拖拉拉

做无关紧要的事情

多虑

凡事过于消极

固执己见，与世隔绝

持续信息过剩

如下实现，用CString时，是肯定会造成内存泄露

车牌识别博客订阅地址

车牌识别中一种新的直接基于彩色图像的二值化简化方法[转]

汽车牌照识别技术的研究与实现

浅谈C++中内存泄漏的检测

A Visual C++ Exception FAQ

A Visual C++ Exception FAQ

Copyright © 2001-2007 Doug Harrison (http://members.cox.net/doug_web/eh.htm)

Comments

简单有效的图像去雾技术

广东：卡口系统年内启用可快速识别套牌车

利用OpenCV进行图像连接

车牌识别 - Ask.com Search

车辆牌照相似字符识别研究

为何美国没有史玉柱而中国没有乔布斯

开源OCR引擎Tesseract 3.0发布支持中文