[
https://issues.apache.org/jira/browse/IMAGING-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14260103#comment-14260103
]
Gary Lucas commented on IMAGING-126:
------------------------------------
Well, first off, switching to Compress is an interesting side issue, not the
key question raised by this particular tracker item. So let me talk about the
code change involved in the size of the compressed images before moving on to
the question of using Compress.
In terms of the image size... I did some work on this a year ago, but got busy
with other things and let the matter drop. Basically, the issue comes down to
the size of a memory allocation used to compress and decompress an image. This
memory holds a "dictionary" of sorts which is used to encode and decode the
image. The current size is 8K. A bigger size, say 32 K, achieves substantially
better compression ratios and results in substantially smaller images.
However, a bigger dictionary presents a larger search space for the compressor
and slows things down. In testing with the existing code I found that 32 K was
a reasonable compromise... It didn't make things as small as I'd wish, but it
didn't increase the run time to an unacceptable degree.
My gut instinct is to simply make 32K be the default and be done with it. Some
of the others who joined the discussion pointed out that this would change the
behavior of the existing code and might interfere with existing applications.
So, what I would propose as an alternate is to offer a new option for the
"parameters" passed to the Imaging.writeImage() methods. This would involve
defining a key/value pair defined in the TiffConstants class which could be
passed in to control compression. This would require extra knowledge on the
part of person writing application code to employ a feature that he would
almost always want, but has the advantage of preserving the existing behavior.
But I do think it's a reasonable approach.
So, if you are looking to wrap things up and put out a release, I will give
this some attention and prepare a patch for you. Is there a consensus on
approach?
----------------------------------------------------------------------
Now, on to the discussion of Compress.
There are tradeoffs involved in adding a cross-project dependency. So if we're
thinking about doing that, let's be sure we've considered all the issues and
have determined that it is a good idea. I will briefly consider both the pro's
and con's.
First the con's: Right now, all you have to do to use Apache Commons Imaging is
download one jar file. Introducing cross dependencies to the build will
complicate its use and management for anyone who wants to use the code. Also,
when I looked at this last year, Compress was not a perfect fit with the LZW
compression used in the TIFF format. Unless things have changed since then
(which is entirely possible), the Compress code would require some
modifications to present a more general-purpose solution that could be used for
Imaging. Also, the current solution in Imaging does work, so it's not as if it
has bugs that need to be fixed.
Now the pro's: One of the issues I mentioned above with the increase in the
size of the memory used for the compression "dictionary" is the increase in
compression time (and decompression time too?) related to the larger search
space. If Compress implements a more advanced compression implementation that
improves performance, that would be a motivation for adopting it.
I don't think that anyone would argue against the idea that, in general, it is
better not to maintain redundant implementations of anything. On the other
hand, sometimes you have a need that is just specialized enough that
maintaining a single code base becomes problematic. We might be looking at just
such a case here.
> 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
> Fix For: Discussion
>
> Attachments: Imaging_126_patch_1.patch, 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.3.4#6332)
