对ptgrey的camera进行编程还是比较painful的。想想以前自己写olympus和DH-400的程序也没这么麻烦呀，可能是应用相对简单吧。现在写ptgrey的程序真是头疼，没有人可以请教请教，API的doc也讲的很简单，提供的sample也比较少，有时候基本上全靠自己一个人在那瞎琢磨，简直就在挑战自己的想象力和排列组合能力。经过3天的排练组合，程序终于可以了修改frame rate和video mode了，但是改成任意大小显示还有点问题，不过应该可以将就着用了。

——————————–

下面是细节的东西，可能也就自己会看看：

程序是从timeSliceDemo这个例子该过来的，创建了单文档多视图的程序，还创建了CMultiDocTemplate。修改frame rate和video mode主要是修改startSync()和grabAndCheckSync()这两个函数，

grabAndCheckSync(), 其中grab image主要由两个函数实现flycaptureLockNext和flycaptureConvertImage。flycaptureConvertImage将arbitrary image type转成dst image，转换之前要设置dst image的格式，我试了一下，这里只能是FLYCAPTURE_BGRU，不然该程序就会报错，血的教训呀，2天时间。如果设置成FLYCAPTURE_BGRU的话，在startSync中创建buffer的时候就要为cols * rows * 4，因为4个channel嘛。

startSync()，这个函数里pixelFormat也要设置成FLYCAPTURE_BGRU，如果设置成FLYCAPTURE_MONO8， FLYCAPTURE_422YUV8， FLYCAPTURE_BGR， FLYCAPTURE_RGB8等都会出错。doc里没有说，显然ptgrey连明年版本里的功能都先写进doc里了，可把我害惨了。如果要改变图像的分辨率，要在这两个函数里改，flycaptureGetCustomImagePacketInfo和flycaptureStartLockNextCustomImagePacket。或者不用packet，直接用flycaptureStartLockNext，而不用flycaptureStartLockNextCustomImagePacket，这样就可以设置VIDEO_MODE和FRAME_RATE。比如设置成15Hz，省得server的workload太大。

lab买的server内存大了也麻烦，整个8G内存居然camera的驱动就不认了，只好拔掉4根内存条，或者将OS从windows2003server Enterprise转成winxp32bit，这时PTgrey的camera才能用（据说ptgrey做的camera还是最好的）。这些哥们设计驱动的时候估计压根就没有想到有人将这么多个camera同时连到一个server上，就算想到了估计也没有想到会在机子里装这么多内存，可是我们就是这么干的。搞得这一星期来我就不停的重起机子，在server，winxp64，winxp32之间不停的切换，感觉自己在无偿得为ptgrey做测试，到现在提交的问题一个也没有解决，郁闷不是一两星期了。

其中有一个问题得到了confirm，就是现在他们的驱动在32bit的OS下，只能支持小于4G的内存，大于4G的话程序就不能运行。今天那个Paul给我发邮件说，其实不用每次将内存拔下来的，只用这样这样那样就可以了。就是修改系统的BOOT.INI文件，在

[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows 2003 Server, Enterprise Edition" /fastdetect

后面加个/maxmem=3000就行了，3000指的是3000M内存。如果你的机子装了多OS，这里会有好几条信息，对应着系统启动时不同的选择信息，随便删掉一个，那个对应的系统就没法启动了。有时安装OS时会产生冗余的启动选择项，就可以跑到这里来，删掉就可以了。

http://www.codeguru.com/forum/showthread.php?t=408061

Q: I have an MFC application that runs on my computer, but when I try to run it on another PC I receive an error message that the application failed to initialize and I should re-install it. What should I do?
A: By default, Visual C++ 2005 builds all native C/C++ applications as isolated applications, i.e. self-describing applications that use manifest files to describe their dependencies to VC++ libraries. The problem occurs because your application doesn’t have a manifest, or it has dependencies to assemblies that don’t exist on the target PC, or they have a different version number. Basically you have to do two things to solve the problem:

• Distribute a manifest resource file along with your application
• Deploy the re-distributable assemblies that your application depends upon

Q: What is a manifest resource?
A: A manifest resource is an XML file that describes the dependencies of your application. Such dependencies can include the most current version of the Windows common controls, as well as library assemblies, such as MFC, ATL or CRT assemblies.
Your manifest should have the same name as the application and the extension "manifest" and should specify the version number of your assembly (executable or dynamic library), processor architecture, name of the assembly and platform type; a description of your assembly is also recommended.

Code:

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
<assemblyIdentity 
  version="1.0.0.0" 
  processorArchitecture="X86" 
  name="CompanyName.ProductName" 
  type="win32"
 /> 

 <description>Description of your application.</description>
</assembly>

Q: How do I specify dependencies?
A: You have to add a element to the XML-based manifest. For instance, if you want your application to use the Windows common controls with the XP-like style, add a dependency to the assembly called "Microsoft.Windows.Common-Controls":

Code:

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
<assemblyIdentity 
  version="1.0.0.0" 
  processorArchitecture="X86" 
  name="CompanyName.ProductName" 
  type="win32"
 /> 

 <description>Description of your application.</description>

<dependency> 
  <dependentAssembly> 
   <assemblyIdentity 
    type="win32" 
    name="Microsoft.Windows.Common-Controls" 
    version="6.0.0.0" 
    processorArchitecture="X86" 
    publicKeyToken="6595b64144ccf1df" 
    language="*" 
   />
  </dependentAssembly> 
 </dependency>

</assembly>

Q: I now understand what a manifest resource is, but what are re-distributable assemblies?
A: These are assemblies provided as dynamic link-libraries that you can deploy with your application, because they are required for the application to work. Assemblies are provided in several configurations, Release and Debug, but you can only re-distribute the release configurations (can be found in Visual Studio 8 installation folder, VC\redist).
Visual C++ 2005 supports a new deployment model for Windows client applications based on isolated applications and side-by-side assemblies. Basically, assemblies can be:

• shared (they are globally registered in the system, installed in the Global Assembly Cache – GAC folder in Windows – and available to all applications) or
• side-by-side, described with a manifest, distributed with the application and available only to that application

In Visual C++ 2005, library assemblies (such as MFC, ATL, CRT) have been rebuilt as shared side-by-side assemblies and installed in the native assembly cache, WinSxS folder in Windows. That means they are not globally registered in the system, but are globally available to the applications that specify a dependency with a manifest file.
The target machine where you run your application may already have the required dependencies installed. You can look-up for them in the WinSxS folder. Assemblies are grouped here on categories, each with its own folder. Folder names start with the platform name, followed by Microsoft, category (Windows, VC80, MSXML, Tools), assembly name, a token number, version and additional identifiers. The manifest files for these assemblies are located in the Manifest subfolder of WinSxS and have the same name as the folder of the assembly group they contain information about.
Q: How do I specify dependencies for my application in the manifest file?
A: Suppose your application uses MFC as a shared library, so it has at least a dependency on MFC and one on the C runtime library and C++ runtime library (these two part of the CRT assembly group). In this case your manifest file should look like this:

Code:

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
<assemblyIdentity 
  version="1.0.0.0" 
  processorArchitecture="X86" 
  name="CompanyName.ProductName" 
  type="win32"
 /> 

 <description>Description of your application.</description>

<dependency>
    <dependentAssembly>
      <assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50727.42' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
    </dependentAssembly>
  </dependency>

  <dependency>
    <dependentAssembly>
      <assemblyIdentity type='win32' name='Microsoft.VC80.MFC' version='8.0.50727.42' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
    </dependentAssembly>
  </dependency>

</assembly>

If the target machine already has these assemblies and the version info (process architecture, version, public key token) matches, you don’t have to redistribute anything, because your application will be able to use the assemblies from the native assembly cache (WinSxS). Since you cannot be sure of that you should distribute these assemblies with your application (in the same folder with the application). Windows will first looks-up for assemblies in the current folder and then in WinSxS and GAC, so distributing them in the working folder ensures those assemblies are used.
To distribute the correct assemblies after building the application, go to the Visual Studio 8 installation folder in VC\redist and select your target platform folder, i.e. x86 or amd64. Inside, you will see folders for ATL, MFC, CRT, MFCLOC and OPENMP.
The Microsoft.VC80.MFC folder contains 4 DLLS and a manifest file, called Microsoft.VC80.MFC.manifest. You must copy at least MFC80.DLL (or MFC80U.DLL if you built for UNICODE) to your application working folder. You must make sure that the version number of the MFC assembly specified in this manifest matches the one you put in your application manifest and the one of the DLL itself (this should be implicit, but should check that from the file properties, Alt + Enter > Version).
The Microsoft.VC80.CRT contains 3 DLLs and the manifest. Of these three DLLs you need at least msvcr80.dll (C runtime library) and msvcp80.dll (C++ runtime library). The same caution for the version number must be taken.
With all these taken care of, your application should correctly run on any target machine.

Matt Pietrek

One of the pleasures of working on the bleeding edge of Windows^® is poking around in a new technology to see how it works. I don’t really feel comfortable with an operating system until I have a little under-the-hood knowledge. So when the 64-bit editions of Windows XP and Windows Server™ 2003 appeared on the scene, I was all over them.

The nice thing about Win64 and the x64 CPU architecture is that they’re different enough from their predecessors to be interesting, while not requiring a huge learning curve. While we developers would like to think that moving to x64 is just a recompile away, the reality is that we’ll still spend far too much time in the debugger. A good working knowledge of the OS and CPU is invaluable.

In this article I’ll boil down my experiences with Win64 and the x64 architecture to the essentials that a hotshot Win32^® programmer needs for the move to x64. I’ll assume that you know basic Win32 concepts, basic x86 concepts, and why your code should run on Win64. This frees me to focus on the good stuff. Think of this overview as a look at just the important differences relative to your knowledge of Win32 and the x86 architecture.

One nice thing about x64 systems is that you can use either Win32 or Win64 on the same machine without serious performance losses, unlike Itanium-based systems. And despite a few obscure differences between the Intel and AMD x64 implementations, the same x64-compatible build of Windows should run on either. You don’t need one version of Windows for AMD x64 systems and another for Intel x64 systems.

I’ve divided the discussion into three broad areas: OS implementation details, just enough x64 CPU architecture to get by, and developing for x64 with Visual C++^®.

http://msdn.microsoft.com/msdnmag/issues/06/05/x64/default.aspx

第一次作业做两幅图像的fusion，用Laplacian Pyramid 的方法。自己写卷积函数，上采样下采样函数，还有Pyramid函数。搞不懂vison的老师为什么还要我们实现这么老的算法，上学期都已经学过Poisson Image Editing了，这学期反而退化去实现这个Pyramid算法，简直没有脾气。

输入两幅图像，还有mask图像：

 融合结果为下左，接着相加的结果为下右：

郁闷，不能release image

Unhandled exception at 0x7c901230 in Prog1.exe: User breakpoint

程序停在free.c的return HeapAlloc(_crtheap, 0, size);这一行

如果ignore，and continue,则会碰到

Insufficient memory (Out of memory) in function cvAlloc, .\cxalloc.cpp(111)

….

搞了快6个小时才发现，image循环的for loop写错了，写成了

for(int i = 0; i < src->widthStep; i ++)

这样image的数据就写出届了，搞得image的data crash了，因而不能release。还好现在都搞定了，只用了0.2s，删掉了4个字母。