Bug#1127449: Please add support for arithmetic-encoded JPEGs to loupe

[Albert Nash]

Package: loupe
Version: 49.1-1
Control: affects -1 glycin-loaders
A traditional example of a JPEG created with arithmetic encoding is https://issues.chromium.org/action/issues/41288624/attachments/53088388 https://issues.chromium.org/action/issues/41288624/attachments/53088388. On this example, loupe complains with “Could not Load Image” followed by “Either the image is unsupported or it contains unsupported elements”. Clicking “More Information” yields “Remote error: org.gnome.glycin.Error.LoadingError: glycin-loaders/glycin-image-rs/src/main.rs:307:54: Format error decoding Jpeg: "Parsing of the following header `DAC` is not supported,cannot continue" stderr: Setting process memory limit”.
A reader might wonder, why care about the arithmetic encoding? Recently, I tried to compress a rather big scan (private content, an A4 page at 1200 dpi with black foreground text and a nontrivial green-white background) into a JPEG file of a possibly small size. I ran:
cjpeg -quality 0 -arithmetic -dct float -outfile output.arithmetic.jpg -report -strict -verbose input.pnm
cjpeg -quality 0 -optimize -dct float -outfile output.optimized.jpg -report -strict -verbose input.pnm
cjpeg -quality 0 -dct float -outfile output.unoptimized.jpg -report -strict -verbose input.pnm
(Quality 1 would do as well. The real file names have been replaced by “input” and “output” for privacy here.)
The sizes are this:
output.arithmetic.jpg: 239224 bytes
output.optimized.jpg: 807963 bytes
output.unoptimized.jpg: 1928235 bytes
The foregrounds of the three files are readable and have visually comparable quality. The savings in size between output.arithmetic.jpg and output.optimized.jpg are a factor exceeding 3.3. (And NOT a tiny one-digit percentage, as reported in “A Review on JPEG2000 Image Compression” by Maini and Mehra and in the Wikipedia article on JPEG.) These savings do make a difference if you use more images of this kind and your storage or bandwidth is restricted.
An aside. I was wondering about whether to add the control line “Severity: wishlist” and decided against it, as, strictly speaking, the files on which the error occurs, though uncommon, strictly conform to the JPEG standard. The corresponding patents expired, so the only limiting factor is human work hours to implement this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnome-maintainers/attachments/20260209/b9107c90/attachment-0001.htm>