乱七八糟

回国频繁碰到的东西:

奥运//到处都是奥运图标,从下飞机的那一刻到上飞机的那一刻

新xxx。新楚留香,新上海滩,新。。。//感觉大家都在怀旧

淘宝//表姐和老哥都想在上面开店赚钱

集结号,投名状//国内又开始贺岁片

Merry Christmas//还没到Christmas,各大商店就开始营造气氛,连饭店,邮局的服务员都带一个小红帽,这一点美国差远了

 

Advertisements

乱七八糟

时差没倒过来,一夜没怎么睡着觉。睡觉也是在做梦。

过几天就得提交一个20来页的报告,不知道该怎么写。iai定义的任务太模糊了,不知道该怎么着手。想了老久想出一些东西。结果老板给的解释又是另外一套东西。而这套东西又觉得有问题。operational range?老板的意思可能是baseline。可是baseline跟performance又没有什么太大的关系。如果跟前一个报告结合起来,倒是可以。先把老板说的实现了吧。

一个月内又得整一篇paper。大致的思路已经有了,感觉应该也可行。不过问题又回到最初的point correspondences上来。想了很多,又看了些东西。感觉MOPS简单一些,而且跟自己的思路比较像。sift反复看也没完全明白。如果没说错的话,scale invariant主要靠以不同的scale先resize image,在不同scale level上都取特征。rotation invariant主要靠先计算一个orientation,就算是normalize一下。另外,用haar like的feature算一个hash值可以加速matching。

无论如何,得花时间写代码了。

还是point correspondences

又准备重写point correspondences。搞了一两天,还处于思考状态。想加入scale, luminance, rotation invariant。然后看paper,上网搜索。http://www.robots.ox.ac.uk/~vgg/research/affine/index.html。好像sift还是最好的。可是代码都是linux下的。用vc20005编译siftpp,整了老半天,最后导致编译器出错,wk~。看来最后还是必须自己实现。可是实现也需要花很多的时间。花了很多的时间其实还不一定有效。以前好像也尝试过,发现效果很多时候还没有自己简单的方法好。怎么办呢?

特定的应用有特定的需求。很多时候简单的方法就能work得很好,甚至更好。实际其实很少有极端特殊的情况。可能主要是luminance的变化,或者有一点儿rotation什么的。那么针对实际应用写对应的算法?

无论如何,先把简单的重构了吧。

乱七八糟

12月22号第三次婚宴,以后谁要结婚可以找我帮忙

老哥喝了很多很多的酒,说心情很好

23号老哥生日,买了个大蛋糕,第一次给老哥过生日

昨天在广埠屯武汉口腔医院,洗牙180,补了两个小洞150,在美国估计就要上千美金了

在电脑城买了两个鼠标,总共45,都很漂亮,买了两个ibm笔记本的套子

今天继续干活儿

重写代码

一直想改写类库,但总是没时间,每次写代码都是火烧眉毛的时候,只想着用最简单,最笨的方法尽快实现,有时甚至是直接copy paste,根本没有功夫组织代码,重构什么的。现在回国,趁着任务不是很紧急,静下心来,多花些时间思考,重新整理一下代码。想把之前的应用也重新写一下,也算是整理研究问题上的思路。回去后就要开始准备写论文了,这个事情也就非常的必要。其实任务也是很紧张,iai公司的活儿下个月初就得交报告。aaai的deadline是下个月末。louie的项目如果顺利的话下个月初就要开始。所以其实事情是相当相当的多。

首先重构类库。主要问题是归类整理,重新命名等。看起来简单,其实很麻烦。而且自己也缺少经验。其实应该花些时间看看好的c++类库。但是也不知道哪些比较好。boost?也没有一本专门介绍如何写类库方面的书。不过自己的问题也很特殊。首先是要基于opencv,在上面补充一些东西。另外自己做的应用牵涉到各种不同的方面。而有些东西的算法又是不断的演变的,或者不同的情况需要不同的算法。没有一个十全十美的算法。如果这些算法都堆积到类库,那么就得经常往类库添加或者修改东西。可是如果不放在统一的类库里,又导致出现许多的小类库,引用和重用可能也很麻烦。而c++又不像java那样方便部署。想来想去决定分离。前几天想到一个原则:把有很多不同算法的东西分离出来,作为单独的应用或者类库。如果一个问题没有很多的算法,仅仅是简单的一个标准公式,或者有些标准算法,那么就扔到类库里去。比如说点与线的距离。不过,即使对于有很多算法的一个问题,也在类库里面提供最简单的实现算法。程序设计的原则之一是分离不变的和易变的。这通常导致应用接口和实现的分离。不过通常来说这些接口和实现都放在一起。我以前也这么干,但是现在感觉自己的问题特殊一些。因为学术界的问题虽然定义简单,但是有无数种的算法,这也是每年为什么都有那么多paper的原因。所以呢,一个简单的接口引申出来的实现总是越来越膨胀,不像工业界,程序和流程只是固定的那么几种,而且清晰明了。

另外的问题是ui。一个问题可能有很多算法,一个算法又可能有很多的参数。几个月前写了一些console的程序。虽然自己使起来很方便,但是让别人用就不行了。那么写gui?又很繁琐,有太多的选项。而且,还涉及到parse参数文件的问题。这些都得花很多功夫。可是时间又很紧张。而且自己写gui的功底也不行。又想都已经2008年了,还在用vc6.0的那些东西,是不是过时了?