From: albertnash@ro.ru   
      
   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-loa   
   ers/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 o   
   tput.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.   
      
   --==bound.0.f18520aa0cb447a4537b62b3b5c09144.mail.rambler.ru=Con   
   ent-Transfer-Encoding: quoted-printable   
   Content-Type: text/html; charset=utf-8   
      
   
Package: loupe

Version:   
   49.1-1

Control: affects -1   
   glycin-loaders



A traditional example of a JPEG created with arithmetic   
   encoding is https://issues.chro   
   ium.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/glyci   
   -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:

<   
   iv>
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   
   /div>

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:<   
   div>

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 o   
   tput.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.
   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)