Skip to main content

[JAI-IMAGEIO] How to handle TIFF decoding exceptions (particularly fax images)

11 replies [Last post]
Anonymous

As you all know there have been a lot of postings about exceptions encountered
while reading TIFF streams. These have been particularly salient for the cases
of the ITU T.4 and T.6 (fax group 3 and 4) bi-level compression types. The
effect of these exceptions is that decoding fails for the entire image thereby
causing problems for the application. The ultimate cause of the exceptions in
general is either a non-comformant encoder or a corrupt bitstream. The
proximate cause of the exceptions is the failure of the decoder to recognize
non-fatal situations such that at least part of the image could be read.

One proposed solution to this problem is to trap all IIOExceptions generated
by the TIFFDecompressor being used, print a warning message, and continue with
the next segment, i.e., strip or tile. This solution is supposed to be applied
regardless of the compression type used and is therefore not limited to
bi-level encodings.

Another solution is specific to bi-level encodings. This solution would
change the decoding behavior such that when error conditions from which
recovery might be possible are detected, instead of throwing an exception, a
meaningful warning message would be emitted and decompression would continue
with the next line or segment as appropriate.

Any comments on the relative merits of these two solutions would be welcome as
would be alternate solution proposals.

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.
Robert Engels

I think it is going to depend on the application. For example, if reading
the TIFF of a fingerprint for crime analysis, ANY errors might cause the
program to want to disregard the image, but in other applications some image
corruption is tolerable.

So I suggest always emit every warning that is detected, and always attempt
to continue reading the image. I think the code does need to be careful that
it doesn't get itself into an impossible situation (e.g. a corrupted length,
so it consumes all memory). It is also quite probably that the image will be
"unreadable", but that is certainly the case anyway if it aborted.

I think the major problem right now with the ImageIO tiff reader is the hard
JVM crashes in the native code, and the image decoding problem (of good
images). If it cannot partially decode some corrupted images is less of a
concern (but I am sure others will disagree).

Since time is precious, the easiest solution might be to read until you get
the first error, then emit the warning, and return the partially read image.
Then you do not need any recovery code.

-----Original Message-----
From: Brian.Burkhalter@Sun.COM [mailto:Brian.Burkhalter@Sun.COM]
Sent: Friday, May 26, 2006 7:50 PM
To: interest@jai-imageio.dev.java.net
Subject: RE: [JAI-IMAGEIO] How to handle TIFF decoding exceptions
(particularly fax images)

On Fri, 26 May 2006, Robert Engels wrote:

> I must have had some bad coffee today... I still don't get it.
>
> Wouldn't we want in ALL cases to notify the warning listener and then
> continue to read the image if possible.

That's what I am asking.

> If the caller did not want to continue, it would call abort() in the
> warning listener.

Yes. It is not apparent right now however whether the caller would be able
to decide on the basis of the message whether to abort.

> What would be the benefit for doing it ONLY for the Java bi-level
> decompresses?

That seems to be the most problematic compression type and in particular the
bitstreams most susceptible to corruption.

> Sorry if I am being a pain here (I've been bit by this problem SOOO
> many times, I have a great interest in seeing it resolved
> "correctly".)

Same here, about the "correctly".

----------------
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 I suggest always emit every warning that is detected, and always attempt
> to continue reading the image.

Agreed.

> I think the code does need to be careful that
> it doesn't get itself into an impossible situation (e.g. a corrupted length,
> so it consumes all memory). It is also quite probably that the image will be
> "unreadable", but that is certainly the case anyway if it aborted.

These correupted images seem almost always to be fax images.

> I think the major problem right now with the ImageIO tiff reader is the hard
> JVM crashes in the native code, and the image decoding problem (of good
> images). If it cannot partially decode some corrupted images is less of a
> concern (but I am sure others will disagree).
>
> Since time is precious, the easiest solution might be to read until you get
> the first error, then emit the warning, and return the partially read image.
> Then you do not need any recovery code.

Perhaps.

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

Rather than printing a warning message, shouldn't the

public interface IIOReadWarningListener extends EventListener {

/**
* Reports the occurence of a non-fatal error in decoding. Decoding
* will continue following the call to this method. The application
* may choose to display a dialog, print the warning to the console,
* ignore the warning, or take any other action it chooses.
*
* @param source the ImageReader object calling this
method.
* @param warning a String containing the warning.
*/
void warningOccurred(ImageReader source, String warning);
}

interface be used? If the user wants to stop the processing, they call
abort() on the ImageReader instance.

-----Original Message-----
From: Brian.Burkhalter@Sun.COM [mailto:Brian.Burkhalter@Sun.COM]
Sent: Friday, May 26, 2006 6:17 PM
To: JAI-Image I/O discussion list
Subject: [JAI-IMAGEIO] How to handle TIFF decoding exceptions (particularly
fax images)

As you all know there have been a lot of postings about exceptions
encountered while reading TIFF streams. These have been particularly salient
for the cases of the ITU T.4 and T.6 (fax group 3 and 4) bi-level
compression types. The effect of these exceptions is that decoding fails for
the entire image thereby causing problems for the application. The ultimate
cause of the exceptions in general is either a non-comformant encoder or a
corrupt bitstream. The proximate cause of the exceptions is the failure of
the decoder to recognize non-fatal situations such that at least part of the
image could be read.

One proposed solution to this problem is to trap all IIOExceptions generated
by the TIFFDecompressor being used, print a warning message, and continue
with the next segment, i.e., strip or tile. This solution is supposed to be
applied regardless of the compression type used and is therefore not limited
to bi-level encodings.

Another solution is specific to bi-level encodings. This solution would
change the decoding behavior such that when error conditions from which
recovery might be possible are detected, instead of throwing an exception, a
meaningful warning message would be emitted and decompression would continue
with the next line or segment as appropriate.

Any comments on the relative merits of these two solutions would be welcome
as would be alternate solution proposals.

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

Yes, IMHO. When I use the word "emit" this is what I am referring to.

On Fri, 26 May 2006, Robert Engels wrote:

> Rather than printing a warning message, shouldn't the
>
> public interface IIOReadWarningListener extends EventListener {
>
> /**
> * Reports the occurence of a non-fatal error in decoding. Decoding
> * will continue following the call to this method. The application
> * may choose to display a dialog, print the warning to the console,
> * ignore the warning, or take any other action it chooses.
> *
> * @param source the ImageReader object calling this
> method.
> * @param warning a String containing the warning.
> */
> void warningOccurred(ImageReader source, String warning);
> }
>
> interface be used? If the user wants to stop the processing, they call
> abort() on the ImageReader instance.
>
>
> -----Original Message-----
> From: Brian.Burkhalter@Sun.COM [mailto:Brian.Burkhalter@Sun.COM]
> Sent: Friday, May 26, 2006 6:17 PM
> To: JAI-Image I/O discussion list
> Subject: [JAI-IMAGEIO] How to handle TIFF decoding exceptions (particularly
> fax images)
>
> As you all know there have been a lot of postings about exceptions
> encountered while reading TIFF streams. These have been particularly salient
> for the cases of the ITU T.4 and T.6 (fax group 3 and 4) bi-level
> compression types. The effect of these exceptions is that decoding fails for
> the entire image thereby causing problems for the application. The ultimate
> cause of the exceptions in general is either a non-comformant encoder or a
> corrupt bitstream. The proximate cause of the exceptions is the failure of
> the decoder to recognize non-fatal situations such that at least part of the
> image could be read.
>
> One proposed solution to this problem is to trap all IIOExceptions generated
> by the TIFFDecompressor being used, print a warning message, and continue
> with the next segment, i.e., strip or tile. This solution is supposed to be
> applied regardless of the compression type used and is therefore not limited
> to bi-level encodings.
>
> Another solution is specific to bi-level encodings. This solution would
> change the decoding behavior such that when error conditions from which
> recovery might be possible are detected, instead of throwing an exception, a
> meaningful warning message would be emitted and decompression would continue
> with the next line or segment as appropriate.
>
> Any comments on the relative merits of these two solutions would be welcome
> as would be alternate solution proposals.
>
> 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

Robert Engels

I must be misreading something, but I can't see the difference between the
two options?

-----Original Message-----
From: Brian.Burkhalter@Sun.COM [mailto:Brian.Burkhalter@Sun.COM]
Sent: Friday, May 26, 2006 6:26 PM
To: interest@jai-imageio.dev.java.net
Subject: RE: [JAI-IMAGEIO] How to handle TIFF decoding exceptions
(particularly fax images)

Yes, IMHO. When I use the word "emit" this is what I am referring to.

On Fri, 26 May 2006, Robert Engels wrote:

> Rather than printing a warning message, shouldn't the
>
> public interface IIOReadWarningListener extends EventListener {
>
> /**
> * Reports the occurence of a non-fatal error in decoding. Decoding
> * will continue following the call to this method. The application
> * may choose to display a dialog, print the warning to the console,
> * ignore the warning, or take any other action it chooses.
> *
> * @param source the ImageReader object calling this
> method.
> * @param warning a String containing the warning.
> */
> void warningOccurred(ImageReader source, String warning); }
>
> interface be used? If the user wants to stop the processing, they call
> abort() on the ImageReader instance.
>
>
> -----Original Message-----
> From: Brian.Burkhalter@Sun.COM [mailto:Brian.Burkhalter@Sun.COM]
> Sent: Friday, May 26, 2006 6:17 PM
> To: JAI-Image I/O discussion list
> Subject: [JAI-IMAGEIO] How to handle TIFF decoding exceptions
> (particularly fax images)
>
> As you all know there have been a lot of postings about exceptions
> encountered while reading TIFF streams. These have been particularly
> salient for the cases of the ITU T.4 and T.6 (fax group 3 and 4)
> bi-level compression types. The effect of these exceptions is that
> decoding fails for the entire image thereby causing problems for the
> application. The ultimate cause of the exceptions in general is either
> a non-comformant encoder or a corrupt bitstream. The proximate cause
> of the exceptions is the failure of the decoder to recognize non-fatal
> situations such that at least part of the image could be read.
>
> One proposed solution to this problem is to trap all IIOExceptions
> generated by the TIFFDecompressor being used, print a warning message,
> and continue with the next segment, i.e., strip or tile. This solution
> is supposed to be applied regardless of the compression type used and
> is therefore not limited to bi-level encodings.
>
> Another solution is specific to bi-level encodings. This solution
> would change the decoding behavior such that when error conditions
> from which recovery might be possible are detected, instead of
> throwing an exception, a meaningful warning message would be emitted
> and decompression would continue with the next line or segment as
appropriate.
>
> Any comments on the relative merits of these two solutions would be
> welcome as would be alternate solution proposals.
>
> 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 Fri, 26 May 2006, Robert Engels wrote:

> I must be misreading something, but I can't see the difference between the
> two options?

I probably didn't state it clearly so let me try again.

Option A)

* applies to all compression types
* if the TIFFDecompressor decode() method

http://download.java.net/media/jai-imageio/javadoc/1.1-beta/com/sun/media/imageio/plugins/tiff/TIFFDecompressor.html#decode()

throws an IIOException the TIFF ImageReader catches it, prints the exception's
message, and continues with the next strip or tile.

Option B)

* applies only to the Java implementation of the bi-level TIFFDecompressors
for the RLE, T.4 and T.6 compression types
* for those cases where it might be possible to continue decoding even though
an anomaly is encountered, instead of throwing an exception, emit a warning
message to the registered warning listeners and continue decoding the next
line, strip, or tile, as appropriate.

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 must have had some bad coffee today... I still don't get it.

Wouldn't we want in ALL cases to notify the warning listener and then
continue to read the image if possible.

If the caller did not want to continue, it would call abort() in the warning
listener.

What would be the benefit for doing it ONLY for the Java bi-level
decompresses?

Sorry if I am being a pain here (I've been bit by this problem SOOO many
times, I have a great interest in seeing it resolved "correctly".)

-----Original Message-----
From: Brian.Burkhalter@Sun.COM [mailto:Brian.Burkhalter@Sun.COM]
Sent: Friday, May 26, 2006 7:38 PM
To: interest@jai-imageio.dev.java.net
Subject: RE: [JAI-IMAGEIO] How to handle TIFF decoding exceptions
(particularly fax images)

On Fri, 26 May 2006, Robert Engels wrote:

> I must be misreading something, but I can't see the difference between
> the two options?

I probably didn't state it clearly so let me try again.

Option A)

* applies to all compression types
* if the TIFFDecompressor decode() method

http://download.java.net/media/jai-imageio/javadoc/1.1-beta/com/sun/medi...
ageio/plugins/tiff/TIFFDecompressor.html#decode()

throws an IIOException the TIFF ImageReader catches it, prints the
exception's message, and continues with the next strip or tile.

Option B)

* applies only to the Java implementation of the bi-level TIFFDecompressors
for the RLE, T.4 and T.6 compression types
* for those cases where it might be possible to continue decoding even
though an anomaly is encountered, instead of throwing an exception, emit a
warning message to the registered warning listeners and continue decoding
the next line, strip, or tile, as appropriate.

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 Fri, 26 May 2006, Robert Engels wrote:

> I must have had some bad coffee today... I still don't get it.
>
> Wouldn't we want in ALL cases to notify the warning listener and then
> continue to read the image if possible.

That's what I am asking.

> If the caller did not want to continue, it would call abort() in the warning
> listener.

Yes. It is not apparent right now however whether the caller would be able to
decide on the basis of the message whether to abort.

> What would be the benefit for doing it ONLY for the Java bi-level
> decompresses?

That seems to be the most problematic compression type and in particular the
bitstreams most susceptible to corruption.

> Sorry if I am being a pain here (I've been bit by this problem SOOO many
> times, I have a great interest in seeing it resolved "correctly".)

Same here, about the "correctly".

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

Bob Deen

>> Wouldn't we want in ALL cases to notify the warning listener and then
>> continue to read the image if possible.
>
> That's what I am asking.

I concur. Seems like you'd want to use the warning listener for all cases.

For that matter, I don't see why both approaches couldn't be used. Catch
all exceptions, and route them to the warning listener (assuming you can
continue from the exception). But also, look specifically at problem cases
you "expect" and use the listener then too, without the overhead of an
actual
exception.

This could perhaps be applied across all file types, not just tiff?

>> If the caller did not want to continue, it would call abort() in the
>> warning
>> listener.
>
>
> Yes. It is not apparent right now however whether the caller would be
> able to decide on the basis of the message whether to abort.

It does seem unfortunate that the warning listener has only a string
to go on, not an exception object or some such.

-Bob

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

Aaron Bruegl

First, I must say thank you for the work in this area, as it is of very
much importance to me. I agree with Bob that both approaches could be
used, but I'd like to see Option B) implemented first and expand into
Option A) later.

Honestly, all I care about is getting an image if possible, then were
there any warnings, and then what were they.

Regards,
-Aaron

Bob Deen wrote:
>>> Wouldn't we want in ALL cases to notify the warning listener and then
>>> continue to read the image if possible.
>>
>> That's what I am asking.
>
> I concur. Seems like you'd want to use the warning listener for all
> cases.
>
> For that matter, I don't see why both approaches couldn't be used. Catch
> all exceptions, and route them to the warning listener (assuming you can
> continue from the exception). But also, look specifically at problem
> cases
> you "expect" and use the listener then too, without the overhead of an
> actual
> exception.
>
> This could perhaps be applied across all file types, not just tiff?
>
>>> If the caller did not want to continue, it would call abort() in the
>>> warning
>>> listener.
>>
>>
>> Yes. It is not apparent right now however whether the caller would be
>> able to decide on the basis of the message whether to abort.
>
> It does seem unfortunate that the warning listener has only a string
> to go on, not an exception object or some such.
>
> -Bob
>
> ---------------------------------------------------------------------
> 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

Unfortunately this does not fix the Error 6 problem which requires a fix in
the fax decompressor. This approach handles problems in a significant way only
if the data are stripped or tiled.

Brian

On Fri, 26 May 2006, Aaron Bruegl wrote:

> First, I must say thank you for the work in this area, as it is of very much
> importance to me. I agree with Bob that both approaches could be used, but
> I'd like to see Option B) implemented first and expand into Option A) later.
>
> Honestly, all I care about is getting an image if possible, then were there
> any warnings, and then what were they.
>
> Regards,
> -Aaron
>
>
> Bob Deen wrote:
>>>> Wouldn't we want in ALL cases to notify the warning listener and then
>>>> continue to read the image if possible.
>>>
>>> That's what I am asking.
>>
>> I concur. Seems like you'd want to use the warning listener for all cases.
>>
>> For that matter, I don't see why both approaches couldn't be used. Catch
>> all exceptions, and route them to the warning listener (assuming you can
>> continue from the exception). But also, look specifically at problem cases
>> you "expect" and use the listener then too, without the overhead of an
>> actual
>> exception.
>>
>> This could perhaps be applied across all file types, not just tiff?
>>
>>>> If the caller did not want to continue, it would call abort() in the
>>>> warning
>>>> listener.
>>>
>>>
>>> Yes. It is not apparent right now however whether the caller would be able
>>> to decide on the basis of the message whether to abort.
>>
>> It does seem unfortunate that the warning listener has only a string
>> to go on, not an exception object or some such.
>>
>> -Bob
>>
>> ---------------------------------------------------------------------
>> 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