Artifacts on image after using gm convert
Swiss army knife of image processing
Brought to you by:
bfriesen
Menu
▾
▴
1 Attachments
#456 Artifacts on image after using gm convert
Hey guys,
I'm running a resize image server, basically where our users can upload photos from client mobile apps, and graphicsmagicks is in charge of generating 3 images from the source image (we generate one of 300px, one of 1024px, one of 2048px) to be used in various places in a webapp afterwards. We started the resize server approximately two months ago, and some users recently reported some problems with their images.
Basically, some images were blurry, with lots of artifacts on it, and overall unusable.
We managed to reproduce the bug, which kinda weirdly only happens with pictures coming from iOS or Windows Surface devices.
Here is the commande used to resize :
gm convert ${filePath} -resize ${format}x${format}> -quality 70 -interlace Line +profile "*"
We are using gm v1.3.25.
Also, we noticed that when removing the interlace parameter, the bug seems to happen less frequently.
Anyone already encountered a bug like this ? If so, how did you solved it ? Any pointers to what could cause the problem ?
I attached a zip file that shows an image, before and after the convert.
Thank you very much
On Fri, 8 Sep 2017, troudier wrote:
The file 01ac9fe3-0737-45c1-9996-d2ed6d152fff.jpg is defective and
results in "Corrupt JPEG data: premature end of data segment". Is
this the input file or the output file?
If I do 'gm identify -verbose
9a3123fc-c26f-4f2c-8590-bde4062faf28.jpg' then I see these claimed
JPEG encoding properties (estimated):
JPEG-Quality: 78
JPEG-Colorspace: 2
JPEG-Colorspace-Name: RGB
JPEG-Sampling-factors: 2x2,1x1,1x1
The behavior of JPEG depends heavily on the JPEG library used and the
encoding properties used. It may be that some JPEG libraries will
accept a corrupt file and produce a low grade image from it and others
will reject it. Modern GM tends to reject corrupt files rather than
produce a low-grade result.
Regardless, the first thing to look at is the decoding and encoding of
the JPEG.
Bob
Hi, and thanks for your answer. The 01ac9fe3-0737-45c1-9996-d2ed6d152fff.jpg is the result of the conversion.
Regarding the rest of your answer, I'm not sure where you are getting at. Could you elaborate a bit ?
Thanks very much
On Fri, 8 Sep 2017, thib_rdr wrote:
The image containing a red arrow is the original or are both of the
images supposed to contain the red arrow?
There is something severely wrong if you can't write a proper JPEG
file using GM. I would tend to suspect the JPEG library you are
using or a mismatch with it (e.g. a different libjpeg is being used
than GM was built against).
What libjpeg are you using? There are many choices available now
(some of which pretend to be another) so it is important to know which
one you are using.
Where did the GraphicsMagick come from that you are using? Did you
build it yourself from source code or was it built by someone else on
a different computer?
If I know enough to recreate the problem, then perhaps I can fix it.
Bob
Both images are supposed to contain the red arrow.
As I said, the images came from uploads from iOS and Windows devices.
Regarding my installation of Graphics Magick, it's the version available in the Jessie repository from Debian.
On Fri, 8 Sep 2017, thib_rdr wrote:
What is the full ouput from 'gm -version'?
It is likely that Debian Jessie is using some version of TurboJPEG.
Bob
Reporter stopped responding regarding this bug report.