Package: firefox-esr
Version: 115.9.0esr-1~deb12u1
Severity: wishlist
In the upstream issue report on this, https://bugzilla.mozilla.org/show_bug.cgi?id=680385 https://bugzilla.mozilla.org/show_bug.cgi?id=680385, the last statement 38 contains “webp probably compresses just as well if not better”. This is extremely wrong in my tests for a file of mine. As I don't have sufficient rights in bugzilla, I ask someone who has sufficient rights to comment there and, if possible, reopen the upstream issue report.
Here's my test. My original file, a nonpublic (sorry about that) portrait photograph, is of size 1483651 bytes. The goal was to compress it as much as possible with GIMP in 1 pass such that the face is still recognizable; we allow color artifacts and a heavily rasterized image. Here are the test results (the first column is the size in bytes, the second column is the format and the settings used for saving):
35623 JPEG, 4:2:0 subsampling, integers
35619 JPEG, 4:2:0 subsampling, float-point numbers
35618 JPEG, 4:2:0 subsampling, fast integers
35254 JPEG, 4:2:0 subsampling, full aliasing, integers
35252 JPEG, 4:2:0 subsampling, full aliasing, float-point numbers
35248 JPEG, 4:2:0 subsampling, full aliasing, fast integers
25656 WEBP, Photo
25484 WEBP, Picture
25364 WEBP, Default
25342 WEBP, Drawing
20720 WEBP, Icon
20720 WEBP, Text
7892 JPEG, arithmetic encoding, 4:2:0 subsampling, full aliasing, integers
7891 JPEG, arithmetic encoding, 4:2:0 subsampling, full aliasing, floating-point numbers
7879 JPEG, arithmetic encoding, 4:2:0 subsampling, full aliasing, fast integers
Of course, we used quality 0 in all places.
As we see, the smallest JPEG file created with the arithmetic encoding blows
- the smallest file created with a WEBP encoding by a factor of around 2.6 and
- the smallest JPEG file created without the arithmetic encoding by a factor of around 4.5.
Also, both epiphany-browser and chromium do show this smallest file created with the arithmetic encoding (and the face on the compressed image is still recognizable).
In my view, both news together (astonishing file-size ratios and support in other browsers) is sufficient at least to reopen the issue report closed 4 years ago (regardless of how to resolve this and who would do this).

severity 1067549 normal
thanks

I would like to express support for enabling arithmetic-coded JPEG (DAC) image decoding in Firefox as shipped in Debian.

Recent practical experiments demonstrate that arithmetic coding can provide very substantial file size reductions compared to optimized Huffman coding for certain document-scanning scenarios. In particular, high-resolution scans of pages with large areas of uniform background and relatively small amounts of text benefit dramatically when encoded at very low JPEG quality.

In the following Debian bug reports, a real-world example is described where arithmetic coding reduces file size by a factor exceeding 3.3 compared to optimized Huffman coding (the original file is not publicly disclosed for privacy reasons): http://bugs.debian.org/1127449 and http://bugs.debian.org/1007710.

Additionally, in the upstream issue https://github.com/etemesi254/zune-image/issues/350, an empty scan is reported where the size reduction factor is ≈ 655: https://github.com/etemesi254/zune-image/issues/350. That issue also provides a direct link to an arithmetic-coded JPEG sample file.

To provide a clean and reproducible test case, the following example was constructed:

1. A grayscale A4 page at 1200 dpi was created using GIMP, containing black text “This is a test” (font: Sans-serif, size 3000) on a white background. This simulates a high-resolution scanned page with relatively little text.

2. The image was exported to JPEG in two ways:
   a. Directly from GIMP:
     • DCT method: float
     • Quality: 0
     • Arithmetic coding enabled versus optimized Huffman coding enabled
   b. Via a PGM intermediate followed by `cjpeg` with:
     • `-dct float`
     • `-q 0`
     • `-arithmetic` versus `-optimized`

File sizes obtained:
• This_is_a_test.png: 303067 bytes.
• This_is_a_test.pgm: 139197502 bytes. (The PGM file is too large for the Debian BTS; it can be regenerated from the PNG using ImageMagick or GIMP.)

cjpeg outputs:
• This_is_a_test.cjpeg.arithmetic.jpg: 23543 bytes.
• This_is_a_test.cjpeg.optimized_Huffman.jpg: 554463 bytes.

Direct GIMP outputs:
• This_is_a_test.GIMP.arithmetic.jpg: 46035 bytes.
• This_is_a_test.GIMP.optimized_Huffman.jpg: 584237 bytes.

For the `cjpeg`-generated files, resolution metadata was set afterward using `exiftool`. The GIMP-generated files contain resolution metadata from export.

The resulting size reductions are:
• ≈ 24× for cjpeg output
• ≈ 13× for GIMP output

These savings are no longer marginal (as often characterized in discussions from the 1990s) and are clearly substantial for document-oriented workflows.

Importantly, these files are fully standards-compliant JPEG images using arithmetic entropy coding (ISO/IEC 10918-1). The relevant patents have expired, and decoder implementations are well understood. Within Debian, browsers such as Chromium and Epiphany can already display arithmetic-coded JPEG images.

Given the potential for significant bandwidth and storage savings in real-world document scanning, enabling arithmetic-coded JPEG decoding in Firefox would improve standards compliance, interoperability, and efficiency.

For these reasons, I respectfully request that support for arithmetic-coded JPEG images be added to Firefox in Debian.

Thank you for your consideration.

The commands

magick -density 1200 "41568-pdf.pdf[2]" -quality 1 -define jpeg:arithmetic-coding=false -define jpeg:optimize-coding=true -define jpeg:dct-method=float -colorspace Gray -depth 8 Whitehead.magick.optimized_Huffman.jpg

magick -density 1200 "41568-pdf.pdf[2]" -quality 1 -define jpeg:arithmetic-coding=true -define jpeg:dct-method=float -colorspace Gray -depth 8 Whitehead.magick.arithmetic.jpg

magick -density 1200 "41568-pdf.pdf[2]" -colorspace Gray -depth 8 Whitehead.magick.pgm

cjpeg -q 0 -grayscale -optimize -dct float -outfile Whitehead.cjpeg.optimized_Huffman.jpg -report -strict -verbose Whitehead.magick.pgm

cjpeg -q 0 -grayscale -arithmetic -dct float -outfile Whitehead.cjpeg.arithmetic.jpg -report -strict -verbose Whitehead.magick.pgm

dpi=1200 && exiftool -overwrite_original -JFIF:XResolution=$dpi -JFIF:YResolution=$dpi -JFIF:ResolutionUnit=inches Whitehead.cjpeg.arithmetic.jpg

dpi=1200 && exiftool -overwrite_original -JFIF:XResolution=$dpi -JFIF:YResolution=$dpi -JFIF:ResolutionUnit=inches Whitehead.cjpeg.optimized_Huffman.jpg

produce the following files:

• Whitehead.magick.pgm: 42120017 bytes
• Whitehead.cjpeg.arithmetic.jpg: 25742 bytes
• Whitehead.cjpeg.optimized_Huffman.jpg: 182812 bytes
• Whitehead.magick.arithmetic.jpg: 68647 bytes
• Whitehead.magick.optimized_Huffman.jpg: 240160 bytes

The savings exceed 7.1× for cjpeg and 3.4× for magick.