Your message dated Sun, 8 Feb 2026 20:04:51 -0500
with message-id
<caaajcmycnkql2rrcd9xuselb7xx44mbjg1tsxlk24p4aymd...@mail.gmail.com>
and subject line Re: Bug#1127449: Please add support for arithmetic-encoded
JPEGs to loupe
has caused the Debian Bug report #1127449,
regarding Please add support for arithmetic-encoded JPEGs to loupe
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1127449: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1127449
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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.
--- End Message ---
--- Begin Message ---
On Sun, Feb 8, 2026 at 7:07 PM Albert Nash <[email protected]> wrote:
> 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
This isn't only a loupe/glycin issue. I am unable to load that file in
Firefox or in eog powered by gdk-pixbuf 2.44.4+dfsg-1 (legacy
loaders). The Chromium issue is
https://issues.chromium.org/issues/41288624 and the file you linked
only shows a gray image so I assume that bug status is correct that
this type of file isn't supported in Chromium either.
The Debian GNOME maintainers aren't really able to do app or library
feature development from Debian requests. You'll need to report this
upstream.
Loupe is powered by glycin. https://gitlab.gnome.org/GNOME/glycin/
says that JPEG files are handled by zune-jpeg so you'll need to report
this to the zune-jpeg project.
I wouldn't bother reporting this against gdk-pixbuf since Debian's
gdk-pixbuf will soon be powered by glycin too.
I'm closing this issue since I don't want to reassign it to Debian's
rust-zune-jpeg package because there's nothing that can be done for
this issue in Debian until it is fixed upstream. Once it's fixed
upstream, you can file a bug if the fix doesn't land fast enough in
Debian.
Thank you,
Jeremy Bícha
--- End Message ---
