Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Fri, 16 Nov 2012 11:48:12 +0000 (UTC)
From: "st.h (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <796247067.123391.1353066492362.JavaMail.jiratomcat@arcas>
In-Reply-To: <1326377926.35357.1345556258568.JavaMail.jiratomcat@arcas>
Subject: [jira] [Comment Edited] (IMAGING-90) ClassCastException: [I cannot
 be cast to java.lang.Number in
 TiffReader.readDirectory(TiffReader.java:239) and JpegImageParser
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

st.h edited comment on IMAGING-90 at 11/16/12 11:46 AM:
--------------------------------------------------------

I finally had the time to look into this more thoroughly.
The problem appears to be that some images specify a count of 0 for the Interoperability Tag.
This is the content of the tag in hex of a big endian encoded image:
{code}
A0 05 00 04 00 00 00 00 00 00 05 10
{code}
I translated this to:
{code}
A0 05 = Interoperability tag
00 04 = LONG
00 00 00 00 = count 0
00 00 05 10 = 1296
{code}
If I interprete JEITA CP-3451 correctly, it specifies a count of 1 for the Interoperability Tag. However, looking into the offset of 1296 beginning from the TIFF Header, I find this data:
{code}
00 02
00 01 00 02 00 00 00 04 52 39 38 00 
00 02 00 07 00 00 00 04 30 31 30 30
00 00 00 00
{code}
If I interprete this correctly, this looks like valid interoperability tags. So I guess the length of the Interoperability Tag has been set incorrectly.
I think the question here is if Tags of length 0 should be ignored, for the sake of being able to process the image? Probably a strict mode which throws an exception and a less strict mode which ignores this error might be a good idea?
                
      was (Author: st.h):
    I finally had the time to look into this more thoroughly.
The problem appears to be that some images specify a count of 0 for the Interoperability Tag.
This is the content of the tag in hex of a big endian encoded image:
{code}
A0 05 00 04 00 00 00 00 00 00 05 10

A0 05 = Interoperability tag
00 04 = LONG
00 00 00 00 = count 0
00 00 05 10 = 1296
{code}
If I interprete JEITA CP-3451 correctly, it specifies a count of 1 for the Interoperability Tag. However, looking into the offset of 1296 beginning from the TIFF Header, I find this data:
{code}
00 02
00 01 00 02 00 00 00 04 52 39 38 00 
00 02 00 07 00 00 00 04 30 31 30 30
00 00 00 00
{code}
If I interprete this correctly, this looks like valid interoperability tags. So I guess the length of the Interoperability Tag has been set incorrectly.
I think the question here is if Tags of length 0 should be ignored, for the sake of being able to process the image? Probably a strict mode which throws an exception and a less strict mode which ignores this error might be a good idea?
                  
> ClassCastException: [I cannot be cast to java.lang.Number in TiffReader.readDirectory(TiffReader.java:239) and JpegImageParser
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: IMAGING-90
>                 URL: https://issues.apache.org/jira/browse/IMAGING-90
>             Project: Commons Imaging
>          Issue Type: Bug
>          Components: Format: JPEG
>    Affects Versions: 1.0
>         Environment: jdk 1.6.0_33
>            Reporter: st.h
>
> Version 1.0 rc2. (Checked the trunk, but couldn't find any commits concerning this issue)
> When calling Imaging.getImageInfo on certain (in this case jpeg) images, there might be a ClassCastException in TiffReader:239 if the entry is not a Number.
> {code}
> int subDirectoryOffset = ((Number) entry.getValue())
>                             .intValue();
> {code}
> This may occur if the entry does not have any actual value. This is the entry shown by the debugger:
> {code}
>  40965 (0xa005: InteropOffset):  (0 Long)
> {code}
> A quick solution to this problem might be to check if entry.getValue() could be cast to a Number before doing so. Probably there is a more elegant way, but I haven't had the time to analyze this thoroughly.
> Here is the stack trace:
> {code}
> Caused by: java.lang.ClassCastException: [I cannot be cast to java.lang.Number
>         at org.apache.commons.imaging.formats.tiff.TiffReader.readDirectory(TiffReader.java:239)
>         at org.apache.commons.imaging.formats.tiff.TiffReader.readDirectory(TiffReader.java:253)
>         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:419)
>         at org.apache.commons.imaging.formats.tiff.TiffReader.readContents(TiffReader.java:410)
>         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}
> The same issue applies to similar uses of TiffField, for instance JpegImageParser around line 676.

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