Skip to main content

[JAI-IMAGEIO] JPEG 2000 reader speed improvement

6 replies [Last post]
Anonymous

Hello everyone.

I just checked in a fix for the Java JPEG 2000 reader plug-in which in my
testing improved reading speed by a factor or more than 3 (no kidding). It
should also greatly reduce memory consumption at least in the case of
file-based streams, probably by an amount about equal to the input file size.
It is available in the CVS tree right now and will be in the daily build of
2006-08-08 which will be built in about 6-7 hours from.

If you use the Java JPEG 2000 reader plug-in, please give this a try and let
us know the outcome, good or bad, at your earliest convenience.

Thanks,

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

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
scyudits
Offline
Joined: 2005-07-15
Points: 0

Hi Brian,

Where can I access the CVS tree or daily build to download the new version?

Thanks,

Sophia

James Cheng

Hi Sophia,

> Where can I access the CVS tree or daily build to download the new version?

https://jai-imageio-core.dev.java.net/source/browse/jai-imageio-core/
https://jai-imageio.dev.java.net/binary-builds.html

Thanks,
-James

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

Nidel, Mike

Can you tell us the nature of the fix?

It's been a long time since we benchmarked the java and native
decoders in JAI ImageIO Tools and we found that for large images
they were essentially useless. They each had different problems,
but the key thing was they both were inefficient reading tiles,
and they both failed to release memory. I don't remember the details
though.

> -----Original Message-----
> From: Brian.Burkhalter@Sun.COM [mailto:Brian.Burkhalter@Sun.COM]
> Sent: Monday, August 07, 2006 8:45 PM
> To: JAI-Image I/O discussion list
> Subject: [JAI-IMAGEIO] JPEG 2000 reader speed improvement
>
>
> Hello everyone.
>
> I just checked in a fix for the Java JPEG 2000 reader plug-in
> which in my
> testing improved reading speed by a factor or more than 3 (no
> kidding). It
> should also greatly reduce memory consumption at least in the case of
> file-based streams, probably by an amount about equal to the
> input file size. It is available in the CVS tree right now
> and will be in the daily build of
> 2006-08-08 which will be built in about 6-7 hours from.
>
> If you use the Java JPEG 2000 reader plug-in, please give
> this a try and let
> us know the outcome, good or bad, at your earliest convenience.
>
> Thanks,
>
> 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
>
>

---------------------------------------------------------------------
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

On Tue, 8 Aug 2006, Nidel, Mike wrote:

> Can you tell us the nature of the fix?

The ImageInputStream was being wrapped into an InputStream which was in turn
being wrapped into a RandomAccessIO. RandomAccessIO is a JJ2000 interface
which is quite similar to ImageInputStream. The implementation class,
ISRandomAccessIO, is quite similar to MemoryCacheImageInputStream, and caches
the *entire* input stream in memory eventually. Also, the implementation class
was reading just a single byte at a time. The updated implementation simply
provides a RandomAccessIO implementation that wraps an ImageInputStream, i.e.,
just forwards its calls to the ImageInputStream. This eliminates the
byte-by-byte reading behavior as well as the extra caching of data in memory.

We are working to improve the JPEG 2000 plug-ins stating with the reader(s) so
hopefully we will be able to bring them in time up to a standard of quality
sufficient to most if not all applications.

> It's been a long time since we benchmarked the java and native
> decoders in JAI ImageIO Tools and we found that for large images
> they were essentially useless. They each had different problems,
> but the key thing was they both were inefficient reading tiles,
> and they both failed to release memory. I don't remember the details
> though.
>
>> -----Original Message-----
>> From: Brian.Burkhalter@Sun.COM [mailto:Brian.Burkhalter@Sun.COM]
>> Sent: Monday, August 07, 2006 8:45 PM
>> To: JAI-Image I/O discussion list
>> Subject: [JAI-IMAGEIO] JPEG 2000 reader speed improvement
>>
>>
>> Hello everyone.
>>
>> I just checked in a fix for the Java JPEG 2000 reader plug-in
>> which in my
>> testing improved reading speed by a factor or more than 3 (no
>> kidding). It
>> should also greatly reduce memory consumption at least in the case of
>> file-based streams, probably by an amount about equal to the
>> input file size. It is available in the CVS tree right now
>> and will be in the daily build of
>> 2006-08-08 which will be built in about 6-7 hours from.
>>
>> If you use the Java JPEG 2000 reader plug-in, please give
>> this a try and let
>> us know the outcome, good or bad, at your earliest convenience.
>>
>> Thanks,
>>
>> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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

Ken Warner

The complexity below is a result -- I think -- of the fact that JJ2000 was supposed to be both a reference implementation of the JPEG 2K codec AND a stand alone demonstration program. None of it's classes -- at least those that I saw when I was hacking on it -- were meant to be reusable by other apps/applets.

I really think that JJ2000 should be scrapped and a whole new implementation of JPEG 2K codec be written from scratch. In the long run it would cost less than to try an reverse engineer and extract working pieces from JJ2000.

Just my humble opinion.

Brian Burkhalter wrote:
> On Tue, 8 Aug 2006, Nidel, Mike wrote:
>
>> Can you tell us the nature of the fix?
>
>
> The ImageInputStream was being wrapped into an InputStream which was in
> turn being wrapped into a RandomAccessIO. RandomAccessIO is a JJ2000
> interface which is quite similar to ImageInputStream. The implementation
> class, ISRandomAccessIO, is quite similar to
> MemoryCacheImageInputStream, and caches the *entire* input stream in
> memory eventually. Also, the implementation class was reading just a
> single byte at a time. The updated implementation simply provides a
> RandomAccessIO implementation that wraps an ImageInputStream, i.e., just
> forwards its calls to the ImageInputStream. This eliminates the
> byte-by-byte reading behavior as well as the extra caching of data in
> memory.
>
> We are working to improve the JPEG 2000 plug-ins stating with the
> reader(s) so hopefully we will be able to bring them in time up to a
> standard of quality sufficient to most if not all applications.
>
>> It's been a long time since we benchmarked the java and native
>> decoders in JAI ImageIO Tools and we found that for large images
>> they were essentially useless. They each had different problems,
>> but the key thing was they both were inefficient reading tiles,
>> and they both failed to release memory. I don't remember the details
>> though.
>>
>>> -----Original Message-----
>>> From: Brian.Burkhalter@Sun.COM [mailto:Brian.Burkhalter@Sun.COM]
>>> Sent: Monday, August 07, 2006 8:45 PM
>>> To: JAI-Image I/O discussion list
>>> Subject: [JAI-IMAGEIO] JPEG 2000 reader speed improvement
>>>
>>>
>>> Hello everyone.
>>>
>>> I just checked in a fix for the Java JPEG 2000 reader plug-in
>>> which in my
>>> testing improved reading speed by a factor or more than 3 (no
>>> kidding). It
>>> should also greatly reduce memory consumption at least in the case of
>>> file-based streams, probably by an amount about equal to the
>>> input file size. It is available in the CVS tree right now
>>> and will be in the daily build of
>>> 2006-08-08 which will be built in about 6-7 hours from.
>>>
>>> If you use the Java JPEG 2000 reader plug-in, please give
>>> this a try and let
>>> us know the outcome, good or bad, at your earliest convenience.
>>>
>>> Thanks,
>>>
>>> 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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>

---------------------------------------------------------------------
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

On Tue, 8 Aug 2006, Ken Warner wrote:

> The complexity below is a result -- I think -- of the fact that JJ2000 was
> supposed to be both a reference implementation of the JPEG 2K codec AND a
> stand alone demonstration program. None of it's classes -- at least those
> that I saw when I was hacking on it -- were meant to be reusable by other
> apps/applets.

I think it is more a result of timing. They completed the JJ2000
implementation in September 2001 but J2SE 1.4, which introduced Image I/O, was
not out until Spring 2002. The byte-by-byte reading, which was the main cause
of the slowness, was actually introduced some time back when JJ2000 was
adapted for Image I/O but was not in JJ2000 per se.

> I really think that JJ2000 should be scrapped and a whole new implementation
> of JPEG 2K codec be written from scratch. In the long run it would cost less
> than to try an reverse engineer and extract working pieces from JJ2000.

I'm not so sure about that. I think it is worth investigating first whether it
can be fixed.

> Just my humble opinion.

I don't have one yet for lack of information ... ;-)

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