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 of pamscale). Version-Release number of selected component (if applicable): netpbm-progs-10.33-1.fc5 How reproducible: Every time I try to scale a big image. Steps to Reproduce: 1. pamscale -reduce 8 -filter=cubic < infile > outfile Actual results: System grinds to a halt with lots of thrashing. Expected results: converted file in a second or two. Additional info: 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.