[
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
