The customer reports and I've verified the Ghostscript locks up reading the attached PDF file. The command line I'm using for testing: bin/gs -sDEVICE=ppmraw -o test.ppm -r10 ./PW-1165.pdf The customer notes that using the -dNOINTERPOLATE option allows the conversion to finish quickly but the customer isn't sure they want to add that option to their default conversion option.
Adobe Acrobat and muDraw both save both the original and the simplified out3.pdf file to a 10 dpi 24 bpp image file in less than a second.
Preventing interpolation resolves the problem, so this isn't a PDF interpreter problem.... Its 'probably' to do with interpolating in an ICCbased color space, but I don't know a lot about the interpolation code.
I wanted to see how long each image took (since it does a potfull of these scaled up interpolated images). I mistyped the command line and had -r20 -dPDFDEBUG and the first image Im2 completed in ~45 seconds. Well and good. Then I "corrected" it and did -r10, expecting it to be faster. I killed it at over 4 minutes. -r30, -r40 were also are about 45 seconds. I tried -r18 and that finishes Im2 in ~45 seconds, but -r17 runs for over 20 minutes (when I killed it). Not that 45 seconds per image is great, but this is not the expected result (lower resolution taking longer and a sharp performance change when the resolution changes just a bit).
The problem is still in the current master branch. One possible solution is creation of a crop filter that picks a rectangular fragment from the source image.
Assigning to Robin purely on the basis of 'interpolation', I haven't looked at the file.
"Fixed" with: commit 1a56803d76fc5ad02f344147c6fbb7ef711a29ec Author: Robin Watts <Robin.Watts@artifex.com> Date: Mon Jun 6 16:46:54 2022 +0100 Bug 695153: Tweak interpolation edge case. The example file (or at least the cut down one), contains a smallish (256x256) image that is scaled up a lot (to 35379449,35379449). This does not fit on the 360x240 output (at 10dpi), so only a small proportion is required. Because interpolation is required, we don't want to calculate all 1.25 quadrillion output pixels. Accordingly, we calculate the 'patch' region of the source that is actually required, and then only process that region. Make the calculations more accurate to try to minimise the source region. In particular, on an upscale, it doesn't need to be increased as much as on a downscale. It's still slower than we might like, but it does at least complete within some reasonable timescale.