[
https://issues.apache.org/jira/browse/PDFBOX-4598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16888685#comment-16888685
]
Jörg Henne commented on PDFBOX-4598:
------------------------------------
Hi Kim,
thanks for the time you are devoting to this issue. First, to answer your
question: when you downsample 1 bpp to (for example) 8 bpp grayscale data, you
are trading spatial resolution for intensity resolution. If you downsample to 1
bpp, all that extra information as nowhere to go and thus is lost. That's why
downsampling 1 bpp and low-bpp images frequently uses a higher bit-depth than
the source. If you take your example image from Wikipedia and think of it as
having only three colors, red, blue and black. How bad would the lower
resolutions look like if they were to use only those colors instead of being
able to use intermediate ones? This effect is also illustrated in
[https://en.wikipedia.org/wiki/Spatial_anti-aliasing]: if you compare figure 1
a and c you can see what we intend to achieve here.
There are many approaches for resampling. I am using "resampling" here as a
general term for the transformation of raster data which covers downsampling
(reduction) as well as upsampling (enlargement) or any more complex
transformations like skewing. The one implemented in the JBIG2 decoder uses the
{{Resizer}} class to resample with a selectable filter function (the default is
a clamped gaussian function) which turns 1 bpp into 8 bpp.
Once you downsample more input pixels into one output pixel than the target
resolution can handle, (i.e. 256 pixels corresponding to a reduction below
1/16th along the axis) which is quite common when producing output like preview
images, you cannot prevent information loss. This is where the source
subsampling comes into play: the resampling actually happens in two stages,
first the subsampling in {{Bitmaps.subsample(...)}} which shrinks the image in
integer increments but still generates 1 bpp and then the {{Resizer}} which
generates 8 bpp grayscale.
By tuning the subsampling/scaling parameters one can, for example, choose to
subsample so that effectively only roughly 16 levels of gray are output which
allows a trade-off between quality and CPU/memory requirements.
With respect to your patches, I think I like #1 best, as it is the most simple
approach to achieve what you want. #2 incurs an IMHO unnecessary blitting step
which should be avoided. The box filter from #3 is essentially the same as
using the {{Resizer}} with {{FilterType.Box}}. However, if one resizes using a
transfer function anyway, it is better to choose one that preserves spatial
information better than a simple box function, like Lanczos or the (default)
Gaussian.
Thanks
Jörg Henne
> oversized jbig2 decoded result that causing unnecessary operation
> -----------------------------------------------------------------
>
> Key: PDFBOX-4598
> URL: https://issues.apache.org/jira/browse/PDFBOX-4598
> Project: PDFBox
> Issue Type: Bug
> Components: JBIG2
> Affects Versions: 3.0.2 JBIG2
> Reporter: Hee Jeong Kim
> Priority: Minor
> Attachments: amb_2.jb2, approach_1.patch, approach_2.patch,
> approach_3.patch, sample.pdf, use_packed_raster_to_read_Jbig2_image.patch
>
>
> Hi! I am using pdfbox 2.0.16 and jbig2-imageio 3.0.2 to read JBIG2 images,
> and found some issue to report.
> It seems like jbig2-imageio creates oversized BufferedImage, and this also
> makes pdfbox to do unnecessary operations.
> To read Jbig2 image, pdfbox with jbig2-imageio do followings:
> 1. find JBIG2 ImageReader
> (https://github.com/apache/pdfbox/blob/2.0.16/pdfbox/src/main/java/org/apache/pdfbox/filter/JBIG2Filter.java#L67)
> 2. read Image and get BufferedImage as a result
> (https://github.com/apache/pdfbox/blob/2.0.16/pdfbox/src/main/java/org/apache/pdfbox/filter/JBIG2Filter.java#L106)
> 2-1. JBIG2 ImageIO 3.0.2 get decoded bitmap
> (https://github.com/apache/pdfbox-jbig2/blob/3.0.2/src/main/java/org/apache/pdfbox/jbig2/JBIG2ImageReader.java#L249)
> 2-2. return the given bitmap as buffered image
> (https://github.com/apache/pdfbox-jbig2/blob/3.0.2/src/main/java/org/apache/pdfbox/jbig2/JBIG2ImageReader.java#L259)
> The problem is
> At step 2-1, roughly 59MB Bitmap is created for given Jbig2 image on the
> second page of sample.pdf (which is correct),
> but oversize(473MB, roughly) BufferedImage is returned at the step 2-2.
> I think this is because jbig2-imageio uses a raster based on a
> PixelInterleavedSampleModel and IndexColorModel with 8 bits.
> https://github.com/apache/pdfbox-jbig2/blob/3.0.2/src/main/java/org/apache/pdfbox/jbig2/image/Bitmaps.java#L177
> https://github.com/apache/pdfbox-jbig2/blob/3.0.2/src/main/java/org/apache/pdfbox/jbig2/image/Bitmaps.java#L286
> https://github.com/apache/pdfbox-jbig2/blob/3.0.2/src/main/java/org/apache/pdfbox/jbig2/image/Bitmaps.java#L291
> This also makes pdfbox to check a pixel size of the color model of result
> buffered image,
> https://github.com/apache/pdfbox/blob/2.0.16/pdfbox/src/main/java/org/apache/pdfbox/filter/JBIG2Filter.java#L116
> and to create another BufferedImage with binary type since it is not 1.
> (jbig2 is 1-bit depth)
> https://github.com/apache/pdfbox/blob/2.0.16/pdfbox/src/main/java/org/apache/pdfbox/filter/JBIG2Filter.java#L122
> I think we should call createPackedRaster and use the returned raster which
> is based on MultiPixelPackedSampleModel, and use IndexColorModel with 1 bits
> since jbig2 is for bi-level image. Please check the attached patch. I tested
> with the patch, and it seems like this patch works well.
> You can reproduce this issue with the second of the sample.pdf file that I
> attached.
> You can also download the file from here:
> http://www.newsgn.com/data/newsgn_com/pdf/201802/2018022229524590.pdf
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
