
互联网的核心目标一直是追求更快、更高效的信息传递。而图片作为重要的媒体资源,自然就成为了优化的重点。
目前,主流的图片格式包括 JPEG、PNG、WebP、HEIF 和 AVIF 等。现在,一种新兴的图片格式——JPEG XL 正在崛起,它的目标是全面超越现有格式,成为更强大的数字图像编码、存储和压缩解决方案。
苹果公司已经率先全面支持这一格式,这可能会推动 JPEG XL 成为新的行业标准。
什么是 JPEG XL 图像格式?
JPEG XL 是一种图像压缩格式,旨在改进传统格式(如 JPEG、PNG 和 WEBP)的性能。它基于 Google 的 PIK 和 Cloudinary 的 FUIF 图像格式研发而成,目标是显著提升压缩效率,同时保持极高的图像质量,使其在互联网应用和专业摄影领域中都能游刃有余。

与传统格式相比,JPEG XL 的压缩能力令人惊艳。例如:
- 在视觉质量相同的情况下,文件大小比 JPEG 小约 60% ;
- 对于无损 JPEG 转码,文件体积可以减小约 20% ;
- 相比 PNG,文件大小可减少约 35% (对于 HDR 图像,甚至高达 50% )。
以上数据表明,JPEG XL 在减小图像文件体积方面具有显著优势。如果你想更直观地了解这种差异,可以参考 JPEG XL 与其他格式的对比示例。更重要的是,JPEG XL 还具备「向后兼容性」,不用担心跟现有系统不兼容。
- JPEG XL 于 2018 年首次推出,技术源自于 Google 的 PIK 和 Cloudinary 的 FUIF 整合。在诞生后的几年里,就逐渐被主流浏览器和技术堆栈所支持。
- 2022 年时,JPEG XL 已经被添加到了 Chrome 和 Firefox。然而,Chrome 后来移除了对 JPEG XL 的支持,原因是开发团队认为其应用前景有限。
- 截至目前,此格式已被 Safari、最新的苹果设备、Linux 系统、安装了 JPEG XL 插件的 Windows 11 24H2,以及 GIMP、Krita 和 Adobe Lightroom 等创意软件所支持,正在被越来越多的用户群体接受。
JXL 文件扩展名
- JPEG XL 图像使用了
.jxl
作为文件扩展名。不过,由于还没有被广泛普及,很多「图像查看器」暂时无法直接显示 JXL 图像。 - 要打开 JXL 图片或对比与其他格式的画质差异,你可以使用一些支持 JXL 的工具,比如 Darktable、Affinity、Photoshop 和 Lightroom。
JPEG XL vs. JPEG vs. PNG
JPEG XL 在文件大小与画质之间实现了优异的平衡。与传统的 JPEG 相比,可以:
- 在保持相似甚至更高图像质量的前提下,将文件大小缩减 20%-30% 。
- 在处理「压缩伪影」方面表现得更加出色。JPEG 为了大幅压缩文件大小,往往会引入明显的伪影,严重影响图像质量。
- 同时支持「无损压缩」和「有损压缩」。在与无损压缩的 PNG 对比时,JPEG XL 的无损文件通常要更小,而且图像质量也能与 PNG 媲美。
- JPEG XL 支持「透明通道」,并提供更高的「色彩深度」。这在处理复杂图像时尤为重要。再加上更小的文件体积,这种优势可能会让 PNG 在互联网中的使用逐渐减少。
JPEG XL 甚至超越了 Google 推出的 JPEGLI,尽管后者也以高质量压缩为卖点。但在更高的压缩比下,JPEG XL 仍能保留更多图像细节,表现得也更加出色。
JPEG XL vs. WebP
在当今的互联网环境中,WebP 已经成为了许多网站的首选图像格式。WebP 和 JPEG XL 也都提供了出色的有损压缩性能,图像质量也几乎不相上下。
- JPEG XL 凭借更高的压缩效率和更出色的色彩深度,在整体性能上要略胜一筹。
- 不过,WebP 在编/解码速度上仍要比 JPEG XL 略快一点。
因此,如果仅从网页加载速度的角度来看,要全面转向 JPEG XL 格式可能还要熬一些时间。
JPEG XL vs. 其他格式:基准测试与实际效果
要更直观地了解 JPEG XL 相比其他图像格式的改进,我们可以参考来自 Cloudinary 和 Fastly 的基准测试结果。
以下是使用 ssimulacra2 工具得出的一组测试结果。展示了将 PNG 转换为 JPEG XL 后的压缩效果,并与其他格式(如 JPEG、AVIF 和 WebP)进行了对比:
- 图中,Y 轴表示编码时间(单位:毫秒),X 轴表示文件大小。
- 结果显示,JPEG XL 几乎在所有情况下表现最好,压缩效率遥遥领先。WebP 紧随其后,AVIF 和 JPEG 分别位列第 3 和第 4。

不过,在编码时间方面,情况有所不同。WebP 的编码速度有时明显快于其他格式,而 JPEG XL 和 AVIF 的编码时间相近。但总体来看,AVIF 的编码速度略有优势。

JPEG XL vs. 主流图片格式:全面对比
尽管 JPEG XL 的支持范围还没有全面覆盖所有平台和应用,但随着支持力度的增加,我们有理由相信,它将被更多主流平台所采纳。
目前,JPEG XL 已经获得了相当多软件的支持,包括 GIMP、Adobe Lightroom、Krita、FFmpeg、ImageMagick,以及开启实验标志(flag)模式的 Firefox 和 Edge。
特性对比表
功能特点 | JPEG XL | PNG | JPEG | WebP |
---|---|---|---|---|
压缩类型 | 有损和无损 | 无损 | 有损 | 有损和无损 |
压缩效率 | 最高 | 高 | 中等 | 高 |
图像质量 | 优异 | 100%(无损质量) | 良好 | 优异 |
色彩深度 | 24 位整型或 32 位浮点 | 8 位和 16 位 | 8 位 | 8 位和 12 位 |
支持透明通道 | 是 | 是 | 否 | 是 |
文件体积 | 最小 | 中等 | 小 | 小 |
JPEG XL 的优劣势解析
尽管相比 JPEG 和 WebP,JPEG XL 拥有明显的优势,但它还是存在一些不足。
优势 | 劣势 |
---|---|
出色的压缩性能,几乎不损失画质 | 支持范围仍然有限 |
同时支持有损和无损压缩 | 无损压缩的文件体积可能依然偏大 |
解决了 JPEG 压缩后常见的色带问题 | 编/解码速度相对竞品并非最快 |
更宽的色域带来更加鲜艳生动的色彩 | |
支持透明度和动画效果 | |
开放、免费且无专利限制 |
谁在阻碍 JPEG XL 普及?
是谁在阻碍 JPEG XL 的普及?这是一个值得深思的问题,答案是——「垄断力量」对技术发展的负面阻碍。
- 早在 2022 年,Chrome 开发团队就突然移除了对 JPEG XL 的支持,给出的理由是——认为这种格式并非未来的发展方向。据称,JPEG XL 的开发者之一 Jon Sneyers 被告知,Chrome 团队基于一些测试结果,断定这项技术不值得进一步投入。
- Jon Sneyers 指出,Chrome 团队的测试存在一些明显的漏洞,但这些反馈却被有意忽视。由于 Chrome 目前处于「主导浏览器」的地位,其对 JPEG XL 的抵制直接遏制了这种新格式的普及速度。直到苹果在其生态系统内全面支持 JPEG XL,这种情况才有所缓解。
- 在 2024 年,由苹果和 Google 等浏览器巨头共同主导的 Interop 项目中,JPEG XL 获得了 646 的高票支持,远超其他竞争对手。但令 JPEG XL 开发团队意外的是,他们的提案仍未入选。有传闻称,又是 Google 作为「反骨仔」对提案表示了反对,从而导致没有采纳。
JPEG XL 或将成为社交媒体的下一场革新
苹果正在积极推动在他们所有设备上采用 JPEG XL。鉴于它的诸多优势,很可能会取代 JPEG,成为社交媒体上的主流图片格式。随着苹果宣布全面支持,JPEG XL 的普及速度无疑将会大大加快。
JPEG XL 能够在提供更高压缩比的同时,保留图像的细节和色彩深度。而社交媒体平台以展示生动、色彩鲜艳的图像为核心,JPEG XL 又提供了更出色的色彩深度和更好的图像质量。因此,问题已经从「是否会成为主流」变成了「何时会成为主流」。
当别家都开始用 JPEG XL 降本增效时,再有人出来「跳反」,不知道会不会被历史的滚滚车轮给碾死。
最新评论
1.你贴的方法我没测试,如果有效,也只适用于个人或小规模使用,不具备普遍性。 2.根据微软最佳实践,是建立一个本地帐户专门用来远程连接。 3.在域环境中,不存在使用 Microsoft 帐户的情况。
关于rdp无法连接win11微软账户的问题 有很简单的解决办法 不需要退出微软账户或者重置之类的 在中文互联网搜索到的教程内容一般是使用MicrosoftAccount\邮箱作为用户名 密码填微软账户密码然后链接 但是这有个问题就是如果服务端(被控端)本身无缓存时将无法链接 改用英文在google搜索后发现了这样一篇微软社区问答 https://answers.microsoft.com/en-us/windows/forum/all/remote-desktop-not-working-with-microsoft-account/71f0c323-688a-4c97-8740-e80eb31ae11d 打开cmd终端后输入runas /u:MicrosoftAccount\你的邮箱 winver并回车 在出现类似输入MicrosoftAccount\xxx@xxx.com:的密码的文本时输入你的微软账户密码并回车(密码不会显示) 如果密码正确 稍后你将会看到一个Windows关于信息框 关掉它既可 这条命令的意思是 以xxx@xxx.com的身份运行winver程序 在完成后它即可以在本地生成关于该账户信息的缓存 接下来即可在客户端(控制端)输入对应地址链接 用户名为MicrosoftAccount\你的邮箱 密码为微软账户密码 如果一切顺利 在建立连接后 即可弹出证书验证框(如果以前从未链接此计算机) 确定即可 稍等即可进入远程桌面 对于伸手不看理论党的直白概括: 被控端: 打开运行框输入cmd回车 在cmd输入runas /u:MicrosoftAccount\你的邮箱 winver并回车 在出现新的文本时输入微软账户密码并回车(密码不会显示的) 关闭新弹出的窗口及cmd 控制端: 打开rdp客户端 输入计算机的地址回车 用户名:MicrosoftAccount\你的邮箱 密码:微软账户密码 回车后保存证书即可链接 您好,这是我转自B站的评论,不知道这个方法是否具有普遍性来辅助我们用同一个账号进行远程控制
没有用哦,
应用安装失败,错误消息: 从 (Microsoft.NET.Native.Framework.2.2_2.2.29512.0_x64__8wekyb3d8bbwe.Appx) 使用程序包 Microsoft.NET.Native.Framework.2.2_2.2.29512.0_x64__8wekyb3d8bbwe 中的目标卷 C: 执行的部署 Add 操作失败,错误为 0x80040154。有关诊断应用部署问题的帮助,请参阅 http://go.microsoft.com/fwlink/?LinkId=235160。 (0x80040154) 大佬看看怎么解决