《A Non-Local Cost Aggregation Method for Stereo Matching》读后感~

最近一直在做stereo matching方向的研究,仔细研读了包括局部算法,全局算法,以及半全局算法三个方面的算法文献,对该方向有了比较清晰的了解,这次分享一下我对杨庆雄的经典文献《A Non-Local Cost Aggregation Method for Stereo Matching》(简称NL算法)的一些理解。

之所以想分享这篇文献,是因为文献明确抛弃了support window的算法思想,指出support window在视察估计上普遍具有陷入局部最优的缺陷,创新性的提出了基于全局最小生成树进行代价聚合的想法,我觉得这点想法非常厉害,全局算法早就有了,但是往往是基于复杂的优化算法,重心放在了视察粗估计和迭代求精两步,十分耗时,而最小生成树,可以天然地建立像素之间的关系,像素之间的关系一目了然,可以大幅减少代价聚合的计算时间,文献表述为线性搜索时间。计算聚合代价,不需要迭代,算法时间复杂度小,符合实际应用的需求,所以NL算法已经获得了不错的引用率。

NL算法,在后续算法中得到了很多改进,一些好的立体匹配算法,如CSCA,ST等都是基于NL进行了改进,以下部分着重说说我对NL核心部分,最小生成树(MST)的理解。

(转载请注明:http://blog.csdn.net/wsj998689aa/article/details/45041547)

1. 算法思想

本文的算法思想,是放弃原有的基于支持窗口的方式,采用基于全局MST的方式,构建代价聚合公式。因为支持窗口的办法,本质上只考虑了窗口内像素对中心像素的影响,窗口之外的像素的影响彻底忽略,其实想想看,这样做也没有什么不妥,但是它并不适用一些场合,比如文献列举的图像,

左上角的图像就是原始灰度图像,这个时候我们就会发现,这幅图像中像素与像素之间的关系用支持窗口来处理明显不灵,比如说周围框状区域的任何一个像素,肯定与框状区域内部的像素的深度信息一致,而与中间区域的像素不同。或者说,如果单考虑颜色信息,红框内的像素关系最大,如何表征这样的关系就是一个问题。很遗憾,我们不能事先提取出这样的区域,因为图像分割真的很耗时,并且不稳定,这就是作者的牛逼之处,他想到了MST可以表示这种像素关系,于是采用像素之间颜色信息作为“边权值”,进一步构建MST。

MST指的是最小生成数,全称是最小权重生成树。它以全图的像素作为节点,构建过程中不断删除权值较大的边。注意,是全图所有的像素,然后采用kruskal(克鲁斯卡尔)算法或prim(普里姆)算法进行计算。这样便得到了全图像素之间的关系。然后基于这层关系,构建代价聚合,这便是文章标题Non-Local
Cost Aggregation的由来。

通过MST计算权值的效果如上图第二行所示,红色代表高权值,蓝色代表低权值。明显发现MST有效的表征了像素对像素的影响。代价聚合公式如下所示,具体的符号含义,这里就不说了,相信做过立体匹配的童鞋一眼就会看明白。

2. 算法核心

我当时看到这里,顿时产生了一个疑问,这样做的代价聚合考虑到的是全部的像素,那么耗时岂不是很惊人?因为我是逐像素计算视差的啊,每个像素都要考虑周围所有的像素。。。。这时间可能太恐怖点了吧!?

请原谅我的愚钝,作者既然考虑到了MST,说明MST的性质也要被很好的利用,我总结MST在计算效率上的一句话是:MST可以将计算范围从图上所有节点缩小到父节点和子节点上。因为人家是一棵树嘛!比如说,全图320*240,也就是76800个节点,而父节点只有一个,一个或多个子节点,效率可想而知。

2.1 leaf-to-root

假设上图是一个MST,边上的数值代表权重,此时如果计算的是V4的代价聚合,那么很容易,直接计算子节点(V3, V4)的代价聚合值与各自边缘的乘积集合,因为V4是根节点,不需要考虑父节点的影响。公式如下所示,

箭头向上代表从叶子到当前节点的代价聚合值,为何只需要考虑子节点,而不考虑孙子节点,重孙子节点等等的原因就是由于在我们实际计算的时候,要从叶子节点一层一层往上算,这样就会利用树的特性,子节点的代价聚合值已经包含了孙子节点等等对我自己的影响。有点一本万利的感觉。。。

2.2 root-to-leaf

但是这样做是不够的,上面的V4没有父亲节点,属于特殊情况,如果我们要计算V3的代价聚合值呢?显然只考虑V1和V2是不够的,还得考虑V4的影响。也就是从上到下的影响。如图所示:

注意和上一幅图的区别,这个时候我们完全可以假设V3为根节点,它的父节点也变为他的子节点,这样的话,可以利用同样的办法,将V4的代价聚合值乘以它的权重一起再加进来。但是,这里还是有区别的,因为V4的代价聚合值已经考虑到了V3的影响,所以必须事先将V4的代价聚合值减去V3的代价聚合值才可以。公式如下所示:

其中,从上向下的代价聚合值就是最终的代价聚合值,同上一步一样的方式,要从上到下一层一层的计算代价,这样便可节省很多计算量。

2.3 时间复杂度

由于MST的性质,使得原本对全部像素的比较,只需要对父节点,子节点的比较即可,每次计算代价聚合值,从上述公式看来只需要一次加法,一次减法和三次乘法,这样便极大提高了速度,同时又考虑到了全局像素的影响。在middlebury上数据集的平均计算时间仅为90毫秒。

作者提供了文献和源代码的同时,也给出了一个ppt,就在作者的主页上,对其算法原理仍旧迷惑的童鞋可以下载去看看。

3. 实验效果&结论

实验效果就不介绍了,论文上一目了然,这篇文章提供了源码,大家可以跑跑看,我这边针对一般场景进行了测试,效果还是很不错的,经过进一步优化可以进行实际应用。这篇文章比较经典,一些后续的算法就是对其进行了改进,比如说分割树算法《Segment-Tree based Cost Aggregation for Stereo Matching》,将图事先进行区域分割,再在各个区域中计算MST,在生成MST的过程中,考虑到了颜色值与距离作为边缘权值,取得了比NL更好的效果。

时间: 2024-08-01 09:05:05

《A Non-Local Cost Aggregation Method for Stereo Matching》读后感~的相关文章

大道至简第五章读后感

第五章 失败的过程也是过程 今天照样老师带领着我们阅读了大道至简第五章,阅读了<大道至简>的第五章,这章在前面的基础上又进了一步,有了技术和团队,加上有效的沟通,接下来就要接项目做工程. “虚有其表耳”,本章以<明皇实录>中的一句话来告诉我们一个深刻的道理:不要只求外表,只做形象工程,而是要透过表象,力求实质. 失败了不要紧,没有失败也就找不到自己的不足,也就不会发现自己的问题,更不用谈改进了.我们的前辈们就是在不断的失败中才总结出了“瀑布模型”“螺旋模型”等模型,方便了我们.但是

大道至简 第五章读后感

第五章 失败的过程也是过程 以得失而论,在瀑布模型与RUP模型之间,学习前者而不成,可思过程的本质:学习后者而不成,可得文字的架子. 如果懂得了所谓的模型原本都演化自那个简单的瀑布,那么文档是按XP写还是按RUP写,也就可以应时.应需,因地置宜,择善而从了. 越是简单的东西,往往越是接近于本质. 项目经理的工作,就是要去组织这个工程中的各个角色,使得分工明确,步调一致,共同地完成这个项目.四川有句地方话叫“做过场”,也有说成“走过场”的.“过场”是舞台术语,意思是角色从舞台一端出场,再走到另一端

大道至简 第五章 失败的过程也是过程 读后感

今天该写一写大道至简第五章读后感了. 首先是“做过程不是做工程”,过程是为了实现某种目的而经历的一些事情,过程有很多种,虽然经历了某种过程,但不一定能实现某种功能.做完过程的每一个阶段,并不等于做工程.做过程不是做工程的精义,也不是最终目的. 然后是“做过场”,做过场就好像是一种形式一样,做了没必要做的事情,就是浪费时间. 我们为什么做工程,不要忘了最终目的.目的,是实现客户的要求,工程只是一种实现的途径.最初做开发的前辈们,不用什么工程或者过程,也一样编出了程序,也一样解决了问题,也一样实现了

大道至简第七章读后感

大道至简第七章读后感——现实中的软件工程 “王不如远交而近攻,得寸,则王之寸:得尺,亦王之尺也.”——<战国策.秦策> 1:大公司手中的算盘 文中列举了IBM,Borland和Microsoft的一些体系,来说明大公司眼中的世界. 大公司们在标准.理论.语言上的争来夺去,未必全然出于“软件实现”的考虑.对统一理论.统一工具.统一过程的企图,其最终目的是在整个软件工程体系中的全面胜出.算 盘 上 的 绝 大 多 数 人 , 只 是 用 于 计 算 胜 负 的 一 枚 算子.所谓编程语言,只不过是

大道至简第五章阅读感想

第五章失败的过程也是过程 今天王建民老师依旧带领着我们阅读了大道至简第五章,第五章是失败的过程也是过程.通过前面的技术.团队和沟通,这章主要讲了关于做工程的问题. 文章开篇以一句<明皇实录>中的“虚有其表耳”来说明一个很重要的问题就是:不能只求外表,而是要透过表象,力求实质. 第五章的整体思想是让我们注重过程,因为有很多人从来不注重过程,只注重结果.然而过程对于一个编程人员也是非常重要,如果一个好的编程员从来不在乎程序的过程,只是关心最后程序是否能够实现,那么这个编程员一定不是一个好的编程员.

大道至简 第六章 读后感

说点什么呢,今天看了看大道至简第六章<从编程到工程>. 文章以<列子·说符>的“得其精而忘其粗,在其内而忘其外:见其所见,不见其所不见,视其所视,而遗其所不视.”为题记.第一节讲了“语言只是工具”,作者讲述了他曾经对一些编程语言的看法.他曾经也热衷于讨论语言的优劣,但是他现在不这样了,他已经不再专注于语言, 正如他在第一章中写到的一样:成天讨论这门语言好,或者那门语言坏的人,甚至是可悲的.确实,程序的好坏不在于语言,在于算法. 第二节又写了“程序”,程序=算法+结构,编程的精义于此

《大道至简》第一章读后感

经常听见有人抱怨编程太难,说自己不是学软件的料,那么他们真该好好看看<大道至简>这本书,相信他们看完这本书后会有很大收获. <大道至简>第一章引用了一个很简单的故事“愚公移山”,用这个故事很好的概述了我们在完成一个项目时所要进行的步骤.听上去“愚公移山”和编程简直是风马牛不相及,但是看过作者的叙述又有原来如此的感觉.其实编程并没有什么难懂的,就和我们日常生活一样,发现问题,分析问题,提出解决问题的方案,实施,和后续的验收.例如某天我们突然发现家里放不出水了,这就是发现问题,我们会观

大道至简第三章读后感

---恢复内容开始--- 大道至简第三章的是团队的问题.我们知道,随着人们生活水平的不断提高,用户对计算机软件的功能要求也日趋上升.这样一来,计算机软件就变得越来越复杂,规模变得越来越庞大,源代码的量也越来越多.在这种市场需求和自身发展的共同要求之下,一个团结而高效的开发团队的作用就不言而喻了.那么如何打造一支强有力.听指挥.能干活的开发团队呢?这一章作者就这个问题和我们展开了讨论. 作者着重的强调了项目经理在开发团队中的作用.首先声明一点,这并不是说团队的开发人员不重要,作者从始至终都认为编程

一切都是为了实现-大道至简第六章读后感

大道至简第六章的内容比较多,也比较深.或者说这一章作者是从一个更高的层次.更开阔的视野.更独特的角度来解读软件工程这四个字的具体含义的. 作者的这些肺腑之言都是作者在软件行业工作了多年之后总结出来的.开发技术对一个软件产品质量的好坏和最终的成功的影响并虽然不能说是一点也没有,但也不是很大.真正起到决定性因素的不是那些技术细节,而是一个高度过程化.通晓方法论.拥有大量工具的开发团队或者是开发公司.在这个团队里面,无论是对项目经理还是开发经理甚至是一个普通的开发人员的要求都是很高的.团队内的每个人必

《大道至简》第一章读后感和伪代码

阅读了<大道至简>第一章,感到作者对编程的精义分析非常具体形象,引用<愚公移山>的故事,说明了编程的本质.又将他们扮演的管理者,技术人员,程序分析师众多形象展现出来.又在困惑人们的"我能不能学会编程"这一问题做出回答,作者列举生活实例,给出了肯定的答案,将很多抽象的东西,简单化,通过最常见的生活中的实例介绍"大道". import java.大道至简.*; public class.yishan.*; { public static void