为何JPEG XL无视位深(Bit Depth)堪称天才之举(而AVIF却无法做到)
常有人问我为何断言“JPEG XL是迄今构思最周全、最具前瞻性的图像格式，其他格式皆望尘莫及”。本文正是其中一个例证。
初闻JPEG XL编码器无视位深度(Bit Depth)时，我几乎觉得这是种鲁莽之举(甚至完全困惑)。在这个痴迷于8位、10位、12位精度之争的世界里，位深度难道不是根本要素吗？位数越多难道不是越好吗？
关键在于：忽略位深度并非缺陷。事实证明，这可能是现代图像压缩领域的绝妙设计决策。它揭示了JPEG XL与AVIF之间根本性的哲学差异，这种差异对图像质量、工作流程简化以及未来兼容性具有深远影响。
让我阐明为何这个“非特性”实则蕴藏着超能力。
症结所在：位深度仅是约定，而非现实
当Fractional初建JPEG XL社区网站时，我为各板块进行了数万次图像测试。当强制cjxl输出10位或12位图像时，生成的文件大小竟完全相同——这让我深感困惑。困惑之深，我甚至联系了Jon(JPEG XL项目的领军人物)，指出这显然是实现层面的缺陷。当他告知这是预期行为时，我的困惑可想而知。
在JPEG XL的无损编码器内部，所有图像数据都会转换为0.0至1.0之间的浮点数。不是整数，不是0-255的8位值，而是完整亮度的分数值。
无论原始数据源是8位JPEG、10位相机RAW、16位专业扫描，甚至32位浮点数据，都无关紧要。所有数据都会映射到相同的[0, 1]区间。编码器关注的是色彩的 意义，而非其在输入前的量化精度。
请思考这意味着什么：位数仅是文件格式约定，而非感知现实。
人眼并不在意渐变是通过256级还是1024级存储，它关注的是渐变是否 看起来 平滑。通过在连续浮点空间中工作，JPEG XL规避了传统编解码器面临的最大限制之一：对任意数字精度边界的依赖。
AVIF的困境
AVIF继承了其视频编解码器祖先(AV1)的架构，将位深度固化于设计之中。编码器处理整数采样缓冲区——通常为8位、10位或12位YCbCr数据，并高效压缩这些样本，但并未真正理解其底层色度含义。
这种局限源于早期数字视频系统——未压缩视频会以惊人速度消耗内存。为控制缓冲区大小和硬件成本，工程师采用最低位深度(及4:2:0等激进色度抽样方案)。这些硬件限制被固化进编解码器设计中，即便在现代系统拥有充足内存的今天，这种设计仍延续了几十年。
你正在编码8位图像？编码器会针对8位量化表进行优化。处理10位HDR？此时需要不同的编码决策、不同的优化策略，本质上需要切换编码模式。这形成了僵化的系统——编解码器必须在每个阶段精确知晓你使用的位深度。
编码器本质上处于“盲态”——它对数值施加有损压缩时，既不知这些数字代表HDR场景中的细腻阴影过渡，也不知它们是徽标中的平面色彩。它本应解决 感知保真度 问题，却在解决 数值精度 问题。
JPEG XL的颠覆性方案：浮点32位+感知意图
JPEG XL摒弃了位深度概念，转而采用亮度目标值——该参数默认设定为255尼特，代表纯白(1,1,1)应呈现的亮度水平。
这个感知锚点远比任意位精度重要，因为它描述了图像在人眼中的实际呈现效果。
随着现代显示器性能远超默认值，问题迅速变得复杂：
- 多数笔记本电脑在SDR模式下可达600-1000尼特
- HDR显示屏常突破1000尼特
- 专业参考监视器可达4000+尼特
采用JPEG XL格式时，您只需根据内容调整亮度目标值。编码器会自动将精度分配至感知关键区域。相同编解码器、相同工具、相同优化策略——仅需设定不同的感知目标值。
无需在8位模式与10位模式间切换。编解码器并不关心显示器的技术规格，它只需知道：“白色代表何种亮度级别？”其余参数皆由此推算。
XYB的秘密武器
这一理念得以实现，全赖JPEG XL采用XYB色彩空间——这是专为有损压缩设计的绝对感知驱动色彩空间，在内部处理中全面应用。
无论输入采用何种色彩空间(sRGB、Display P3、Rec.2020、ProPhoto RGB)，编码器都会在压缩前将所有数据转换为XYB格式。这意味着编码器始终 知晓 感知层面的 观察 对象。
编码器能基于人类视觉敏感度而非任意数值精度，智能分配比特资源。
无论源自8位还是16位数据，阴影细节中的平滑渐变都会被视为感知层面的重要信息。编码器直接针对人眼可辨别的范围进行优化，而非追求数字精确度的保留。
AVIF的盲点
AVIF在处理YCbCr缓冲区时，并不知晓其对应的RGB色彩空间。色彩空间处理发生在文件格式层面，而非核心压缩引擎内部。AVIF并非唯一存在缺陷的格式，它继承了JPEG XL之前几乎所有编解码器采用的相同基础方法。
编码器无法利用色度学知识实现更优感知优化。它压缩的是数字而非色彩，保存的是比特而非视觉。
在压缩对比测试中可见此弊端：当AVIF同时采用4:4:4与4:2:0配置且不同位深度时，每种配置本质上是不同的编码策略——因为核心引擎从未真正理解这些数字的 含义。
为何这对HDR(及暗部场景)至关重要
以下现实场景揭示了感知思维为何优于位精度思维：当在高亮显示环境下观察暗部图像区域——尤其放大至仅可见暗部时(此时眼睛已完全适应)——实际可感知细节远超传统8位编码所能呈现。
人眼具备自适应能力，而传统编解码器对此视而不见。
JPEG XL的感知编码法通过可调强度目标自然解决了这个问题。编码器可根据需求设定更明亮的观看环境，并相应分配精度资源。
反观AVIF这类专注位深的编解码器，无论观看条件如何，用户都只能受限于所选位深的精度上限。
核心要义
JPEG XL对位深的无视并非疏忽或简化，而是从数十年来将数字精度与感知质量混为一谈的累赘中获得的解放。
这标志着我们已超越“每通道多少位”的质量衡量标准，转向“在任何显示设备上，对所有人而言，呈现效果如何？”的全新维度。
受限于视频编解码器基因的AVIF，仍被整数采样缓冲区和特定位深度优化路径所束缚。它作为高效编解码器，专为网络规模的视频流优化而生。但其解决的问题与JPEG XL截然不同(且重要性存疑)。
对于摄影师、网页开发者、档案管理员以及所有关注跨内容类型与观看条件下图像质量的人而言，JPEG XL的方案令人耳目一新。
它减少了一项需要担忧的事项，并在关键领域呈现更优效果。
正因如此，这个看似不起眼的“非特性”实则是JPEG XL最卓越的创新之一。
2025-10-27 更新：本文灵感源自Jon(前文提及)在JPEG XL Discord社区 中描述的强度目标方法启发而成。这让我恍然大悟——真希望我能更早理解这个概念！我修正了部分内容，并删除了读者认为与文章核心观点无关的段落。
本文文字及图片出自 Why JPEG XL Ignoring Bit Depth Is Genius (And Why AVIF Can’t Pull It Off)
在Lightroom Classic中以JPEX XL格式导出图像时，可选择压缩百分比或无损模式(后者会禁用压缩功能)。默认设置为8位，但提供16位选项(当然会导致文件体积大幅增加)，同时包含色彩配置文件设置。因此好奇他们所说的“忽略位深度”具体指什么？
通过对比JXL 8位无损与JPG的样本导出，发现JXL文件明显更大。无论采用100%还是99%的压缩率，结果相同。当JXL压缩率设为80%或70%时，能明显节省空间，但原以为JXL的优势在于以更小体积实现全画质。
公平地说，70%质量的JXL与100%质量确实非常相似，但同样地，在苹果XDR显示器上，JPEG的70%与100%质量也几乎无异。不过在鞋面网眼布等细节处，无论是JPEG还是JPG XL的70%/80%质量设置，我都能观察到视觉差异。
JXL面临诸多兼容性挑战：尽管苹果采用后曾有起色，但进展似乎已停滞，Evoto、Topaz等众多应用均未添加支持。苹果至今仍未全面支持且毫无进展。除非Chrome再次转向，否则AVIF和JXL都将陷入停滞，多数用户仍会选择JPG。不过在TIFF格式方面，无损JXL相较TIFF能显著节省空间，这本应是理想应用场景，但TIFF文件更可能被第三方应用编辑，而这些应用很可能不支持该格式。
> JPEG XL的革命性方案：浮点32位+感知意图
所以是2^32位色深？4字节似乎有些过度设计。
文章提到位深度可达16位。HDR可能需要更多位数，精度处理也需额外位数。例如屏幕像素遵循指数强度曲线，但图像处理更适合线性模式。
不过我质疑浮点数是否必要，甚至相较32位定点数是否更优。浮点格式包含接近零的 次常数 数值，这可能导致精度严重过剩。某些处理器对次常数数值的运算效率极低，且无法完全禁用该功能。
你是否忽略了文章核心？JPEG-XL编码并非依赖量化实现性能目标。这类似于GPU着色器内部使用浮点运算，但为屏幕位深度输出量化值的机制。
顺便说一句，这种说法完全错误。JPEG-XL和其他有损编解码器一样，是在DCT变换后对系数进行量化。大多数编解码器在DCT阶段至少会进行一定程度的范围扩展，因此量化后的值可能比输入数据具有更高的位深度。
> 你是否忽略了文章的核心观点？
抱歉我没明白。那么.jxl文件中如何存储“浮点数”？
每个像素的Float32值总得以某种方式序列化吧？
简而言之，JPEG和JPEG XL并不编码像素值，而是编码二维像素网格的离散余弦变换(类似傅里叶变换)。因此实际存储的更像是像素变化的频率与幅度，而非单个像素值。其压缩原理在于：某些色彩变化的频率-幅度组合比其他组合更易被感知
补充说明：数据在内存中的表示形式可以是Float32，但存储到磁盘时需通过某种熵编码进行转换。通常前期处理步骤就是为熵编码做准备：通过完全可逆(无损)或近乎可逆(有损)的重排操作，使数据更适合熵编码。
不，JPEG并非位图格式。
存储的是梯度信息，而非梯度上的具体点位
确实如此，但为何不将同样的论点应用于分辨率？我认为应该这样做！
我完全赞同。根据我在图像放大、缩小和超分辨率处理方面的有限经验，降低视频分辨率是缩小文件体积的第二粗暴方式。
最粗暴的是对色度通道进行降采样——这对数字格式而言完全毫无意义。
确实如此！但AVIF基于AV1编码。作为视频编解码器，AV1常需通过专用硬件实现以兼顾成本与能效。我认为文中表述存在误导：“该限制源于早期数字视频系统”。不，这在当今视频系统中仍是显著限制。
个人认为，采用单一固定位深与位深无关性是两回事。色彩空间同样适用此逻辑。
他们通过为每个采样点分配32位来“忽略”位深问题。这或许是可行方案，但并非魔法。本质上只是分配了远超其他编解码器的位资源。
这种设计似乎也高度依赖CPU。若实现硬件编解码器，你会发现8/10位与32位方案的成本存在显著差异。这或许源于JPEG XL的预期应用场景？或者是我误解了JPEG XL的本质？
图像解码速度足够快，以至于无人使用硬件编码器。额外的位元在CPU和GPU上都极为廉价，通过内部使用这些位元，可防止内部计算累积误差，最终实现更优的尺寸与质量权衡。(需注意：在8位显示器上输出10位图像仍具价值，因其允许显示管理器对图像进行抖动处理)
有趣的思路。它甚至不会引入额外舍入误差，因为32位XYB转RGB的过程本质上类似于8位YUV转RGB。
不过当将8位质量的图像解码为10位或12位时，这种策略是否会导致最低两位被噪声填充？
可能产生噪声，但找到能平滑还原原始图像的近似值非常实用。视频播放器提到的去带状处理正是这个原理。
我不确定JPEG XL是否要求解决方案必须保持平滑。
我认为其约束为分段平滑(即不平滑边缘但会平滑噪点)
JPEG XL如此出色，独断专行的谷歌却执意推广劣质格式
Mozilla同样不愿支持该格式，不仅谷歌如此。我常看到吹捧JPEG-XL技术优势的文章，但根据我对常见网络图片尺寸的主观测试，AVIF每次都胜出。它不仅在中高压缩图像中产生更少伪影，且这些伪影更不显眼：相比JPEG-XL的块状失真和锯齿效应(叠加 细节损失；本质上与旧版JPEG相同类型的伪影)，AVIF仅出现轻微细节丢失和边缘平滑现象。
或许他们不愿支持XL格式，除了优先级错乱或懒惰之外另有缘由。
> Mozilla同样无意支持该格式
Mozilla其实很乐意采用它，只是不愿采用C++实现方案。他们已明确表示，待Rust实现方案达到生产就绪状态时会考虑采用。
https://github.com/mozilla/standards-positions/pull/1064
现存的Rust实现远不止一种
– https://github.com/libjxl/jxl-rs
– https://github.com/tirr-c/jxl-oxide
– https://github.com/etemesi254/zune-image
等等。你可以再等上二十年“以求万无一失”，或者现在就行动起来。Mozilla在此选择方案A——无所作为
jxl-oxide开发者即jxl-rs开发者。jxl-oxide仅支持解码，而jxl-rs是完整的编码/解码库。
zune同样使用jxl-oxide进行解码。zune拥有编码器且开发成果卓越，但其编码器存在线程安全问题，无法满足Mozilla需求。
目前已有团队着手将 jxl 实现与 Firefox 深度集成，但坦白说这需要时间。
若您真心渴望在 Firefox 中看到 JPEG-XL，其实存在极简方案：贡献代码。开源项目投入的工程时间越多，实现目标的速度往往越快。
您对“考虑”一词的解读实在令人费解。
在我看来这完全是正常用法。上文列举了除Rust实现外需满足的其他条件，这才是需要考虑的因素。
Mozilla表示在满足若干前提条件后愿意考虑此事。GP将其解读为“非常乐意采用”，这绝非正常理解范畴。
根据链接原文：
这已是极其明确的立场。
若Chrome对JPEG-XL不感兴趣，Rust版本距离谷歌的版本还有多远？
可在此处查看详情：https://github.com/libjxl/jxl-rs
该项目似乎正处于高度活跃的开发阶段。
现在我对不再使用火狐浏览器没那么愧疚了。不用它是因为它是C++写的，这简直是<此处省略可能不受欢迎的词汇>
所以你觉得在电脑上最重要的软件(网页浏览器)中，不愿引入可能被远程利用的新漏洞(CVE)是愚蠢的？还是说你暗示那十万行多线程C++代码毫无漏洞，绝不会引入新CVE？
真疯狂——人们竟以为用Rust就能让代码神奇地零漏洞零缺陷，却不觉得程序员比语言本身更该为这些问题负责…
> 却不认为程序员比语言本身更应为这些问题负责
这让我联想到年轻时对单元测试和类型检查的幼稚认知，也呼应了无数工匠在失去肢体前谈论安全规程的论调。
安全机制无法抵御糟糕的程序员。但它们能极大程度保护你免受优秀程序员不可避免的失误所害。
反Rust人士竟认为：仅凭使用内存安全的语言(未必是Rust)就能构造性地消除70%的安全漏洞[1]，这种观点简直荒谬至极——他们竟觉得这是坏事或不值得做。
[1] – https://www.chromium.org/Home/chromium-security/memory-safet…
重点不在于完全无漏洞。安全的Rust将能有效抵御可被利用的解码器漏洞——这类漏洞可能转化为远程代码执行漏洞。相比普通C++中的漏洞，安全Rust中的漏洞要难得多才能转化为实际攻击手段。
> 令人匪夷所思的是，竟有人认为使用Rust就能让代码神奇地毫无漏洞和安全隐患
它无法让所有代码免于漏洞，但确实能让处理不可信输入的代码几乎零漏洞。虽非百分百万无一失，但Rust解析库在此领域的表现远胜C/C++库，且通常运行速度更快。
这算不算稻草人谬误？
多年来针对浏览器的多次严重攻击都瞄准了图像解码器。要求用内存安全的语言实现解码器在我看来非常合理，这让我使用FF时更安心。
这并非单纯“C++有问题”，而是“我们不愿在处理不可信内容的用户直接交互代码中应对内存错误”。
这完全是合理立场。
最近为搭建基准测试平台做过调研，试图厘清现状。过去一年左右似乎已出现转变。
笔记中的一些链接：
https://www.phoronix.com/news/Mozilla-Interest-JPEG-XL-Rust
https://news.ycombinator.com/item?id=41443336(讨论Phoronix网站提及的同一条GitHub评论)
https://github.com/tirr-c/jxl-oxide
https://bugzilla.mozilla.org/show_bug.cgi?id=1986393 (初始化jpegxl Rust代码时禁用预处理功能)
若有人感兴趣，以下是我阅读时参考的基准测试：
https://op111.net/posts/2025/10/png-and-modern-formats-lossl…
不，图像压缩的现状并未改变。你回复的Grand Poster讨论的是典型网页应用场景，即“中度至高度压缩的图像”，而你的基准测试针对的是无损压缩。
顺便说一句，我不明白Mozilla对jpegxl解码器(你提供的第一个链接)的关注，与jpegxl编码器相较于avif编码器的性能有何关联。若你真关注前者，Firefox目前已不止于意向阶段，但仍未投入生产环境：https://bugzilla.mozilla.org/show_bug.cgi?id=1986393
不，demetris的无损图像压缩基准测试并不意味着现状可能改变。:-D
这只是我为了解当前进展而阅读资料时的背景信息。
> 顺便说一句，我不认为Mozilla对jpegxl解码器(你提供的第一个链接)的兴趣与jpegxl编码器相较于AVIF编码器的性能有何关联。若你真关注前者，Firefox目前已不止于意向阶段，但仍未达到生产级别：https://bugzilla.mozilla.org/showbug.cgi?id=1986393
那是我在评论中分享的链接之一(括号里还标注了漏洞标题)。:-)
我在AVIF与JPEG-XL的对比中却得到了完全相反的结果。发现低码率下jxl的性能表现远超AVIF。
我在测试和部署多个同时支持两种格式的网站时也有相同体验。总体而言，AVIF仅在质量设置低到可笑的程度时(远低于任何普通用户或平台的选择)才能在文件大小上胜出。
尤其对于大文件而言，渐进式解码的实际优势更让我倾向于选择JPEG-XL。当能通过任意中止比特流来提供不同尺寸的图像变体时，这种优势更是加倍凸显。
JPEG-XL针对低至零压缩率进行了优化，虽然这种压缩方式在网页中并不常见，但确实满足了特定需求。
谷歌以改进不足为由拒绝采用，此说法颇为模糊。Mozilla则更关注其攻击面问题。
JPEG XL似乎最适合媒体存储与档案保存用途，而如今这类需求主要通过网络应用实现。即便维基共享资源这类基础应用，在该领域仍基本依赖JPEG格式。
基于相同原因，未来PDF/A标准修订版若能纳入JPEG XL将大有裨益——该标准目前缺乏优质的低损(非无损)压缩编解码器(例如JPEG在处理色彩示意图/图纸时表现欠佳，而无损压缩又因体积过大难以实用)。虽然已引入JP2，但其支持度仍相当有限。
>但在针对网页常见图像尺寸的主观测试中，AVIF每次都胜出。
这对应多少bit/pixel？据谷歌Chrome统计，80-85%的网页图像bit深度达1.0或更高，多数人对此并不知情。
专业测试表明，在1.0及以上bpp条件下，JPEG XL几乎在所有场景都优于AVIF。
真希望他们把无损编解码器独立为“WebPNG”。WebP虽优于PNG，但若因设置疏漏导致无损格式变为有损，这种风险实在不值得承担(更别说推荐他人使用)。
我觉得这篇文章可以更精炼些，篇幅减半就能更清晰地传达核心观点。后半部分不该堆砌AI生成的优势列表，不如用那部分空间补充更多技术细节。
如果整篇文章不是完全“AI生成”的话，质量会更好。
至少前半部分还算有点用…
或许我们可以让AI将其总结回原始提示以节省时间。
> 找出生成本文的(最小化)AI提示：[…]
可能生成本文的最小AI提示可能是：
“撰写一篇技术博客文章，比较JPEG XL和AVIF图像格式，重点阐述JPEG XL基于浮点数的位深度无关编码如何优于AVIF的整数编码方案，着重强调感知质量、HDR处理能力和工作流程简便性。”
该提示涵盖核心要素：
– 两种图像格式的技术对比
– 聚焦JPEG XL独特的“忽略位深度”设计
– 强调感知质量与数值质量的差异
– 探讨HDR处理与工作流程优势
– 语气结构与已发布文章一致
该提示将引导AI生成符合以下要求的内容：
1. 阐释编码方法的技术差异
2. 论证JPEG XL方法的优越性
3. 提供对用户的实际应用价值
4. 保持作者的行文风格与技术深度
5. 遵循原文结构，突出“感知意图”优先于位精度的核心理念
这简直太元了——我们正用AI生成提示词，AI产出内容，再用AI复刻生成内容的原始提示词，如此循环往复。最终陷入螺旋式混乱，形成连真人都无法解读的垃圾文本。
不久之后，AI将发明一种与自身实例或其他AI交流的格式，以便传递信息供客户端AI翻译回用户的个人消费偏好。当网站能被压缩成几千字节的提示符，由AI引擎生成完整内容、图像、视频等时，谁还需要压缩或图像优化？
> 撰写短文阐释JPEG XL的精妙之处在于其无色深限制的设计：将所有图像数据转换为感知基浮点格式(XYB)，从而针对人眼实际感知效果优化压缩。反观AVIF受制于视频编码遗产，被迫采用僵化的整数位深度模式，这种模式优化的是数值精度而非真实感知质量。
你凭什么断定这是AI生成的？或许只是我在不熟悉领域中的邓宁-克鲁格效应作祟，但这篇文章的技术深度和叙事连贯性远超AI的常规能力。
文章主要在重复浮点数替代整数表示的论点，并通过不同标题(根号解法、为何重要、秘密武器、哲学、最终结论)将几句话的内容拉伸成数页篇幅。
AI偏爱这种格式，是因为它在生成式AI出现前就很流行。这正是《Slate》杂志等媒体惯用的点击诱饵式“智能”文章模板。
但由于涉及HighestNetWorth读者群感兴趣的主题，这类文章反而能获得赞同票，不像那些网站的内容。因此许多读者通过这些文章重新接触到这种格式。
十年前我们已遭遇过垃圾文章/列表式文章的侵扰，所幸精心筛选的网络内容过滤机制让我们得以规避(但老一辈用户通过Facebook等平台仍会接触到)。如今它们卷土重来，更因人工智能的助力，无需真正懂行的人撰写面向红帽用户群的文章(毕竟懂行者本就拒绝写垃圾内容…但愿如此)。
抛开格式与标题不谈，AI写作中充斥着大量 本地化 的修辞花哨手法和模式，这些特征远比普通低质列表文章更显著——后者不过是刻意吸引你注意力，让你在移开鼠标关闭新闻弹窗时，不小心点开其中一个自动播放的视频。
你心知肚明：这既非 形容词1 也非 形容词2——实则是再普通不过的顿悟！请细细品味——顿悟的重述。重述。顿悟。核心优势：五点式项目符号列表配以精炼加粗标题，随后紧接零新信息。换行。作为惊喜，轻微却终归无意义的反衬，旨在人为强化论点！但矛盾在于——好吧，我实在写不下去了。你懂的。
第一个“并非”之后的内容完全多余，且这种多余性相当明显。
遵循相同逻辑模式。
此处的模式难以言传，但对我而言整体构成单一刺激。至少请注意：论述反复以不同名称和属性重复反驳对象，却无实质语义依据，随后又以精炼的表述重申核心论点。
这类积极、精炼、可引用的结论句式，正是前沿大型语言模型最热衷生成的内容，其特定表述形式亦是如此。类似“冲突已非政治层面的——而是存在层面的”这类句式同样体现了这种特征。
我本承诺不再纠结于小动作、排版等这类确凿证据，但若此生再也不必目睹这段可恶的字符序列……