Legacy ImageMagick Discussions Archive

ImageMagick 6.9.0-0
Steps to reproduce:
I want to compare 2 images https://upload.wikimedia.org/wikipedia/ ... cheval.jpg and the same but converted to png (with no other changes).
If I do: convert original.jpg original.png and then compare -metric PSNR original.jpg original.png difference.png I get inf PSNR. It's OK.
But when I convert to png using GIMP or Phototonic and then compare their png-files with the original jpg one I get 59.5138 PSNR. And this is completely unclear for me: where is the root of the problem - whether Gimp and Phototonic uses low quality color space conversion (or other thing) or convert command does something extraordinary?

In IM, when I convert the jpg to png, I get an exact copy. So a metric of rmse will give 0 and PSNR will be infinite. Both indicate a perfect match. See the IM compare metrics at http://www.imagemagick.org/Usage/compare/#statistics.

I cannot say how GIMP or Phototonic are converting to png. It could be the jpg and png delegates that IM uses are better than whatever the other two are doing.

In principle, converting to PNG should have no losses.

On my IM 6.9.0.0 Q16 Mac OSX, I get
So this is not an IM bug as far as I can tell.

Hmm, yes, there is a small difference. Weird.

If I convert that JPEG to PNG with IM, and compare the JPG with the PNG with IM, there is zero difference. This proves merely that IM is consistent with itself.

Likewise, if I convert with Gimp and compare the JPG with the PNG with Gimp, there is zero difference. This proves merely that Gimp is consistent with itself.

But the IM PNG and Gimp PNG are different. IM says the RMSE difference is 0.5%.

I don't know which is correct: IM or Gimp. Or they might both be wrong.

I suspect the JPG and/or PNG delegate versions or code are different on the two systems.

My OS is Arch Linux x86_64. RMSE gives result 69.3077 (0.00105757).

An RMSE of 0.001, ie 0.1%, is nothing at all unless you are repeatedly re-writing to JPG.

I suppose the difference would be in the JPEG libraries (reading the JPEG), as PNG should be lossless (writing the PNG). I don't know enough about JPEG compression to guess where the difference lies. Maybe in a rounding somewhere.

In my test, I noticed that the mean difference in each channel was far smaller than the RMSE.

I think GIMP process to less precision that IM. That could also be an issue, if you are using 16-bit IM compile (default). Then IM is more accurate. The libjpg versions of GIMP and IM may also be different or use different quantization tables.

Maybe IM uses not the same system library (libjpeg-turbo) as GIMP. Gimp definitely not uses DCT conversion of lover quality - see https://git.gnome.org/browse/gimp/tree/ ... peg-load.c I mean it uses J_DCT_METHOD JDCT_DEFAULT

Can this Arch Linux patch make the difference? https://projects.archlinux.org/svntogit ... jpeg-turbo

Sorry, I am not a Linux user (Mac only) and would not know.

You may already have different versions of libjpeg on your system. IM may be using one and GIMP another. IM expect libjpeg to be where it can find it and will use whichever one it finds at the correct location. Sometimes there can be conflicts between multiple versions of libjpeg. I do not know if any of this is relevant.

Even if there is only one version, the precision of IM and GIMP may be different and that could cause slight differences due to roundoff issues.

I use only libjpeg-turbo library. roundoff issues shouldn't appear as GIMP (I posted a link to part of its source code) uses standard (default) values of libjpeg to open images.

But is it the same libjpeg and is GIMP computational precision the same as in IM?

What's wrong with this world? djpeg9a (reference jpeg decoder) gives worse results - 344.225 (0.00525253) than libjpeg-turbo - this is the comparison for bmp decoded output. IM is the best and decodes with ABSOLUTELY NO errors. The problem was found - bad jpeg - jor jpeg9 and int dct for GIMP. If GIMP will use dct float - there will be no errors and rmse will be 0.