梳理一下关于增强摄影器材的问题

这次CD23的团队摄影行动,基本上能保证出片的成功率了。在此基础上,要考虑增强摄影器材的问题。

一、当前装备的情况

(一)相机
Canon 5D2,曾经的旗舰全画幅,各方面表现都足够让人满意,唯一的问题是对焦点的覆盖率太低。

(二)镜头
24mm-70mm F2.8,灵活性高的变焦牛头,主要问题是广角端还不够广,无法容纳重装备流c的全身。

(三)板系统
110cm柔光板和90cmx120cm银白反光板,其中柔光板的实用性很强,反光板初步估计是很有用的,但用不好。总体来说问题较多:
1.缺少挡光板(被弃置了),烈日下让c正光拍摄有难度
2.柔光板范围不足,无法覆盖全身(实际使用过程中可以靠柔光伞补充一下,但十分麻烦)
3.阳光下,柔光板产生突兀的影子,入镜后太诡异
4.反光板的使用存在严重问题,不打底光(鬼光)情况下,阴天基本上打不准,阳光下不敢使用银板而使用白板,光量不足以照亮c,无法判断是否打准(换言之还是打不准)

(四)灯系统
430Ex,八角罩,柔光伞。主要问题是出力不足,具体:
1.阳光下聊胜于无
2.在无法离c太近的情况下,柔光不存在的,可能还不如关掉伞直打
3.户外大光圈情况下,基本上要上高速同步,理论上应该在镜头上灰度镜,从而在造成c眼睛伤害不变的情况下提高灯的闪光效率

二、综合分析

鼎盛时期,CD两天的快门数达到1400。这次CD快门数在1200左右,但成片率大大提高到九成,按照队长同一场景基本上拍3张以上的习惯,有效的场景应该在300左右。存在以下问题:

1.队长在选择拍摄时机的问题上浪费现场时间。具体来说,因为目前还不能很好处理逆光拍摄的场景,因此对于已经存在的战场,如果c处于逆光位(这也是在午后阳光猛烈时的主流情况),队长基本上选择等待竞争对手散去大半再邀请c切换正光位,有时候需要等很久,暂时退却又有很大几率留下遗憾,为此造成的时间浪费十分严重。
2.大片率低。队长在拍摄中基本上使用如下流程:勾搭(或强行扭转/重置c位置)——在尽可能远的距离拍摄——逐步走近c拍摄。过程中对c动作的考虑十分欠缺,也没有归纳出若干大片的套路,导致大部分照片的拍摄角度不如人意,而且对全身照覆盖能力的缺陷导致几乎无法做到对c服饰的有效记录,拍出来的照片显得较为业余,没有体现出顶级器材应有的水平。
3.照片记录的全面性低。受到镜头焦段、现场条件和队长习惯的限制, 最后的照片形式基本上是极少量的全身、少量大半身、大量的半身和特写。对于主要欣赏c美貌的队长来说可能问题不大,但对于照片的意义感(对c本身的记录程度,以及通过返图回报c两方面)来说则有严重的问题。一个良好的记录应当包含各种不同角度的记录,更不用说需要根据对c角色的理解进行动作指导。只能记录特写或半身的形式,导致回看照片时充满遗憾,返图时也无法得到c太多的肯定或赞赏。

三、下一阶段改进计划

(一)用光的改进
1.一块更大的柔光板也许有助于覆盖全身,但在拍摄全身照的场合,从追求完美的角度来说,不应留下柔光板的影子,因此考虑不升级柔光板。与此同时,为了应付烈日,应当准备一块挡光板(黑板)备用。
2.反光板应有妙用,平常可以创造条件进行测试,目标是实现补光,也可用于创造眼神光。
3.设法增大灯的出力。灯是对应用场景宽容度较高的存在,灯出力增强可以保证任何情况下都能出片,减少队长浪费时间选择拍摄时机。考虑到人手问题,目前还是以单 (伞) 灯方案为主,通过入手一到两盏X900C闪光灯,增大GN值。为了有效利用闪光灯,还应该考虑使用灰度镜。条件成熟的话,出力相对较小的430EX可以挂机顶,装上合适的灯罩创造眼神光。

(二)器材改进
1.队长说要换1DX,有钱任性没什么好说的,主要就是为了更多对焦点,此外如果能实时将照片传输到手机上回看检讨也是好的。
2.有可能需要更广的工作焦段以记录全身照。方案1是我自行入手SEL1635GM挂在α7上,作为副机补充,但鉴于我的杯具勾搭能力以及我可能还需要集中精力思考用灯用光问题,这个方案既费钱又不讨好;方案2是怂恿队长换用1635焦段,但这样就和糖片说再见了…还得再想想。

(三)摄影方式改进
1.绝对不要再浪费时间等待摄影时机,逆光情况下强行跳入战场开灯战斗。
2.考虑到实际情况,现有的拉仇恨——逐步逼近——等换动作的流程可能无法改变很多。计划通过对大片的学习,熟练掌握若干大片套路,在流程中贯彻执行。
3.考虑用更好的方式记录返图联系方式,减少后期的工作量。

坑爹的Hyper-V

电脑上长期装着一个vmware来跑虚拟机,用来放毒瘤应用。

前几天突然脑抽忘了自己为什么不用win自带的虚拟机hyper-v,把vmware卸掉了又装了起来。

结果才想起来hyper-v装win7是没有增会话模式的啊!

还有就是hyper-v是没有音频硬件的啊!有些游戏玩不了!!

搞了半天又要装回vmware…以此为记。

一加3T刷什么系统好呢

最近入手了一加3T。

因为是刚出没多久的新机,现在可用的第三方rom还不多,比较喜欢的魔趣还没有大大适配,cm也只有一个非官方不带root的版本。

前年入手的三星s5还能用,所以就没有急着换用新机。

众所周知,一加对刷入第三方rom的支持是比较友好的,而官方系统再好,也会有后台应用不好管理、流量偷跑、耗电、root后无法ota等问题。

第三方rom能够解决官方系统的很多问题,但又会产生相机未经优化、无法使用指纹支付等新的问题。

更何况现在还没有合适的第三方rom…

在这个当口,我开始纠结要不要用改造的官方系统。

改造的考虑是root,刷入open gapps,也许再加上xposed来上类似于抢红包插件的东东。

如果改造的话,也有基于氢os或氧os的选择。(氧os自带google全家桶所以不用刷入gapps)

官方魔改的主要劣势在于失去ota,对于新版不升级不舒服症患者的我来说,现在还无法评估能否承受。

此外就是无论再怎么优化都不能保证系统的「清爽」,这也是我曾经在s5上换回官方系统但最后又放弃的原因。

到底要不要上呢…

真纠结。快来个大大适配魔趣吧。

两个自己用的效率向userscript

这两个userscript的特点都是在网页载入前用window.stop停止了目标网页的访问,然后建xmlhttprequest取得网页源代码,处理后再呈现出来。这样做是为了减少读取不必要的图像和js代码的时间和资源消耗…我也不知道有没有更好的办法(此前用的是修改css的方法,但发现即使把不必要的元素设置成display:none后,元素仍然会在后台载入,就是说,虽然最终效果是效率提高了,但cpu和内存资源消耗和原来一样…)

1、二次萌エロ画像ブログ页面简化器

这个博客每天都会更新很多「哔——」图,但页面上有大量的广告和js代码,再加上需要爬墙才能上去,于是更慢了…为了解决这个问题就写了这个脚本。简单来说就是把博客文章的核心内容(图片)提取出来,再用瀑布流布局呈现。

2、booru redirection

我通过GR订阅了danbooru和萌妹的感兴趣的tag的rss来收图,这些图片很多都提供了出处(来自p站和nico静画),通常我都要点到出处站点打个分支持下作者。考虑到booru类网站只是我访问的中间环节,我就写了这个自动找到出处链接并且重定向的脚本。

因为功能都太奇葩了,大概不会有别人用吧,倒是希望我的脚本思路能够启发大家改进自己的效率('·ω·`)

关于pubsubhubbub和Google Reader

上一篇文章中,我描述了自己如何重制了一个Danbooru的feed。然而,经过一夜的睡眠,我「惊喜」地发现Google Reader在睡前到醒后的7个多小时里面都没有抓取过我订阅了的这个feed——也就是说,就算重制的feed包含10000条最近更新,只要GR不主动抓取,那这些更新也还是没有意义。

绝望之下,觉得归根到底还是弄清楚pubsubhubbub(以下简称PuSH)协议的原理。试着搜索有关GR和PuSH的文章,发现@keakon曾经发表过『PubSubHubbub不通知Google Reader的原因』『实现PubSubHubbub订阅』和『使用PubSubHubbub』三篇文章。拜读之后,明白了什么叫publisher和subscriber,也得知GR可能会自动忽略订阅数少的feed的PuSH,于是先写了一个sub,然后拿菜包工作室来当小白鼠(不好意思啦@tc201158),由于这个博客刚开张,只有我一个人在GR订阅了(订阅数为1),在装了PuSH插件并在hub上进行subscribe之后果然还是无法实现PuSH,可是我用另外一个GR帐号订阅其feed(订阅数为2)之后,PuSH就能正常工作了。

大喜,以为终于找到了原因,于是对重制的feed也如此这般地弄,结果却失败了…无奈之下,我又试着对danbooru的原feed重新在hub上subscribe,发现原feed实现了PuSH的同时,重制的feed也实现了PuSH!难道因为重制的feed中提供的id、url等信息仍然是原feed的信息,所以只有在收到原feed更新的ping请求后,hub才会通知GR抓取重制的feed?

不过既然原feed能够实现PuSH,那重制的feed就没什么意义了;只需要实现在GAE上利用cron定期检查原feed是否有更新,有的话就ping一下hub就可以了。于是又浪费了一整天的人参来实现了这个功能…

至此,对Danbooru feed的PuSH改造完满完成。经验教训:

  1. 尽管有约定,但在feed中添加hub link并不是必须的,至少对于Google的hub(http://pubsubhubbub.appspot.com)是如此;
  2. 利用第一点,可以对任何一个feed实现PuSH改造。先写一个sub以便在Google的hub上对feed进行订阅(必须有订阅才能实现PuSH),然后写一个cron定期检查feed的更新并且ping hub即可;
  3. 开发GAE应用时,利用handlers和wsgi来架构整个应用,无论是应用结构还是debug都方便太多了,决定从此放弃像twitter2weiboviagtalk那样面向过程开发的方法…

题外话。今天是⑨月⑨日的⑨节,可是⑨的同人图一点都不给力啊…

重制danbooru的feed

作为一只东方众,我每天都会通过Danbooru来收一堆东方同人图——Danbooru类型的图站有一个很出色的地方,就是搜索结果可以输出rss feed,直接在GR中添加feed「http://danbooru.donmai.us/post/atom?tags=touhou」,就可以在GR中订阅D站的带有touhou标签的新投稿,十分方便。

前两天开始,我发现这个feed的更新数变少了——通常一天下来会有超过100的更新,但当天只有六十多,而且某次我在扫feed时,发现feed的上一次抓取时间是2个小时以前;而另外一次扫feed时,发现feed一下子实时更新了20篇——通常一个rss feed只会包含最近20篇投稿,这意味着由于GR的抓取频率比较慢,很可能没有办法将所有的近期更新抓全。

为了解决这个问题,我首先想到的是PubHubSubBub——一个能够在feed有更新时主动通知Hub(如GR),使其主动过来抓取更新的协议。我当然不可能直接让D站方面实现这个协议,但搜索了一下相关资料,似乎并没有要求通知者和feed一定要同一服务器,所以利用PubHubSubBub的代码在本机上测试了一下,发现即使通知了http://pubhubsubbub.appspot.com/,GR也不会主动抓取对应地址的更新…几番测试下依然无解,只能放弃了这个想法,转而考虑为D站的feed制作一个包含足够多篇数的近期更新的feed。

重制feed的应用仍然放在GAE上。初步构想了一下,应用要实现2个功能:

  1. 以比GR高得多的抓取频率(如1分钟1次)抓取D站的对应feed,并且将新投稿保存在数据库中;
  2. 输出rss feed,其中包含足够覆盖GR抓取频率的数量的新投稿数,甚至可以根据GR抓取的User-Agent智能判断那些投稿已经被GR抓取。

然后开始忙活…为了解析D站的feed,先是打算用minidom,后来发现Google Data APIs中提供了atom的解析器,于是将代码下载下来,稍微看了下doc就知道怎样用了;输出rss时则参考了PubHubSubBub代码中的Atom模板。

由于不懂如何在本地环境调试GAE应用,所以每次都要先上传到远程再调试;由于GAE的log有延迟,所以程序出错后要等几分钟才能在后台看到trackback,后来干脆直接把整个程序代码放到一个try-except块中,再用print命令把异常打印到网页上。

就这么个小东西弄了一天,半吊子的悲剧啊…

架设个人DNS服务器来解决一些「国情」问题@

 

具体请移步这里:http://www.blogjava.net/stone2083/archive/2011/07/09/353664.html

这个小程序的本意是在局域网中建立一个简单的DNS服务器,不过由于其支持通配符hosts,所以可以用于干坏事:之前的hosts经常要这样改:

203.208.46.133 www.google.com
203.208.46.133 mail.google.com

有了这个应用,就可以实现这样的hosts:

203.208.46.133 *.google.com
203.208.46.133 *.youtube.com

该作者刚更新了一个standalone版本序,配置十分方便,推荐有大规模hosts需要的童鞋去试试看。

twitter2weiboviagtalk发布,欢迎试用

https://code.google.com/p/twitter2weiboviagtalk/

能将twitter帐号的消息同步到围脖中,利用了围脖的gtalk机器人功能发布消息功能和GAE的xmpp功能,借鉴了月光博客的twitter-feed项目写出来的程序。

自己之前一直在用,后来在推上看到有一些人也有这个需求,就把程序改了下放出来了。没什么代码规范可言,只是做到“能用”的程度…

不知道会不会被广泛使用,也不知道渣浪到时会不会把这个东西封掉…

欢迎大家拖走测试。