Skip to main content

[JAI-IMAGEIO] TIFF bi-level encodings user: please try the latest daily build

13 replies [Last post]
Anonymous

If you read T.4 or T.6 compressed bi-level TIFF images, please try the latest
daily build 2006-06-27 or newer

https://jai-imageio.dev.java.net/binary-builds.html#Daily_builds_1.1

which containts some fundamental changes to the T.4 and T.6 decoding methods
which we hope will make them more robust.

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.
Aaron Bruegl

I tested some of my problem images with the 28_Jun_2006 build.

* I still get the error with the native libs included detailed in the
"JVM Crash on tiff read!!!" thread
* I could no longer get the "Error 6" on some of my G3 faxes, so this
looks fixed
* On some images that display fine in the MS fax viewer (with one good
page and one undisplayable page - result of corruption, it really should
only have the one good page), I get this

Exception in thread "main" java.lang.NullPointerException
at
com.sun.media.imageioimpl.plugins.tiff.TIFFImageReader.getTileOrStripOffset(TIFFImageReader.java:453)
at
com.sun.media.imageioimpl.plugins.tiff.TIFFImageReader.decodeTile(TIFFImageReader.java:1122)
at
com.sun.media.imageioimpl.plugins.tiff.TIFFImageReader.read(TIFFImageReader.java:1412)
at javax.imageio.ImageReader.read(ImageReader.java:923)

So trying to read with JAI results in this error:

Exception in thread "main" java.lang.RuntimeException: Invalid code
encountered.
at
com.sun.media.jai.codecimpl.TIFFFaxDecoder.decodeNextScanline(TIFFFaxDecoder.java:612)
at
com.sun.media.jai.codecimpl.TIFFFaxDecoder.decode2D(TIFFFaxDecoder.java:879)
at
com.sun.media.jai.codecimpl.TIFFImage.getTile(TIFFImage.java:1072)
at
javax.media.jai.RenderedImageAdapter.getTile(RenderedImageAdapter.java:148)
at javax.media.jai.NullOpImage.computeTile(NullOpImage.java:162)
at
com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904)
at javax.media.jai.OpImage.getTile(OpImage.java:1129)
at javax.media.jai.PlanarImage.getData(PlanarImage.java:2090)
at javax.media.jai.RenderedOp.getData(RenderedOp.java:2275)
at
com.sun.media.jai.codecimpl.TIFFImageEncoder.encode(TIFFImageEncoder.java:1011)
at
com.sun.media.jai.codecimpl.TIFFImageEncoder.encode(TIFFImageEncoder.java:151)

So I guess my question would be is there a bug on file to fix the native
lib part? Would you like a sample image for the error in the 3rd point?

Thank you,
-Aaron Bruegl

Brian Burkhalter wrote:
> If you read T.4 or T.6 compressed bi-level TIFF images, please try the
> latest daily build 2006-06-27 or newer
>
> https://jai-imageio.dev.java.net/binary-builds.html#Daily_builds_1.1
>
> which containts some fundamental changes to the T.4 and T.6 decoding
> methods which we hope will make them more robust.
>
> Thanks,
>
> Brian
>
> ----------------
> Brian Burkhalter
> Java Media, Imaging, and Graphics
> Sun Microsystems, Inc.

---------------------------------------------------------------------
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 Wed, 28 Jun 2006, Aaron Bruegl wrote:

> I tested some of my problem images with the 28_Jun_2006 build.
>
> * I still get the error with the native libs included detailed in the "JVM
> Crash on tiff read!!!" thread

This problem is in the native code and was not addressed in the recent
checkin. Please make sure there is an issue on file in jai-imageio-core.

> * I could no longer get the "Error 6" on some of my G3 faxes, so this looks
> fixed

Good: that was the target here.

> * On some images that display fine in the MS fax viewer (with one good page
> and one undisplayable page - result of corruption, it really should only have
> the one good page), I get this
>
> Exception in thread "main" java.lang.NullPointerException
> at

[...]

> So trying to read with JAI results in this error:
>
> Exception in thread "main" java.lang.RuntimeException: Invalid code
> encountered.

[...]

> So I guess my question would be is there a bug on file to fix the native lib
> part?

I don't see one.

> Would you like a sample image for the error in the 3rd point?

Yes, please.

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

Robert Engels

I have a question about the additional DLLs on windows.

I am curious as to why the clib_sse2.dll is so large (what does it contain
vs. previous releases?).

Doesn't this just map calls into existing dlls in the JVM dlls? And if so, I
would think it would be much smaller. Does it maybe have debug info compiled
in?

Thanks,
Robert

-----Original Message-----
From: Brian.Burkhalter@Sun.COM [mailto:Brian.Burkhalter@Sun.COM]
Sent: Tuesday, June 27, 2006 10:24 AM
To: JAI-Image I/O discussion list
Subject: [JAI-IMAGEIO] TIFF bi-level encodings user: please try the latest
daily build

If you read T.4 or T.6 compressed bi-level TIFF images, please try the
latest daily build 2006-06-27 or newer

https://jai-imageio.dev.java.net/binary-builds.html#Daily_builds_1.1

which containts some fundamental changes to the T.4 and T.6 decoding methods
which we hope will make them more robust.

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

James Cheng

Hi Robert,

> I have a question about the additional DLLs on windows.
>
> I am curious as to why the clib_sse2.dll is so large (what does it contain
> vs. previous releases?).

clib_jiio_sse2.dll contains exactly the same functions as those
in clib_jiio.dll. But some functions in clib_jiio_sse2.dll for
JPEG codec were implemented with SSE2/MMX instructions for better
performance. It was added mainly for fixing this bug:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5094376

In terms of size, clib_jiio_sse2.dll is actually smaller than
clib_jiio.dll:

1064960 May 15 10:24 clib_jiio.dll
1032192 May 15 10:24 clib_jiio_sse2.dll
20480 May 15 10:24 clib_jiio_util.dll

> Doesn't this just map calls into existing dlls in the JVM dlls? And if so, I
> would think it would be much smaller. Does it maybe have debug info compiled
> in?

These dlls have nothing to do with the dlls in the JVM. They are
part of codecLib (or clib) for JPEG, JPEG 2000, PNG, G3Fax (T.4),
and G4Fax (T.6) codecs.

HTH,
-James

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

But you need both dlls to be downloaded, correct? So effectively the size of
the dll component has nearly doubled.

I guess the basic question is (in reading the bug you refer to), it seems
the JVM jpeg reader was faster, and _sse2 is designed to make the ImageIO
plugin as fast as the JVM jpeg reader - but why doesn't the ImageIO plugin
just defer to the JVM to read JPEGs (without needing another dll - or have
the _sse2 dll the same native methods in the JVM) - wouldn't the effect be
the same? (No need to duplicate the code between _sse2 and the JVM).

I am probably just not understanding the packaging or dependencies.

-----Original Message-----
From: James.Cheng@Sun.COM [mailto:James.Cheng@Sun.COM]
Sent: Tuesday, June 27, 2006 12:21 PM
To: interest@jai-imageio.dev.java.net
Subject: Re: [JAI-IMAGEIO] TIFF bi-level encodings user: please try the
latest daily build

Hi Robert,

> I have a question about the additional DLLs on windows.
>
> I am curious as to why the clib_sse2.dll is so large (what does it
> contain vs. previous releases?).

clib_jiio_sse2.dll contains exactly the same functions as those in
clib_jiio.dll. But some functions in clib_jiio_sse2.dll for JPEG codec were
implemented with SSE2/MMX instructions for better performance. It was added
mainly for fixing this bug:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5094376

In terms of size, clib_jiio_sse2.dll is actually smaller than
clib_jiio.dll:

1064960 May 15 10:24 clib_jiio.dll
1032192 May 15 10:24 clib_jiio_sse2.dll
20480 May 15 10:24 clib_jiio_util.dll

> Doesn't this just map calls into existing dlls in the JVM dlls? And if
> so, I would think it would be much smaller. Does it maybe have debug
> info compiled in?

These dlls have nothing to do with the dlls in the JVM. They are part of
codecLib (or clib) for JPEG, JPEG 2000, PNG, G3Fax (T.4), and G4Fax (T.6)
codecs.

HTH,
-James

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

James Cheng

On 2006/06/27 11:28 AM, Robert Engels wrote:
> But you need both dlls to be downloaded, correct? So effectively the size of
> the dll component has nearly doubled.

Right, currently you can not download individual dlls.

> I guess the basic question is (in reading the bug you refer to), it seems
> the JVM jpeg reader was faster, and _sse2 is designed to make the ImageIO
> plugin as fast as the JVM jpeg reader - but why doesn't the ImageIO plugin
> just defer to the JVM to read JPEGs (without needing another dll - or have
> the _sse2 dll the same native methods in the JVM) - wouldn't the effect be
> the same? (No need to duplicate the code between _sse2 and the JVM).

The clib JPEG plugin supports JPEG-LOSSLESS and JPEG-LS while the core
JPEG plugin doesn't. If you don't need that feature, you can skip the
clib dlls.

Other codecs in the _sse2 dll might be faster than their counterparts
in clib_jiio.dll, as more aggressive optimization flags were used when
building the _sse2 dll.

> I am probably just not understanding the packaging or dependencies.

If all installed properly, two JPEG plugins are available: clib JPEG and
core J2SE JPEG, with the former has a higher priority by default in the
registry.

-James

---------------------------------------------------------------------
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 apologize, but I must be missing something.

#1. Do I need both clib_jiio.dll and clib_sse2.dll ? If not, in what cases
is _jiio.dll used vs. _sse2.dll?

#2. There never used to be an _sse2.dll - this was added. What is it used
for?

#3. What codecs require the native dll's? (I thought originally ImageIO
stated that all features would be provided available in non-native
installations).

Just trying to get an idea on the packaging.

Thanks.

-----Original Message-----
From: James.Cheng@Sun.COM [mailto:James.Cheng@Sun.COM]
Sent: Tuesday, June 27, 2006 1:44 PM
To: interest@jai-imageio.dev.java.net
Subject: Re: [JAI-IMAGEIO] TIFF bi-level encodings user: please try the
latest daily build

On 2006/06/27 11:28 AM, Robert Engels wrote:
> But you need both dlls to be downloaded, correct? So effectively the
> size of the dll component has nearly doubled.

Right, currently you can not download individual dlls.

> I guess the basic question is (in reading the bug you refer to), it
> seems the JVM jpeg reader was faster, and _sse2 is designed to make
> the ImageIO plugin as fast as the JVM jpeg reader - but why doesn't
> the ImageIO plugin just defer to the JVM to read JPEGs (without
> needing another dll - or have the _sse2 dll the same native methods in
> the JVM) - wouldn't the effect be the same? (No need to duplicate the code
between _sse2 and the JVM).

The clib JPEG plugin supports JPEG-LOSSLESS and JPEG-LS while the core JPEG
plugin doesn't. If you don't need that feature, you can skip the clib dlls.

Other codecs in the _sse2 dll might be faster than their counterparts in
clib_jiio.dll, as more aggressive optimization flags were used when building
the _sse2 dll.

> I am probably just not understanding the packaging or dependencies.

If all installed properly, two JPEG plugins are available: clib JPEG and
core J2SE JPEG, with the former has a higher priority by default in the
registry.

-James

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

James Cheng

On 2006/06/27 11:54 AM, Robert Engels wrote:
> I apologize, but I must be missing something.
>
> #1. Do I need both clib_jiio.dll and clib_sse2.dll ? If not, in what cases
> is _jiio.dll used vs. _sse2.dll?

Technically, only one is needed for a given system. The
clib_jiio_util.dll is loaded first to help checking whether
the underlying cpu supports SSE2. If yes, clib_jiio_sse2.dll
is loaded. Otherwise, clib_jiio.dll is loaded.

> #2. There never used to be an _sse2.dll - this was added. What is it used
> for?

As I said earlier, it was added mainly for fixing that performance
bug. But, for future releases we might use SSE2 in more functions
for better performance.

> #3. What codecs require the native dll's? (I thought originally ImageIO
> stated that all features would be provided available in non-native
> installations).

Currently, only the JPEG plugin with JPEG-LOSSLESS and JPEG-LS
support doesn't have a counterpart in pure Java (or core) plugins.

-James

---------------------------------------------------------------------
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, 27 Jun 2006, James Cheng wrote:

>> #3. What codecs require the native dll's? (I thought originally ImageIO
>> stated that all features would be provided available in non-native
>> installations).
>
> Currently, only the JPEG plugin with JPEG-LOSSLESS and JPEG-LS
> support doesn't have a counterpart in pure Java (or core) plugins.

That is exactly correct.

Note also that sans the native shared libraries the PNG and native-based JPEG
2000 plug-ins in JAI Image I/O Tools will "disappear" and there will not be
any native acceleration of the bi-level encodings in TIFF. All of these things
should in theory represent differences in performance only as opposed to
actual loss of functionality which is what James pointed out.

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

Robert Engels

So if the DDLs are removed there will be no PNG support?

Should we maybe work on a ImageIO Reader that differs to the JVM Toolkit to
read images?

-----Original Message-----
From: Brian.Burkhalter@Sun.COM [mailto:Brian.Burkhalter@Sun.COM]
Sent: Tuesday, June 27, 2006 6:29 PM
To: interest@jai-imageio.dev.java.net
Subject: Re: [JAI-IMAGEIO] TIFF bi-level encodings user: please try the
latest daily build

On Tue, 27 Jun 2006, James Cheng wrote:

>> #3. What codecs require the native dll's? (I thought originally
>> ImageIO stated that all features would be provided available in
>> non-native installations).
>
> Currently, only the JPEG plugin with JPEG-LOSSLESS and JPEG-LS support
> doesn't have a counterpart in pure Java (or core) plugins.

That is exactly correct.

Note also that sans the native shared libraries the PNG and native-based
JPEG 2000 plug-ins in JAI Image I/O Tools will "disappear" and there will
not be any native acceleration of the bi-level encodings in TIFF. All of
these things should in theory represent differences in performance only as
opposed to actual loss of functionality which is what James pointed out.

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

> So if the DDLs are removed there will be no PNG support?

No PNG support in JAI Image I/O Tools but the plug-ins in J2SE will still be
there.

> Should we maybe work on a ImageIO Reader that differs to the JVM Toolkit to
> read images?

I don't exactly understand the question. I'm going to follow this up with
another posting entitled "Which formats are supported by what".

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

Robert Engels

I keep forgetting that there are standard IMageIO plugins as part of the
J2SE, but this is not the same code as used by ToolKit.createImage().

I seem to recall that ToolKit.createImage() was better at reading some image
formats than the standard J2SE ImageIO plugins.

I know it is not your area, but do you know if there are any plans to merge
the ToolKit code and the standard ImageIO plugins? Maybe make
ToolKit.createImage() differ to ImageIO? If not, maybe we should create a
Reader tools plugin that differs to ToolKit.createImage()?

-----Original Message-----
From: Brian.Burkhalter@Sun.COM [mailto:Brian.Burkhalter@Sun.COM]
Sent: Tuesday, June 27, 2006 6:41 PM
To: interest@jai-imageio.dev.java.net
Subject: RE: [JAI-IMAGEIO] TIFF bi-level encodings user: please try the
latest daily build

> So if the DDLs are removed there will be no PNG support?

No PNG support in JAI Image I/O Tools but the plug-ins in J2SE will still be
there.

> Should we maybe work on a ImageIO Reader that differs to the JVM
> Toolkit to read images?

I don't exactly understand the question. I'm going to follow this up with
another posting entitled "Which formats are supported by what".

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 this topic you'd do better to post to java2d-interest@java.sun.com.

On Tue, 27 Jun 2006, Robert Engels wrote:

> I keep forgetting that there are standard IMageIO plugins as part of the
> J2SE, but this is not the same code as used by ToolKit.createImage().
>
> I seem to recall that ToolKit.createImage() was better at reading some image
> formats than the standard J2SE ImageIO plugins.
>
> I know it is not your area, but do you know if there are any plans to merge
> the ToolKit code and the standard ImageIO plugins? Maybe make
> ToolKit.createImage() differ to ImageIO? If not, maybe we should create a
> Reader tools plugin that differs to ToolKit.createImage()?
>
> -----Original Message-----
> From: Brian.Burkhalter@Sun.COM [mailto:Brian.Burkhalter@Sun.COM]
> Sent: Tuesday, June 27, 2006 6:41 PM
> To: interest@jai-imageio.dev.java.net
> Subject: RE: [JAI-IMAGEIO] TIFF bi-level encodings user: please try the
> latest daily build
>
>> So if the DDLs are removed there will be no PNG support?
>
> No PNG support in JAI Image I/O Tools but the plug-ins in J2SE will still be
> there.
>
>> Should we maybe work on a ImageIO Reader that differs to the JVM
>> Toolkit to read images?
>
> I don't exactly understand the question. I'm going to follow this up with
> another posting entitled "Which formats are supported by what".
>
> 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