I would vote for #1 - get rid of the classes entirely in Java 7. The warning
is already out there when compiling in Java 6.. there is no sense in dragging
it on.
I would also vote for rewriting the JPEG loaders in Image I/O as they are quite
poor performance-wise (and so is
My results are 18,250ms for ImageIO and 15,172 for JpegEncode.
I will try to make a more thorough test and will try JAI.
Thank,
Carl
[Message sent by forum member 'carcour' (carcour)]
http://forums.java.net/jive/thread.jspa?messageID=212065
I received the test image from Carl and it does have an APP2 marker
with an ICC profile so its as I suspected.
com.sun.image.codec.jpeg is faster mainly because its not processing
this.
On my XP PC for 50 loads of the sample image I have
ImageIO : 32 seconds
JPEGDecoder : 13 seconds
But if I
Thanks Phil.
I tried it. It it is a faster but not as fast as the old library. It still
looks to me that at 400ms this is slow. Shouldn't it be possible to make a
multi threaded image reader. Do you know what is really taking most of this
time? I have read somewhere that the C library used is
I tried it.
what is the percentage differential you measure?
I trust you ran a benchmark which ran a loop of (say) 50 times?
I have read somewhere that the C library used is not efficient and
that the Intel library is faster.
no idea what that's about. Both APIs use the same C lib. Its the IJG
There may be some differences in the way that the two APIs process the
image.
For example I noted recently that the old com.sun.image.codec,jpeg is
completely
ignorant of an APP2 marker with an ICC profile in which case its faster,
but produces incorrect
results. So for many photographic images
I've run some tests and concluded that JPEGCodec.createJPEGDecoder(new
FileInputStream(file)).decodeAsBufferedImage() is faster than ImageIO.read(new
File(file)) .
I have a test image that's 1978x2500 that loads in 375ms using JPEGCodec and
735 ms using ImageIO. I set
The package com.sun.image.codec.jpeg was added in JDK 1.2 (Dec 1998)
as a non-standard way of controlling the loading and saving of JPEG
format image files.
It has never been part of the platform specification and is not part
of any compatibility test suite and so compatible Java implementations
