Skip to main content

[JAI-IMAGEIO] Retiring the package com.sun.image.codec.jpeg

23 replies [Last post]
Anonymous

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
are not required to include it.
The documentation for it has always been buried under a separate
'other API' heading, clearly distinct from the Java platform API
specification. The intention was to replace it with a standard API.

In JDK 1.4 (FCS/GA 2001) the Java Image I/O API was added
(see JSR-15 at http://jcp.org/en/jsr/detail?id=15) as a standard API.
This resides in the package javax.imageio.
It provides a standard mechanism for controlling the loading and
saving of sampled image formats and requires all compliant Java SE
implementations to support JPEG as per the Image I/O specification.

In JDK 6 to encourage migration to Image I/O several things happened.

1. All documentation of com.sun.image.codec.jpeg was removed
although the classes are still present in *Sun* implementations
- I can't speak for others - and probably only direct Sun licensees
are likely to ship the API assuming they bother to do so.

2. When compiling code using these classes using JDK 6 a warning
is emitted :

warning: com.sun.image.codec.jpeg.JPEGCodec is Sun proprietary API and
may be removed in a future release
JPEGCodec.createJPEGDecoder(...);
^
3. There were substantial performance improvements to Image I/O
including JPEG, and overall the performance is now very similar
between the two APIs.

So we think its time to retire com.sun.image.codec.jpeg so we
can focus on the single preferred standard API.

However we are aware that applications do still use it, typically
because they were written to run on JDK versions prior to 1.4,

There are several options, not all exclusive :

1. Remove completely in JDK 7 - the most aggressive option.

2. Warn in JDK 7 release notes that it will be removed completely in
JDK8 - this is really just incremental to the existing compilation
warning

3. Make further javac changes in JDK 7 so that the classes are not
located when compiling. ie the compilation warning turns into an error.
Again, with this option the classes *are* still available at runtime so
that code compiled with 1.6 or earlier will still find these classes
and run on JDK 7 This preserves binary compatibility.

4. Remove the classes completely in a release after JDK 7
after a combination of notifications via release notes
and compiler warnings/errors. Ideally this would then
happen in JDK8

Implementing 2+3+4 comes down to using JDK 7 to provide
a further period of grace to migrate and probably provides
the right balance between notice and compatibility (to these
non-standard, unsupported APIs). Particularly since JDK 6
already began this process.

How long does this give people to migrate?
Our historical run rate of releases is one every two years.
JDK 1.2 - Dec 1998
...
JDK 6 Nov 2006
Management may try different models and so forth but I think
that's a good enough estimate which predicts
JDK7 - late 2008
JDK8 - late 2010

Does anyone think they have current code that uses
com.sun.image.codec.jpeg that would have a problem
with this proposed removal?

Any comment on the options?

FYI I am sending this to each of :
JAVA2D-INTEREST@JAVA.SUN.COM
JAVA-IMAGEIO-INTEREST@JAVA.SUN.COM
JAI-INTEREST@JAVA.SUN.COM
interest@jai-imageio.dev.java.net
so many of you may get this message several times.

-Phil Race,
Java 2D.

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Brian Burkhalter

Are you using the Java SE JPEG reader or the one in jai-imageio.dev.java.net?
Which platform?

Brian

On Tue, 27 Mar 2007, jai-imageio@javadesktop.org wrote:

> OK. I modified the test.java to loop through 10 different files (files are copies of each other).
>
> import java.awt.image.*;
> import java.io.*;
> import javax.imageio.ImageIO;
>
> import com.sun.image.codec.jpeg.JPEGCodec;
>
>
> public class test
> {
>
> public test()
> {
> }
>
> /**
> * @param args the command line arguments
> */
> public static void main(String[] args)
> {
> try
> {
> for (int i=1; i<11; i++)
> {
> //ImageIO.setUseCache(false);
> FileInputStream fis = new FileInputStream(args[i]);
> long elapsed = 0;
> if (args[0].equalsIgnoreCase("imageio"))
> {
> elapsed = -System.nanoTime();
> BufferedImage bimg = ImageIO.read(new BufferedInputStream(fis));
> elapsed += System.nanoTime();
> }
> else if (args[0].equalsIgnoreCase("jpeg"))
> {
> elapsed = -System.nanoTime();
> BufferedImage bimg = JPEGCodec.createJPEGDecoder(
> new BufferedInputStream(fis)).decodeAsBufferedImage();
> elapsed += System.nanoTime();
> }
> System.out.format("Elapsed time reading %s using %s is %d milli seconds\n",args[1],args[0],elapsed/1000000);
> }
> }
> catch (Exception ex)
> {
> ex.printStackTrace();
> }
> }
>
> }
>
> The command line is:
>> java test jpeg 1.jpg 2.jpg 3.jpg 4.jpg 5.jpg 6.jpg 7.jpg 8.jpg 9.jpg 10.jpg
> Elapsed time reading 1.jpg using jpeg is 17 milli seconds
> Elapsed time reading 1.jpg using jpeg is 2 milli seconds
> Elapsed time reading 1.jpg using jpeg is 2 milli seconds
> Elapsed time reading 1.jpg using jpeg is 2 milli seconds
> Elapsed time reading 1.jpg using jpeg is 2 milli seconds
> Elapsed time reading 1.jpg using jpeg is 2 milli seconds
> Elapsed time reading 1.jpg using jpeg is 2 milli seconds
> Elapsed time reading 1.jpg using jpeg is 2 milli seconds
> Elapsed time reading 1.jpg using jpeg is 2 milli seconds
> Elapsed time reading 1.jpg using jpeg is 3 milli seconds
>
> and
>
>> java test imageio 1.jpg 2.jpg 3.jpg 4.jpg 5.jpg 6.jpg 7.jpg 8.jpg 9.jpg 10.jpg
> Elapsed time reading 1.jpg using imageio is 85 milli seconds
> Elapsed time reading 1.jpg using imageio is 10 milli seconds
> Elapsed time reading 1.jpg using imageio is 10 milli seconds
> Elapsed time reading 1.jpg using imageio is 9 milli seconds
> Elapsed time reading 1.jpg using imageio is 10 milli seconds
> Elapsed time reading 1.jpg using imageio is 16 milli seconds
> Elapsed time reading 1.jpg using imageio is 57 milli seconds
> Elapsed time reading 1.jpg using imageio is 3 milli seconds
> Elapsed time reading 1.jpg using imageio is 3 milli seconds
> Elapsed time reading 1.jpg using imageio is 3 milli seconds
>
> If I now use ImageIO.setUseCache(false) in the imageio case I get:
>
>> java test imageio 1.jpg 2.jpg 3.jpg 4.jpg 5.jpg 6.jpg 7.jpg 8.jpg 9.jpg 10.jpg
> Elapsed time reading 1.jpg using imageio is 70 milli seconds
> Elapsed time reading 1.jpg using imageio is 9 milli seconds
> Elapsed time reading 1.jpg using imageio is 9 milli seconds
> Elapsed time reading 1.jpg using imageio is 9 milli seconds
> Elapsed time reading 1.jpg using imageio is 9 milli seconds
> Elapsed time reading 1.jpg using imageio is 9 milli seconds
> Elapsed time reading 1.jpg using imageio is 29 milli seconds
> Elapsed time reading 1.jpg using imageio is 9 milli seconds
> Elapsed time reading 1.jpg using imageio is 51 milli seconds
> Elapsed time reading 1.jpg using imageio is 3 milli seconds
>
> Repeat invocations of the program give similar results (within a couple of milliseconds) for both cases however the JPEGCodec.createJPEGDecoder(..) method gives consistently low numbers
> [Message sent by forum member 'byhisdeeds' (byhisdeeds)]
>
> http://forums.java.net/jive/thread.jspa?messageID=210190
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
>
>

----------------
Brian Burkhalter
Java Media, Imaging, and Graphics
Sun Microsystems, Inc.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any
unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

Brian Burkhalter

10 loops within a single trial or 10 separate trials?

On Mon, 26 Mar 2007, jai-imageio@javadesktop.org wrote:

> I tired it about 10 times and the numbers are within a couple of milli seconds of each other.
>
> With regards to using a BufferedInputStream instead of a FileInputStream, is the former faster?
> [Message sent by forum member 'byhisdeeds' (byhisdeeds)]
>
> http://forums.java.net/jive/thread.jspa?messageID=209987
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
>
>

----------------
Brian Burkhalter
Java Media, Imaging, and Graphics
Sun Microsystems, Inc.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any
unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

Phil Race

Hi,

It looks as if this is largely down to the initialisation overhead.
If I loop 100 times (using what I am told is your actual image) then
I see ImageIO is slower but only by a fraction rather than the 5X slower
you are seeing.

Eg I see about 4-6 ms for each of ImageI/O and com.sun.image.codec.jpeg

We do have some overhead we need to take out for smaller images like
your 240x240 one. We are looking into that.

As noted by someone else setUseCache(false) is one way to help.
Here's my results from my prog (below) which shows how you can do
that and more.

Time for 100 loops on Solaris 10 SPARC (JDK 1.7 b10)
jpeg : 465ms
imageioreader = 655 ms
imageio : 771ms

-phil

jai-imageio@javadesktop.org wrote:
> I have an application that processes hundreds of jpreg file and I need speed. I just ran the following test program.
>

[SNIP]

> I get the following when I load a 24 bit RGB jpeg image of 240x240 (test.jpg):
>
>> java test imageio test.jpg
> Elapsed time reading test.jpg using imageio is 89 milli seconds
>
>> java test jpeg
> Elapsed time reading test.jpg using jpeg is 16 milli seconds
>
> Am I not turing on something here.
> [Message sent by forum member 'byhisdeeds' (byhisdeeds)]
>
> http://forums.java.net/jive/thread.jspa?messageID=209979
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
>

import java.awt.image.*;
import java.io.*;
import java.util.*;
import javax.imageio.*;
import javax.imageio.stream.*;

import com.sun.image.codec.jpeg.*;

public class test2 {

public static void main(String[] args) {
boolean useIIO = args[0].equalsIgnoreCase("imageio");
boolean useIIOReader = args[0].equalsIgnoreCase("imageioreader");
boolean useJPEG = args[0].equalsIgnoreCase("jpeg");
ImageIO.setUseCache(false);
ImageReader jpegReader = null;
if (useIIOReader) {
Iterator it =
ImageIO.getImageReadersBySuffix("jpg");
jpegReader = it.next();
}
long total=0L;
for (int i=0;i<101;i++) {
try {
long elapsed = 0;
if (useIIOReader) {
elapsed = -System.nanoTime();
RandomAccessFile file = new RandomAccessFile(args[1],
"r");
ImageInputStream stream = new FileImageInputStream(file);
jpegReader.reset();
jpegReader.setInput(stream);
BufferedImage bimg = jpegReader.read(0);
elapsed += System.nanoTime();
} else if (useIIO) {
elapsed = -System.nanoTime();
BufferedImage bimg = ImageIO.read(new File(args[1]));
elapsed += System.nanoTime();
} else if (useJPEG) {
elapsed = -System.nanoTime();
FileInputStream file = new FileInputStream(args[1]);
BufferedInputStream stream = new
BufferedInputStream(file);
JPEGImageDecoder decoder =
JPEGCodec.createJPEGDecoder(stream);
BufferedImage bimg = decoder.decodeAsBufferedImage();
elapsed += System.nanoTime();
}
if (i != 0) {
total += elapsed;
}
/*
System.out.format
("Elapsed time reading %s using %s is %d milli seconds\n",
args[1],args[0],elapsed/1000000);
*/
} catch (Exception ex) {
ex.printStackTrace();
}
}
System.out.println("total="+total/1000000);
}
}

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

byhisdeeds
Offline
Joined: 2006-01-06

OK. I have tried the test2 code with the following results.

java test2 jpeg 1.jpg
total=200
java test2 imageio 1.jpg
total=348
java test2 imageioreader 1.jpg
total=311

I am running on an Intel Core 2 2.33GHZ processor under Fedora Core 6, with JAVA SE 1.6. I do not have the jai-imageio librraies installed yet so the jpeg reader would be that included with the JAVA SE 1.6.

Although these numbers are tighter, the imageioreader is still 50% slower than the JPEG reader. Any idea about how much closer these numbers may get in the near future.

linuxhippy
Offline
Joined: 2004-01-07

> For client-side Java, isn't Java Kernel the right
> answer ? Remove the code from the core and when
> someone needs it, it can be dynamically downloaded.

I really wonder what all "you" java-kernel-criers will say if this would really become reality.
If your clients would need to stay 24/7 online because all the application load parts from time to time.
I can just speak for me, but wouldn't this be a lot annoying? Why not download 8mb once, but 8mb in 10 pieces?

lg Clemens

nopjn
Offline
Joined: 2003-12-27

Read some Java Kernel doc and you'll see that it's way more clever than that.

But I hope you'll enjoy your CORBA client application with your superb MIDI sound.

That's what we call cutting-edge ! Everybody should download those parts...just in case :)

benloud
Offline
Joined: 2005-08-09

I'm curious, you say the performance is similar, I always just assumed ImageIO actually used com.sun.image.codec.jpeg.* for it's JPEG plugin, I take it that's not the case then. What's the difference between them? Is one pure Java and the other using native code? Or do they both use native code, but different libraries? And do Toolkit and JAI each use seperate codecs aswell? It's all very confusing!

Phil Race

They both directly use the same native library - the IJG JPEG code.
So all JPEG decoding is done in 'C' code.
Toolkit also uses the IJG library directly too via its own calls into
that lib.
So there's three paths into IJG.

So when it comes down to it they are pretty much the same.
Performance differences can come from API overheads and subtleties of
the java->native glue code. For an extreme example if one API has higher
overhead
1x1 JPEG images can be measurably different due to that overhead

See
http://weblogs.java.net/blog/campbell/archive/2006/01/400_horsepower.html
for some more information.

JAI uses its own library that has some acceleration from using
VIS (on SPARC) and MMX (on intel). However JAI can
also fall back to using the built-in code if its native lib isn't available.

So for the most part everything is using the IJG lib.

-phil

jai-imageio@javadesktop.org wrote:
> I'm curious, you say the performance is similar, I always just assumed ImageIO actually used com.sun.image.codec.jpeg.* for it's JPEG plugin, I take it that's not the case then. What's the difference between them? Is one pure Java and the other using native code? Or do they both use native code, but different libraries? And do Toolkit and JAI each use seperate codecs aswell? It's all very confusing!
> [Message sent by forum member 'benloud' (benloud)]
>
> http://forums.java.net/jive/thread.jspa?messageID=205176
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

Brian Burkhalter

The JAI codec (com.sun.media.jai.codec) wraps the com.sun.image.codec.jpeg
codec.

The JAI Image I/O Tools (https://jai-imageio.dev.java.net) is an entirely
separate set of code from all the rest.

Brian

On Sun, 25 Feb 2007, Phil Race wrote:

> JAI uses its own library that has some acceleration from using
> VIS (on SPARC) and MMX (on intel). However JAI can
> also fall back to using the built-in code if its native lib isn't available.
>
> So for the most part everything is using the IJG lib.
>
> -phil
>
> jai-imageio@javadesktop.org wrote:
>> And do Toolkit and JAI each use seperate codecs aswell?
>> [Message sent by forum member 'benloud' (benloud)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=205176
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
>> For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
>
>

----------------
Brian Burkhalter
Java Media, Imaging, and Graphics
Sun Microsystems, Inc.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any
unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

byhisdeeds
Offline
Joined: 2006-01-06

I have an application that processes hundreds of jpreg file and I need speed. I just ran the following test program.

import java.awt.image.*;
import java.io.*;
import javax.imageio.ImageIO;

import com.sun.image.codec.jpeg.JPEGCodec;

public class test
{

public test()
{
}

/**
* @param args the command line arguments
*/
public static void main(String[] args)
{
try
{
FileInputStream fis = new FileInputStream(args[1]);
long elapsed = 0;
if (args[0].equalsIgnoreCase("imageio"))
{
elapsed = -System.nanoTime();
BufferedImage bimg = ImageIO.read(fis);
elapsed += System.nanoTime();
}
else if (args[0].equalsIgnoreCase("jpeg"))
{
elapsed = -System.nanoTime();
BufferedImage bimg = JPEGCodec.createJPEGDecoder(
new BufferedInputStream(fis)).decodeAsBufferedImage();
elapsed += System.nanoTime();
}
System.out.format("Elapsed time reading %s using %s is %d milli seconds\n",args[1],args[0],elapsed/1000000);
}
catch (Exception ex)
{
ex.printStackTrace();
}
}
}

I get the following when I load a 24 bit RGB jpeg image of 240x240 (test.jpg):

> java test imageio test.jpg
Elapsed time reading test.jpg using imageio is 89 milli seconds

> java test jpeg
Elapsed time reading test.jpg using jpeg is 16 milli seconds

Am I not turing on something here.

robert engels

You need to pass a buffered input stream to ImageIO as well, not just
a FileInputStream.

On Mar 26, 2007, at 5:58 PM, jai-imageio@javadesktop.org wrote:

> I have an application that processes hundreds of jpreg file and I
> need speed. I just ran the following test program.
>
> import java.awt.image.*;
> import java.io.*;
> import javax.imageio.ImageIO;
>
> import com.sun.image.codec.jpeg.JPEGCodec;
>
>
> public class test
> {
>
> public test()
> {
> }
>
> /**
> * @param args the command line arguments
> */
> public static void main(String[] args)
> {
> try
> {
> FileInputStream fis = new FileInputStream(args[1]);
> long elapsed = 0;
> if (args[0].equalsIgnoreCase("imageio"))
> {
> elapsed = -System.nanoTime();
> BufferedImage bimg = ImageIO.read(fis);
> elapsed += System.nanoTime();
> }
> else if (args[0].equalsIgnoreCase("jpeg"))
> {
> elapsed = -System.nanoTime();
> BufferedImage bimg = JPEGCodec.createJPEGDecoder(
> new BufferedInputStream(fis)).decodeAsBufferedImage();
> elapsed += System.nanoTime();
> }
> System.out.format("Elapsed time reading %s using %s is %d
> milli seconds\n",args[1],args[0],elapsed/1000000);
> }
> catch (Exception ex)
> {
> ex.printStackTrace();
> }
> }
> }
>
> I get the following when I load a 24 bit RGB jpeg image of 240x240
> (test.jpg):
>
>> java test imageio test.jpg
> Elapsed time reading test.jpg using imageio is 89 milli seconds
>
>> java test jpeg
> Elapsed time reading test.jpg using jpeg is 16 milli seconds
>
> Am I not turing on something here.
> [Message sent by forum member 'byhisdeeds' (byhisdeeds)]
>
> http://forums.java.net/jive/thread.jspa?messageID=209979
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-
> imageio.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

Brian Burkhalter

Also a more reliable value is obtained by computing the meaning over a certain
number of loops and ignoring the time required for the first loop.

On Mon, 26 Mar 2007, robert engels wrote:

> You need to pass a buffered input stream to ImageIO as well, not just a
> FileInputStream.
>
> On Mar 26, 2007, at 5:58 PM, jai-imageio@javadesktop.org wrote:
>
>> I have an application that processes hundreds of jpreg file and I need
>> speed. I just ran the following test program.
>>
>> import java.awt.image.*;
>> import java.io.*;
>> import javax.imageio.ImageIO;
>>
>> import com.sun.image.codec.jpeg.JPEGCodec;
>>
>>
>> public class test
>> {
>>
>> public test()
>> {
>> }
>>
>> /**
>> * @param args the command line arguments
>> */
>> public static void main(String[] args)
>> {
>> try
>> {
>> FileInputStream fis = new FileInputStream(args[1]);
>> long elapsed = 0;
>> if (args[0].equalsIgnoreCase("imageio"))
>> {
>> elapsed = -System.nanoTime();
>> BufferedImage bimg = ImageIO.read(fis);
>> elapsed += System.nanoTime();
>> }
>> else if (args[0].equalsIgnoreCase("jpeg"))
>> {
>> elapsed = -System.nanoTime();
>> BufferedImage bimg = JPEGCodec.createJPEGDecoder(
>> new BufferedInputStream(fis)).decodeAsBufferedImage();
>> elapsed += System.nanoTime();
>> }
>> System.out.format("Elapsed time reading %s using %s is %d milli
>> seconds\n",args[1],args[0],elapsed/1000000);
>> }
>> catch (Exception ex)
>> {
>> ex.printStackTrace();
>> }
>> }
>> }
>>
>> I get the following when I load a 24 bit RGB jpeg image of 240x240
>> (test.jpg):
>>
>>> java test imageio test.jpg
>> Elapsed time reading test.jpg using imageio is 89 milli seconds
>>
>>> java test jpeg
>> Elapsed time reading test.jpg using jpeg is 16 milli seconds
>>
>> Am I not turing on something here.
>> [Message sent by forum member 'byhisdeeds' (byhisdeeds)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=209979
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
>> For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
>

----------------
Brian Burkhalter
Java Media, Imaging, and Graphics
Sun Microsystems, Inc.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any
unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

Brian Burkhalter

I intended the "mean" (arithmetic mean), not "meaning".

On Mon, 26 Mar 2007, Brian Burkhalter wrote:

> Also a more reliable value is obtained by computing the meaning over a
> certain number of loops and ignoring the time required for the first loop.
>
> On Mon, 26 Mar 2007, robert engels wrote:
>
>> You need to pass a buffered input stream to ImageIO as well, not just a
>> FileInputStream.
>>
>> On Mar 26, 2007, at 5:58 PM, jai-imageio@javadesktop.org wrote:
>>
>>> I have an application that processes hundreds of jpreg file and I need
>>> speed. I just ran the following test program.
>>>
>>> import java.awt.image.*;
>>> import java.io.*;
>>> import javax.imageio.ImageIO;
>>>
>>> import com.sun.image.codec.jpeg.JPEGCodec;
>>>
>>>
>>> public class test
>>> {
>>>
>>> public test()
>>> {
>>> }
>>>
>>> /**
>>> * @param args the command line arguments
>>> */
>>> public static void main(String[] args)
>>> {
>>> try
>>> {
>>> FileInputStream fis = new FileInputStream(args[1]);
>>> long elapsed = 0;
>>> if (args[0].equalsIgnoreCase("imageio"))
>>> {
>>> elapsed = -System.nanoTime();
>>> BufferedImage bimg = ImageIO.read(fis);
>>> elapsed += System.nanoTime();
>>> }
>>> else if (args[0].equalsIgnoreCase("jpeg"))
>>> {
>>> elapsed = -System.nanoTime();
>>> BufferedImage bimg = JPEGCodec.createJPEGDecoder(
>>> new BufferedInputStream(fis)).decodeAsBufferedImage();
>>> elapsed += System.nanoTime();
>>> }
>>> System.out.format("Elapsed time reading %s using %s is %d milli
>>> seconds\n",args[1],args[0],elapsed/1000000);
>>> }
>>> catch (Exception ex)
>>> {
>>> ex.printStackTrace();
>>> }
>>> }
>>> }
>>>
>>> I get the following when I load a 24 bit RGB jpeg image of 240x240
>>> (test.jpg):
>>>
>>>> java test imageio test.jpg
>>> Elapsed time reading test.jpg using imageio is 89 milli seconds
>>>
>>>> java test jpeg
>>> Elapsed time reading test.jpg using jpeg is 16 milli seconds
>>>
>>> Am I not turing on something here.
>>> [Message sent by forum member 'byhisdeeds' (byhisdeeds)]
>>>
>>> http://forums.java.net/jive/thread.jspa?messageID=209979
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
>>> For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
>> For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
>>
>
> ----------------
> Brian Burkhalter
> Java Media, Imaging, and Graphics
> Sun Microsystems, Inc.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> This email message is for the sole use of the intended recipient(s)
> and may contain confidential and privileged information. Any
> unauthorized review, use, disclosure or distribution is prohibited.
> If you are not the intended recipient, please contact the sender by
> reply email and destroy all copies of the original message.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
>
>

----------------
Brian Burkhalter
Java Media, Imaging, and Graphics
Sun Microsystems, Inc.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any
unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

byhisdeeds
Offline
Joined: 2006-01-06

I tired it about 10 times and the numbers are within a couple of milli seconds of each other.

With regards to using a BufferedInputStream instead of a FileInputStream, is the former faster?

byhisdeeds
Offline
Joined: 2006-01-06

I just tried the BufferedInputStream instead of FileInpoutStream for ImageIO.read(...) and the results are the same.

import java.awt.image.*;
import java.io.*;
import javax.imageio.ImageIO;

import com.sun.image.codec.jpeg.JPEGCodec;

public class test
{

public test()
{
}

/**
* @param args the command line arguments
*/
public static void main(String[] args)
{
try
{
FileInputStream fis = new FileInputStream(args[1]);
long elapsed = 0;
if (args[0].equalsIgnoreCase("imageio"))
{
elapsed = -System.nanoTime();
BufferedImage bimg = ImageIO.read(new BufferedInputStream(fis));
elapsed += System.nanoTime();
}
else if (args[0].equalsIgnoreCase("jpeg"))
{
elapsed = -System.nanoTime();
BufferedImage bimg = JPEGCodec.createJPEGDecoder(
new BufferedInputStream(fis)).decodeAsBufferedImage();
elapsed += System.nanoTime();
}
System.out.format("Elapsed time reading %s using %s is %d milli seconds\n",args[1],args[0],elapsed/1000000);
}
catch (Exception ex)
{
ex.printStackTrace();
}
}
}

Harald Kuhr

Hi,

Try:

ImageIO.setUseCache(false);

Which disables the read-through disk based caching ImageIO uses by default.
This should give ImageIO quite similar read times.

>java -cp build TestJPEG jpeg test.jpg
Elapsed time reading test.jpg using jpeg is 1.0608 milliseconds

>java -cp build TestJPEG imageio test.jpg
Elapsed time reading test.jpg using imageio is 1.1398 milliseconds

Note: I changed the code slightly, this is an average of 10000 iterations,
reading a small JPEG image.

If this is not possible, you could try instantiating a
MemoryCacheImageInputStream directly.

Still, it seems that using the native code of JPEGCodec is a bit faster...
Someone probably has tips for tweaking things further.

--
Harald K

> -----Original Message-----
> From: jai-imageio@javadesktop.org
> [mailto:jai-imageio@javadesktop.org]
> Sent: 27. mars 2007 02:27
> To: interest@jai-imageio.dev.java.net
> Subject: Re: [JAI-IMAGEIO] Retiring the package
> com.sun.image.codec.jpeg
>
> I just tried the BufferedInputStream instead of
> FileInpoutStream for ImageIO.read(...) and the results are the same.
>
> import java.awt.image.*;
> import java.io.*;
> import javax.imageio.ImageIO;
>
> import com.sun.image.codec.jpeg.JPEGCodec;
>
>
> public class test
> {
>
> public test()
> {
> }
>
> /**
> * @param args the command line arguments
> */
> public static void main(String[] args)
> {
> try
> {
> FileInputStream fis = new FileInputStream(args[1]);
> long elapsed = 0;
> if (args[0].equalsIgnoreCase("imageio"))
> {
> elapsed = -System.nanoTime();
> BufferedImage bimg = ImageIO.read(new
> BufferedInputStream(fis));
> elapsed += System.nanoTime();
> }
> else if (args[0].equalsIgnoreCase("jpeg"))
> {
> elapsed = -System.nanoTime();
> BufferedImage bimg = JPEGCodec.createJPEGDecoder(
> new BufferedInputStream(fis)).decodeAsBufferedImage();
> elapsed += System.nanoTime();
> }
> System.out.format("Elapsed time reading %s using %s is
> %d milli seconds\n",args[1],args[0],elapsed/1000000);
> }
> catch (Exception ex)
> {
> ex.printStackTrace();
> }
> }
> }
> [Message sent by forum member 'byhisdeeds' (byhisdeeds)]
>
> http://forums.java.net/jive/thread.jspa?messageID=209988
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail:
> interest-help@jai-imageio.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

byhisdeeds
Offline
Joined: 2006-01-06

I run the test 10 different times.

I tried the ImageIO.setUseCache(false) and the ImageIO use drops from 90 to 70 ms.

byhisdeeds
Offline
Joined: 2006-01-06

OK. I modified the test.java to loop through 10 different files (files are copies of each other).

import java.awt.image.*;
import java.io.*;
import javax.imageio.ImageIO;

import com.sun.image.codec.jpeg.JPEGCodec;

public class test
{

public test()
{
}

/**
* @param args the command line arguments
*/
public static void main(String[] args)
{
try
{
for (int i=1; i<11; i++)
{
//ImageIO.setUseCache(false);
FileInputStream fis = new FileInputStream(args[i]);
long elapsed = 0;
if (args[0].equalsIgnoreCase("imageio"))
{
elapsed = -System.nanoTime();
BufferedImage bimg = ImageIO.read(new BufferedInputStream(fis));
elapsed += System.nanoTime();
}
else if (args[0].equalsIgnoreCase("jpeg"))
{
elapsed = -System.nanoTime();
BufferedImage bimg = JPEGCodec.createJPEGDecoder(
new BufferedInputStream(fis)).decodeAsBufferedImage();
elapsed += System.nanoTime();
}
System.out.format("Elapsed time reading %s using %s is %d milli seconds\n",args[1],args[0],elapsed/1000000);
}
}
catch (Exception ex)
{
ex.printStackTrace();
}
}

}

The command line is:
> java test jpeg 1.jpg 2.jpg 3.jpg 4.jpg 5.jpg 6.jpg 7.jpg 8.jpg 9.jpg 10.jpg
Elapsed time reading 1.jpg using jpeg is 17 milli seconds
Elapsed time reading 1.jpg using jpeg is 2 milli seconds
Elapsed time reading 1.jpg using jpeg is 2 milli seconds
Elapsed time reading 1.jpg using jpeg is 2 milli seconds
Elapsed time reading 1.jpg using jpeg is 2 milli seconds
Elapsed time reading 1.jpg using jpeg is 2 milli seconds
Elapsed time reading 1.jpg using jpeg is 2 milli seconds
Elapsed time reading 1.jpg using jpeg is 2 milli seconds
Elapsed time reading 1.jpg using jpeg is 2 milli seconds
Elapsed time reading 1.jpg using jpeg is 3 milli seconds

and

> java test imageio 1.jpg 2.jpg 3.jpg 4.jpg 5.jpg 6.jpg 7.jpg 8.jpg 9.jpg 10.jpg
Elapsed time reading 1.jpg using imageio is 85 milli seconds
Elapsed time reading 1.jpg using imageio is 10 milli seconds
Elapsed time reading 1.jpg using imageio is 10 milli seconds
Elapsed time reading 1.jpg using imageio is 9 milli seconds
Elapsed time reading 1.jpg using imageio is 10 milli seconds
Elapsed time reading 1.jpg using imageio is 16 milli seconds
Elapsed time reading 1.jpg using imageio is 57 milli seconds
Elapsed time reading 1.jpg using imageio is 3 milli seconds
Elapsed time reading 1.jpg using imageio is 3 milli seconds
Elapsed time reading 1.jpg using imageio is 3 milli seconds

If I now use ImageIO.setUseCache(false) in the imageio case I get:

> java test imageio 1.jpg 2.jpg 3.jpg 4.jpg 5.jpg 6.jpg 7.jpg 8.jpg 9.jpg 10.jpg
Elapsed time reading 1.jpg using imageio is 70 milli seconds
Elapsed time reading 1.jpg using imageio is 9 milli seconds
Elapsed time reading 1.jpg using imageio is 9 milli seconds
Elapsed time reading 1.jpg using imageio is 9 milli seconds
Elapsed time reading 1.jpg using imageio is 9 milli seconds
Elapsed time reading 1.jpg using imageio is 9 milli seconds
Elapsed time reading 1.jpg using imageio is 29 milli seconds
Elapsed time reading 1.jpg using imageio is 9 milli seconds
Elapsed time reading 1.jpg using imageio is 51 milli seconds
Elapsed time reading 1.jpg using imageio is 3 milli seconds

Repeat invocations of the program give similar results (within a couple of milliseconds) for both cases however the JPEGCodec.createJPEGDecoder(..) method gives consistently low numbers

bpb
Offline
Joined: 2004-06-23

We are wondering whether there might be something about this specific file which might provoke the differences. Do you suppose that you could supply the image? You could e-mail directly if necessary (bpb@dev.java.net).

Thanks ...

> OK. I modified the test.java to loop through 10
> different files (files are copies of each other).
>
> import java.awt.image.*;
> import java.io.*;
> import javax.imageio.ImageIO;
>
> import com.sun.image.codec.jpeg.JPEGCodec;
>
>
> public class test
> {
>
> ublic test()
> {
> }
>
> **
> * @param args the command line arguments
> */
> public static void main(String[] args)
> {
> try
> {
> for (int i=1; i<11; i++)
> {
> //ImageIO.setUseCache(false);
> FileInputStream fis = new FileInputStream(args[i]);
> long elapsed = 0;
> if (args[0].equalsIgnoreCase("imageio"))
> {
> elapsed = -System.nanoTime();
> BufferedImage bimg = ImageIO.read(new
> BufferedInputStream(fis));
> elapsed += System.nanoTime();
>
> else if (args[0].equalsIgnoreCase("jpeg"))
> {
> elapsed = -System.nanoTime();
> BufferedImage bimg =
> bimg = JPEGCodec.createJPEGDecoder(
> new
> BufferedInputStream(fis)).decodeAsBufferedImage();
> elapsed += System.nanoTime();
> }
> System.out.format("Elapsed time reading %s
> using %s is %d milli
> seconds\n",args[1],args[0],elapsed/1000000);
> }
> }
> catch (Exception ex)
> {
> ex.printStackTrace();
>
> }
>
>
>
> The command line is:
> > java test jpeg 1.jpg 2.jpg 3.jpg 4.jpg 5.jpg 6.jpg
> 7.jpg 8.jpg 9.jpg 10.jpg
> Elapsed time reading 1.jpg using jpeg is 17 milli
> seconds
> Elapsed time reading 1.jpg using jpeg is 2 milli
> seconds
> Elapsed time reading 1.jpg using jpeg is 2 milli
> seconds
> Elapsed time reading 1.jpg using jpeg is 2 milli
> seconds
> Elapsed time reading 1.jpg using jpeg is 2 milli
> seconds
> Elapsed time reading 1.jpg using jpeg is 2 milli
> seconds
> Elapsed time reading 1.jpg using jpeg is 2 milli
> seconds
> Elapsed time reading 1.jpg using jpeg is 2 milli
> seconds
> Elapsed time reading 1.jpg using jpeg is 2 milli
> seconds
> Elapsed time reading 1.jpg using jpeg is 3 milli
> seconds
>
> and
>
> > java test imageio 1.jpg 2.jpg 3.jpg 4.jpg 5.jpg
> 6.jpg 7.jpg 8.jpg 9.jpg 10.jpg
> Elapsed time reading 1.jpg using imageio is 85 milli
> seconds
> Elapsed time reading 1.jpg using imageio is 10 milli
> seconds
> Elapsed time reading 1.jpg using imageio is 10 milli
> seconds
> Elapsed time reading 1.jpg using imageio is 9 milli
> seconds
> Elapsed time reading 1.jpg using imageio is 10 milli
> seconds
> Elapsed time reading 1.jpg using imageio is 16 milli
> seconds
> Elapsed time reading 1.jpg using imageio is 57 milli
> seconds
> Elapsed time reading 1.jpg using imageio is 3 milli
> seconds
> Elapsed time reading 1.jpg using imageio is 3 milli
> seconds
> Elapsed time reading 1.jpg using imageio is 3 milli
> seconds
>
> If I now use ImageIO.setUseCache(false) in the
> imageio case I get:
>
> > java test imageio 1.jpg 2.jpg 3.jpg 4.jpg 5.jpg
> 6.jpg 7.jpg 8.jpg 9.jpg 10.jpg
> Elapsed time reading 1.jpg using imageio is 70 milli
> seconds
> Elapsed time reading 1.jpg using imageio is 9 milli
> seconds
> Elapsed time reading 1.jpg using imageio is 9 milli
> seconds
> Elapsed time reading 1.jpg using imageio is 9 milli
> seconds
> Elapsed time reading 1.jpg using imageio is 9 milli
> seconds
> Elapsed time reading 1.jpg using imageio is 9 milli
> seconds
> Elapsed time reading 1.jpg using imageio is 29 milli
> seconds
> Elapsed time reading 1.jpg using imageio is 9 milli
> seconds
> Elapsed time reading 1.jpg using imageio is 51 milli
> seconds
> Elapsed time reading 1.jpg using imageio is 3 milli
> seconds
>
> Repeat invocations of the program give similar
> results (within a couple of milliseconds) for both
> cases however the JPEGCodec.createJPEGDecoder(..)
> method gives consistently low numbers

nalte
Offline
Joined: 2006-02-01

Phil,

can you please point out how the functionality of JPEGEncodeParam (e.g. setQuality(...)) is reflected in the ImageIO API.

Thanks, Hans

Phil Race

ImageI/O has ImageReadParam and ImageWriteParam
The latter has a method the setCompressionQuality()

The package javax.imageio.plugins.jpeg contains several classes which
provide control over the encoding and decoding process similar to
that provided in com.sun.image.codec.jpeg including subclasses of
those generic classes.

javax.imageio.plugins.jpeg.JPEGImageWriteParam dicusses quality settings
in its class javadoc.

>the quality setting in an |ImageWriteParam| has the same meaning as
for the underlying library:
>1.00 means a quantization table of all 1's, 0.75 means the "standard",
visually lossless quantization table,
>and 0.00 means aquantization table of all 255's.

-phil.

jai-imageio@javadesktop.org wrote:
> Phil,
>
> can you please point out how the functionality of JPEGEncodeParam (e.g. setQuality(...)) is reflected in the ImageIO API.
>
> Thanks, Hans
> [Message sent by forum member 'nalte' (nalte)]
>
> http://forums.java.net/jive/thread.jspa?messageID=205170
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

nopjn
Offline
Joined: 2003-12-27

For server-side Java, you can remove it. If someone wants to change its version of runtime, I hope some tests will be done before putting it on production.

For client-side Java, isn't Java Kernel the right answer ? Remove the code from the core and when someone needs it, it can be dynamically downloaded.

Phil Race

jai-imageio@javadesktop.org wrote:
> For server-side Java, you can remove it. If someone wants to change its version of runtime, I hope some tests will be done before putting it on production.
>

I hope so.

> For client-side Java, isn't Java Kernel the right answer ? Remove the code from the core and when someone needs it, it can be dynamically downloaded.
> [Message sent by forum member 'nopjn' (nopjn)]
>

This goal isn't to save download footprint. The goal is to retire this API.
Any way of making it 'separately available' doesn't achieve that.

-phil.

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net