Happy to fix it, but I need to be able to reproduce it first, using only
libjpeg-turbo. Currently I cannot. I tried running
jpegtran -optimize -rotate 270 003632r270.jpg >out.jpg
and
jpegtran -progressive -optimize -rotate 270 003632r270.jpg >out.jpg
with valgrind, and no issues were detected.
I also tried the convert command line listed above, and with my
(admittedly older) version of ImageMagick, no issues were detected.
This leads me to suspect an issue with ImageMagick, not libjpeg-turbo.
Furthermore, Mozilla bangs on the -optimize switch a tremendous amount,
since that switch is enabled by default in their mozjpeg encoder
(mozjpeg is focused on getting the absolute best compression ratio
possible-- at the expense of like a 50x drop in performance-- so they
enable progressive & optimize by default, as well as include other
extensions like jpgcrush and trellis coding that aren't in
libjpeg-turbo.) Furthermore, there is nothing about the optimized
(multi-pass) Huffman coding feature that is different between
libjpeg-turbo and libjpeg, so if this is genuinely a bug in
libjpeg-turbo, it is likely to exist in libjpeg as well. Our
optimizations affect only single-pass Huffman coding.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
