抗不住了

 如果脚没废自认为还真能继续坚持一两个月。这下真挂了,上下楼可以靠电梯,总不能平时不走路吧,只好回家看书去了。

 假期到目前为止最大的收获在于HKUST的大牛来实验室做讲座,虽然不及人家在BNU、ZJU的系列课程,但一些关于前沿技术的全貌还是了解到了。感触最深的是教授不经意间流露出对众师兄师姐们的“同情”之心了。

Comments

掩帘向学II

 既来之,则安之。

 看来我的假期在两年前已经结束了。

Comments

外显金玉的《新红楼梦》

 抽空回了趟家,原是想做《古剑奇谭》首发体验评测的,但由于时间仓促,无法赶到本来就落地极少的本地店铺,另一方面又听说官方18号在图书大厦搞签售,就决定等看过首周的玩家评论再说。

 恰好7月的p到了,主题是web设计十周年,想到曾经自己也觉得Designer有趣,毕竟精力有限,后来就不能深究了。此外,一连看了十五集的《新红楼梦》。

 我读《红楼梦》也有一段时间了。最早是92湖南少年儿童版的《红楼梦》连环画,然后是96人民文学版,以及一些其它出版社的四大名著合集(可以说是我最喜欢读的四大名著之一了)。后来,看过周汝昌先生的红学随笔,才发现自己离“看懂”红楼梦还差很远,又从网上找来脂批读,每次都有不少的新鲜发现。

 至于电视剧版,87版也看了好几遍,就如同前一段时间令人耳目一新的《新三国》一样,《新红楼梦》自然提起了我的兴趣。

 从前面这十多集来看,《新红楼梦》在服装道具等硬件设施上确实投入不小,但想想前期炒作了好几年时间,又不太令人觉得浪费了。一方面,电视剧版必须在演员年龄上有一定限制,以前看过央视的红楼重聚首,知道演员们其实严格培训了很长时间才正式开拍。据说这次也对演员们进行了一定的培训,撇开外形不谈,现在看来似乎也没什么成效。另从配音来看,几乎没听出一个符合角色性格的来。配乐方面尤甚,毕竟是传统文化剧,剧中到处是无谓的呻吟鬼嚎,有些甚至像是《西游记》的妖魔登场(有人说像聊斋,我看聊斋不多,就不好附和了)。

 感触较深的还是演员的台词部分,忠于原著的演绎也可,演员缺乏功底效果就极差,《新三国》大谈白话最终却受到好评,可见《新红楼梦》的编剧和导演充其量只是擅长推销某种非主流的审美观罢了。

Comments

要返校了

 刚到家的第一天,因为帮同学代办毕业手续的原因就不得不赶回学校,回来后正想着休息几天,次日又被叫回实验室干活…第三天(也就是明天),干脆搬回学校住了。

Comments

四年了

 最近两天终于要发双证回家了,整月都在忙毕业的事情,学习上也没什么收获,下两个月倒是巩固基础的绝佳时机。

 网站上的消息是,wp3.0正式版已于2周前发布,我们将择日更新,同时按既定目标继续扩展功能。

 另一方面,《古剑奇谭》这部打着仙3制作人旗号的rpg将于10日首发,从预售来看势头甚至有些超过了定于年底出炉的仙5。目前来看《古》系列(官方的“系列”说法)的前景还是有些令人担忧的,首先在于自有世界观和主题与《仙》、《轩》系列的关系应如何把握,如果仅仅是模仿前两者,无疑将成为阉割之作。其次,仍然是还未上市就炒作dlc的概念,我们之前已经提到(见云之遥相关),国产游戏的游戏性如关卡、交互设计太弱,不适合像日本经典游戏那样出dlc延伸作品,除非就是将完整的主线剧情编成连续剧,每半个月出1个小时的剧情补丁,那还不如去看日间肥皂剧。总之无论如何,一切等游戏上市以后即见分晓。

答辩结束

 毕业设计/论文工作终于“完成”了,不过接下来反倒比以前要忙许多。

 都说做科研要集团作战才有搞头,无奈现在这样单纯的人太少…奇怪的是目前各大公司都宣扬“牛人狩猎计划”,馋得大家围着一两个方向上演“百万大军过独桥”的好戏,力争自己能贴上牛屁股,结果到最后对自己的老本行一窍不通,连“牛”的任何部位都没能贴上。

 到处传言找工作不容易,却发现好马们一个比一个跳的勤。

Comments

DLC付费也疯狂

 从没想过《轩辕剑》系列会出付费DLC,轩迷们不免又要被痛宰一把了。作为投资方——大宇心中的小算盘昭然若揭:把一部游戏拆成两部分卖,更重要的是后者实际上起到剧情补完的作用:没玩过付费DLC也敢说自己玩过《云之遥》?

 当然从质量上看《兰茵篇》对于区区200多新台币来说可称得上是物有所值,但制作方给人感觉实在是太为了DLC而DLC,这次发售更是主打一些新增的周边产品。其次,类似于剧情补漏DLC这种模式国产rpg以后最好戒了算了,否则实在让人怀疑研发团队的诚意。

 联想到前段时间另外一部喜欢的作品《ZWEI ii plus》发售,很多人说国人缺乏创造力,模仿就成了混饭吃的唯一出路。但为了长远考虑,还请财主们允许team member尽量模仿到骨髓吧!

 总之,11小时的《兰茵篇》初体验给人感觉是欣慰的,但像本传那样目标全任务全装备的二周目只好等以后有空再说了。

Comments

更多关于flash的一些思考

 我对flash可以说是情有独钟的。

 记得在2001年,请同学在劳动南路代购了flash5英文版,在语言完全不通的情况下,逐渐摸清了时间轴和一些基本动画制作。但如果说首次了解flash这一名词,还得追溯到2000年《网友世界》(当时还是《网友》)创刊了。后来因为某期杂志上对美女闪客“哎呀呀”的专访,使得我从此踏上了拜师学艺之路。

 现在看来,我的flash学习之路并非一帆风顺,原因如下:

 首先,当时我并未意识到flash作为web媒体的作用,平时接触到的仅仅是一些大师们令人拍案叫绝的动画作品。直到2003年加入网民的行列之后才对此有所了解。

 其次,开始很长一段时间里,我仅能通过月刊或后来的半月刊来自学。由于学业的原因,根本无法借助书籍来海量学习,更别说求助“前辈”了。

 再次,我很快发现,纯粹的flash动画制作实际上需要很深厚的计算机美术功底,我在“专业不对口”的情况下硬坚持了几年。记得在2005年,还有幸帮助表哥的大学同学完成了课题设计(尽管现在看来那玩意似乎只是最终敷衍一下通识课老师而已)。

 2006年起,flash对我来说有了新的意义,即web媒体。起初热衷于flash整站建设,后来发现知识储备不足,又去学习php和js,可以说flash伴随着我遨游互联网长达7、8年之久。

 2008年,我开始着手重建hanyi.name,从此对flash也有了新的看法。

 近日,jobs在apple网站上发布了一篇《Thoughts on Flash》(原文链接:http://www.apple.com/hotnews/thoughts-on-flash/),更加加深了我对flash的某些担忧,这也是写作本文的初衷。

 我认为flash对用户最大的困扰在于其安全性和稳定性。我从去年开始尝试一些非IE引擎的浏览器,原因即在于网页中嵌入flash player时可能会发生负载过高的情况,最终发现问题还是出在flash player自身,后来索性在chrome上屏蔽了flash。

 同时对开发者而言,如果某个平台会对用户造成很多困扰,那么抛弃它也就在所难免了。这也是我最终不得不去深入学习js、jquery的原因。

 事实上,jobs提到flash只适用于pc。但我认为在未来移动计算和pc业务将重新融合(合久必分,分久必合?),留给flash的空间到底有多少就很难说了。

 Adobe是我非常尊敬的一家公司,但它也是一家非常热衷于发布新标准的公司(因为它有足够的话语权)。令人遗憾的是,Macromedia的出售或许只是为了创造“大奥多比时代”,在互联网开放平台风气日益浓厚的今天,商业巨舰缺少太多的灵活性,掌舵人的开明程度就将决定产品未来的生死。

 由此联想到近期热议的“云端之争”,rich client的未来依旧未卜。flash作为ms鄙视、google忽视、apple歧视的“悲剧儿”,到底是一条道走到黑,还是另辟蹊径,恐怕都将成为互联网时代的经典案例。

Comments

关于GrassrootDCM补完

 之前提到GDCM基层DCM类库是一个颇为强大的开源dicom文件基础类库。目前,GDCM已经专门针对vtk提供了应用程序接口,我们可以利用vtkGDCMImageReader和vtkGDCMImageWriter两个类完整支持DICOM标准V3的IO操作。

 但是获得GDCM后,遇到一些颇为棘手的问题。

 首先,GDCM对Win32平台只支持vc7.1以后的编译器,而现有的vtk则是采用vc6.0编译。即是说,如果编译GDCM时要cmake选择vtk的扩展项,就必须采用vc7.1以后的编译器重新编译vtk。

 其次,现有的工程均是采用vc6.0创建,如果将平台完全迁移至后续vc版本,就可能会影响目前的工程进度。

 另外,从vc6.0迁移至新版本中所带来的编码问题可能会影响到应用程序的稳定性。

 出于以上考虑,先尝试重新编译vtk,这里我们预设的编译平台为vs2005,即vc8.0。但注意不应覆盖原有vc6.0编译的vtk文件,即在cmake阶段改一下prefix属性值就可以了,其余操作不变。对于新install的vtk文件,我们将环境变量path中bin的原有vtkbin的设置改为新版本值(有些读者之前可能会选择将所有bin文件放入system32中,但是按修改path的方法较好,当然后者的修改方法是相对应的)。

 现在cmake从sourceforge上找来的GDCM2.0.x,仔细检查一些配置项,尤其是扩展vtk项一定要选,g后用vc8.0编译。这里不应出现任何error。现在看来,GDCM的安装步骤其实和vtk没有什么区别,但是对vtk和编译器的要求较严格。

 这里再总结一下我们针对vc6.0使用GDCM+VTK编程的基本思路:

 1、vc6.0引用库采用原有vc6.0编译生成的vtk文件。

 2、运行库采用vc8.0编译生成的vtk文件(即DLL文件)。

 3、在vc6.0中再引用vc8.0编译生成的GDCM文件。

 完成上述步骤,就可以使用vc6.0进行下一步工作了。要注意的是,vtk的运行库一定要更新为vc8.0新编译版本,否则我们一调用GDCM就会因为DLL版本不足而出错。

 关于gdcm的全套文档可以参考:

 http://gdcm.sourceforge.net

 这里要再次说明一下,gdcm完整支持dicomV3,这是vtkDICOMImageReader乃至ITK都无法与之相提并论的。在实际应用开发中,还要注意程序基础构架对选择开发平台的影响。

Comments

医学影像的基本文件存储格式与vtk集成方法

 毫无疑问,PACS已经是现代乃至未来医疗机构里不可或缺的基础设施之一,医学影像的基本存储格式就成为了标准化过程中的关键环节。

 ACR/NEMA联合发布了数字医学影像和通信标准,即DICOM。DICOM涉及的领域非常之多,NEMA上公布了DICOM的全部文档信息:

 http://medical.nema.org/

 此外,通常我们研究DICOM存储格式主要是为了实现文件压缩格式的转换,这里建议参考一些额外信息,以避免受到DICOM海量文档的困扰:

 http://www.dclunie.com/medical-image-faq/html/part8.html 

 这里我们主要讨论vtk对DICOM标准的支持情况。在早期vtk版本中并未直接提供对DICOM的IO支持,读取DICOM文件通常要借助vtkVolume16Reader来完成,但要涉及一系列复杂问题,我们使用如下示例说明:

[c] vtkVolume16Reader *Reader = vtkVolume16Reader::New(); Reader->SetDataDimensions(256,256); //图像尺寸 Reader->SetDataByteOrderToLittleEndian (); Reader->SetFilePrefix ("E:\ct"); //路径 Reader->SetImageRange(1, 93); //切片起始段 Reader->SetDataSpacing (0.8, 0.8, 1.5); //切片间距 [/c]

 另外,该方法也不支持对压缩数据或多帧影像进行IO操作。

 从vtk4.4起,一个直接针对DICOM文件读取的类被引入vtkDICOMImageReader,从而完全替代了vtkVolume16Reader的历史地位。vtkDICOMImageReader的重要改进在于,其直接支持DICOM,避免了许多没有必要的前置操作。

 http://www.vtk.org/doc/nightly/html/classvtkDICOMImageReader.html

 但在实际应用中vtkDICOMImageReader仍然无法满足需求,如不支持查看完整的meta file,也不支持压缩数据和多帧影像。

 为了全面支持DICOM 3.0标准,开发者必须借助外部组件辅助IO。我们在起初提出引入ITK是一种有效的改进方法,这里推荐另外一个重要的开源项目GrassrootDCM基层dicom库,简称GDCM。

 GDCM旨在对DICOM文件编码进行处理,提供DICOM标准中各类编码格式的相互转换操作,包括将各种文件编码转换为RAW原始数据文件。目前GDCM已经提供了针对vtk的DICOM文件IO接口,结合vtk和gdcm,我们就可以完全实现稳定的dicom文件IO操作了。

 但是将GDCM纳入现有工程项目中并非易事,我们将在后续文章中就gdcm做一些说明。

Comments