Add support for arithmetic-coded JPEG (standard feature, potential significant size savings)

[AlbertNashr]

Continuing from #274:

Arithmetic coding in JPEG is defined in the CCITT Recommendation T.81 (identical to ISO/IEC 10918-1) with T.81 Corrigendum 1 as part of the extended sequential and progressive processes. While it is not included in the baseline profile, it is a fully standardized feature of JPEG. In addition, ITU-T Recommendation T.851 with T.851 Corrigendum 1 later defined a baseline arithmetic coding process, further standardizing this mode.

Historically, arithmetic coding saw little adoption due to patent concerns, and many implementations focused exclusively on baseline Huffman coding. With the relevant patents long expired, the original barrier to adoption no longer applies.

Published estimates of the expected size savings vary. Some sources mention typical reductions of around 5–7% compared to optimized Huffman coding, while other reports suggest higher gains. For example, the Chromium issue Arithmetic coded JPEG support indicates savings of up to 16% compared to optimized Huffman coding and 19% compared to non-optimized Huffman coding.

In a recent local test, the savings were significantly larger for one test input. A 1200-dpi scan of an A4 page with black text on a light-green textured background was encoded using cjpeg -q 1 with three configurations:

• Arithmetic coding
• Optimized Huffman coding
• Default (non-optimized) Huffman coding

File sizes:

• input PNM file: 339,278,652 bytes
• output arithmetic-coded JPEG: 239,224 bytes
• output optimized Huffman-coded JPEG: 807,963 bytes
• output unoptimized Huffman-coded JPEG: 1,928,235 bytes

All three JPEG outputs had the same, subjectively sufficient visual readability. In this case, the arithmetic coding reduced the size by more than a factor of 3 compared to the optimized Huffman coding and more than a factor of 8 compared to the unoptimized Huffman coding.

While such gains may not be typical for all images, this example shows that arithmetic coding can provide very substantial size reductions in at least some cases.

Given that:

• arithmetic coding is standardized in T.81 and T.851,
• the patent situation is no longer a concern, and
• the potential size savings can be significant,

support for arithmetic-coded JPEGs would improve standards coverage and could provide meaningful benefits in some use cases. It would also help address downstream issues such as https://bugs.debian.org/1127449.

Thank you for considering this feature.

[etemesi254]

Hello, the problem is not even in the benefits or scope implementation, the problem is in the effort to return ratio.

1. I do not know how long it will take, it may be 2 weeks, or 2 months or even two years, it may introduce bugs/vulnerabilities/crashes which may require it to be fixed over time to be stable, and this is for a very obscure functionality in a format.

2. I am a bit busier this days than in the initial days of this project, I do enjoy working on the project still and doing research on many image features, and for it to continue, I need to find the joy to work on whatever feature I want to, adding arithmetic coding does not spark joy.

I am not against a PR implementing it, I will scrutinize it thoroughly but I do not see myself in the near future sitting down and writing it myself.

[AlbertNashr]

Thank you for the clarification. I completely understand the effort-to-return considerations and the need to focus on features that are personally interesting.

Regarding the description of arithmetic coding as ‘very obscure’, I assume this mainly refers to its limited presence in typical Web images and Web browsers. Historically, this was largely due to patent concerns rather than technical difficulty or lack of usefulness. The feature itself is part of the core JPEG standard (T.81 and T.851), and major tools such as ImageMagick and GIMP can handle arithmetic-coded JPEGs, so it does see some real-world use.

From a technical perspective, it is a relatively self-contained entropy-coding component. Compared to more modern formats such as JPEG 2000 or AVIF, the arithmetic coding used in JPEG is mathematically much simpler. That makes it closer to a focused algorithmic addition than a large architectural change.

You mentioned uncertainty about the implementation time. Rough estimates suggest that, for someone already familiar with the codebase, the effort could be in the order of a few weeks of part-time work rather than a long multi-month effort, although the actual time would, of course, depend on testing and hardening.

There may also be some practical downstream benefits. Since zune-image is used in projects such as GNOME's glycin/loupe and potentially other desktop components, support for arithmetic-coded JPEGs would improve compatibility with images that can already be handled by tools like ImageMagick and GIMP.

In any case, I fully understand if you prefer not to implement it yourself. I appreciate your openness to reviewing a pull request, and I would be grateful if the issue could remain open so that a future contributor could pick it up.

Thank you again for your work on zune-image.

Albert

[sophie-h]

Duplicate of #318?

[AlbertNashr]

@sophie-h Thanks for the pointer.

Issue #318 and this issue #350 are clearly related, since they both concern arithmetic-coded JPEG support. From my perspective, this issue was intended as a continuation and expansion of #274, with more background, references, and an example showing the potential size savings. While the underlying request is the same, the newer issue mainly adds context and motivation.

Regarding the note in #318: yes, in my own tests, GIMP was able to export arithmetic-coded JPEGs successfully. I observed that cjpeg produced an overall smaller file, but the important point is that arithmetic-coded images can indeed be produced with common tools.

If you prefer to keep only one issue open, that is of course fine. It might help if the the issue that remains open retains the additional context from #350, since that could help a future contributor understand the motivation and pick up the implementation.

In any case, thanks to both of you for looking into this.