jpegoptim icon indicating copy to clipboard operation
jpegoptim copied to clipboard

Jpegoptim changes ImageMagick rgb decode of a few images

Open dreamlayers opened this issue 3 years ago • 3 comments

In the past I verified that jpegoptim does not alter images by doing an ImageMagick convert rgb decode before and after, and then comparing md5 sums. Right now I'm finding that some images are altered. I'm attaching one here: P7010105 A quick glance through cmp -l output shows that many pixel values are changed by 1. (Example JPEG file MD5 is be84d44f1c409d570e40e5a84571c3be, and I've verified that GitHub didn't alter it.)

This problem is present with v1.4.4 which I built myself, v1.4.6 which is available in Ubuntu 21.04 and v1.4.7beta which I just built from git source. I'm using convert "$i" "$i.rgb" with "ImageMagick 6.9.10-23 Q16 x86_64 20190101" which is part of Ubuntu 21.04. All of this is in Ubuntu 21.04, on two different x86_64 systems.

This happens both with normal and progressive (interlaced) output.

dreamlayers avatar Apr 05 '21 17:04 dreamlayers

I have the same issue in Windows 10 with Ubuntu 20.04.2 LTS running under WSL1. It has jpegoptim v1.4.6 and ImageMagick 6.9.10-23 Q16 x86_64 20190101. The problem also happens with that file when I use my old jpegoptim v1.4.4beta built using Cygwin i686-w64-mingw32 in Windows.

dreamlayers avatar Apr 05 '21 17:04 dreamlayers

The output of djpeg from libjpeg-turbo version 2.0.6 (build 20210328) is not changed by jpegoptim for these same images. Why do djpeg and convert act differently?

Simply running jhead -purejpg (without using jpegoptim) on the images doesn't change ImageMagick rgb output. Also, after that jpegoptim also changes ImageMagick rgb output. So it's not some header thing like a colour profile.

dreamlayers avatar Apr 05 '21 18:04 dreamlayers

I would guess this has something to do with the JPEG library that jpegoptim was compiled against... (seen weird behavior with libjpeg-turbo in the past...)

I tested with latest (compiled from git) and wasn't able to reproduce your issue:

$ cp original.jpg test.jpg
$ ./jpegoptim test.jpg
test.jpg 2288x1520 24bit N Exif  [OK] 680763 --> 670108 bytes (1.57%), optimized.
$ gm compare -metric mse original.jpg test.jpg 
Image Difference (MeanSquaredError):
           Normalized    Absolute
          ============  ==========
     Red: 0.0000000000        0.0
   Green: 0.0000000000        0.0
    Blue: 0.0000000000        0.0
   Total: 0.0000000000        0.0

Tried also converting to progressive JPEG (that usually yields slightly smaller output files):

$ ./jpegoptim --all-progressive test.jpg 
test.jpg 2288x1520 24bit N Exif JFIF  [OK] 670108 --> 638980 bytes (4.65%), optimized.
$ gm compare -metric mse original.jpg test.jpg 
Image Difference (MeanSquaredError):
           Normalized    Absolute
          ============  ==========
     Red: 0.0000000000        0.0
   Green: 0.0000000000        0.0
    Blue: 0.0000000000        0.0
   Total: 0.0000000000        0.0

tjko avatar Apr 05 '22 05:04 tjko