commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Lucas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IMAGING-126) TIFF and PNG images should not be bigger than the ones created by java ImageIO
Date Mon, 29 Dec 2014 13:37:13 GMT

    [ 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)

Mime
View raw message