You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Justin McCarthy <ju...@gmail.com> on 2006/04/03 21:27:07 UTC
PNG transcoding time -- f(resulting file size)?
I've spent 20 minutes or so digging through the archives without finding
much detail on this topic. Apologies if I missed an obvious thread, but I
have an interesting observation to share anyway --
Here's the problem:
I'm deploying Batik as a servlet. This application will be deployed to a
high load, highly concurrent environment. We'll be rasterizing both JPEGs
and PNGs in equal number.
Unfortunately, encoding exactly the same SVG with exactly the same
parameters, but substituting the PNGTranscoder for the JPEGTranscoder runs
about 10x slower. Here's the interesting part: at least 20% of the
execution time in the PNG scenario can be attributed to Firefox rendering
the PNG slowly (I'm logging the transcode after streaming the result to the
browser). Here are the logs; width=500, height=500; the final number is
time, in ms:
Apr 3, 2006 12:11:43 PM com.cafepress.svg.SvgServlet logTranscode (JPEG from
FF)
INFO: Transcode complete: - 500 500 image/jpeg 47
Apr 3, 2006 12:11:45 PM com.cafepress.svg.SvgServlet logTranscode (JPEG from
IE)
INFO: Transcode complete: - 500 500 image/jpeg 47
Apr 3, 2006 12:11:48 PM com.cafepress.svg.SvgServlet logTranscode (PNG from
IE)
INFO: Transcode complete: - 500 500 image/png 532
Apr 3, 2006 12:11:51 PM com.cafepress.svg.SvgServlet logTranscode (PNG from
IE)
INFO: Transcode complete: - 500 500 image/png 547
Apr 3, 2006 12:11:59 PM com.cafepress.svg.SvgServlet logTranscode (PNG from
FF)
INFO: Transcode complete: - 500 500 image/png 688
Apr 3, 2006 12:12:03 PM com.cafepress.svg.SvgServlet logTranscode (PNG from
FF)
INFO: Transcode complete: - 500 500 image/png 672
So, my question is:
Do we expect PNG transcoding to be an order of magnitude slower than JPEG?
The example image I provide below _is_ a photograph, and therefore
transcodes much larger as PNG than JPEG. Do we expect transcoding time to
be linear with resultant file size? Is IO the dominant component of any
transcoding operation? If so, I think the mystery is solved (and we'll just
have to figure a way to avoid PNG'ing certain graphics).
Here's the SVG:
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://web.resource.org/cc/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink" width="500" height="333">
<g id="layer1" transform="rotate(15)">
<image
id="puppy"
height="333"
width="500"
xlink:href="http://static.flickr.com/41/122717114_84699d322f.jpg"
x="0" y="0"/>
</g>
</svg>
Thanks for the help,
Justin
Re: PNG transcoding time -- f(resulting file size)?
Posted by th...@kodak.com.
"Justin McCarthy" <ju...@gmail.com> wrote on 04/03/2006 04:19:22
PM:
> > 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.
FYI, if you check out the trunk from SVN you should be able to
switch to the JIIO stuff by simply editing the file:
resources/META-INF/services/org.apache.batik.ext.awt.image.spi.ImageWriter
So that 'org.apache.batik.ext.awt.image.codec.png.PNGImageWriter' is
commented out and
'org.apache.batik.ext.awt.image.codec.imageio.ImageIOPNGImageWriter'
is uncommented and retest. I would test carefully as when this was
uncommented we had regressions in our tests, but it may be unimportant
differences.
> > 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
> libraries).
>
> 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.
>
> /Justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: PNG transcoding time -- f(resulting file size)?
Posted by Justin McCarthy <ju...@gmail.com>.
> 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
libraries).
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.
/Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: PNG transcoding time -- f(resulting file size)?
Posted by th...@kodak.com.
Hi Justin,
"Justin McCarthy" <ju...@gmail.com> wrote on 04/03/2006 03:27:07
PM:
> Unfortunately, encoding exactly the same SVG with exactly the same
parameters,
> but substituting the PNGTranscoder for the JPEGTranscoder runs about 10x
> slower.
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.
> Here's the interesting part: at least 20% of the execution time in
> the PNG scenario can be attributed to Firefox rendering the PNG slowly
(I'm
> logging the transcode after streaming the result to the browser). Here
are
> the logs; width=500, height=500; the final number is time, in ms:
> Do we expect PNG transcoding to be an order of magnitude slower than
JPEG?
It is likely to be much slower.
> 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.
> Do we expect transcoding time to be linear with resultant file size?
> Is IO the dominant component of any transcoding operation?
I don't think so, PNG may well be slower than JPEG but if both are
native I would expect them to be much closer.
> If so, I think the mystery is solved (and we'll just have to
> figure a way to avoid PNG'ing certain graphics).
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org