GIMP coverts jpg to png image with massive, but imperceptible differences in color throughout the image. The same conversion process in GraphicsMagick produces 100% identical to the original jpg PNG image. Confirmed on various GIMP and GM versions using various compressions, icc inclusion and source images.
Comparisons can be made using GM or Imagemagick
PS. Why this website doesn’t cover GraphicsMagick tool? This is far far more better and robust software then ImageMagick.
Could you please provide more information about your conversion process, showing examples? That would help the forum get to the bottom of it. I agree we don’t talk about GraphicsMagick. I wonder how different it is from IM at this point…
In principle, decoding a JPEG is lossless. However, it does involve heavy arithmetic, including decompression and conversion from YCbCr to sRGB.
When two different programs are used for supposedly identical image processing, the results will often be slightly different. This is because they often use different algorithms, which result in different arithmetic rounding.
When I take toes.jpg (which is has no embedded colour profile), and create 8-bit t.png from Gimp, and 8-bit t2.png from ImageMagick, there is a difference:
I reckon an RMSE of 0.01 is only just visible. So an RMSE of less than 0.001 is almost certainly not visible.
(I have no experience of GraphicsMagick. But I would expect any two different software systems to show some difference. When two software systems use the same decoding library, there may be no difference.)
If you use gm compare to compare the JPG and each of the PNGs, you’re going to compare the JPG rendering (interpretation, decoding) produced by gm, encoded (losslessly) as a PNG, with another (Gimp) rendering, encoded (losslessly) as a PNG. Since the PNG produced by gm simply contains the data that gm extracted from the JPG, there will be no differences (if the PNG en/decoding code of gm has no bugs). What you are comparing is the way two libraries (the one used by gm and the one used by Gimp) decode the JPG, not how they encode the extracted data into PNG.
Both GM and GIMP uses libjpeg-turbo, same versions on my machine, to decode jpgs. More information is needed. I shall perrom tests with other libre applications later.
ok, so why then when we compare jpgs exported / created in GIMP, further opened in GIMP and converted to PNG are exact compared to exported from GM. I do not implying that somewhere GIMP does something wrong, but GM goes through rigid code check, that was a reason of imagemagick fork back in 2002.
ok, so why then when we compare jpgs exported / created in GIMP, further opened in GIMP and converted to PNG are exact compared to exported from GM.
Sorry, I don’t understand.
By “exact”, are you now saying that that using GIMP to read a JPG and export as PNG, gives exactly the same pixels using GM to read the JPG and write a PNG?
When I do this with ImageMagick, the pixels are slightly different. But the difference is very small. For example, from the Gimp result:
Another possibility: In this experiment, I am using pre-built versions of ImageMagick and Gimp. Even if they use the same jpeg library, that will have been built by different people on different computers, possibly with different compilers and compilation options. In particular, different optimisations can cause different orderings of arithmetic expressions. As before, this can cause differences in rounding.
libjpeg-turbo>=1.3.0_2 here. Krita produces png that is the exact copy of jpg.
“different optimisations can cause different orderings of arithmetic expressions” I’d rather believe that. But my friends comfirmed my results and they run completely different distro. Yeah, the difference is negligable, but I however had more variance in results with badly encoded jpegs from archives, still unnoticable, but colors changed almost everywhere in the image, compared to
