JPEG-XL:有多少种 VarDCT 实现？

Question

我正在查看以下看似无辜的命令行:

% cjxl flower.png flower.jxl
[...]
Encoding [Container | VarDCT, d1.000, effort: 7 | 3332-byte XMP], 

使用完全相同的源代码但在不同的体系结构上编译，这是我观察到的:

<表类="s-表"><头>Debian 架构JPEG XL 编码器 v0.7.0压缩字节<正文>amd64[AVX2,SSE4,SSSE3,未知]压缩为 450659 字节，包括容器 (1.051 bpp)。arm64[ NEON ]压缩为 450660 字节，包括容器 (1.051 bpp)。武器[未知]压缩为 450828 字节，包括容器 (1.052 bpp)。 ARM hf[ NEON ,未知]压缩为 450664 字节，包括容器 (1.051 bpp)。i386[SSE4,SSSE3,未知]压缩为 450678 字节，包括容器 (1.051 bpp)。ppc64el[未知]压缩为 450858 字节，包括容器 (1.052 bpp)。

我了解，对于有损压缩，一致性阈值是根据每个样本的 RMSE 和峰值绝对误差定义的。这些阈值是非零的，以允许实现以尽可能最好的方式使用 SIMD，这可能会导致非常轻微的不同结果(显然没有任何可见的差异)。

但是在这种情况下似乎至少还有另一个因素:armel和 ppc64el似乎默认为非 SIMD 代码路径，但它们会产生不同的输出。

因此我的问题是:有多少 VarDCT 实现？

---

供引用:

% file flower.png
flower.png: PNG image data, 2268 x 1512, 8-bit/color RGB, non-interlaced

Answer 1

我认为(编译器、编译器版本、CPU 架构)的每种组合都可能导致(略微)不同的结果。简单到

float a = b * c + d;

最终可能会被编译成非常不同的指令，导致最终结果略有不同，例如融合乘加法比先乘法再加法稍微精确一些；在没有浮点运算的旧平台上，结果可能仍然不同；编译器可能会重新排序或自动矢量化导致略有不同的结果。

soft-float 和 hard-float 之间的 160-190 字节差异似乎有点大，可能值得研究为什么会有如此大的差异。 armel 和 ppc64el 之间的差异可能是由各自的 soft-float 实现的差异引起的，通常编译器创建的代码会有所不同，因为它们不相同平台。

明确一点:一致性只是关于解码，而不是编码。只要编码器产生有效的比特流，它们就可以为所欲为——一致性规范没有说明任何关于编码的内容。唯一具有一致性容差的是解码比特流的结果，我们确实希望保证解码器的各种实现(包括 libjxl 的各种版本和构建)之间的解码图像差异非常小。

在编码器中，即使在进行无损编码时，比特流大小也会有一些差异。原因是一些编码器试探法是使用 float 实现的，稍微不同的结果会导致不同的选择，这会对比特流大小产生相当大的影响，例如如果最终使用略有不同的上下文模型，即使实际图像数据相同，它也会在比特流大小上产生差异；在进行有损时，在选择 block 大小和类型或自适应量化权重的方式上也可能会略有不同，这可能会导致图像数据和比特流大小的差异。