[
https://issues.apache.org/jira/browse/IMAGING-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16894362#comment-16894362
]
Bruno P. Kinoshita commented on IMAGING-234:
--------------------------------------------
Hi,
Thanks for the code and information provided for this issue, especially the
example file.
Successfully reproduced it. Went with a debugger examining each directory and
field in the image, and the EXIF metadata is correctly parsed... up until all
the fields were processed.
At this point, according to the standard, we should get a "Next IFD" that has 4
bytes 0 0 0 0. For some reason Imaging is getting 0 0 -1 -1. Looking at the
HTML output of exiftool, it looks like it got 00 00 00 00... not sure where the
-1 -1 (FF FF) are coming from.
Tried running exiftool with some different settings to see if there was any
warning hidden, but no luck. My guess now is that hopefully there is either a
new addendum to the specification that says that it's fine to get only 2 bytes,
or maybe that we should ignore if the Next IFD is not valid.
Commenting the code where the exception is thrown, it looks like the rest of
the file is parsed successfully.
> Unable to get ImageMetadata from JPEG file
> ------------------------------------------
>
> Key: IMAGING-234
> URL: https://issues.apache.org/jira/browse/IMAGING-234
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: JPEG
> Affects Versions: 1.0-alpha1
> Reporter: Michelle Cabahug
> Priority: Major
> Attachments: 20190725_102443_t.jpg
>
>
> Imaging.getMetadata() API is failing for JPEG image file (see attached)
> Error message:
> {code:java}
> 07-25 12:06:54.034 4495 4660 W ExifHelper: Error getting exif metadata from
> 20190725_114523_t.jpg
> 07-25 12:06:54.040 4495 4660 W ExifHelper: Exception: java.io.IOException:
> Not a Valid TIFF File
> {code}
>
> Code:
> {code:java}
> try {
> Map params = new HashMap();
> params.put(ImagingConstants.PARAM_KEY_READ_THUMBNAILS, Boolean.FALSE);
> params.put(ImagingConstants.PARAM_KEY_STRICT, Boolean.FALSE);
> ImageMetadata metadata = Imaging.getMetadata(jpegFile);
> JpegImageMetadata jpegMetadata = (JpegImageMetadata) metadata;
> if (jpegMetadata != null) {
> return jpegMetadata.getExif();
> }
> } catch (Exception e) {
> Log.w(TAG, "Error getting exif metadata from " +
> jpegFile.getAbsolutePath());
> Log.w(TAG, "Exception: " + e);
> }
> {code}
>
> jhove output:
> {code:java}
> ❯ ./jhove 20190725_102443_t.jpg
> Jhove (Rel. 1.22.1, 2019-04-17)
> Date: 2019-07-25 11:54:41
> EDT RepresentationInformation: 20190725_102443_t.jpg
> ReportingModule: BYTESTREAM, Rel. 1.4 (2018-10-01)
> LastModified: 2019-07-25 10:27:40 EDT Size: 18212
> Format: bytestream
> Status: Well-Formed and valid
> SignatureMatches: JPEG-hul MIMEtype: application/octet-stream
> {code}
>
> exiftool output:
> {code:java}
> ❯ exiftool -api validate=2 20190725_102443_t.jpg
> ExifTool Version Number : 11.50
> File Name : 20190725_102443_t.jpg
> Directory : .
> File Size : 18 kB
> File Modification Date/Time : 2019:07:25 10:27:40-04:00
> File Access Date/Time : 2019:07:25 11:31:49-04:00
> File Inode Change Date/Time : 2019:07:25 10:27:40-04:00
> File Permissions : rw-r--r--
> File Type : JPEG
> File Type Extension : jpg
> MIME Type : image/jpeg
> Exif Byte Order : Big-endian (Motorola, MM)
> Image Description : shawty snappppp
> X Resolution : 72
> Y Resolution : 72
> Resolution Unit : inches
> Y Cb Cr Positioning : Centered
> Exif Version : 0210
> Components Configuration : Y, Cb, Cr, -
> Flashpix Version : 0100
> Color Space : Uncalibrated
> Exif Image Width : 0
> Exif Image Height : 0
> Image Width : 423
> Image Height : 238
> Encoding Process : Baseline DCT, Huffman coding
> Bits Per Sample : 8
> Color Components : 3
> Y Cb Cr Sub Sampling : YCbCr4:2:0 (2 2)
> Image Size : 423x238
> Megapixels : 0.101{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
