Limit rendered image size in icepdf - icepdf

Question

While rendering a bunch of PDFs to images, icepdf seemingly randomly bombs out with an OutOfMemoryError. Trying to track this down I find two things:
Close to the OOM it rendered an A0 page or similarly large document pages
With eclipse memory analyzer I find 1/2GB images in memory.
This suggests to limit the output image size to something managable. I wonder what the easiest way is to do this?
I looked at icepdf's Page object but there it is strongly recommended to just always use Page.BOUNDARY_CROPBOX and other uses seem not to be documented in the Javadoc.
How can I limit the output image size of Document.getPageImage or what other measure could I use to prevent the OOM (other than just increasing the Xmx, which I can't). Reduction of image quality is an option. But it should apply only to "oversize" images, not to all.
I tried already to use a predefined image using Document.paintPage(), but this was not sufficient.
Debug finally allowed me to zoom in on a document that is problematic. I get a log like:
2016-12-09T14:23:35Z DEBUG class org.icepdf.core.pobjects.Document 1 MEMFREE: 712484296 of 838860800
2016-12-09T14:23:35Z DEBUG class org.icepdf.core.pobjects.Document 1 LOADING: ..../F1-2.pdf
2016-12-09T14:23:37Z WARN class org.icepdf.core.pobjects.graphics.ScaledImageReference 1 Error loading image: 9 0 R Image stream= {Type=XObject, Length=8 0 R, Filter=FlateDecode, ColorSpace=DeviceGray, Decode=[1, 0], Height=18676, Width=13248, Subtype=Image, BitsPerComponent=1, Name=Im1} 9 0 R
so this would be Height=18676, Width=13248 which is really huge.
I guess that the OOM happens already during loading of the image, so later scaling does not help. Also it seems that the property org.icepdf.core.imageReference=scaled does not hit early enough.
For me it would be fine to just ignore oversized images like this. Any chance?

Answer 1

Image loading is by far the most memory expensive memory task when decoding PDF content. At this time there isn't an esasy way to turn off image loading for really large image however I'll give you a few code hints if you want to implement this your self.
The ImageReferenceFactory.java class is the factory behind the system property org.icepdf.core.imageReference, you'll see that the default for getImageReferenced() is ImageStreamReference. You can create a new ImageReference type like this:
public static org.icepdf.core.pobjects.graphics.ImageReference
getImageReference(ImageStream imageStream, Resources resources, GraphicsState graphicsState,
Integer imageIndex, Page page) {
switch (scaleType) {
case SCALED:
return new ScaledImageReference(imageStream, graphicsState, resources, imageIndex, page);
case SMOOTH_SCALED:
return new SmoothScaledImageReference(imageStream, graphicsState, resources, imageIndex, page);
case MIP_MAP:
return new MipMappedImageReference(imageStream, graphicsState, resources, imageIndex, page);
case SKIP_LARGE:
return new SkipLargeImageReference(imageStream, graphicsState, resources, imageIndex, page);
default:
return new ImageStreamReference(imageStream, graphicsState, resources, imageIndex, page);
}
}
Next you can extend the class ImageStreamReference with your new SkipLargeImageReference class. Then override the call() method as follows and it will skip the loading of any image over the defined MAX_SIZE .
public BufferedImage call() {
BufferedImage image = null;
if (imageStream.getWidth() < MAX_SIZE && imageStream.getHeight() < MAX_SIZE){
long start = System.nanoTime();
try {
image = imageStream.getImage(graphicsState, resources);
} catch (Throwable e) {
logger.log(Level.WARNING, "Error loading image: " + imageStream.getPObjectReference() +
" " + imageStream.toString(), e);
}
long end = System.nanoTime();
notifyImagePageEvents((end - start));
return image;
}
return null;
}
On a side note: To minimize the the amount of memory needed to decode an image make sure you are using org.icepdf.core.imageReference=default as this will decode the image only once. org.icepdf.core.imageReference=scaled will actually decode the image at full size and then do the scale which can create a very large memory spike. We are experimenting with NIO's direct ByteBuffers which looks promising to moving the decode memory usage off the heap, so hopefully this will get better in the future.