Skip to main content

[JAI-IMAGEIO] About the JPEG reading performance

3 replies [Last post]
Anonymous

Hello.

As my imaging application uses JPEG for encoding thumbnails, and
there are batches of thumbnails that need to be shown as quick as
possible, I need to optimize the things in this area.

I've read previous emails and links about this topic, and I
understand that at the moment the performance in this area is not
good. I need to have some confirmations:

1. JAI provides its own optimized JPEG reader, but it needs the
native libraries (which I don't have, as I'm on Mac OS X) - in this
case it falls back to the ImageI/O reader, right?
2. JAI provides also a JPEG2000 reader/writer, but its performance is
poor without the native libraries;
3. Should I use the TIFF writer/reader with JPEG compression, would
it use the same code of the JPEG codecs? Or would it be faster/
slower? The point is that I can control the format of the thumbnails,
and I could use a different format than JPEG if it was convenient:
any other format could be faster? I need to get a compression similar
to JPEG though.

Also, I've just changed my code to use all the cores on my laptop
(that is, processing two images in parallel) and I got a surprise:
the time to read a JPEG (400x400) using a single core is around
130msec (mean duration in 50 rounds), while the time to read two
JPEGs (same file) using two cores at the same time is 230msec. It's
getting worse instead of improving. Note that the test is done
reading the image from two distinct memory buffers, thus the disk I/O
access etc... can't be an issue. Maybe the native code for the JPEG
stuff is single thread?

Thanks.

--
Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
Fabrizio.Giudici@tidalwave.it - mobile: +39 348.150.6941

[att1.html]

Reply viewing options

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

Fabrizio,

> 1. JAI provides its own optimized JPEG reader, but it needs the native
> libraries (which I don't have, as I'm on Mac OS X) - in this case it falls
> back to the ImageI/O reader, right?

I think you mean JAI Image I/O Tools. If so, that is correct. JAI itself
provides a JPEG decoder that merely wraps the com.sun.image.codec.jpeg package
bundled with Java SE. Both it and the Java SE JPEG reader eventually use
native code. Actually all of the JPEG decoder/readers do ...

> 2. JAI provides also a JPEG2000 reader/writer, but its performance is poor
> without the native libraries;

Poor is an absolute term. It is slower than the native libraries in many
cases. The computational complexity of JPEG2000 as opposed to baseline DCT
JPEG is from what I understand about double.

> 3. Should I use the TIFF writer/reader with JPEG compression, would it use
> the same code of the JPEG codecs?

It would eventually use one of the JPEG implementations.

> Or would it be faster/slower? The point is
> that I can control the format of the thumbnails, and I could use a different
> format than JPEG if it was convenient: any other format could be faster? I
> need to get a compression similar to JPEG though.

I don't think you are going to get compression ratios similar to JPEG from any
of the other formats except JPEG 2000.

> Also, I've just changed my code to use all the cores on my laptop (that is,
> processing two images in parallel) and I got a surprise: the time to read a
> JPEG (400x400) using a single core is around 130msec (mean duration in 50
> rounds), while the time to read two JPEGs (same file) using two cores at the
> same time is 230msec. It's getting worse instead of improving.

I must be missing something: 230 msec/ 2 images = 115 msec/image as opposed to
130 msec. How is that worse?

> Note that the
> test is done reading the image from two distinct memory buffers, thus the
> disk I/O access etc... can't be an issue. Maybe the native code for the JPEG
> stuff is single thread?

None of the readers/decoders is multi-threaded. I don't think that this is
even possible in the true sense of the term even for tiled data unless there
were multiple input streams and there are not.

Regards,

Brian

>^..^< >^..^<

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

Fabrizio Giudici

On Oct 3, 2007, at 02:05 , Brian Burkhalter wrote:

> Fabrizio,
>
>> 1. JAI provides its own optimized JPEG reader, but it needs the
>> native libraries (which I don't have, as I'm on Mac OS X) - in
>> this case it falls back to the ImageI/O reader, right?
>
> I think you mean JAI Image I/O Tools.

Yep, sorry, I make always the same mistake...

> Poor is an absolute term. It is slower than the native libraries in
> many cases. The computational complexity of JPEG2000 as opposed to
> baseline DCT JPEG is from what I understand about double.

Ok, this kills it as a possible alternate candidate for me.

>> Also, I've just changed my code to use all the cores on my laptop
>> (that is, processing two images in parallel) and I got a surprise:
>> the time to read a JPEG (400x400) using a single core is around
>> 130msec (mean duration in 50 rounds), while the time to read two
>> JPEGs (same file) using two cores at the same time is 230msec.
>> It's getting worse instead of improving.
>
> I must be missing something: 230 msec/ 2 images = 115 msec/image as
> opposed to 130 msec. How is that worse?

You're right, it's not worse, but it's not even better (but
marginally :-) I expected a slight overhead, but the two tasks to
complete in 150-170 msec.

>
>> Note that the test is done reading the image from two distinct
>> memory buffers, thus the disk I/O access etc... can't be an issue.
>> Maybe the native code for the JPEG stuff is single thread?
>
> None of the readers/decoders is multi-threaded. I don't think that
> this is even possible in the true sense of the term even for tiled
> data unless there were multiple input streams and there are not.

I don't understand this, probably I was not clear. The tests are
performed using two byte buffers, two input streams and two image
readers.

--
Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
Fabrizio.Giudici@tidalwave.it - mobile: +39 348.150.6941

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

robert engels

i think there must be something wrong with your program... I used the
program below.

On a dual core machine, when I ran with 1 thread, the avg time was
708 ms, when I ran with 2 threads it was 390ms. Almost a linear
performance improvement by number or threads/cores.

import java.io.*;
import java.util.*;

import javax.imageio.ImageIO;

import junit.framework.TestCase;

/**
* read an image test program
*/
public class TestMultiThreadRead extends TestCase {
static int NTHREADS = 2;
static int NIMAGES = 50;

static Queue queue = new LinkedList();

public static void main(String[] args) throws Exception {

InputStream is = TestMultiThreadRead.class.getClassLoader
().getResourceAsStream("sample.jpg");
byte[] data = new byte[is.available()];
is.read(data);
is.close();

for(int i=0;i queue.add(data);
}

Thread[] threads = new Thread[NTHREADS];

for(int i=0;i threads[i] = new ReadThead();
threads[i].start();
}
long start = System.currentTimeMillis();
for(int i=0;i threads[i].join();
}
System.out.println("avg time per image "+(System.currentTimeMillis()-
start)/NIMAGES);
}

private static class ReadThead extends Thread {
public void run() {
while(true) {
byte[] data;
synchronized(queue) {
data = queue.poll();
}
if(data==null)
break;
try {
ImageIO.read(new ByteArrayInputStream(data));
} catch (IOException e) {
e.printStackTrace();
}
}
}
}

}

On Oct 2, 2007, at 7:26 PM, Fabrizio Giudici wrote:

>
> On Oct 3, 2007, at 02:05 , Brian Burkhalter wrote:
>
>> Fabrizio,
>>
>>> 1. JAI provides its own optimized JPEG reader, but it needs the
>>> native libraries (which I don't have, as I'm on Mac OS X) - in
>>> this case it falls back to the ImageI/O reader, right?
>>
>> I think you mean JAI Image I/O Tools.
>
> Yep, sorry, I make always the same mistake...
>
>> Poor is an absolute term. It is slower than the native libraries
>> in many cases. The computational complexity of JPEG2000 as opposed
>> to baseline DCT JPEG is from what I understand about double.
>
> Ok, this kills it as a possible alternate candidate for me.
>
>>> Also, I've just changed my code to use all the cores on my laptop
>>> (that is, processing two images in parallel) and I got a
>>> surprise: the time to read a JPEG (400x400) using a single core
>>> is around 130msec (mean duration in 50 rounds), while the time to
>>> read two JPEGs (same file) using two cores at the same time is
>>> 230msec. It's getting worse instead of improving.
>>
>> I must be missing something: 230 msec/ 2 images = 115 msec/image
>> as opposed to 130 msec. How is that worse?
>
> You're right, it's not worse, but it's not even better (but
> marginally :-) I expected a slight overhead, but the two tasks to
> complete in 150-170 msec.
>
>>
>>> Note that the test is done reading the image from two distinct
>>> memory buffers, thus the disk I/O access etc... can't be an
>>> issue. Maybe the native code for the JPEG stuff is single thread?
>>
>> None of the readers/decoders is multi-threaded. I don't think that
>> this is even possible in the true sense of the term even for tiled
>> data unless there were multiple input streams and there are not.
>
> I don't understand this, probably I was not clear. The tests are
> performed using two byte buffers, two input streams and two image
> readers.
>
> --
> Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
> Tidalwave s.a.s. - "We make Java work. Everywhere."
> weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
> Fabrizio.Giudici@tidalwave.it - mobile: +39 348.150.6941
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-
> imageio.dev.java.net
>

[att1.html]