Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Fri, 16 Nov 2012 20:13:12 +0000 (UTC)
From: "st.h (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <1945615078.125521.1353096792482.JavaMail.jiratomcat@arcas>
In-Reply-To: <930795974.113427.1352891892158.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (IMAGING-99) java.io.IOException: Could not read
 block
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/IMAGING-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13499112#comment-13499112 ] 

st.h commented on IMAGING-99:
-----------------------------

The problem here appears to be a wrong JPEGInterchangeFormatLength Tag. The value specified is 8861, with an offset of 442 specified in JPEGInterchangeFormat. However, the actual data viewed in a hex editor appears to be 8860 bytes long (including SOI and EOI).

I would suggest replacing this function in TiffReader:513
{code}
    private JpegImageData getJpegRawImageData(ByteSource byteSource,
            TiffDirectory directory) throws ImageReadException, IOException {
        ImageDataElement element = directory.getJpegRawImageDataElement();
        int offset = element.offset;
        int length = element.length;
        // Sony DCR-PC110 has an off-by-one error.
        if (offset + length == byteSource.getLength() + 1) {
            length--;
        }
        byte data[] = byteSource.getBlock(offset, length);
        return new JpegImageData(offset, length, data);
    }
{code}
with something, that is capable of dealing with more generic errors - instead of just using a fix for the Sony DCR-PC110 problem.
{code}
    private JpegImageData getJpegRawImageData(ByteSource byteSource,
            TiffDirectory directory) throws ImageReadException, IOException {
        ImageDataElement element = directory.getJpegRawImageDataElement();
        int offset = element.offset;
        int length = element.length;
        // In case the length is not correct, adjust it and check if the last read byte actually is the end of the image
        if (offset + length > byteSource.getLength()) {
            length = (int) byteSource.getLength() - offset;
        }
        byte data[] = byteSource.getBlock(offset, length);
        // check if the last read byte is actually the end of the image data
        if (data[data.length - 2] != -1 || data[data.length - 1] != -39) {
        	throw new ImageReadException("End of image could not be found at expected location");
        }
        return new JpegImageData(offset, length, data);
    }
{code}
Actually I am still somewhat confused, why the data byte array always seems to return an encoding independent format. Probably there has been a conversion somewhere before, but I haven't had the time yet to figure that out to be entirely sure. At least the above code works fine with the included tests.
                
> java.io.IOException: Could not read block
> -----------------------------------------
>
>                 Key: IMAGING-99
>                 URL: https://issues.apache.org/jira/browse/IMAGING-99
>             Project: Commons Imaging
>          Issue Type: Bug
>          Components: Format: JPEG
>    Affects Versions: 0.97
>            Reporter: st.h
>
> We have found that certain images could not be read with imaging, even they usually appear to be fine. This is the stack trace:
> {code}
> java.io.IOException: Could not read block (block start: 442, block length: 8861, data length: 9301).
> 	at org.apache.commons.imaging.common.bytesource.ByteSourceArray.getBlock(ByteSourceArray.java:46)
> 	at org.apache.commons.imaging.formats.tiff.TiffReader.getJpegRawImageData(TiffReader.java:491)
> 	at org.apache.commons.imaging.formats.tiff.TiffReader.readDirectory(TiffReader.java:216)
> 	at org.apache.commons.imaging.formats.tiff.TiffReader.readDirectory(TiffReader.java:103)
> 	at org.apache.commons.imaging.formats.tiff.TiffReader.readDirectory(TiffReader.java:272)
> 	at org.apache.commons.imaging.formats.tiff.TiffReader.readDirectory(TiffReader.java:103)
> 	at org.apache.commons.imaging.formats.tiff.TiffReader.readDirectories(TiffReader.java:95)
> 	at org.apache.commons.imaging.formats.tiff.TiffReader.read(TiffReader.java:421)
> 	at org.apache.commons.imaging.formats.tiff.TiffReader.readContents(TiffReader.java:412)
> 	at org.apache.commons.imaging.formats.tiff.TiffImageParser.getMetadata(TiffImageParser.java:132)
> 	at org.apache.commons.imaging.ImageParser.getMetadata(ImageParser.java:203)
> 	at org.apache.commons.imaging.formats.jpeg.JpegImageParser.getExifMetadata(JpegImageParser.java:335)
> 	at org.apache.commons.imaging.formats.jpeg.JpegImageParser.getMetadata(JpegImageParser.java:295)
> 	at org.apache.commons.imaging.formats.jpeg.JpegImageParser.getImageInfo(JpegImageParser.java:668)
> 	at org.apache.commons.imaging.Imaging.getImageInfo(Imaging.java:683)
> 	at org.apache.commons.imaging.Imaging.getImageInfo(Imaging.java:615)
> {code}
> Further research showed that these images usually are made with a certain type of camera. I have searched flicker and found a image which shows the same problems. (This image does not belong to me, but I guess this should be fine for testing purposes)
> http://www.flickr.com/photos/sara-net/3880941727/sizes/o/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira