I am reading a PNG image using a PNG ImageReader. I am marking the initial position of the ImageInputStream through IIS.mark() call just before invoking the reader.read() method. This read process is aborted when it completes 50% by calling abort() in one of the listener methods. After this, I am resetting the position of the ImageInputStream to the initial marked position by calling IIS.reset(). Then I am using the same reader to the read the image till completion. This results in an IIOException. Call to IIS.reset() throws an exception saying the initially marked position has been discarded. Caching is disabled at begining of the application.

PNG ImageReader actually calls IIS.flushBefore() which actually flushes the portion of the image input stream that was marked earlier. This does not seem to be happening with other image formats. However, there is an issue with JPEG where the abort flag is not cleared properly and causes every subsequent read operation to be aborted when abort() is called once. A separate bug has been filed on this. (4885702)

This is reproducible on all platforms since JDK1.4.

I have attached a sample testcase. Execute the testcase and pass a png image. You would see the exception given below when calling the reset() on the IIS.

Here is the exception:
javax.imageio.IIOException: Previous marked position has been discarded!
at javax.imageio.stream.ImageInputStreamImpl.reset(ImageInputStreamImpl.java:780)
at RasterListenerTest.<init>(RasterListenerTest.java:45)
at RasterListenerTest.main(RasterListenerTest.java:67)

N/A

This is blocking some performance test development, so it should be investigated
sooner rather than later.  The ImageInputStream.flushBefore() method was
created for a valid reason, but the original authors probably did not consider
the case mentioned in this bug report.  We could remove the flushBefore()
calls from the PNGImageReader, and that would solve the problem, but it
doesn't prevent other plugins from using the flushBefore() method and causing
similar problems for application code.  I'm not sure if there's a good solution
here.
Posted Date : 2005-10-20 01:30:58.0

After further discussion, it is clear that ImageReaders should be allowed
to call ImageInputStream.flushBefore() as part of the decoding process ("if
ImageReaders are not allowed to call it, who is?" says one of the original
designers of the API).  So it seems that applications should not assume that
a marked position will remain valid after a call to one of the ImageReader
methods.  I suppose we could close this as "not a bug", but we should probably
update the documentation somewhere (mark()?) so that developers are not
surprised if they stumble across this behavior in the future.
Posted Date : 2005-11-23 08:15:39.0