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.
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
I see now that this was requested upstream and the upstream maintainer is not interested in working on it themselves currently: https://github.com/etemesi254/zune-image/issues/274 A workaround is to use gimp which still can display the file even after gdk-pixbuf is switched to glycin. Thank you, Jeremy Bícha
I'm closing this bug since this can't be fixed in eog directly. Image loading is handled by gdk-pixbuf. Debian's gdk-pixbuf will soon be replacing its image loading with the glycin library. As I pointed out in https://bugs.debian.org/1127449 , this issue will need to be reported upstream to the zune-jpeg project since that's what glycin uses to handle jpeg loading. I see now that this was requested upstream and the upstream maintainer is not interested in working on it themselves currently: https://github.com/etemesi254/zune-image/issues/274 It does look like the workaround of using gimp still works after gdk-pixbuf is switched to glycin. Thank you, Jeremy Bícha
The upstream issue #274 in the zune-image repository discussed arithmetic coding as potentially non-standard and rare, but I've since clarified that it's a fully standardized feature under ITU-T T.81 (ISO/IEC 10918-1) and ITU-T T.851 with their corrigenda. Patents that historically limited adoption are now expired, opening the door for broader support. The upstream maintainer indicated they'd consider adding this if a strong reason or motivated contributor emerged. To address that, I've created https://github.com/etemesi254/zune-image/issues/350 https://github.com/etemesi254/zune-image/issues/350 with detailed rationale, including potential file size savings (e.g., 5-7% in literature, up to 16% in Chromium benchmarks, and over 3× in my local test). This could benefit Debian users by enabling more efficient image handling in applications relying on zune-image. I'm motivated to see this through and happy to assist with testing if needed. If the upstream ultimately declines, we could explore alternatives, but I believe this merits reconsideration given the new information. Would you please consider reopening the bug to allow further discussion? Thank you for your time and efforts in maintaining Debian. Gratefully, Albert
Sorry, there isn't really anything to discuss on the Debian side. The Debian maintainers don't have the capacity to fix this issue downstream. There are about 5,000 open bugs between the Debian GNOME and GNOME Extras teams, which is too many for us to manage. We simply can't keep feature request bugs open unless the team is actively working on implementing those features. Thank you, Jeremy Bícha
In the meantime, DAC seems to have been implemented upstream; cf. https://github.com/etemesi254/zune-image/issues/318 and https://github.com/etemesi254/zune-image/pull/373. Unless already happened (which I don't see in the changelogs of loupe and glycin-loaders), I wonder whether I could kindly ask you to prepare a package (or packages if more than one needs to be changed) for the experimental repository so that I (and, hopefully, other users) could test it. I'd test the user viewers `loupe` and `eog`. There is no rush, and, unless you object, I would be happy to re-open #1127449, as the circumstances have changed (cf. “until it is fixed upstream” above).
Please file an issue upstream with glycin asking then to support this with links to the zune-image PRs. best,
Hi Albert, I'm also a user who has been affected by this bug, and I'm eager to see Loupe work. You might've seen my comments on the upstream issues; I like to use GIMP to export JPEG images with comically low quality (look up "deep-fried memes" to get an idea), and in that case turning on arithmetic encoding shrinks the file by 70% or more usually. I'd been doing that for years absent-mindedly, which is why I have a lot of images accumulated that use it. I'm eager to try the fix too and I'm happy you've helped coordinate this. I don't know much about Rust but I do know my way around building Debian packages, and I plan on making a build to try anyway. Do I understand correctly that you use testing (Forky) on an amd64 system? Let me know your release and architecture. Fortunately JPEG loading is taken care of by a glycin loader, so my plan is to - patch the rust-zune-jpeg source package, and build binaries from it - then rebuild src:glycin, which incorporates source code from rust-zune-jpeg to build the /usr/libexec/glycin-loaders/1+/glycin-image-rs binary that is used to decode JPEG image files (If that doesn't make sense it's mainly a note for myself when I come back to this tomorrow 🙂) Programs that use glycin like Loupe shouldn't need any change at all then; upgrading the glycin-loaders binary package alone ought to suffice.
Hi John, Great! I run trixie on amd64 with GNOME 48 and a tiny amount of updated packages from forky. Until a few hours ago, I thought I would be able to get the necessary packages from Debian experimental once the arithmetic-JPEG decoder has arrived there. Now, I discovered that a new loupe and a new glycin-loaders already require upgrading GNOME from 48 to 50. This opens yet another can of worms for me, as I am unsure whether GNOME 50 would run on my machine. In the worst case, I might need to get a new machine or switch from GNOME to another desktop environment, such as KDE Plasma, XFCE, Mate, Cinnamon, or LXQt. Therefore, if you have a choice of how to build glycin-loaders for the purpose of testing viewing arithmetic-coded JPEGs, please feel free to build a package what works in trixie on amd64. If you can't, feel free to go for forky on amd64. I also wonder whether you (or anyone else) might like to reopen this Debian bug report #1127449. Gratefully, Albert
Therefore, John, I guess that to prepare a new package, you might wish to take any version of glycin-loaders between 2.0.8-1 (which wouldn't cause me problems) and the current one in forky (which I still have to test; it's likely to open a can of worms for me) as a basis.
Ah, right. From the Debian side: Once upstream has release a new zune-jpeg supporting that I think all that's needed is to rebuild glycin-loaders with that version and things should just work. best,