JPEG XL 与帕累托前沿
JPEG XL 被描述为一种高效的下一代图像编解码器，在压缩率和速度上都优于 JPEG、WebP、AVIF 和 PNG，并具备无损 JPEG 重压缩、渐进式解码、HDR 支持以及强大的无损性能等特性。评论者赞赏其近期在编码器和内存占用上的改进，但也指出，现实影响受到浏览器支持不一致、专利焦虑以及 Chromium 在事实标准形成中的主导地位所限制。普遍共识是，JPEG XL 在技术上令人印象深刻，对摄影、归档和专业工作流很有吸引力，但它在网页上的未来最终取决于主要厂商的采纳决策，而不仅仅是技术优劣。
浏览器支持与“守门人”
- 很多评论集中在 Chrome 在一个标志位后移除了 JPEG XL，并拒绝发布它，即使社区提出了请求。
- 有人认为 Chrome 的分支（Edge、Brave、Opera）可以通过启用 JXL 来形成差异化，但通常并没有这样做，这表明真正脱离 Chromium 的代价很高。
- Safari 已经发布了 JPEG XL；Firefox 被描述为“中立”的且资源受限，工作停滞在 nightly 版本。
- 有人担心 Chromium 的主导地位使其成为事实上的守门人；也有人回应说，市场份额并不意味着必须实现每一种格式。
专利、法律风险与安全性
- 讨论一个与 ANS 相关的 Microsoft 专利是否吓退了浏览器厂商；也有人反驳说它不适用于 JXL，而且这只是猜测。
- Apple 和 Adobe 发布 JXL 被引用为专利风险是可控的证据。
- 有人澄清，Cloudinary 和 Google 为其与 JXL 相关的专利提供免版税许可；剩余风险对任何较新的格式来说都很常见。
- 另一个担忧是：libjxl 是 C++ 写的，已经出现过内存安全漏洞；有人认为，未来会被广泛使用的新型复杂编解码器应该用安全语言编写。
已有一个 Rust 解码器，并且已经经过验证。
压缩质量与速度
- 无损：JXL 和 WebP 无损都很强；AVIF 无损普遍被批评，且常常比 PNG 更差。WebP 无损广受称赞，但仅限于 8 位和较小尺寸。
- 有损：在典型的网页质量下，JXL 往往优于 JPEG 和 WebP；AVIF 在低码率下可能更好。有人觉得低质量 JPEG 细节更多，但指出它使用了更多比特。
- JXL 编码器在 v0.10 中的改进显著降低了内存占用并提升了速度，尤其是多线程无损编码。
- 讨论焦点还包括如何绘制帕累托前沿，以及某些点是否被错误归类。
解码性能与用户体验
- 许多人认为，对于服务端场景（大规模编码），编码速度在经济上至关重要；在现代设备上，解码速度“已经足够好”。
- 渐进式/流式解码被认为比原始解码吞吐量更能改善用户体验；JXL 支持很强的渐进式解码，而 AVIF 不支持。
功能与生态系统
- 一个主要卖点是：JXL 可以无损重压缩现有 JPEG，并重建比特级完全一致的 JPEG，从而在不损失质量的情况下节省存储空间。
- 与 JPEG 兼容的编码器“jpegli”在保持 JPEG 兼容的同时带来了令人印象深刻的提升，强化了“老 JPEG 仍然有生命力”的观点。
- 工具链方面：人们希望更好地集成 JXL（例如在 libvips、ImageMagick 的版本中），并提到从 JXL 工作中分拆出来的 SIMD 库 Highway。
- 也仍有人怀疑：尽管技术上很出色，JXL 的采用速度仍然缓慢，现实世界中的使用仍远低于其宣传热度。