如标题所述，这是一篇针对 《色彩可视化：从图片制作 CIE 1931 色谱》 的补遗。若尚未阅读前述文章，推荐先行阅读，它粗略地描述了利用 ICC 文件进行颜色管理的流程；本文意在对前文中「不一定正确」的说法进行纠正、补足及扩展。

本文 不是 一个校色教程，也 不会 事无巨细地描述某一步中具体的操作，而是一篇理论小记，全文字数约 6000，偶尔有图。

与前文相同，阅读本文需要读者具有至少中国大陆大学理工科的基本数学知识。作者并非数字图像处理、数字传媒或相关专业学生，作为补遗，本文希望 尽可能准确 地描绘出色彩科学的真实图景，但势必仍有疏漏与错误，若有偏颇还请指正。

色彩空间转换、色度适应变换

在前文中，色彩空间转换的章节有如下一段：

当然，阅读源码可以知道，经过 TRC 转换后，我们并没有进一步使用 matrix 计算得出 PCS XYZ。这是因为它作为 profile connection space，虽然与 CIE XYZ 大致相同，不过白点是 D50，而非常用的 D65；为了控制变量，我们忽略 ICC 提供的转换矩阵，直接统一使用 colour-science 提供的计算方法。

理论很美好，对吧？但实际的实现却很矬：

认识不认识的摄影人都在用照片总结自己过去的一年，思考了很久要不要凑这个热闹。想来并没有特别珍贵、值得留存的回忆，更没有足够出彩的照片，拿出来也撑不住场面。

不过细想，或许还是需要一份以图为主的快速回顾。

故有此文。

前方致死量图片警告。为保证阅读质量，大部分图片仅展示压缩版本，可点击图片查看原始大图。

文中所有图片均以 知识共享 署名-非商业性使用-相同方式共享 4.0 (CC BY-NC-SA 4.0) 协议授权免费使用。部分图片另有 Unsplash 版本，由 Unsplash 分发的图片遵循 Unsplash License 。

一直以来，针对色彩的讨论都是「玄学」重地。无论是手机还是相机、镜头，评测里绝对少不了大谈特谈一番「色彩」，却又鲜有人真能说出个门道。若设备有明显色彩倾向，或许还能用上个「偏黄」「发绿」之类字眼，对于「佳能拍人像、尼康拍风景」，或者「苹果真实而寡淡、小米浓郁而偏暖」，听着就只是一种刻板印象了。

但这又确实是一个，长久以来一直都可以严谨量化的领域。哪怕以 1931 年国际照明委员会提出 CIE RGB / XYZ 色彩空间作为起点，至今也已有八十余年，甚至比现行使用最广泛的 JPEG (ISO/IEC 10918-1:1994) 标准都要早半个世纪。到今天，几乎所有图片都会附带一个 ICC 文件，专门用来完成色彩管理工作；无论是还原到线性 gamma，还是从线性 gamma 转换至 CIE / PCS XYZ 再进一步绘出 CIE 1931 色谱，哪怕不是非常简单，至少也有标准可循。

这也是一个，长久以来一直欠缺严谨量化的领域。1931 年画出的那个舌形图至今仍具有相当理论价值，可即使是 DXOMARK 这类专业评测，都鲜有针对镜头色彩的测试；DPReview 曾经有 相关对比 ，给出 CIELUV 的色域分布，但它最多只能算是同一相机不同输出模式的比较，不具备太多参考意义。至今可能只有先看走得最远，他们在 视频 里提到，日后将与中国计量科学研究院合作，把色彩表现能力纳入评测内容。尽管视频中的评测方式不一定适用于计算摄影，如果他们后续开始对色彩进行客观评价，那也是评测行业一个不小的进步。

触动我的则主要是群友的博客： 《「所谓玄学」Part I：给色彩，打上花火》 。在这篇博客里，群友波波通过限定环境标板测试与实拍测试，证明了色彩的可量化性，并且通过标板的测试结果，成功解释了不同镜头在实拍测试中的表现。然而，中国计量科学研究院、标板、严格到色温的光照条件，这些名词离普通人都太远了。有没有办法直接从照片获得色彩分布呢？

这学期前，学校防火墙迎来一波升级，路由器上本来用于绕过多设备封锁的方式尽数失效，考虑到它还跑着非常古老且风评不佳的修改版 OpenWrt，也是时候进行一点系统升级了。新系统最先困扰我的问题就是防火墙变动，OpenWrt 22.03 起，防火墙由 fw3 切换到了 fw4 ，底层也从 iptables 变成了 nftables 。相较于 iptables，nftables 配置更灵活，语法更友好，并且可以直接接管 Xtables ——或者说此前整个 iptables 大家族——的功能，从 ipset 到 mangle 无所不能，但对于习惯 iptables 的用户来说，底层突然切换无疑会带来一定学习成本。

好在， nftables 的强大并不意味着它难以上手。正相反，花两天时间与它相处后，我发现借助详尽的 官方 wiki ，我能迅速熟悉这个新工具，甚至开始依赖起它带来的一些新特性。虽然 iptables-nft 可以非常方便地将 iptables 语句翻译为 nftables 配置，但它毕竟只是一个转换，更适合用于兼容古董软件，而且一些高级特性也无法被它正确识别，掌握如何自己配置 nftables 依旧重要。因此我将我的经验写在这里，希望能帮到更多初次接触 nftables 的读者。

本文默认读者拥有初步的 Linux、SSH 及计算机网络知识，否则可能会因为专业术语过多而导致理解困难，还请谅解。
我的设备为红米 AX6，系统为自己从源码构建的 ImmortalWrt 23.05 SNAPSHOT，部分操作在不同设备上可能不同。
事实上，官方 wiki 对于上手来说也非常不错，如果英语阅读能力过关，可以直接参考 Quick reference-nftables in 10 minutes 。

原理：从 Netfilter 说起

前些日子对手上的 Pixel 6 Pro 忍无可忍，趁着好友换小米 14 的机会，带走了他的小米 13。作为对日用系统有着严苛要求、见不得一丝广告的人，到手第一件事自然是解锁刷国际版。由于 EU 版 只是 基于国行系统 的 第三方 魔改，我对它也不太信任，选择了从底层上就不一样的 EEA 版，它由官方发布，专为欧盟地区定制，理论上广告和遥测都很少，而且深度集成 Google，对于 Pixel 用户来说迁移起来也很方便。

EEA 版本哪里都好，唯独缺了一项重要的功能：NFC 卡模拟。在国行系统中，这一功能由「钱包」应用提供，它以特殊的方式集成在系统底层，能够直接与安全模块通讯；EEA 版由于底层不一致，系统内没有安全模块的选项，向系统内塞智能卡组件更是直接闪退。尝试使用 Card Emulator Pro (NFC 卡模拟) 也以失败告终，我并不确定它生成配置的原理，但它似乎只是往固定的位置塞固定的文件，一旦 NFC 配置不同就会失效，甚至直接使 NFC 功能不可用。

除此之外，可能是由于安全模块仍在工作，直接读取手机的 ID 得到的值不是固定的 01, 02, 03, 04 ，而是 08, XX, XX, XX ，其中后三位完全随机，难以直接全文搜索替换。由此看来，唯一能够实现这一功能的方式，就是自行提取、修改系统的 NFC 配置，再将其刷回。我将我的解决办法记录于此，希望能对你有所帮助。

最近读完了广西师范大学出版社 2017 年出版的《摄影小史》，收录了 瓦尔特 · 本雅明Walter Benjamin 著四篇论文的中译本，其中《摄影小史》(1931) 和《机械复制时代的艺术作品》(1936, 下称《机械复制》) 尤其具有参考价值与思辨意义，让我一个非科班、纯用爱发电的爱好者，也觉得该为读完这本书而写点什么东西了。

受这两篇文章本身 论文essay 属性、译本差异以及语言鸿沟等因素限制，本文试图在记下阅读感受的同时，结合艺术、摄影及文化史有关内容，解释一些书中较为复杂的概念，同时结合时代加上我本人的思考。无论你是否读过原著、是否认同本文观点，都希望能给你带来一些启发。

本文约 8500 字，阅读约需 30 分钟，全程量子叠加态有图，请放心食用。

瓦尔特 · 本雅明

理解一本书前提是理解作者，《摄影小史》也不例外。如果用一句话为作者定性，瓦尔特 · 本雅明 (1892-1940) 是一位隶属于法兰克福学派、笃信西方马克思主义的犹太人、文化理论家。如此便算是交代了历史背景，足以理解本书的写作意图与作者许多观念的形成原因。本节还会简述一些与他相关的重大事件，它们摘译自斯坦福大学哲学百科全书 瓦尔特 · 本雅明词条 ，若是不感兴趣，直接跳到下一段也无妨。

如 我的数据备份方案 所述，我的照片通过 Pixel XL 上传至 Google Photos，以便随时随地翻阅。这一方案体验一直很好，直到我先后购入了两台发布于 2010~2015 年的相机。不知为何，它们直出的照片在 Google Photos 网页端顺序混乱且没有规律，还常有显示日期错误，点开详情看时间却正常的问题，而手机拍摄的照片与经过 Photoshop 后期的照片则相当正常。经过一番探索，我发现问题主要出现在时区上，我上传的照片时区从 GMT-8 到 GMT+8 都有，导致照片排序混乱不堪。

一番折腾后，我最终以较优雅的方式解决了这个问题，以下是我的探索过程与解决方案：

定位问题

已知是时区问题，首先就要弄清楚 Google Photos 如何确定时区。根据 Google 到的相关资料，Google Photos 会优先使用照片的 GPS 位置来确定时区，其次是照片 Exif 中包含的时区信息。然而，发布于 2016 年的 Exif v2.31 才正式加入时区偏移值，2016 年以前发售的相机自然不会支持。在没有 GPS 也没有时区的情况下，Google Photos 会使用多个办法估计照片的预计位置，例如其它设备的位置、具有相似内容的照片的拍摄位置等，没有启用预计位置时，它的时区判断依据就变成了 上传 IP 。

依稀记得 10 岁时，我盼望着时间流逝，想要尽快成为大人；而十年之后，我离 20 岁已经不远，或许已经逐渐成为能独当一面的大人，却发现转瞬间，一年时光又要划上句号。

今年过得实在太快，甚至没有机会思考自己，想了许久，我决定将一年拆散成几个主题，它们交织着，构成了「我」奔二年代最后的故事。

本文约 4000 字，全程有图，请放心食用。

还来不及学会珍惜

寒假将至那几天，在五一广场旁某个酒店，我用《紫罗兰永恒花园》，试图告诉另一个人也告诉自己，什么是爱、如何去爱；在过得太快的年里，我难得地与各路好友聚首，在小城中四处游走，用美食作为冬日温暖。一顿火锅、数次炸鸡与不计其数的烧烤下肚后，回首远望来时方向，仿佛我与过去距离还不甚遥远，仿佛时光还没来得及形成沟壑，黄金时代余韵不绝，在我的心中激荡。

故事开始，还得从 2020 年 11 月苹果发布会说起。那天，M1 芯片正式发布 ，将 ARM 芯片的笔记本电脑带入寻常百姓家，以超高能效和超长续航一举成名，彻底改变大家对 ARM 的印象。偷偷嘲讽 Mac 用户没游戏玩时，我内心不免好奇：这是什么来自西方的神秘魔法？ARM 桌面处理器居然这么神奇？？直到那时，搭载 ARM 处理器的 Windows 设备才正式进入我的视野。

然而，苹果对于穷学生来说实在是太遥不可及，当时我才刚入手 LG Gram 五个月，对它抱有相当好感，再加上各种渠道听说 ARM Windows 笔记本搭载的 WoAWindows on ARM 还是个半成品，不适合作为主力，于是萌生的想法被搁置，一拖直接拖到苹果发布会两年后的另一个 11 月。当我发现 LG Gram 二手价格已经跌到不堪入目，我的笔记本使用需求逐渐轻量到「能办公就行」，我知道是时候做出改变，拥抱一点新东西了。心一横，一天后到手一台 Surface Pro X，本文则是对我和它磨合过程中，写下的一点记录与思考。

太长不看：能用了吗？

能用了，甚至很好用。许多软件都提供 ARM 支持，x64 软件通过转译也能正常运行，除 Canon 的打印驱动外几乎没有不兼容。这里是常用软件及 Windows on ARM 体验对照表，后面 体验 部分有各种场景的综合体验评分，可以作为参考。

六月初，苦苦等待许久的 CanoKey Pigeon 终于上线第二批，拿到之后，我非常兴奋地用它绑定了一大堆常用网站的 两步验证2 Factor Authorization (2FA) ，折腾半天后发现一个问题：如果对 OpenPGP 和 PIV 没有需求，仅仅把它作为 2FA 工具使用，我好像还不如直接用 Apple Watch 上的 Authy 来得安全、方便。

而且我有很多个理由拒绝 OpenPGP / PIV。两者在不同平台上需要各种配置，至少对于坚定的 Windows + WSL 用户如此；文件形式密钥备份起来非常不方便，尤其是出于安全性考虑，还有多介质备份 + 脱机条件一次性操作 + 主密钥、三个子密钥、撤销凭证备份、有效期、使用方法不同等等要求；各种操作都需要不同长度、不同作用的 PIN，我能记住超过三个 PIN 就很不错了，可能对于许多用户，需要的密码越多，越可能使用雷同密码或弱密码；最重要的是无法保证跨平台可用性，万一某一天出门在外突然有认证需求，却只有 iOS 设备，那直接完蛋；比起记住一次到处通用，数据、设备全部丢失也不会掉的密码（体系），实在是脆弱、复杂太多。

但当我百无聊赖坐在电脑前，望向放在桌上吃了两周灰的 CanoKey，我又感觉可以试试看。就算不把它作为主要认证方式，至少玩玩看嘛。于是，在我花费大半个上午生成 key，再将 Windows 的 gpg-agent 塞进不支持访问 USB 设备更别说 CanoKey 的 WSL 1 之后，我写下这篇文章作为记录，以便此后能随时回顾，希望能帮助到同样有需求的人。