xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Justin McCarthy" <justinamccar...@gmail.com>
Subject Re: PNG transcoding time -- f(resulting file size)?
Date Mon, 03 Apr 2006 20:19:22 GMT
>    Yah, the biggest problem is that the PNG encoder is 100% pure java and
> the JPEG encoder is 100% native code.  You might try the new ImageWriter
> stuff
> which would enable you to use the javax.imageio PNG encoder which I think
> is
> native underneath.  This might be much faster.  Checking this is one of
> the
> things on my TODO list.

Ok, that explains things. Thanks.

> > The example image I provide below _is_ a photograph, and therefore
> transcodes
> > much larger as PNG than JPEG.
>    Essentially everything will transcoder much larger as PNG than JPEG
> PNG is lossless and JPEG is lossy.

I've seen PNGs weigh in under JPEGs for primitive shapes -- corporate
logos and such; my reasoning was that PNG does run-length encoding,
making large homogenous areas highly compressable -- although now that
I think about it, seems like JPEG does RLE as well <shrug>.  Encoder
idiosyncrasies, I guess (I was thinking of .NET's native drawing

Anyway, thanks for sorting this out.  I'll start poking around the
source a bit, see if I can begin to comprehend how we could get the
native PNG encoding wired up.  If anyone else is interested in further
investigation, let me know, and we can coordinate our efforts.


To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org

View raw message