分类 观点 下的文章

今年 Black Duck 和 North Bridge 发布了第十届年度开源软件前景调查,来调查开源软件的发展趋势。今年这份调查的亮点在于,当前主流社会对开源软件的接受程度以及过去的十年中人们对开源软件态度的变化。

2016 年的开源软件前景调查,分析了来自约3400位专家的反馈。今年的调查中,开发者发表了他们的看法,大约 70% 的参与者是开发者。数据显示,安全专家的参与人数呈指数级增长,增长超过 450% 。他们的参与表明,开源社区开始逐渐关注开源软件中存在的安全问题,以及当新的技术出现时确保它们的安全性。

Black Duck 的年度开源新秀奖 涉及到一些新出现的技术,如容器方面的 Docker 和 Kontena。容器技术这一年有了巨大的发展 ———— 76% 的受访者表示,他们的企业有一些使用容器技术的规划。而 59% 的受访者正准备使用容器技术完成大量的部署,从开发与测试,到内部与外部的生产环境部署。开发者社区已经把容器技术作为一种简单快速开发的方法。

调查显示,几乎每个组织都有开发者致力于开源软件,这一点毫不惊讶。当像微软和苹果这样的大公司将它们的一些解决方案开源时,开发者就获得了更多的机会来参与开源项目。我非常希望这样的趋势会延续下去,让更多的软件开发者无论在工作中,还是工作之余都可以致力于开源项目。

2016 年调查结果中的一些要点

商业价值

  • 开源软件是发展战略中的一个重要元素,超过 65% 的受访者使用开源软件来加速软件开发的进度。
  • 超过 55% 的受访者在生产环境中使用开源软件。

创新的原动力

  • 受访者表示,开源软件的使用让软件开发更加快速灵活,从而推进了创新;同时加速了软件推向市场的时间,也极大地减少了与上司沟通的时间。
  • 开源软件的优质解决方案,富有竞争力的特性,技术能力,以及可定制化的能力,也促进了更多的创新。

开源商业模式与投资的激增

  • 更多不同商业模式的出现给开源企业带来了前所未有的价值。这些价值并不依赖于云服务和技术支持。
  • 开源的私募融资在过去的五年内,已增长了将近四倍。

安全和管理

一流的开源安全与管理实践的发展,也没有跟上人们使用开源不断增长的步伐。尽管备受关注的开源项目近年来爆炸式地增长,调查结果却指出:

  • 50% 的企业在选择和批准开源代码这方面没有出台正式的政策。
  • 47% 的企业没有正式的流程来跟踪开源代码,这就限制了它们对开源代码的了解,以及控制开源代码的能力。
  • 超过三分之一的企业没有用于识别、跟踪和修复重大开源安全漏洞的流程。

不断增长的开源参与者

调查结果显示,一个活跃的企业开源社区,激励创新,提供价值,共享情谊:

  • 67% 的受访者表示,它们积极鼓励开发者参与开源项目。
  • 65% 的企业正致力于开源项目。
  • 约三分之一的企业有专门为开源项目设置的全职岗位。
  • 59% 的受访者参与开源项目以获得竞争优势。

Black Duck 和 North Bridge 从今年的调查中了解到了很多,如安全,政策,商业模式等。我们很兴奋能够分享这些新发现。感谢我们的合作者,以及所有参与我们调查的受访者。这是一个伟大的十年,我很高兴我们可以肯定地说,开源的未来充满了无限可能。

想要了解更多内容,可以查看完整的调查结果


via: https://opensource.com/business/16/5/2016-future-open-source-survey

作者:Haidee LeClair 译者:Cathon 校对:wxy

最近,著名的测评网站 phoronix.com 进行了三个 Windows 和 Linux 性能方面的测评: Windows vs. Linux AMDGPU-PRO / RadeonSI testingGTX 1080 Windows vs. Linux resultsIntel Windows vs. Linux benchmarks,通过将这三个测评的数据使用 OpenBenchmarking.org 进行合并归一,可以得出一个令人伤心的结论:大部分游戏在 Linux 下的性能不及 Windows 。与原生的 Windows 游戏的性能相比,很多 Linux 移植版游戏的性能简直就是垃圾,或者说,就像垃圾一样。

以下是一些游戏在 Windows 下和 Linux 下的性能比较:

Phoronix 的老读者们都知道,Linux 版本的 虚幻引擎 Unigine 演示的效果与 Windows 相比差距不少,不过过去了这些年,虚幻引擎在 Linux 下的测试性能已经接近了 Windows 版本了,这主要是因为 Linux 下的 GPU 驱动问题越来越少了。这是一个不多的好消息。

《Xonotic》是一个开源的跨平台第一人称视角的射击游戏,在 Linux 下的 Intel 驱动的性能差的令我们吃惊,不过其它的驱动看起来还好。我们考虑这里肯定有一些需要特定优化的地方。

《古墓丽影》在 Linux 下的性能十分之糟,只有 Windows 下的一半左右。

超级房车赛:汽车运动 GRID Autosport 》在 Linux 下的性能只有 Windows 下的 60% 左右。

Valve 的《Dota 2》 / Source 2 引擎的性能不错!这应该是整个测试中唯二让人满意的结果了。

中土世界:暗影魔多 Middle-Earth: Shadow of Mordor 》的 Linux 下的性能要比其它的 Linux 游戏稍好一些,但是仍然不能同 Windows 下的相比。

《F1 2015》的性能也非常糟糕。

这简直太糟糕了,如此多的 Linux 游戏与其对应的 Windows 下的游戏相比性能差的不是一点半点,不管是什么显卡或驱动都是这样。希望过些时间下一代的游戏能够借助 Vulkan 提升其性能表现吧。

当 Canonical 宣布他们的 Snappy 方案已可以用于包括 Debian、Arch Linux、OpenWrt 在内的一些主流 Linux 发行版时,遭遇到了一些来自社区的反驳意见,还有人问 Canonical 是否已经准备好给其它的发行版提供 Snap 软件包。

每个人都会首先问道,“为什么我没有见到 Snappy 服务器的源代码出现?”有些人对 Canonical 在其 Snap 发布公告中的许多内容表示了不满,特别是,Canonical 并没有发布 Snappy 商店的源代码,人们通过 snapcraft.io 网站提交了 Snap 软件包后根本不知道后面都发生了什么。

如果开发者想使用 Snap 软件包跨多个 GNU/Linux 发行版发布软件的话,在 snapcraft.io 上所提供的指导中有一个步骤需要开发者接受在社区争议很大的 Ubuntu CLA( 贡献者许可同意书 Contributor License Agreement )。

Snap 并不依赖商店

前几天,就是 6 月 23 日的时候,Canonical 和 Ubuntu 的创始人 Mark Shuttleworth 在给社区的一封邮件中透露了一些信息:从设计上来说, Snap 事实上并不依赖于某个商店,这意味着应用开发者可以建立他们自己的商店。不过,从另外一个方面来说,说明他也并不指望其它的发行版会从 Ubuntu Snappy 商店中获取 Snap 软件包。

“Snap 软件包格式本质上并不依赖商店,你可以在系统里面采用 Snap ,而不用管它是如何到达系统的。所以,当前的商店解决方案并没有什么关系,”Mark Shuttleworth 说,“我并不指望别的发行版会去从 Ubuntu 获取 Snap 软件,除非这里有他们需要的软件包,Snap 可以很容易的用于 Debian.org 。”

他也回应了那些批评 Canonical 在 Snap 格式上不公平竞争的指责,他说:“从某种意义上说,Snap 是顺应发展而出现的——当然,Ubuntu 有个很庞大的商店,因为我们已经在移动和物联网方面努力了好多年了。但是这并不是非难 Snap 的原因,我觉得恰恰相反。”

据 Mark Shuttleworth 说,应用开发者要从他们自己的商店分发 Snap 的最简单的办法就是通过 HTTPS。他认为,很显然选择了 Snap 格式在多个平台上分发的人可以在他自己的代码里面实现这个。当然,你可以可以采用其他的类似解决方案,包括最新发布的 Flatpak 或 AppImage。

编者按:这个消息是几个月前曝出的,也许我们该对基础软件的安全问题更加重视。

谷歌披露的一个严重漏洞影响到了主流的 Linux 发行版。glibc 的漏洞可能导致远程代码执行。

几个月前,Linux 用户都在竞相给一个可以使系统暴露在远程代码执行风险中的核心 glibc 开放源码库的严重漏洞打补丁。这个 glibc 的漏洞编号被确定为 CVE-2015-7547,题为“getaddrinfo 基于堆栈的缓冲区溢出”。

glibc,或 GNU C 库,是一个开放源码的 C 和 C++ 编程语言库的实现,是每一个主流 Linux 发行版的一部分。谷歌工程师们在他们试图连接到某个主机系统时发生了一个段错误导致连接崩溃,偶然发现了 CVE-2015-7547 问题。进一步的研究表明, glibc 有缺陷而且该崩溃可能实现任意远程代码执行的条件。

谷歌在一篇博客文章中写道, “当 getaddrinfo() 库函数被使用时,glibc 的 DNS 客户端解析器易受基于堆栈缓冲区溢出的攻击,使用该功能的软件可能通过攻击者控制的域名、攻击者控制的 DNS [域名系统] 服务器,或通过中间人攻击方式(MITM)进行破坏。”

其实利用 CVE-2015-7547 问题并不简单,但它是可能的。为了证明这个问题能被利用,谷歌发布了论证一个终端用户或系统是否易受攻击的概念验证(POC)代码到 GitHub 上。

GitHub 上的 POC 网页说“服务器代码会触发漏洞,因此会使客户端代码崩溃”。

Duo Security 公司的高级安全研究员 Mark Loveless 解释说 CVE-2015-7547 的主要风险在于依赖于 DNS 响应的基于 Linux 客户端的应用程序。

Loveless 告诉 eWEEK “需要一些特定的条件,所以不是每个应用程序都会受到影响,但似乎一些命令行工具,包括流行的 SSH[安全 Shell] 客户端都可能触发该漏洞,我们认为这是严重的,主要是因为对 Linux 系统存在的风险,但也因为潜在的其他问题。”

其他问题可能包括一种通过电子邮件触发调用易受攻击的 glibc 库 getaddrinfo() 攻击的风险。另外值得注意的是,该漏洞被发现之前已存在于代码之中多年。

谷歌的工程师不是第一或唯一发现这个 glibc 安全风险的团体。这个问题于 2015 年 7 月 13 日首先被报告给了 glibc 的 bug跟踪系统。该缺陷的根源可以更进一步追溯到在 2008 五月发布的 glibc 2.9 的代码提交时首次引入缺陷。

Linux 厂商红帽也独立找到了 glibc 中的这个 bug,而且是在 2016 年 1 月 6 日,谷歌和红帽开发人员证实,他们作为最初与上游 glibc 的维护者私下讨论的部分人员,已经独立在为同一个漏洞工作。

红帽产品安全首席软件工程师 Florian Weimer 告诉 eWEEK “一旦确认了两个团队都在为同一个漏洞工作,我们会合作进行可能的修复,缓解措施和回归测试,我们还会共同努力,使测试覆盖尽可能广,捕捉代码中的任何相关问题,以帮助避免今后更多问题。”

由于缺陷不明显或不易立即显现,我们花了几年时间才发现 glibc 代码有一个安全问题。

Weimer 说“要诊断一个网络组件的漏洞,如 DNS 解析器,当遇到问题时通常要看抓到的数据包的踪迹,在这种情况下这样的抓包不适用,所以需要一些实验来重现触发这个 bug 的确切场景。”

Weimer 补充说,一旦可以抓取数据包,就会投入大量精力到验证修复程序中,最终完成回归测试套件一系列的改进,有助于上游 glibc 项目。

在许多情况下,安全增强式 Linux (SELinux) 的强制访问安全控制可以减少潜在漏洞风险,但是这个 glibc 的新问题例外。

Weimer 说“由于攻击者提供的任意代码的执行,会对很多重要系统功能带来风险。一个合适的 SELinux 策略可以遏制一些攻击者可能会做的损害,并限制他们访问系统,但是 DNS 被许多应用程序和系统组件使用,所以 SELinux 策略只提供了针对此问题有限的遏制。”

在揭露漏洞的今天,现在有一个可用的补丁来减少 CVE-2015-7547 的潜在风险。


via: http://www.eweek.com/security/linux-systems-patched-for-critical-glibc-flaw.html

作者:Michael Kerner 译者:robot527 校对:wxy

本文由 LCTT 原创翻译,Linux 中国 荣誉推出

阿里云云栖大会6月15号在厦门盛大召开,我们有幸和阿里云资深总监李津面对面进行了交流,就阿里云在云计算方面的一些发展和战略进行了较为深入的讨论。

这次谈话是在李津(以下简称李)、Linux中国的创始人王兴宇(以下简称王)之间展开的。通过这次讨论让我们对阿里云有了更新的认识。

话题是先从 HTTPS 云加速引开的

王:在之前已有消息说阿里云在开发 HTTPS 云加速的服务,而业界,包括国内已经有云加速服务商提供了 HTTPS 云加速服务。不知道阿里云这方面的进展如何?

李:阿里云的 HTTPS 的云加速其实从技术上已经完成了,目前还在调测一些用户体验的部分,技术上并不是障碍,关键是易用性。HTTPS 云加速事实上是基于 CDN 做的,但是这里还有一些需要完善的部分,CDN 本身是一种管道,解决了从 CDN 到用户的加密传输,但是还需要解决从源站到 CDN 节点间的传输。如果用户本身没有支持 HTTPS ,那么还需要考虑从源站到 CDN 节点之间的传输问题,而部署 HTTPS 对于不少客户来说还是比较复杂的,很多用户希望有一键部署的体验。

此外,对于已经部署 HTTPS 的用户,他们还是愿意将其私钥放在自己控制的服务器上,而不是放到阿里云的 CDN 节点上,对于这种情况下,有两种方式:一种是采用伪密钥的方式,即由 CDN 提供证书给客户,另外一种是客户将自己的 SSL 证书上传,这可以是上传到一个信任的第三方的黑盒中。

窦:说到证书服务,阿里是否有计划建立自己的 CA 或者购买一家 CA 服务商?

李:CA 服务商最重要的不是颁发证书,而是要对所颁发证书的可信性进行背书。颁发了证书就要确保该证书所保护的信息具备起码的安全水准,有些 CA 服务商这方面做的还不够。不仅仅是用户购买就颁发证书,而且要对客户进行检查和判断,判断是否达成安全可信标准。CA 服务商不是一个生意,更多的是一种保障的能力。

王:如果阿里云提供 CA 服务,是否会采用类似 Let’s Crypt 这种免费模式?

李:如果不叠加更多安全服务,是可以采用免费摸,但是如果叠加了比如扫描检查等增值服务,就需要商业收费模式。这些年来,对于安全方面的承诺,需要越来越慎重, CA 证书代表的是信任所传递的责任。

云计算的新形势下,基础运维的变化

窦:云计算让运维行业迎来了第二春,对运维人员的界定也在发生变化。那么您认为将来运维行业会发生什么变化?

李:首先,云计算是从运维上发展起来的一个方向,而不是一个自顶向下的变化。其次,随着 DevOps 的流行,开发和运维在某种程度上是融合的,今天的运维人员已经有能力和空间去做一些更应该去做的事情了,而不仅仅是守在机房整理机架。运维是什么?按照 Google SRE 的说法,就是站点的可持续性的保障。

窦:随着云计算的发展,传统的互联网公司的基础运维部分会越来越少,这部分过渡到了云计算平台服务商了。

李:从使用者的角度看,基础运维会越来越少,而业务运维会越来越多。云计算平台不会提供所有服务,但是会尽量提供各种原子性的服务。比如说,在我看来,MySQL、Cache 现在就是一个原子性的服务,而不像过去,是一个解决方案。现在的业务运维就是快速地用原子化的部件搭建自己的业务系统,支撑业务运维,就像乐高积木一样搭建。今天很多云服务商都喜欢用乐高积木来比喻其服务,其实就是指这些服务会形成标准件,用户可以用这些标准件来搭建自己的业务系统。

当然这种标准件会让客户丧失部分的自主权,比如说某种原子化部件不存在怎么办?有两种方式,如果确实是一种原子性的产品,那么云计算服务商一定会提供的;如果是当下急需或个性的需求,那就可以客户自己做。非常有意思的是,每个大的云计算服务商背后都会有一个云市场,你自己做出自己的原子化部件,也可以将它放到云市场上去。

窦:在这个方面我发现一个问题,比如说他们已经做出来了这个原子件,但是有一天云计算厂商发现这个东西不错,我也要做这个,那你怎么平衡这个关系?

李:这个事情从某种程度上讲一定会发生。为什么呢?原子化的就是抽象化的,如果云技术服务商发现它已经成为大多数人所需要的一个东西,就会向下抽象,让它成为服务平台的一部分。那么对于上层厂商来说该如何发展呢?他们应该向上走,将这个东西做的更细分、更好。这就是一种倒逼机制,就像是假如你要做一个杯子,而你的杯子的生产成本已经远远高于通用化制造的杯子,那你肯定会被淘汰。但是如果你把这个杯子变成陶瓷的、变成有收藏价值的,那就可以做了,不会被通用化制造的杯子挤压到没有市场。

举例说, AWS 上有两家存储服务商,DropBox 和 Box,那这两家公司有生存空间么?其实他们都是做数据文件的共享,而文件共享其实是 AWS 的基础服务。这两家做的是数据增值服务,如果这种增值服务对所有人来说都是标准服务需求的时候,它就会被 AWS 所提供,那么这两家厂商就不停的被底层的厂商倒逼着不停地提供更多的增值服务。但是它们越做新的增值服务,就和用户越贴近,挖掘到的需求对用户的帮助就越大。这个时候产业是良性的。但是如果厂商固守在数据存储上,那这个“游戏”就结束了。

我们再换个例子说,比如手机里面,之前任何一个智能手机里面都有一个“日历”应用的厂商,但今天还有日历厂商么?很少了,因为这种需求已经是一个通用的需求了。但是“万年历”还存在,这是因为“万年历”这个数据是独特的,也不是通用的需求。但是普通的日历、农历是通用的需求,所以就被底层厂商“吃”掉了;同样,“手电筒”应用也是,它成为了手机自身的功能。

安全服务的边界

王:刚才我们提到了安全问题,我们知道阿里云给客户提供了很多安全服务。做安全实际上存在一个矛盾,在效率和安全之间是存在一定的抵触的。据我所知,阿里云至少在两个层面上为客户提供了安全服务,一个是在云的层面上提供了云防火墙;另外一个是在主机层面提供主机安全防护。这里我想知道,阿里云在安全方面的策略是如何的?因为如果安全方面厂商做的太多,会影响到客户的使用,但是如果有些服务不做的话,一些安全问题就会导致客户应用的问题,甚至会造成安全事故的蔓延。

李:安全的最大问题是:安全的边界。如果这个边界说不清,就会出现你说的这个问题,多做、少做都不对。第二个问题是,安全边界是个大家认知的问题,道德和法律的差异,法律是本分、道德是情分,这是有差别的。在安全方面,阿里云做了三个层面:业务安全、主机安全和平台安全。业务安全是防止客户被入侵,保障客户应用的安全,是从外向里看;而主机安全是从主机向外看。还有一个层面是平台本身的安全。

安全一定是要划清边界的,因为不可能包揽百分百,这就一定要和用户说清楚那些部分是不能包揽的。安全里面 30% 是技术的问题,70% 是人的问题,但今天有没有什么办法让人的部分降低到那怕是 50%?让使用更便捷一点?但是这里有个问题是,当你管的多了时候,客户怎么确认你管的这么多是合适的?

窦:很多人对安全的保姆模式还处于一个认可的过程,对保姆模式的信任也没有建立起来。

李:首先是你说的客户不一定相信,不是你说了客户就会相信,这是一个很正常的事情。那只能是在一开始的时候就尽量将事情说清楚。其次是,能以授权的方式存在的就一定要以授权的模式做,让客户随时可控。

当时“安骑士”这个事件之后,在我们内部反思过这个问题。在我看来,第一个,授权做的不清晰;第二个,给用户做的可上可下的提示不明确。如果它是可上可下的、授权清晰的,那就是个用户自我选择的问题。然后是,“安骑士”你到底都做了什么?这个你得给客户提供审计报告出来。

不只是“安骑士”,包括阿里云做的所有东西,都应该提供专业的审计报告。比如说一台主机,服务商进行了维护调整,环境上有了变化,它可能都会对用户发生影响。这个时候,作为用户,我都看不到就没有安全感。那么这个时候应该以一种什么样的方式将这个报告提供出来?所以,我们今天就将各种服务,比如 RDS 的维护日志、用户自己的操作日志都让用户能看到。而且如果用户使用了多种服务,如何将多个报告融合在一起,这也需要我们大量的工作。

企业的开源发展的四个阶段

王:阿里云做了许多产品,也开源了许多产品,阿里云在开源方面的战略是如何的?

李:阿里云做了很多中间件,最流行的是 dubbo。为什么它会很快的流行呢?首先它是一个简单的应用,其次是它被阿里淬炼过,保证了其稳定性。我最近在管理开源社区方面的事务,发现它的社区非常大,使用文档、案例、手册等庞大无比,我非常惊讶,远远超过我的预期!社区对它的贡献非常大。我想说的是,在它刚刚推出的那一刻,它是不成功的,但是随着社区对它的完善,包括我们自己还不断的对它做升级。它变了,它变成了一个很庞大的东西。在它刚刚推出的那个时候,它是不够简单易用的,但是随着社区对它的贡献参与,它就变得简单易用了。之所以这样,是因为它有了更多的使用案例。

我认为开源有四个阶段:

第一个阶段是拥抱开源,就是你去用开源软件,这样让你可以最快地有能力达到一个基本的技术水准上。

第二个阶段是回馈开源,比如你可以将你的一些补丁反馈给社区。比如阿里就对 mysql、hadoop 等做了很多贡献。

第三个阶段是融合开源,你的产品别人是否支持?之前是我反馈给社区,而现在别人是否在开源产品中支持你,比如在 Hadoop 源码中支持你,在 Docker 源码中支持你。我拥抱你,你拥抱我,互相接纳。

第四个阶段是回报开源,当你已经被开源社区接受的时候,那这个时候你要有选择性的回报,将一些产品开源出去。这里是有你自己的商业诉求在里面,比如说你有一个方向性的东西你看不清,那么开源出来,大家一起来做,这种情况就比如说 Google 开源它的深度学习。另外一个做法是是将之前换代的产品开源出去。

阿里集团有一个开源委员会,旗下的各个商业部门都有参与,用来决策如何开源,以什么原则,什么节奏去开源。

结语

经过长达一个小时的深入沟通,我们对许多问题进行了探讨和了解,从阿里云这里能够看到,国内的顶级互联网企业,已经跳出了巢臼,能够更大的从产业、文化、趋势方面对运维行业、云计算领域乃至于互联网行业进行深远的布局。

以上,由 Linux 中国的老王为您独家披露。

在刚结束的这个夏天里,我是 NASA 格伦中心 GVIS 实验室的实习生,我将我对开源的热情带到了那里。我的任务是改进我们实验室对 Dan Schroeder 开发的一个开源流体动力学模拟器的贡献。原本的模拟器可以显示用户用鼠标绘制的障碍物,并建立计算流体动力学模型。我们团队的贡献是加入图像处理的代码,分析实况视频的每一帧以显示特定的物体如何与液体相互作用。而且,我们还要做更多事情。

我们想要让图像处理部分更加健壮,所以我致力于改善图像处理库。

得益于新的库,模拟器可以检测轮廓、进行空间坐标变换以及找到物体的质心。图像处理并不直接与流体动力学模拟器物理相关。它用摄像头检测物体,并且获取物体轮廓,为流体模拟器创建一个障碍物。随后,流体模拟器开始运行,而输出结果会被投射到真实物体上。

我的目标是通过以下三个方面改进模拟器:

  1. 找寻物体的轮廓
  2. 找寻物体的质心
  3. 能对物体中心进行相关的精确转换

我的导师建议我安装 Node.jsOpenCVNode.js bindings for OpenCV。在等待软件安装的过程中,我查看了 OpenCV 的 GitHub 主页上的示例源码。我发现示例源码使用 JavaScript 写的,而我还不懂 JavaScript ,所以我在 Codecademy 上学了一些课程。两天后,我对 JavaScript 依旧生疏,不过我还是开始了我的项目……它包含了更多的 JavaScript 。

检测轮廓的示例代码工作得很好。事实上,它使得我用几个小时就完成了第一个目标!获取一幅图片的轮廓,它看起来像这样:

包括所有轮廓的原始图

检测轮廓的示例代码工作得有点好过头了。不仅物体的轮廓被检测到了,整个图片中的轮廓都检测到了。这会导致模拟器要与那些没用的轮廓打交道。这是一个严重的问题,因为它会返回错误的数据。为了避免模拟器接触到不想要的轮廓,我加了一个区域约束。轮廓要位于一定的区域范围内才会被画出来。区域约束使得轮廓变干净了。

过滤后的轮廓,包含了阴影轮廓

虽然无关的轮廓没有了,但是图像还有个问题。图像本该只有一个轮廓,但是它来回绕了自己两次,没有完整地圈起来。区域在这里不能作为决定因素,所以必须试试其他方式。

这一次,我不是直接去找寻轮廓,而是先将图片转换成二值图。二值图是转换之后只有黑白像素的图片。为了获取到二值图我先把彩色图转成灰度图。转换之后我再用阈值函数对图片进行处理。阈值函数遍历图片每个像素点的值,如果值小于 30 ,像素的颜色就会改成黑色。否则取反。在原始图片转换成二值图之后,结果变成这样:

二值图

然后我获取了二值图的轮廓,结果是一个更干净的轮廓,没有了阴影轮廓。

最后的干净轮廓

这个时候,我可以获取干净的轮廓、计算质心了。可惜的是,我没有足够的时间去完成质心的相关变换。由于我的实习时间只剩下几天了,我开始考虑我在这段有限时间内能做的其它事情。其中一个就是边界矩形。边界矩形是包含了图片轮廓的最小四边形。边界矩形很重要,因为它是在页面上缩放轮廓的关键。虽然很遗憾我没时间利用边界矩形做更多事情,但是我仍然想学习它,因为它是个很有用的工具。

最后,经过以上的努力,我完成了对图像的处理!

最终图像,红色的边界矩形和质心

当这些图像处理代码写完之后,我用我的代码替代了模拟器中的老代码。令我意外的是,它可以工作。

嗯,基本可以。

程序有内存泄露,每 1/10 秒泄露 100MB 。我很高兴不是因为我的代码。坏消息是我并不能修复它。另一个好消息是仍然有解决方法,虽然并非最理想的,但我可以使用。这个方法是不断检查模拟器使用的内存,当使用内存超过 1GB 时,重新启动模拟器。

在 NASA 实验室,我们会使用很多的开源软件,没有这些开源软件的帮助,我不可能完成这些工作。


via: https://opensource.com/life/16/3/image-processing-nasa

作者:Lauren Egts 译者:willowyoung 校对:PurlingNayuki

本文由 LCTT 原创编译,Linux中国 荣誉推出