Occational random line through images

[XDAMDaniel]

I just completed 1,000 converts with the following command:

Code: Select all

convert -limit map 512mb -limit memory 512mb -limit thread 1 '1000.tif' -scale '2000x2000' -flatten -quality 85 output/testImage$i.tif;

Image 86 has a line in it. So, it looks like we're experiencing the issue even when only dealing with Tiff files. That should eliminate libjpeg as a factor shouldn't it?

Regarding the IM versions I know I mentioned a number of versions and there's getting to be a lot of text in this thread so I'll try to summarize again:

IM 6.7.3-3 - newest "fast version" (processing time went from 2 seconds to 20 seconds per image when upgrading beyond this version)*
IM 6.7.4-4 - newest version without line problem
IM 6.9.3-8 - version used for all posts in this thread.

*Note that we run four to five convert commands and some identify commands for each image processed.

I'll admin we didn't try every single version between 6.7.4-4 and 6.9.3-8 but all of the ones we have tried have produced the line problem. Having said that do you think upgrading libjpeg will actually do anything to help us?

[fmw42]

No if it fails for all tif files, then upgrading libjpeg won't help. It really looks to me (and I am no expert on this) that it is either your configuration/install, or OS, or a problem with scale. Since it fails for 6.9.3.8, that foregoes an issue with old code. Since no one else has reported a similar issue, that sort of makes -scale less doubtful. Can you post an example of a result with the line(s) in them so we can see exactly what it looks like? My suspicion is your OS, but that is just a guess. Do you have plenty of space in your tmp directory? Where are your IM temp files going?

If you remove all your -limits, use the IM default limits and just run the simple convert without -flatten and with only -scale, does it happen?

[snibgo]

The posted example testimage121.jpg is 2000x2000 pixels, and has the line at y=1411. Is the line always in ths position? The line is nearly white, but not exactly (off-white possibly from JPEG compression). In the TIF output, is the line exactly white?

As Fred says, eliminate all parts of your command. Does the problem occur with a simple:

Code: Select all

convert in.tif out.tif

If not, then which option(s) cause failure?

[fmw42]

Sorry, I did not notice the posted example with the line in it. I have it now. No need to repost.

Just to re-iterate in more detail. If snibgo's command works, then just add -scale and see if that works. Then if that works, add -flatten. Then if that works, add different -limits. Hopefully, one of those will show where it breaks.

If it fails with just -scale, the see if it fails with (-filter point or -filter box) -resize.

Once you get it pinned down further, one of the IM developers can run a long series of iterations, hopefully on a similar platform and see it it breaks and go from there.

[fmw42]

I ran 500 iterations of the following before it got too late tonight and no lines. IM 6.9.3.8 Q16 Mac OSX

Code: Select all

convert -limit map 512mb -limit memory 512mb -limit thread 1 '1000.tif' -scale '2000x2000' -flatten -quality 85 output/testImage$i.tif

[XDAMDaniel]

Thanks all for the suggestions. I've run a number of additional tests since my last post. After following the suggestions above and removing pretty much every part of the command and slowly adding it back, I found that everything went fine and I didn't get any images with lines, until the very last step when I added the "-limit memory 512mb" back into the command.

So no lines with:

Code: Select all

convert -limit map 512mb -limit thread 1 '1000.jpg' -scale '2000x2000' -flatten -quality 85 output/testImage1.jpg

But do get lines with:

Code: Select all

convert -limit map 512mb -limit memory 512mb -limit thread 1 '1000.jpg' -scale '2000x2000' -flatten -quality 85 output/testImage1.jpg

The posted example testimage121.jpg is 2000x2000 pixels, and has the line at y=1411. Is the line always in ths position?

No, the line is neither always in this position nor is it always this color. It may be near the top, near the bottom, or somewhere in the middle. It may be white, gray, or black. The only consistent thing is that it is always horizontal.

[quote=""fmw42"]Do you have plenty of space in your tmp directory? Where are your IM temp files going?[/quote]

Yes, the server has 23G of free space. I'm not certain where the IM temp files are going, I assume they are going to /tmp if it's even using tmp files at all. My understanding is that if the pixel cache has to go to the disk the process is 1,000 times slower. Right now it's moving along at a reasonable speed so I assume we're not using disk.

Another note, I don't think it's the OS. I spun up an Ubuntu 15.10 server (also in Amazon EC2) and installed the package managers version of ImageMagick: IM 6.8.9-9 and the 887th image has a line in it (using the second command from above). I guess I could update that to the newest version of IM to be sure we're getting apples to apples on that test but I was just trying to get a quick peak at what would happen on a different OS.

I recall that earlier we removed the -scale and the line problem also went away so it seems to me that we've triangulate the issue to using "-scale" with "-memory limit". All of these tests were performed in the amazon EC2 environment. I'd be slow to point a finger at the virtualization platform but I guess it is worth noting that is one variable that has not been tested. I'm currently running an enormous batch of images with the "successful" command to ensure that we really do have a no line command. If that succeeds I'll plan to run another batch of images with the memory limit in and -scale out. Hopefully with that triangulated we can figure out why memory limit with -scale causes the lines since omitting the memory limit isn't really going to be an option in our current environment.

[fmw42]

Once you get it pinned down, I expect one of the IM developer can check out the -limit memory issue, if that is what breaks it.

[XDAMDaniel]

It's beginning to very much look limit the "-limit memory" is the issue. I tried increasing the limit and I tried removing -scale and I'm still seeing lines when the memory limit is in the command.

[XDAMDaniel]

Also as a note the other thread involving a line issue (that I mentioned in the original post) was using a convert command with the -limit memory: viewtopic.php?t=16496.

It seems like we may hand found the trigger for the line issue.

[fmw42]

I think it would be time now for one of the IM developers to look into this.

[magick]

If you haven't tried already, disable OpenMP (./configure --disable-shared). We have seen bugs in certain releases of libgomp that can cause random pixels (even if you set the threads to 1). If the problem persists, it could be a bug in ImageMagick or in libjpeg / libtiff. As always, we need to be able to reproduce the problem before we can fix it. In the mean-time, lets try your command on our Fedora system. If there are any differences, we get an RMSE metric that is not zero. Note, 512MB is very different from 512mb.

Code: Select all

#!/bin/csh
convert -size 1000x1000 plasma:fractal plasma.tif
convert plasma.tif -scale 2000x2000 reference.tif
set i = 0
while ( $i < 1000 )
  echo -n "$i "
  convert -limit map 512MB -limit memory 512MB -limit thread 1 plasma.tif \
    -scale '2000x2000' -flatten -quality 85 image.tif
  compare -metric rmse image.tif reference.tif null:
  echo ""
  @ i ++
end

We get 1000 lines with a metric of 0 suggesting the command worked as expected, flawlessly. We tried -resize instead of -scale with the same results.

[snibgo]

I'm not an IM developer, and I can't reproduce the problem. The following is merely a suggestion.

resize.c function ScaleImage() seems to correctly check for failures of GetCacheViewVirtualPixels() and so on.

GetCacheViewVirtualPixels() return the results of GetVirtualPixelsFromNexus(), so report NULL if GetVirtualPixelsFromNexus() is NULL.

GetVirtualPixelsFromNexus() returns NULL on various failure conditions. However, it is also recursive; it calls itself. These recursive calls are checked for NULL, causing a loop break, but then do not appear to cause the caller to return NULL. Hence, it seems that an out-of-memory condition can cause GetVirtualPixelsFromNexus() to return an array of pixels that is correctly allocated but not correctly populated.

[magick]

As we iterate over all the rows of an image, if an exception is thrown while reading or writing pixels, the loop exits prematurely. However, we set the 'status' variable and destroy the scaled image and return a null image. The user then sees the exception, the reason for the failure, and the command exits. Of course there could be a lurking bug that has alluded us thus far.

[snibgo]

GetVirtualPixelsFromNexus() can report success even though a recursive call of itself has failed.

[fmw42]

He seemed to say earlier that it fails without -scale, but with -limit map.