Random pixel drop outs on image pipeline

[locriani]

Hello!

I've been encountering a very persistent issue with the ImageMagick 6.9.* series (I have attempted to resolve this by trying every version in this series).
This is using RMagick, but I am able to duplicate the issue consistently by reproducing the processing pipeline using the command line.

Code: Select all

Version: ImageMagick 6.9.4-10 Q16 x86_64 2016-08-19 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2016 ImageMagick Studio LLC
License: http://www.imagemagick.org/script/license.php
Features: Cipher DPC OpenMP 
Delegates (built-in): bzlib cairo djvu fontconfig freetype gvc jbig jng jpeg lcms lqr lzma openexr png rsvg tiff wmf x xml zlib

The Issue:

Given an original image TIFF: https://s3.amazonaws.com/weaveup-apertu ... ginal.tiff

and then performing the following operations (via the API, command line equivalents provided):

Code: Select all

convert https://s3.amazonaws.com/weaveup-aperture-dev/imagemagick_issues/8d0a4826_original.tiff -alpha remove removed_alpha.tiff
convert removed_alpha.tiff -colorspace Lab to_lab.tiff
convert to_lab.tiff -sample 2048x2048\> tile_primitive.tiff
#page sizes and tile dimensions are calculated dynamically, this is for this specific image example
convert -page +0+0 tile_primitive.tiff -page +0+2048 tile_primitive.tiff -page +2048+0 tile_primitive.tiff -page +2048+2048 tile_primitive.tiff -page +0+4096 tile_primitive.tiff -page +2048+4096 tile_primitive.tiff -mosaic tiled.tiff
convert tiled.tiff -resize 320x320^ aspect_ratio_resized.tiff
convert aspect_ratio_resized.tiff -gravity Center -crop 320x320+0+0 cropped.tiff
convert cropped.tiff output.png

I get output like:


instead of the expected:


This occurs with many source images:



At first I suspected a memory corruption issue, so I nuked the server that is responsible for processing these images and spun up a new one in a different data center. This issue continued to reveal itself, so I tried a couple more times, and with every version of ImageMagick in the 6.9.x series.
I also have validated that this occurs even if there is plenty (30gb +) of free RAM available on the box.

I cannot downgrade to the ImageMagick (6.5 series) supported by Ubuntu, as that causes a separate but just as awful issue with the same image processing pipeline:

[snibgo]

On v6.9.2-5 Q16 pre-built binary, on Windows 8.1, I can't reproduce the problem.

For me, "convert -list format" includes the lines:

Code: Select all

PNG* rw-   Portable Network Graphics (libpng 1.6.20)
TIFF* rw+   Tagged Image File Format (LIBTIFF, Version 4.0.6)

If your libraries are much older, that might be the problem.

You might want to insert "+repage" after the crop.

The final conversion to PNG will also convert to sRGB, as PNG can't store CIELab. But you might want to make the colorspace conversion explicit.

[locriani]

Yeah, the lab conversions are part of the pipeline because it forks in several places and we need CIELab output for the majority of the images (just not the pngs).

I was actually able to resolve this issue a few minutes ago by grabbing the bytes directly from imagemagick instead of having imagemagick persist the file to disk, and then using ruby to write the bytes to a file directly.

I would assume, based on that, there is some issue with the file persistence mechanism caused by either imagemagick or the specific OS / imagemagick combination we have.

[snibgo]

I know nothing about Ruby and RMagick.

The offset in cropped.tiff may cause problems, if you are reading IM pixels at a low level:

Code: Select all

identify cropped.tiff

cropped.tiff TIFF 320x320 320x320+0+80 8-bit CIELab 178KB 0.000u 0:00.000

[magick]

It could be an OpenMP problem. Try building ImageMagick without OpenMP support (e.g. --disable-openmp option to the configure command-line) or reduce the threads to 1 (e.g. convert -limit threads 1).

[locriani]

Confirmed that this is an issue with OpenMP support.