Red Hat Bugzilla – Bug 199871
pamscale goes berserk
Last modified: 2013-07-02 19:16:44 EDT
Description of problem:
On i386 platform attempting to scale a 5598x5125 .pnm file with a scale
factor of 8 (reducing it from 600dpi to 72dpi) using the cubic filter
seems to go berserk. Memory goes to 100%, swap goes to 100%, the whole
system becomes nonresponsive.
The x86_64 build of pamscale does not exhibit this problem, but simply
spits out the converted file in short order.
Also the equivalent ImageMagic "convert" command works fine on i386 in
just a few seconds (naturally I changed my script to use convert instead
Version-Release number of selected component (if applicable):
Every time I try to scale a big image.
Steps to Reproduce:
1. pamscale -reduce 8 -filter=cubic < infile > outfile
System grinds to a halt with lots of thrashing.
converted file in a second or two.
There are 2gig of physical memory and 8gig of swap on this system, so
consuming everything is pretty impressive.
The pnm file you use for downsampling is pgm or ppm?
Here's the source of the image:
scanimage --mode Gray --depth 8 --resolution 600 -x 217 -y 237 | \
pamflip -rotate270 > chemlawn.pnm
I forget which is which in pgm versus ppm, but it is whatever the heck
that scanimage call generates (8 bit grayscale).
Possibly relevant, the actual image I used for testing was a scan of a small
piece of paper, so the 217x237 mm image will actually have quite a lot
of white background from the scanner lid (though it seems to have the same
behavior for different scans).
Fixed. It was caused by the fact, that pamscale used uninitialized variables for
the output X and Y resolutions of the image and the cubic filter pass then tried
to fill the image up in the invalid bounds what caused wasting of all system
resources. FC5 update is comming soon.
netpbm-10.34-1.fc5 has been pushed for fc5, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.