[
https://issues.apache.org/jira/browse/IMAGING-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13912843#comment-13912843
]
Gary Lucas commented on IMAGING-126:
------------------------------------
I plan on turning the enhancement for the rows-per-strip calculation, but first
I need to do some careful testing... After all the original author put a lot
of effort into correctness-of-implementation issues and I think we should honor
his example :-) The change isn't a rows-per-strip setting per se, but rather
how much memory is temporarily dedicated to the processing of an image. This
setting would be relevant on both when the image is compressed and when it is
decompressed on the application side. A setting of 32 or 64 K is probably okay,
even on hand-held devices.
My change will address only half of this JIRA tracker item. I do a lot of work
with TIFFs, so I know the code for that format fairly well. I've never looked
at the code for PNGs.
if you would like to experiment with the changes I propose to make, the
following code would be inserted in TiffImageWriterBase.java at about line 308.
Note that I am taking the cautious approach of increasing the memory used to
the rowsPerStrip calculation only for the LZW compression format, leaving the
others alone. There may be merit in extending it to the other formats, but I
am reluctant to do so without more study and testing:
// The original implementation was based on the concept of limiting
// the size of strips to about 8K bytes ( 64000 = 8*8000)
// This gave disappointing data compression ratios when using LZW.
// Based on the Adobe TIFF Technical Notes, March 22, 2002, the
value
// was increased to 64K. To be cautious, this change is is applied
// for LZW compressed cases only, not the other formats.
int rowsPerStrip = 64000 / (width * bitsPerSample *
samplesPerPixel);
if (compression == TIFF_COMPRESSION_LZW) {
rowsPerStrip=(64*1024*8)/(width * bitsPerSample *
samplesPerPixel);
}
rowsPerStrip = Math.max(1, rowsPerStrip); // must have at least one.
P.S.
I went looking on the web for alternate LZW compressors to at least experiment
with improving the time required to write image files. It would be nice to
speed up the processing of LZW encoded TIFFs... Remarkably, nobody's written a
good LZW compressor in Java. I suppose that with GZIP being part of the
standard API, there's really no motivation to do so. The Apache POI project
has a decompressor which seems to have be extensively tested and vetted, but
they don't have a compressor. The was a compressor on Sourceforge which I can
look at for ideas, but unfortunately it was licensed under the viral GPL, so it
is of little value to the community in the long run. I'm not highly motivated
to work on the compressor/decompressor because what we have now is quite stable
and functional, but faster software is always welcome, especially when it comes
to image processing.
> TIFF and PNG images should not be bigger than the ones created by java ImageIO
> ------------------------------------------------------------------------------
>
> Key: IMAGING-126
> URL: https://issues.apache.org/jira/browse/IMAGING-126
> Project: Commons Imaging
> Issue Type: Improvement
> Components: Format: PNG, Format: TIFF
> Affects Versions: 1.0
> Environment: W7
> Reporter: Tilman Hausherr
> Priority: Minor
> Attachments: pdfbox-1870-devicen3-01.png,
> pdfbox-1870-devicen3-01.tif, pdfbox-1870-devicen3.pdf-1.png,
> pdfbox-1870-devicen3.pdf-1.tif
>
>
> I tried to use Apache Imaging for the PDFBOX project (PDFBOX-1734) because of
> problems with setting the tiff resolution in java imageio.
> While the code is pretty nice, I found that the generated images are
> sometimes much bigger in size than the ones generated by java imageio.
> Example:
> pdfbox-1870-devicen3-01.png 50 KB (imageio)
> pdfbox-1870-devicen3.pdf-1.png 70 KB (imaging)
> pdfbox-1870-devicen3-01.tif 401 KB (imageio)
> pdfbox-1870-devicen3.pdf-1.tif 1063 KB (imaging)
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
