[
https://issues.apache.org/jira/browse/IMAGING-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147190#comment-17147190
]
Gary Lucas edited comment on IMAGING-258 at 6/28/20, 3:45 AM:
--------------------------------------------------------------
I was able to create a small test file that exhibits this issue. I have posted
a the test file, a code fix, and a new unit test to github.
I researched this problem and it turns out that it is related to the including
a private IFD in a TIFF file (see TIFF Revision 6.0, June 1992, page 9). The
TIFF specification uses the term "private IFD" to mean basically what the same
idea as a "custom IFD", in other words one that contains metadata not covered
in the standard TIFF definition. To include a private IFD, a TIFF file needs
to store a file-position for the IFD using a TiffField. In the original 1992
specification, the relevant field was defined as having a type of Long. But
the file cited above uses a type of IFD:
34665 (0x8769: ExifOffset): 699860352 (1 IFD)
The IFD field type is not defined in the original TIFF specification, but is a
later addition. It turns out that some authoring tools use type Long for the
ExifOffset tag while others use type IFD. So the fix was simply to make
Commons Imaging robust enough to accept either data type.
The new test file is named Imaging258.tiff and is stored in the "data"
subfolder under the "test" folder in the Commons Imaging software distribution.
was (Author: gwlucas):
I was able to create a small test file that exhibits this issue. I have posted
a the test file, a code fix, and a new unit test to github.
I researched this problem and it turns out that it is related to the including
a private IFD in a TIFF file (see TIFF Revision 6.0, June 1992, page 9). The
TIFF specification uses the term "private IFD" to mean basically what the same
idea as a "custom IFD", in other words one that contains metadata not covered
in the standard TIFF definition. To include a private IFD, a TIFF file needs
to store a file-position for the IFD using a TiffField. In the original 1992
specification, the relevant field was defined as having a type of Long. But
the file cited above uses a type of IFD:
34665 (0x8769: ExifOffset): 699860352 (1 IFD)
The IFD field type is not defined in the original TIFF specification, but is a
later addition. It turns out that some authoring tools use type Long for the
ExifOffset tag while others use type IFD. So the fix was simply to make
Commons Imaging robust enough to accept either data type.
> TiffReader.readDirectories() fails on EXIF data
> -----------------------------------------------
>
> Key: IMAGING-258
> URL: https://issues.apache.org/jira/browse/IMAGING-258
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: TIFF
> Affects Versions: 1.0-alpha1
> Reporter: Gary Lucas
> Priority: Minor
>
> When reading a TIFF directory that contains an EXIF sub directory, the
> TiffReader class throws an ImageReadException stating that "ExifOffset has
> incorrect type IFD".
> This exception occurs in the TiffReader.readDirectories() call which attempts
> to read all IFD's (directories) in a TIFF file. It can be avoided by calling
> TiffReader.readFirstDirectory(). Of course, if you do that, you will not be
> able to access the EXIF elements.
> This happens when accessing the TIFF element with TIFF Tag 0x8769. I suspect
> that it could also happen with TIFF files containing GPS extensions, Tag
> 0x8825.
> I've gotten this issue with GeoTIFF files from a couple of different sources.
> The one I'd recommend for testing would be the public-domain "Natural Earth
> Data" medium-size Cross-blended Hypsometric Tints file at
> [https://www.naturalearthdata.com/downloads/10m-raster-data/10m-cross-blend-hypso/]
> I am not experienced with the EXIF sub-directory specification and do not yet
> have a good sense of what the level of effort for a fix would be.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
