互联网域名系统迎来变革：RDAP 即将取代 WHOIS
互联网域名系统即将迎来重大更新。ICANN 近期宣布，将于 2025 年 1 月 28 日正式启用 Registration Data Access Protocol (RDAP)，并逐步淘汰沿用多年的 WHOIS 服务。未来，RDAP 将成为查询通用顶级域名 (gTLD) 注册信息的权威来源。
RDAP 的优势
相较于 WHOIS，RDAP 协议拥有多项显著优势：
- 更好地支持国际化： RDAP 在设计上考虑了多语言环境，能够更好地处理不同语言的域名注册信息。
- 提供更安全的数据访问方式： RDAP 提供了更现代化的数据访问机制，提升了数据安全性。
- 具备权威的服务发现机制： RDAP 允许客户端自动发现可用的服务，简化了查询流程。
- 能够实现差异化的数据访问权限控制： RDAP 可以根据用户身份和权限，提供不同级别的数据访问权限，更好地保护个人隐私。
实际上，ICANN 认证的注册商和 gTLD 早在 2019 年就已开始提供 RDAP 服务。此次公告更像是一份正式的“退休”通知，宣告 WHOIS 协议即将退出历史舞台。
WHOIS 的退役与未来
用户可以通过 ICANN 提供的在线查询工具 lookup.icann.org 或开源命令行客户端体验 RDAP 查询。市面上也涌现了一些第三方 RDAP 客户端工具。对于需要访问非公开 gTLD 注册数据的用户，ICANN 还提供了 Registration Data Request Service (RDRS)，但这项服务主要面向执法部门、知识产权专业人士等具有正当理由的机构。
社区的讨论：LLM 与数据解析、新旧协议的兼容
评论区普遍对 WHOIS 的退役表示欢迎，认为 WHOIS 协议已显得过时。有人提到在 IETF 会议上，ICANN 宣布 WHOIS 退役时间表时，现场甚至响起了欢呼声。
尽管 ICANN 宣布了 WHOIS 的落幕，但有观点认为，许多域名运营商可能会在一段时间内继续保留 WHOIS 服务，RDAP 和 WHOIS 在未来或将并存。开发者们也分享了使用 RDAP 的经验，以及处理新旧协议数据格式兼容性的问题。
有趣的是，有评论员调侃，当我们终于拥抱结构化数据时，大型语言模型 (LLM) 却已能解析非结构化文本数据。但这一观点很快遭到反驳，大家认为 LLM 不适用于对准确性要求极高的数据解析工作，传统解析器在需要精确和可重复结果的场景中更可靠。关于 LLM 解析 WHOIS 数据的讨论也引发了关于 WHOIS 数据“人类友好性”的争议，许多人认为 WHOIS 数据格式混乱，远非“人类友好”。
总而言之，社区普遍认为 RDAP 的出现是互联网基础设施现代化的重要一步。
亚马逊取消 Alexa 隐私功能引用户强烈不满
亚马逊近期宣布取消 Alexa 的一项隐私功能，该功能原本允许用户选择不发送语音录音。这一变动立即引发了用户的强烈不满，人们纷纷质疑亚马逊对用户隐私的承诺。
用户质疑亚马逊的隐私承诺
用户在 Mastodon 上分享了亚马逊的通知截图，内容显示“不发送语音录音”功能即将失效。用户对此感到震惊和愤怒，因为该功能曾是许多人选择 Alexa 设备的重要原因，代表了用户对个人隐私的掌控。亚马逊取消此选项，无疑是对用户隐私的又一次侵犯，加剧了人们对智能家居设备安全性的担忧。许多用户表示将放弃 Alexa，转投更注重隐私保护的智能家居方案，如 HomeAssistant。
社区的讨论：隐私担忧、智能助手发展方向
评论区讨论的焦点集中在用户隐私、企业道德以及智能助手的发展方向。有人回顾了 2019 年一位自称亚马逊首席工程师的评论，当时该工程师强调亚马逊重视用户隐私，并以硬件静音按钮为例。如今看来，这种说法显得格外讽刺。
有人分享了物理移除麦克风的“硬核”静音方法，但也有人指出这可能无法完全阻止设备监听。关于智能音箱的“智能”是否必要也引发讨论，有人认为语音控制并非音箱核心需求，隐私保护更为重要。更有评论直言，用户对隐私的担忧由来已久，只是在便利性面前选择了妥协，而亚马逊的举动再次提醒人们，科技巨头对用户数据的收集和使用已近乎肆无忌惮。
对于生成式 AI 是否能为语音助手带来新生，社区存在分歧。有人认为 AI 或许能提升语音助手的智能化水平，但也有人担心这会加剧隐私泄露风险，因为更多数据将被用于模型训练。“人们是否真的关心隐私”成为核心辩题，一方认为用户并非真正在意隐私，否则不会购买此类产品；另一方则反驳，指出用户并非不关心隐私，而是常常缺乏选择，且对科技公司的真实行为缺乏了解。
开源工具 MVT：为你的手机做一次安全体检
今天介绍一款有趣的开源项目：Mobile Verification Toolkit (MVT)，移动设备验证工具包。这款工具能帮助用户检测手机是否被恶意软件入侵或存在安全风险，如同为手机进行一次“体检”。
MVT 的功能与原理
MVT 是一款移动设备端的法证工具箱，专门用于检测 Android 和 iOS 设备上的潜在安全风险。它由国际特赦组织安全实验室开发，最初是为了调查 Pegasus 间谍软件泄露事件而诞生。
MVT 的核心思路是利用已知的“入侵指标”（IOCs）扫描手机。这些指标如同间谍软件留下的“指纹”，帮助追踪已知的恶意活动。MVT 可以检查手机的各种数据，如已安装应用、系统日志、进程列表等，以寻找可疑痕迹。
开发者也提醒，仅依靠公开的 IOCs 并不能保证绝对安全，因为新的间谍软件可能尚未被收录。对于高度关注手机安全的用户，寻求专业安全专家的深入分析更为稳妥。
社区的讨论：实用性、技术细节、隐私问题
评论区围绕 MVT 的实用性展开讨论。开发者或技术爱好者认为 MVT 是不错的自检工具，有助于了解手机安全状况。技术专家可能更关注 MVT 的技术细节，例如扫描文件系统、分析日志的方式以及检测效率。
隐私问题也受到关注，毕竟深度扫描手机涉及个人数据。开源特性受到好评，意味着代码透明，可供审查和改进。但 IOCs 方法的局限性也引发质疑，因为间谍软件不断进化，攻击手法日新月异。
社区成员可能会分享 MVT 使用经验、提出改进建议，甚至讨论是否有其他类似工具可以配合使用，从多角度保障移动设备安全。
Pivotal Tracker 即将关闭，社区积极寻找替代方案
Pivotal Tracker 即将关停，这对于许多开发者来说是一个值得关注的消息。不少老用户对此感到惋惜，但社区也积极行动起来，目前已有十多个团队正在加紧开发替代品，力求继承 Pivotal Tracker 的优点。
Pivotal Tracker 的独特之处
Pivotal Tracker 并非简单的项目管理工具，其独特之处在于专注于开发者体验，摒弃了繁琐的功能，力求提升效率。它更像是一个“项目追踪器”，与 Bug 管理系统或面向项目经理的工具不同。
项目追踪器的核心是促进开发人员和产品经理在简洁环境中高效协作，确保信息同步，避免因复杂的设置而产生理解偏差。Pivotal Tracker 的周期计划是自动生成的，无需手动调整，团队只需关注任务优先级，从而更准确地预估交付时间，减轻开发人员被追问进度的压力。
社区的讨论：怀念与替代品、工具选择
评论区充满了对 Pivotal Tracker 的怀念之情，许多人对其简洁的界面和流畅的操作赞不绝口。有人将 Pivotal Tracker 比作开发工具中的法拉利，专注于核心功能；而 JIRA 则像十八轮大卡车，功能全面但略显笨重。
Pivotal Tracker 的成功之处在于其“有主见”的设计理念，例如强制使用故事点、独特的 Bug 处理方式等。虽然有时限制了灵活性，但也确保了项目管理的规范性。
虽然 Linear 等工具也被认为是 Pivotal Tracker 的替代品，但一些用户认为 Linear 功能过于繁杂，失去了 Pivotal Tracker 的纯粹体验。也有开发者认为 GitHub Projects 对于开发者而言更加自然易用。
评论区中，各种声音交织，有人推荐 Redmine 等老牌工具，有人分享正在开发的新工具，甚至有人开始怀念 Rails、MongoDB 等 Pivotal Tracker 流行年代的技术，将讨论带回了那个时代。
总的来说，社区对 Pivotal Tracker 的关闭感到惋惜，但同时也对社区自发寻找替代品的热情感到欣慰，毕竟优秀的工具是每个开发者都渴望的。
探索“例外约当代数”：数学与物理的奇妙交汇
Hacker News 上一篇热议文章深入探讨了一个略显硬核的数学概念——“例外约当代数”。文章以浅显易懂的方式介绍了这种看似高深，实则在数学和物理领域都扮演着独特角色的代数结构。核心内容是揭示一种非同寻常的约当代数，它与常见的矩阵代数不同，并与神秘的八元数以及更奇特的空间结构存在着千丝万缕的联系。
约当代数的起源与特性
文章首先回顾了约当代数的起源，它最初是为了形式化厄米矩阵的代数性质而提出的。关键在于，约当代数定义了一种特殊的“对称化乘积”，这种乘积满足交换律和双线性性质，同时还具备幂结合性和形式实性。“形式实性”保证了“平方和为零当且仅当每个加数都为零”，这使得我们可以定义“非负元素”和“锥”的概念，与矩阵分析中的半正定矩阵概念相呼应。
例外约当代数的独特性
文章随后点明了约当、冯·诺依曼和维格纳的分类工作。他们证明了有限维形式实约当代数可以分解为“简单”代数的直和，而这些简单代数大部分属于四个无限族。然而，最引人入胜之处在于存在一个“例外”——例外约当代数，它无法归入这四个无限族中的任何一个。这个例外是由 3x3 自共轭八元数矩阵构成的代数，配备了对称化乘积。作为一个实向量空间，它具有 27 维，结构相当复杂。
约当代数与射影空间
文章继续探讨了约当代数与射影空间的关系。对于由实数、复数或四元数矩阵构建的约当代数，它们的幂等元素（满足 A²=A 的元素）对应于射影空间中的子空间层级结构。而例外约当代数则引出了“八元数射影平面”，这是一个由露丝·穆方发现的奇特结构。由于八元数射影平面中笛沙格定理不成立，我们无法构建更高维的八元数射影空间。
文章还提到了自旋因子，它们可以被视为由任意维球体构建的“射影直线”。更令人着迷的是，文章将例外约当代数与一个“奇异时空”联系起来，类比我们熟悉的闵可夫斯基时空，将李群 E6、F4 和自旋群 Spin(9) 纳入讨论，揭示了例外结构在更广泛数学框架下的意义。
最后，文章还触及了“整数点”的概念，即在例外约当代数中，非对角元素是凯莱整数，对角元素是普通整数的矩阵。这种结构与 27 维时空中的唯一单模整数格有关，并与著名的泄露格点有着深刻的联系。文章还推荐了一些深入阅读的资源，引导读者进一步探索八元数、凯莱整数和例外约当代数的奥秘。
社区的讨论：自旋子、专业概念的深入探讨
评论区讨论的焦点主要集中在与文章内容紧密相关的概念，特别是“自旋子”的定义和理解。有人注意到文章发表日期与一篇新的 arXiv 论文上传日期巧合，猜测两者之间可能存在关联，暗示了该领域研究的活跃度。
关于自旋子的讨论非常专业，有评论者提问如何正式定义自旋子，引发了一系列深入解答。讨论中，有人从变换的角度解释了自旋子的特性，指出自旋子与向量的变换方式不同，与自旋群 Spin(n) 的表示有关，并提及了 Spin(n) 是 SO(n) 的双重覆盖这一概念。更有人深入到克利福德代数和最小左理想的角度阐述自旋子的定义，虽然较为抽象，但也展现了自旋子概念的多样性。
关于 Spin(8) 和三元性的讨论也十分热烈，有评论指出 Spin(8) 本身与三元性关系密切，三元性描述了 Spin(8) 表示之间的一种不寻常的对称性。评论区还澄清了“自旋群的表示”作为自旋子定义的局限性，指出仅凭这一点不足以唯一确定自旋子，需要更具体地指明是哪种表示。
整体来看，评论区不仅是对文章内容的延伸探讨，更像是一个小型学术研讨会，参与者在专业领域内互相交流，共同探索深奥的数学概念，体现了 Hacker News 社区技术人员对硬核知识的浓厚兴趣。
经典再现：《C 语言图像处理》引发关于图像处理技术价值的讨论
一篇 2000 年发布的 PDF 书籍《C 语言图像处理》近日在 Hacker News 上引发热议。这本书是一份专注于用 C 语言实现各种图像处理技术的教程。书中详细讲解了图像处理的基础概念，并配有实际的 C 代码示例，涵盖了从文件输入输出到更高级的图像分割、边缘检测等多种操作。
书籍内容简介
这本书内容扎实，从图像文件的读写入手，逐步深入到直方图均衡化、边缘检测、空间滤波等核心技术。它不仅介绍了各种算法的原理，还提供了 C 语言的实现代码，帮助读者从底层理解图像处理的运作方式。书中还涉及了半色调技术、图像几何变换、纹理分析甚至图像隐写术等有趣的应用。作者的目标是让读者能够用普通 PC 进行图像处理，并提供了一个名为 CIPS 的图像处理软件系统作为基础。
社区的讨论：经典方法 vs 神经网络、技术价值的辩论
评论区主要围绕经典图像处理技术在当今的意义展开辩论。有人认为，在神经网络盛行的今天，书中一些经典方法，如边缘检测，已经过时，神经网络能更有效地完成这些任务。
但许多人强调经典方法依然有其价值。他们认为，相比于神经网络的“黑箱”操作，经典方法更易于解释、调试和改进，尤其在工业视觉和安全攸关的应用中，其可信度和效率仍然重要。还有人提出，经典方法可以作为神经网络的预处理步骤，提升整体效果。
讨论中，大家也提到在学术研究、工程实践和个人爱好等不同场景下，对图像处理技术的需求侧重点有所不同。最终，评论区呈现了对经典图像处理技术和现代神经网络技术并存和融合的思考，各种观点交锋，颇具启发性。
人工光合作用新突破：太阳能驱动有机合成
一篇 Nature 上的新文章《面向有机合成的人工光合作用》引发关注。科学家们受到植物光合作用的启发，开发出一种人工光合系统，但其目标并非像植物一样生产糖类，而是直接合成各种有用的有机化合物。
APOS 的概念与目标
文章指出，自然界光合作用效率不高，仅为百分之几，但它能利用太阳能和水，自给自足地制造复杂有机物。目前人工光合作用研究主要集中在无机物合成，如水分解制氢或二氧化碳还原成燃料。而本文重点是“人工光合作用定向有机合成”（APOS），目标是直接利用太阳能和水，将简单有机物转化为更复杂、更有价值的有机物。
双光催化剂系统与反应机制
研究团队开发了一种双光催化剂系统，使用银负载的二氧化钛和铑铬钴负载的铝掺杂锶钛酸盐。这两种催化剂协同作用，利用光能和水为原料，实现烯烃的碳羟基化反应，即在碳碳双键上连接一个碳基和一个羟基，一步合成功能化的醇类。更值得称道的是，该过程同时释放氢气，具有环保意义。
反应机制颇具新意。首先，水分子在光催化剂作用下裂解产生羟基自由基。该自由基攻击有机分子的碳氢键，引发一系列氧化还原反应，最终实现碳羟基化，并将水中的氢释放出来。水在此过程中身兼数职，既是羟基自由基的来源，又是氢气的来源，还是产物中氧原子的来源。
为验证方法的实用性，研究人员成功利用其合成了一种抗过敏药特非那定。实验结果表明，该方法适用范围广泛，可用于各种烯烃和不同的碳氢键供体。研究人员还优化了反应条件，提高了效率。
社区的讨论：效率、应用前景、太空殖民
文章在 Hacker News 上引发热烈讨论。有人直接指出，自然光合作用效率低下，仅为 1-2%，而太阳能电池板效率已超过 20%，人类技术早已超越自然，无需效仿植物。
但很快有人反驳，认为这种比较不恰当。人工光合作用的目的并非单纯的能量转换，而是有机合成，是模仿植物的生物制造过程。植物的优势在于其自复制和自维护能力，以及对环境资源的利用。此外，植物能合成的不仅是糖类，还有各种复杂的结构材料和生物分子，这是目前工业合成方法难以企及的。
有人从太空殖民的角度解读，认为植物如同自带工厂的种子，可利用太空中的太阳能和水就地取材进行生产，这对未来的太空探索至关重要。当然，也有人较为务实，指出目前人工光合合成有机物的效率仍然较低，成本较高，距离实际应用尚有距离。
总而言之，这篇文章展示了一种前景广阔的有机合成新思路，利用太阳能和水实现清洁高效的化学转化，并将副产物转化为有价值的氢气。尽管目前仍处于实验室阶段，但若未来能进一步提高效率、降低成本，或许真能如评论区所言，构建出比植物更强大的“太阳能有机物工厂”。
HTTP/3 普及的悖论：用户端广泛应用，开发者工具支持不足
一篇 Hacker News 热文指出一个有趣的现象：HTTP/3 协议在用户端浏览器和大型 CDN 服务商中已广泛普及，但在开发者常用的工具和库中却鲜有踪迹。
HTTP/3 的普及现状与困境
文章肯定了 HTTP/3 的巨大进步，95% 的浏览器已支持该协议，Cloudflare 三分之一的流量也运行在 HTTP/3 上。然而，作者笔锋一转，指出 Node.js、Go、Python 等主流编程语言的标准库均未内置 HTTP/3 支持。网络神器 curl 也仅实验性地支持，且默认关闭。服务器端情况更糟，Nginx 的 HTTP/3 支持仍为实验性质，Apache 毫无动静，Kubernetes 的 Ingress-Nginx 项目甚至放弃了 HTTP/3 计划。这不禁令人发问，HTTP/3 优势显著，为何开发者使用却如此困难？
“双层网络”现象
为探究原因，文章回顾了 HTTP 协议发展的必要性。有人可能认为 HTTP/1.1 已足够，或 HTTP/2 在负载均衡后意义不大。但作者反驳称，HTTP/2 和 HTTP/3 的多路复用、头部压缩、双向流等特性在数据中心内部、移动应用、物联网等场景下仍能显著提升性能。特别是 HTTP/3，基于 UDP 协议，解决了 TCP 的队头阻塞问题，在网络不稳定的情况下更可靠，且连接建立更快，延迟更低。文章还引用 benchmark 数据佐证 HTTP/3 的速度优势。
文章提出了“双层网络”的概念，将互联网流量分为“超大规模网络”和“长尾网络”。前者指大型浏览器与少数头部公司（如 Google、Meta、Amazon）之间的流量，它们有充足资源和动力拥抱新技术，HTTP/3 在此快速落地。“长尾网络”则包括其他开发者、小型网站、移动应用、物联网设备等，它们依赖开源工具，更新迭代缓慢，对新技术的支持滞后。OpenSSL 对 QUIC 协议支持的策略加剧了这种分裂。OpenSSL 作为最流行的 TLS 库，其 QUIC API 迟迟不出，导致 HTTP/3 在开源生态中难以普及。
社区的讨论：运维角度、调试难度、技术选择 (.NET)
文章总结道，“双层网络”的差距可能带来严重后果。长尾网络或因无法使用 HTTP/3 而在性能上落后，新的 Web 技术可能忽略长尾需求，HTTP/3 的缺失甚至可能成为识别非浏览器客户端的特征，导致长尾客户端被排斥。作者对未来抱有希望，相信随着时间推移，外部库会成熟，OpenSSL 的问题也可能解决。但短期内，开发者若想使用端到端的 HTTP/3，仍需付出努力。
评论区围绕文章展开热烈讨论。有人从运维角度出发，认为在负载均衡层终结 HTTP/3，后端继续使用 HTTP/1.1 或 HTTP/2 更为简单高效，HTTP/3 和 IPv6 更适合移动网络，在数据中心优势不明显。但也有人反驳称 IPv6 在数据中心能减少开销，解决子网冲突问题。IPv6 普及的痛点，如基础设施支持不足、ISP 普及缓慢等也被提及。
HTTP/3 的调试难度也引发担忧，非明文协议增加了排错复杂度。有人提到 gRPC 选择了 HTTP/2，若当初选择 HTTP/1.1，可能更普及。当然，也有人反驳 HTTP/2 比 HTTP/1.1 更好。
评论中关于 .NET 技术的讨论颇为有趣。有人提到 .NET 实际上对 HTTP/3 有良好支持，但 .NET 和 C# 经常被低估。这引发了关于 .NET 是否过时、是否跨平台、是否开源的争论，甚至上升到对微软历史和企业文化的评价。有人认为 .NET 因微软的历史包袱而被低估，但也有人认为微软并未真正拥抱开源，.NET 的“开放”程度仍有限。
Rust + WASM 跳棋游戏引发技术与规则的双重讨论
Hacker News 上一个用 Rust 编写并编译为 WebAssembly 的跳棋游戏帖子引起热议。作者也现身评论区，可见这个小项目意外地受到了关注。
项目亮点与技术特点
帖子链接指向一个在线跳棋游戏，界面简洁，可在浏览器中直接运行。作者使用 Rust 语言编写游戏逻辑，并编译为 WASM，从而在浏览器中实现高效运行。评论中，有人赞赏这种基于属性的 WASM 绑定方式，认为代码结构清晰，只需一个简单的 HTML 文件即可运行。有人认为，与复杂的 Rust Web 框架相比，这种简洁性令人眼前一亮，甚至戏称 Dioxus 框架也需要一个“轻量版”。
社区的讨论：跳棋规则、项目误解
评论区最热闹的讨论围绕跳棋规则展开。许多用户在试玩后发现游戏规则与自己平时所玩的有所不同，例如不能后退吃子，或必须强制吃子。起初，许多人以为是游戏 Bug，后来才意识到是自己对正规跳棋规则不熟悉。有人贴出了国际跳棋规则链接，作者也更新了 README，补充了规则说明。大家这才意识到跳棋规则的细致之处，不同地区甚至家庭可能有各自的“家规”。有人戏称，每次玩跳棋都要先花时间协商规则。
更令人忍俊不禁的是，有人最初误以为该项目是类型检查器（type checker），因为英文 “checkers” 也有检查之意，点击链接后才发现是跳棋游戏，闹了个小乌龙。
总而言之，这个帖子引发了技术和规则两个层面的讨论，既展现了 Rust 和 WASM 在 Web 开发上的潜力，也意外地普及了跳棋的“正规”玩法，颇具趣味性。
Spectral JPEG XL：光谱图像压缩的新方案
本文探讨了使用 Spectral JPEG XL 技术压缩光谱图像，旨在解决光谱渲染中图像文件过大的问题。文章提出了一种针对光谱图像特性优化的新型压缩方法。
Spectral JPEG XL 的压缩原理
为有效压缩光谱图像，研究人员采用了在波长域进行余弦变换的技术。这种变换可以将光谱数据转换到频域，从而更好地利用 JPEG XL 的压缩能力。关键步骤在于，他们将高频傅里叶系数除以平均亮度（即零频系数），以降低高频系数的动态范围。这样做的好处是，可以更加重视感知上最重要的平均亮度信息，并对其进行高质量存储。对于高频部分，则可采用更高的压缩比，甚至降低分辨率，在保证图像质量的同时大幅减小文件体积。最终，所有系数图像均使用 JPEG XL 格式存储。
实验结果与优势
实验结果表明，Spectral JPEG XL 格式能够支持 spectral OpenEXR 的全部功能，且相比 ZIP 压缩的 OpenEXR 文件，文件大小可缩小 10 到 60 倍，压缩效果显著。
社区的讨论：实际应用、替代方案、libjxl 限制
评论区开发者主要围绕实际应用中的问题和替代方案展开讨论。有人表示，虽然希望使用 libjxl，但实际使用中发现编码器不太理想，最终选择了 TIFF 格式配合 lzw:2 压缩，认为 TIFF 格式更灵活。有人猜测，若使用 JPEG XL 的无损压缩模式，是否能更直接地解决问题。还有评论提出使用 ZSTD 压缩 TIFF 文件，以及将光谱图像的每一帧视为视频帧，使用 HEVC 视频编解码器进行压缩的思路，试图利用成熟的视频压缩技术。
JPEG XL 的开发者之一也参与讨论，强调有损压缩在大幅减小文件大小方面的必要性，并肯定了 JPEG XL 在每层图像进行不同缩放方面的能力。同时，有人指出当前 libjxl 库在实现上存在一些限制，例如在对每个子图像进行压缩参数调整方面的不足，这促使文章作者选择为每个通道单独使用一个 JPEG XL 文件，以获得更精细的控制。
总体而言，评论区既肯定了 Spectral JPEG XL 的潜力，也指出了实际应用中需要考虑的各种因素和权衡。