WordPress 使用 SQLite 数据库

之前写了一半的,如何在轻量级个人 VPS 上搭建各种服务的帖子。一时懒得去把坑填完了。但前几天突然发现自己落入了思维误区:为了配合 Mastodon 或 Pleroma,总想着如何把 WordPress 从 MySQL 迁移到 PostgreSQL。——但是,其实完全可以用 SQLite 啊!对于偶尔才更新一篇的个人 blog 用户,把数据库放在一个 SQLite 文件里,不需要另外安装数据库服务,完全是可行的。

用 Docker 观察内存开销。对于新建的 wordpress 站点,wordpress 本身(包括 php-fpm、nginx)占用内存大约是 40-100M(使用缓存插件后会减少);MySQL 数据库占用内存 200M,随着渐渐使用,有着近千篇文章和评论的 blog 站点,MySQL 占用内存会达到 500M 甚至更多。 ——数据库的这部分内存,使用 SQLite 后,完全是可以省下的。

可以通过 SQLite Integration 插件,安装基于 SQLite 的 WordPress。Wordpress 官网的插件页面,因为作者失联而停更。但隐藏的插件下载链接,一直都还有效:

https://downloads.wordpress.org/plugin/sqlite-integration.1.8.1.zip

最新版本的 WordPress 也仍然可用。Github 上也有这个插件的分支

使用非常简单,就是把 db.php 复制到 wp-content 目录里,同时确保你的系统安装了 php-sqlite3 模块。这里有篇攻略。现有的站点,可以通过 Duplicator 之类的 wordpress 备份插件,或者 wordpress 自身的导入导出功能,进行迁移,不需要进行数据库级别的转换操作。

注意事项:

1. 最重要的,数据库的文件的存放位置,这个一定要改!默认的数据库位置是在 wp-content/database/.ht.sqlite,是会被人通过浏览器从 http://website/wp-content/database/.ht.sqlite 直接下载的!虽然插件在 database 文件里添加了 .htaccess 权限控制,但对于如今大家用的 Nginx,是默认无效的。

在 wp-config.php 里添加设置:

define('DB_DIR', '/absolute/custom/path/to/directory/for/sqlite/database/file/');
define('DB_FILE', 'custom_filename_for_sqlite_database');

可以更改数据库文件的存放位置。强烈建议把数据库文件,放到无法直接用网址从外部访问的目录(记得给那个文件夹授权可写)。

2. SQLite 不适合多线程的高并发使用。如果网站会有多个用户同时在后台编辑,那么网站不适合使用 SQLlite;如果只有一个写作者自己编辑 blog,就很合适。但要避免使用那些,在一般访客浏览网站时,也会导致对数据库进行写入的插件,如:

  • WP Statistics 这样的访客统计插件,会把来访者的每一次点击,都记录到本机数据库里。建议使用 Google Analysis 之类的外置统计软件(Google 给 wordpress 做了个官方插件 Site Kit by Google),通过在页面嵌入 js ,发送访客数据到 Google 服务器,不会写入本地数据库。
  • 官方的防垃圾评论插件 Akismet Anti-Spam,其实也是先把每条评论写入本地数据库,再判断是否垃圾的。如果被机器人大量发送垃圾评论,也会造成数据库写入的压力。建议使用 WP Captcha 之类的验证码插件(可以单独使用或配合 Akismet 一起用),把大多数垃圾评论在写入数据库之前就过滤掉。

3. 使用 WP Super Cache 插件,为网站生成缓存文件,可以极大地减少对数据库的读取操作。个人用户完全可以在插件设置里,关闭默认的 Garbage Collection 功能。


网上搜到的 WordPress + SQLite 的 docker images(12),Wordpress 和 php 的版本都有些过时了,本身也有一些小问题(如数据库文件夹的权限设置),建议修改 Dockerfile 然后自行编译。回头有时间我去改个试试。

WordPress 的 ActivityPub 插件

试用一下 WordPress 的 ActivityPub 插件(官网 / Github)。

主要功能,就是在 wordpress 上,建一个 Fediverse 账号,Mastodon / Pleroma / Misskey / Honk……的用户可以 follow 这个账号。新的 blog 文章发布时,这个账号会发一条嘟文,大家可以转发这条嘟文。followers 对这条嘟文的回复,会自动同步到 blog 文章的评论区。

就像我为这个 blog 建的 fedi 账号:@[email protected]

需要指出的是,并不存在 blog.fivest.one 这样一个 fediverse 实例。陌生人搜索这个账号,看不到任何历史嘟文;这个账号不能去 follow 别人,不能对别人说话,不能回复别人对自己嘟文的回复,也不能看到多少人转发点赞了自己的嘟文。——这些功能也许以后会有,但目前,这个插件所做的,只是在新 blog 发布的那一刻,向所有 follow 这个 id 的账号,push 一条嘟文。这条嘟文,在 blog 服务器上,并没有保存;而只存在于 follow 它的那些实例上,再被人转发到更多实例。

当 blog 的文章被删除时,这个插件也会通知所有的 followers,从他们的实例上删除对应的嘟文。但是就像我说过的,这个机制并不能把那些,被转发到其它实例的嘟文,也一起删除。所以,当你在 blog 按下发布按钮的一刹那,带着你所写的全部内容(或者摘要,可设置)的嘟文,就可能会永远飘在 fediverse 世界里,无从反悔。所以,写完这篇文章后,我还不确定自己是否会继续用这个插件……

所以我只是觉得这个插件运行的机制很有趣,向大家介绍一下而已。它仅仅是通过 ActivityPub 协议,和其它实例通信,而本身并没有创建实例。这个插件在 wordpress 的数据库里,甚至没有新增一个 table,而只是把 followers 的公钥,存到了 wp-options 里(我觉得这么折腾 options 表,有点过犹不及了……)。总而言之,这是个超级轻量化,在 wordpress 基础上,完全不产生多余开销的东西。

我之前吐槽过,目前所有的 Fediverse 引擎,都是用软件工程模块,匆匆拼出来的臃肿怪兽:开销巨大,数据结构不美观,依赖的技术模块未必有长久的生命力,安全性抗冲击性都很差……其实我很期待,一个单用户版的,完全没有 local 功能,支持 ActivityPub 协议的引擎。结构的简洁程度,和资源的开销,要比现在这些要好很多。从这个插件可见一斑(虽然这个插件和完整的个人版 fedi 实例,是完全两回事……


测试了一下。好像只有 follower 的回复(公开 or 私密)才会同步到 blog 的评论区;陌生人的不可以。但目前还没有做 follow 的审核通过机制。所以理论上是可以用这个功能发垃圾评论……

以及目前还没有让用户修改个人简介的功能,图片上那些简介,都是我在插件 templates/author-json.php 里手动改代码的。

关于 fediverse 的删除机制

在当前的很多 fediverse 服务(mastodon、pleroma…)里,当 A 站的用户 a 被另一个实例(譬如:B 站)的用户关注时,他所发的嘟文,会在 B 站的服务器上储存一个副本,B 站的用户,通过访问这个副本,来阅读这条嘟文。当原本的嘟文被删除时,A 站会通知 B 站,删除相应的副本。但这个时候,这条嘟文未必像人们期待的那样,从 fediverse 上彻底消失。

假设存在如下情况:

  • A 站的 a 用户
  • B 站的 b 用户,b 在关注 a
  • C 站的 c 用户,c 在关注 b,但 C 站没有人关注 a
  • a 发了一条公开嘟文,此时 b 可以看到这条嘟文,而 c 是看不到的。
  • b 转发了 a 的这条嘟文,此时 c 可以看到这条嘟文了。C 站的所有人,在查询 a 的时候,也都可以看到 a 的这条嘟文。
  • 如果这个时候,a 再把这条嘟文删除,那么 A 站会通知 B 站这条嘟文已删,而 B 站也会把这条嘟文在 B 站的镜像删除。于是 b 就看不到这条嘟文了。

——然而,似乎并没有一个机制,去通知 C 站,这条嘟文已删?也就是说,这个时候,c 和 C 站的所有人,都仍然可以看到 a 已经删掉的这条嘟文?

如果这个时候 C 站有人再转发这条嘟文,而 B 站甚至 A 站有人关注这个人,那么,B 站和 A 站的人,就又能看到这条嘟文了?甚至连 a 自己,也能看到的?(这个有待验证)


听起来似乎很不靠谱,但也不是不能接受。就像 twitter 还没有官方 retweet 的时代,所有的转发,都是由用户手动复制一个副本。而最初的推文被删除,完全不会影响这些副本继续存在。所以这里只是提醒大家,有这么一个机制。具体的隐私控制,还要由创作者自行把握。你曾发到网上的东西,可能永远不会真正消失。

Mastodon 的「去中心化」所导致的……?

看到 @[email protected] 写的论文导读。在 Mastodon 的去中心化网络里,用户之间的关联状况,其实比 twitter 更加高度集中。

Raman, Aravindh, Sagar Joglekar, Emiliano De Cristofaro, Nishanth Sastry, and Gareth Tyson. 2019. “Challenges in the Decentralised Web: The Mastodon Case.” Pp. 217–229 in Proceedings of the Internet Measurement Conference, IMC ’19. New York, NY, USA: Association for Computing Machinery.
研究人员爬取了在2017年4月到2018年7月期间的1750个实例,涵盖了23.9万用户和六千七百万条嘟嘟。基于这些数据,构建了用户相互关注的网络,以及实例之间的连接网络。

通过分析这些网络,论文发现了长毛象的中心化趋势。以下结果是基于搜集到的样本,不是全长毛象数据。

1. 用户方面,大约50%的用户都集中在10%的实例里面,因此少数的管理员在长毛象联邦中拥有过量的影响力。开放注册的实例拥有的用户比邀请注册实例里的更多,但是,邀请注册实例的用户平均嘟嘟数量差不多是开放实例用户嘟嘟数量的两倍(187嘟/人 vs. 95嘟/人)。不管哪种实例,都有中心化趋势,服从幂律(power law),前5%的实例容纳了约95%的嘟嘟;

2. 内容方面,只要关掉最大的10个实例,跨站时间轴上62.69%的嘟嘟都会消失。有些实例带有话题标签,研究发现,科技相关实例占据了55.2%的实例,却只容纳20.8%的用户和24.5%的嘟嘟。相比之下,虽然只有12.3%的实例是跟色情相关,但是却吸引了61%的全网用户;

3. 服务器方面,大部分实例都集中在少数的自治系统(Autonomous System, AS)上,主要在日美法德四国。最大的三个AS就有62%的实例。比如亚马逊AS上集中了62%的用户,尽管上面只有6%的实例。关注网络上,92%的用户是连接在一起的,但在极端情况下,只要五个AS崩坏,就会把相互连接的用户数量减到46%。

作者还分析了网络结构的强度。虽然长毛象分成了很多独立的实例,但是用户之间是高度连接的,跟推特相比,长毛象的连接更加脆弱,只要破坏少量的重要节点(高关注用户)就能够极大破坏原本的连接,相比之下,推特的关注网络就比较稳健。

伦理声明:研究通过了大学伦理审查,只收集了公共嘟嘟,并进行了匿名处理,论文结果不包括任何的嘟文内容分析。

实际使用中,也有类似的感觉,Mastodon 用户互相 follow 所形成的网络,比 twiiter 更加纵向化。大家相对更集中关注一些较活跃的用户,而在用户网络的末梢,横向的互相关注相对较少,尤其是不同实例之间的关注,更是如此。

但我觉得这种状况,是和 Mastodon(以及整个 ActivityPub)目前的设计机制有关。最近自己架设实例时,看了一下 Mastodon 和 Pleroma 的后台数据库,架构上有一些莫名其妙的地方:

( btw,我的新帐号: @[email protected]

在当前实例里访问其它实例的文章时,系统要先把其它实例的文章(以及图片附件)复制到当前实例的服务器(而且是和本地用户的文章放在同一个数据表里……),才能被本地用户读取。本地用户所看到的,并不是其它实例的原始数据,而是被保存在本地实例的镜像。

当一个实例的用户 follow 其它实例的用户时,两个实例的数据库把外来实例用户的信息和 public key,保存在各自的数据库里(也是本地用户和外来用户存在同一个数据表里……)。当外来实例的用户发布新文章时,外来实例的服务器会把这条新文章,主动 push 到订阅了它的那些服务器里存起来。

我能看出这样做的一些好处,譬如减少了实例之间的重复通信、避免最终用户和外来实例间的翻墙屏蔽、增强安全性……etc。然而,一切外来实例的文字和图片,都要先保存到本地服务器,才能被阅读,由此导致的,就是用户在随意浏览外面实例的历史文章时,体验非常不友好

界面里显示的外部实例用户的 following 和 followers 数量,也仅仅是当前实例里和这个用户有关联的用户的数量,而不是这个用户在所有实例的真正总关联数。

不仅是外面实例陌生人的信息,不能直接看到;连已经 follow 的用户,在 follow 之前所写的文章,也不能在系统里直接看到。一定要再打开一个浏览器页面,访问对方在其自己实例上的页面,才能浏览。对历史信息的转发和回复也非常不便。

当用户在 Mastodon 界面中,点开一个陌生人的帐号时,有三种情况:

  1. 陌生人也在同一个实例。此时用户可以直接看到陌生人的所有历史文章;
  2. 陌生人在其它实例,但之前曾经被用户实例里的其它用户 follow 过。此时用户可以直接看到,从这个实例里第一次有人 follow 开始,陌生人发过的所有文章。再之前的文章,则必须打开外置浏览器才能查看;
  3. 陌生人在其它实例,之前用户所在实例并没有人 follow 过他。此时用户完全不能直接看到陌生人的任何历史文章,只能通过打开外置浏览器查看。

不能方便地查看一个人以前发过的文章,也就自然没有兴趣去 follow 他。这就导致了两种「集中化」的关联:

  1. 在同一实例内部的人,由于可以互相看到历史文章,所以更方便互相 follow;
  2. 一些已经被实例里其它人 follow 过的「热门用户」,他们的文章更容易被这个实例里的其它用户看到,从而更容易被 follow。

而与之相对的,就是不同实例之间从没 follow 过的陌生人之间,其横向关联度急剧下降。

如果换一种架构模式,每个实例把自己用户的文章都做出静态缓存;然后用户访问外来实例时,直接访问对方服务器的页面,这样的话,情况会不会好很多?

我的技术水平不够,不能再深入分析对比这些机制的优劣了。但这些,其实和「去中心化」本身,并没有直接的联系。「去中心化」和「中心化」的区别,其实仅仅是后台服务器由谁去建,以及随之带来的审查和信息自由度方面的不同。普通用户在使用中,其实是不应该感受到 Mastodon 和 Twitter 的差别的。我们所面对的,并不是「去中心化」带来的问题,而是在做一套新的「去中心化」架构时,所没能解决好的技术问题。那些「中心化」的服务,也有很多因为设计的不如 twitter 理想,而最终倒闭了。目前而言,Mastodon 的架构还远称不上完美,有很多不足,或者让用户觉得不习惯的地方。但这些问题,其实只属于某个产品设计上的问题,而不应该归咎于「去中心化」

个人 VPS 上的服务安装(未完稿)

这篇文章要讨论的是,如何在一台轻量级的 VPS 服务器上,基于自己的域名,同时安装如今各种流行,去中心化的网络服务:

  • 个人博客:Wordpress
  • ActivityPub 社交网络:Pleroma 或 Mastodon
  • Matrix 聊天服务器:Synapse 或 Dendrite
  • 个人网盘和在线办公套件:Nextcloud

然而,原本我一直在用 Linode 每月 5 美元,1C1G(1个CPU,1G内存)的服务器,打算安装的服务,也是基于这个级别的配置。然而弄到一半,突然被乔乔推荐了 Contabo 每月 5 欧元(要一次缴一年,不然有额外费用),4C8G 的服务器。虽然实际速度和网速,并不比 Linode 或 Vultr 好多少,但 8G 内存,选择各种服务的余地可就大多了。所以我整理出来的 1C1G 方案,自己并没有在用……原因我后面会说。

之前也犹豫,既然同样价钱都能 4C8G 了,那为啥还要写 1C1G 的方案?很快大家的配置也都会变高级了吧?但想想也未必,还是整理一下吧。


这篇文章讨论如何在轻量级服务器里塞进各种服务。——前提是这台服务器,假定只会有你一个人在用,最多加上你的闺蜜和男朋友。我并不知道几十个用户的 Mastodon 会有怎样的开销,至少在 1C1G 上这样做非常不靠谱。我所面向的,只是两三个好友自用的私人 VPS 而已。

这篇文章不是写给小白用户的。整个系统还是很复杂的。指望有一个教程,或者一个 docker-compose,能够让完全不懂 Linux 的用户,通过逐行复制命令,就能搞定所有的安装,目前还不现实。你至少要有在完全理解的基础上,用 LNMP 搭出 Wordpress 的能力。所以我也没必要把用过的每一条命令,都放在这篇文章里。——对于每一项服务,我会尽量给出相关靠谱攻略的链接,并且讨论一下里面的坑,和我个人所作的选择。

所以,其实这篇文章本质上就一句话:

是的,这些服务都可以装到一台机器上,不冲突。我弄过了,没问题,你们放心慢慢弄吧。


安装环境:一台 1C1G(或更好的) VPS 服务器,一个你自己的域名。

Continue reading

Macbook Pro 三系统 Mac + Win + Linux 安装攻略

Macbook Pro 三系统 Mac + Win + Linux 安装攻略
前几天把笔记本清空重装,顺便整理一下 Macbook Pro 装三系统的攻略。这个应该是最简单的方案了,不用装 rEFIt 引导分区,也不用再手动运行 GRUB 修复 Linux 或 Windows 的引导。
0.1 技术思路,简要地说,就是 Macbook 用 GPT 管理硬盘分区,但 Windows 的 MBR 只能识别 GPT 的前四个分区。所以先在 Mac OS 下用 BootCamp 划出 Mac 以外的分区,然后先用 Linux 安装盘的工具把整个硬盘分区,把 Win 装到第四个分区,再安装 Linux 顺便用 GRUB 自动引导 Win 。
0.2 Win 和 Linux 都是用光盘安装,没有光驱的机器,请去自行查询如何用 ISO 制作 Macbook 的 USB 安装盘——其实满复杂的,新人建议去找个外置光驱……
0.3 安装环境:
Macbook Pro 5.5(2009年款,另外附上作为非果粉当年的吐槽评测
Mac OS X 10.8 Mountain Lion(10.6 Snow Leopard 之后的都可以,之前的没试过)
Windows 7,XP 也可以
Ubuntu 12.04 LTM —— 推荐新人和懒人用这个版本。最新的12.10安装盘内置的 partman 分区软件在 Mac 下会报错。也可以用其它发行版如 Xubuntu 12.04 之类,但 Xubuntu 安装盘自带的 GRUB 包好像不全,安装过程中建议把网络连上自动更新,否则引导程序可能会自动安装失败,可以事后手动安装,但不叫做简单了。
1 安装 Mac OS,安装前用 Mac 安装盘里的【磁盘工具】,把要安装的硬盘设成一个分区(Mac OS),分区方式选择 Guid 。 / 没有安装盘的,也可以找个移动硬盘,Guid 分区后把现有系统映像过去,用移动硬盘启动,Guid 现有分区后,再映像回来。——总之就是确保 Mac OS 所在硬盘是 Guid 格式的分区,不然 BootCamp 不能通过。已有 Guid 系统的可以直接到下一步。
2 Mac OS下,放入 Windows 安装盘( BootCamp 要检测到 Win 安装盘才工作),【应用程序 – 实用工具 – BootCamp】,选择安装 Win ,划分区,系统重启时按【Option】键进入 Mac 引导界面,按退出键退出 Win 安装盘,插入 Linux 安装盘。
3 从 Linux 安装盘启动,不要直接安装,选择【Try Ubuntu】,打开【终端 Terminal】,输入【sudo gparted】,在 gparted 中将现有硬盘分区:

如图,sda1 和 sda2 是 Mac OS 的系统分区,不要动,后面有1个(BootCamp做的 Win 分区)或2个(可能有的 Mac 会留个系统恢复区)分区,把这些全部删除,重新添加分区;
sda3 是我硬盘中最大的分区,作为三个系统共同的数据分区,可以格式化成 ext2(推荐,Mac和Win都要装驱动识别、后期还要在Linux下调整权限)、NTFS、或者FAT32(其实这个最方便,但有单个文件4G的限制);
sda4 是给 Windows 留的分区,建议格式化为 FAT32,在Win安装界面下再重新格为 NTFS(如果直接格 NTFS,安装Win时可能不识别)。另外传说 Win 一定要装在第4个分区,装在第3个会引导失败,我以前试过一个好像也没问题,懒得多试了;
sda5 是Ubuntu分区,这后面的分区Win都无法访问了。随便你格式化成 ext2/3/4、ReiserFS 都可以。如果不需要数据分区的话,把 Linux 装到 sda3 也无所谓;
sda6 是Linux的交换分区,内存够大的话,没有也可以。
点击【√】确认所有修改,退出系统,关机。
4 开机,按【Option】,换碟,从 Win 安装盘启动,安装 Windows 时选择高级自定义分区,分区界面里只显示前四个分区(后面的显示未分配,不要动),把第4个分区格式化,安装 Win 到第4个分区。和一般装Win时一样,过程中会重启几次,直到 Win 全部装完。关机。
5 开机,换 Linux 安装盘,安装 Ubuntu 。安装类型选择【Something else】,打开分区软件,挂载要安装的 Linux 分区( /dev/sda5 → / 、 /dev/sda3 → /home or /data )。最下面的Boot Loader安装位置,确认是 /dev/sda 。

安装完成,每次开机时按【Option】键,选择启动 Mac OS 还是 Windows(可以在 Mac 或 Win 的 BootCamp 设置默认),选择 Win 后进入 Linux 的 Grub 菜单,选择进入 Linux 还是 Windows(可以在 Linux 里更改默认项和等待时间;另外从 Grub 里启动 Mac OS 似乎不管用的,以后可以研究或者直接删掉)。
好久没写技术帖了。

景深与画幅的关系

Ted GUO: 仔细看了弥散圈概念和景深的推导过程,发现景深与胶片/CCD尺寸相关。在景深计算器里照相机/底片尺寸是参数。所以胶片机镜头上的景深标尺不能直接用在非全副数码机上,超焦距也不同。呃,幸好早发现,没拍多少。

呃,这么说倒是没错。但问题比你想象滴复杂。。。
弥散圆(CoC)和景深(DoF)是两个概念。弥散圆是指焦外一点在底片上形成的像斑大小,就是这个公式(wiki:示意图):

可以看出,弥散圆大小是由(光孔-A,焦距-f,像距-S)决定,也就是教材中的景深三要素,和相机型号、画幅大小无关,任何一支镜头,三要素固定后,把后面的机身换成数码、非全幅、120甚至大画幅,形成的弥散圆不变。
景深则是人为的定义。它首先给定一个常数c,然后计算形成的弥散圆小于c的那段像距范围。在定义c时,首先认定人眼在25cm外的分辨率是0.2mm,然后计算把照片放大到10英寸(25cm)时,照片上的0.2mm对应底片上多长的距离。底片越小,0.2mm对应的弥散圆c越小,成像小于c的范围就越短,景深也就越小。直观上很好理解:小底片需要比大底片放大更多倍才能到10寸,那些本来在景深范围内还算清晰的,放大了就会更不清晰。
所以,与其说“景深与胶片/CCD尺寸相关”,不如说与你要把照片放多大相关。镜头上那个景深标识只是理想条件下(放大10寸,距离25cm)的数值。当你在显示器上把同一张照片全屏显示和嵌在网页里显示,这两种方式的景深就已经不一样了。另外有的时候我们需要的未必是这种定义下的景深,买全幅相机的目的之一是为了印出更大的图片,同样的CCD技术下,同一个镜头,如果把全幅和非全幅的相机都印出和各自的最大分辨率对应的1:1的照片,凑近看,它们的焦外清晰程度是完全一样的。所谓非全幅其实就是在全幅画面中挖出中间一块,然后非要把这一块放大到原先大小去比哪个清楚。。。那个“与CCD尺寸相关”的说法实在是欺侮弱小 ^-^
当然了,照片越大,通常观看的距离就越远,所谓(10寸,25cm)的定义,其实指的是一个大约53度的视角。所以说【胶片机镜头上的景深标尺不能直接用在非全副数码机上】,这么说完全正确。但景深这种凭感觉定义出来的东西,受影响的因素太多了。景深受三要素尤其是像距(是的,新人想玩景深的话,凑近了拍效果远比用大光圈明显)的影响远远大于受画幅的影响。甚至在把照片导出到JPG过程中做了自动锐化的话,景深也被改变了。除非是摄影棚里拍静物广告,否则也没什么人需要精确计算这个—-控制在一个数量级内也就够了。
想准确地计算画幅改变后的新的景深范围,是很难的。这个变化幅度随三要素而改变,手头没有专门软件,基本不可能换算出来。但所幸超焦距的变化是线性的。譬如Canon 500D的等效焦距要x1.6,全幅50mm镜头在f8光圈下的超焦距为大约10m,也就是说从5m到无穷远的距离可以同时清晰;那么在500D上只需简单把这个数值x1.6:焦距放在约16m,从8m到无穷远同时清晰。
而且弥散圆随画幅的变化也是线性的。上面的例子看似少了3m的清晰范围,实际上这5m-8m内的物体,其清晰程度也就从原先的一个点变成了最多1.6个点,和你照片是按1280 * 960还是800 * 600显示,造成的影响差不多,小于锐化造成的影响。这种改变你拍人文完全无视也无所谓的。
但不管怎样,不要把焦距等效成50mm * 1.6 = 80mm再去求景深,完全不一样的。
由此引发的一些相机上的问题:
—————————————-
1、那些非全幅镜头上的景深标尺,是已经修正过的么?(我没怎么用过非全幅头,它们有标景深咩?)
2、故老相传,在一些自动单反相机尤其是Canon上,存在一种叫景深优先曝光的东东。用户可以分别对需要的最近和最远清晰点对焦,然后相机根据范围自动计算出光圈。俺没用过这东东,不知道全幅和非全幅的计算结果有没有区别?
3、关于景深预测。单反相机中,本来在胶片/CCD位置的成像经三次反射进入拍摄者眼中,其景深的观测环境也应该满足(CCD画幅 : 内部光路总长度)的比例关系。如果你觉得取景器里的视角不像是53度的话(绝大多数都不是),那么这个景深预测本身就是错滴。当然我说过的这种弥散圆一两个点的变化完全可以无视,再继续掰就是矫情了。
re ninety:
—————————————-
其实我们平时拍照时,真正想要关注的【景深效果】,并不是指这个清晰的范围(任何照片放大到一定规模,谈清晰什么的就都没意义了),而是弥散圆随着物体在焦点前后移动而放大的速度。也就是

c / |S2 – S1| = A * f / S2 * ( S1 – f )

这个就是纯粹的三要素了:景深效果的强烈程度,和光孔大小成正比、和镜头焦距成正比、和距离成反比、和画幅和CCD无关。

EXIF vs ICC

(本文不提供名词解释。)
前几天打算去掉手头一批照片的exif信息(主要是去掉拍摄日期保护隐私)。然后想到:这样做会不会同时去掉照片的色彩空间/内嵌ICC信息?照片信息中对色彩空间的定义,是不是和exif信息放在一起的?
首先要找到能够识别图片的色彩空间和exif的软件。专业图片处理工具如Photoshop、GIMP,能够识别图片内嵌的色彩空间,但似乎需要另外的插件才能读exif。绝大多数看exif的常用小工具(如Exif Viewer)都不支持查看色彩空间。Windows下有个叫PhotoMe的免费软件,可以查看/修改图片的各种信息,用着还不错。
查了下Exif的标准,在EXIF Sub IFD里,确实有一个地址[A001]被定义为ColorSpace的,但我试过的所有exif软件里都看不到这个字段的内容(回头试试直接源文件寻址),而photoshop等软件嵌入色彩空间信息时,似乎也是存在了别的地方,和这个字段无关。所以貌似exif里是可以定义色彩空间的,但似乎没人这样用过。。。
其实照片的头信息中,有很多种不同的结构标准:Exif、IPTC、GPS、ICC、XMP….之间彼此独立,可以共存于照片文件中。照片的色彩空间信息是存在ICC的部分,和Exif无关。所以理论上移除exif信息,是不会影响图片的icc信息的。但事实上很多号称移除exif的软件,都是不分青红皂白,把文件的很多其它信息一起删除,慎用。推荐一下jhead,有选项可以控制只删除exif还是删除所有信息,多平台,命令行模式,支持批处理。

jhead -de -di -dx ×.jpg
移除所有jpg文件的Exif、IPTC、XMP信息,保留ICC色彩空间信息

另外发现有些软件(如GIMP)在把照片存贮为sRGB空间时,实际上并没有往照片的ICC信息中写入任何内容,而是直接存成了无色彩定义的文件(?待验证)。虽然这种无定义的文件在显示时基本都被默认当成sRGB了,但理论上用户可以把自己的默认显示定义为其它非sRGB空间,所以GIMP这样处理似乎不大好?
最后做一下试验。八张图
0.  1.
2.  3.
4.  5.
6.  7.
0. 源文件,包含exif信息,指定sRGB空间(Lightroom导出)
1. 在GIMP中,把0重新指定(Assign)为sRGB空间,但这时候另存为的文件其实是没有指定任何icc的
2. 在GIMP中,把0不做任何转换,直接指定为AdobeRGB空间(Assign Color Profile)
3. 在GIMP中,把0转换到AdobeRGB空间(Convert to Color Profile),注意2和3的区别!
4. 移除2的exif信息,保留icc
5. 移除3的exif信息,保留icc
6. 移除2的全部信息,pure jpg
7. 移除3的全部信息,pure jpg
童鞋们可以思考一下,这八张图都应该是什么效果(完全看不出区别的请自剐双目)
答案(用鼠标选中下列文字):
——————–
一共有三种效果:
A – 原图效果
B – sRGB被显示成AdobeRGB,造成的失真
C – AdobeRGB被显示成sRGB,造成的失真

在支持色彩空间的浏览器,如Firefox(需要改变默认配置#)、Safari上,效果为AABABAAC
在不支持色彩空间的浏览器,如IE、Chrome上,效果为AAACACAC

——————–
Update:发现2012年以后的 Chrome 好像增加了色彩管理功能,可以正常显示了。只是时不时还传出中间某些版本功能突然失灵的消息……
这个网站通过鼠标悬浮动态演示,几种效果间的对比更好看。