[jira] [Commented] (IMAGING-90) ClassCastException: [I cannot be cast to java.lang.Number in TiffReader.readDirectory(TiffReader.java:239) and JpegImageParser
[ https://issues.apache.org/jira/browse/IMAGING-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13498748#comment-13498748 ] st.h commented on IMAGING-90: - 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
[jira] [Commented] (IMAGING-90) ClassCastException: [I cannot be cast to java.lang.Number in TiffReader.readDirectory(TiffReader.java:239) and JpegImageParser
[ https://issues.apache.org/jira/browse/IMAGING-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481338#comment-13481338 ] Stefan Huber commented on IMAGING-90: - Sorry for the late update - I haven't received any notification about the comment. Unfortunately I can not provide a sample image at the moment as they do not belong to me. Sorry about that. > 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: Stefan Huber > > 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
[jira] [Commented] (IMAGING-90) ClassCastException: [I cannot be cast to java.lang.Number in TiffReader.readDirectory(TiffReader.java:239) and JpegImageParser
[ https://issues.apache.org/jira/browse/IMAGING-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13446643#comment-13446643 ] Damjan Jovanovic commented on IMAGING-90: - Can I please see a sample image with this issue? > 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: Stefan Huber > > 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