Gunnar Hillert created IMAGING-377:
--------------------------------------

             Summary: Imaging.getImageInfo causes an IllegalArgumentException 
"Couldn't read array"
                 Key: IMAGING-377
                 URL: https://issues.apache.org/jira/browse/IMAGING-377
             Project: Commons Imaging
          Issue Type: Bug
          Components: Format: JPEG
    Affects Versions: 1.0.0-alpha5
            Reporter: Gunnar Hillert
         Attachments: image_with_faulty_thumbnail.jpg

The reading of Image Metadata should maybe be made more robust. I ran into a 
weird issue with images taken on my Android phone (OnePlus). Calling
{code:java}
Imaging.getImageInfo("/path/to/image_with_faulty_thumbnail.jpg") {code}
resulted in an rather unhelpful:

 

 
{code:java}
java.lang.IllegalArgumentException: Couldn't read array (start: 1070, length: 
-29, data length: 1041).
        at 
org.apache.commons.io.build.AbstractOrigin.getByteArray(AbstractOrigin.java:503)
     at 
org.apache.commons.imaging.bytesource.ByteSource.getByteArray(ByteSource.java:63)
    at 
org.apache.commons.imaging.formats.tiff.TiffReader.getJpegRawImageData(TiffReader.java:147)
  at 
org.apache.commons.imaging.formats.tiff.TiffReader.readDirectory(TiffReader.java:373)
        at 
org.apache.commons.imaging.formats.tiff.TiffReader.readDirectory(TiffReader.java:423)
        at 
org.apache.commons.imaging.formats.tiff.TiffReader.readDirectory(TiffReader.java:413)
        at 
org.apache.commons.imaging.formats.tiff.TiffReader.readDirectory(TiffReader.java:423)
        at 
org.apache.commons.imaging.formats.tiff.TiffReader.readDirectories(TiffReader.java:271)
      at 
org.apache.commons.imaging.formats.tiff.TiffReader.read(TiffReader.java:216) at 
org.apache.commons.imaging.formats.tiff.TiffReader.readContents(TiffReader.java:223)
 at 
org.apache.commons.imaging.formats.tiff.TiffImageParser.getMetadata(TiffImageParser.java:614)
        at 
org.apache.commons.imaging.formats.tiff.TiffImageParser.getMetadata(TiffImageParser.java:73)
 at 
org.apache.commons.imaging.AbstractImageParser.getMetadata(AbstractImageParser.java:652)
     at 
org.apache.commons.imaging.formats.jpeg.JpegImageParser.getExifMetadata(JpegImageParser.java:232)
    at 
org.apache.commons.imaging.formats.jpeg.JpegImageParser.getMetadata(JpegImageParser.java:642)
        at 
org.apache.commons.imaging.formats.jpeg.JpegImageParser.getImageInfo(JpegImageParser.java:375)
       at 
org.apache.commons.imaging.formats.jpeg.JpegImageParser.getImageInfo(JpegImageParser.java:65)
        at org.apache.commons.imaging.Imaging.getImageInfo(Imaging.java:420)    
at org.apache.commons.imaging.Imaging.getImageInfo(Imaging.java:441)    at 
com.hillert.image.metadata.service.support.MetadataExtractorTests.testExtractMetadata(MetadataExtractorTests.java:13)
        at java.base/java.lang.reflect.Method.invoke(Method.java:580)   at 
java.base/java.util.ArrayList.forEach(ArrayList.java:1596)   at 
java.base/java.util.ArrayList.forEach(ArrayList.java:1596) {code}
After some investigation, I think I traced it down to the Thumbnail metadata in 
the *IFD1* segment. *Exiftool* using 
{code:java}
exiftool /path/to/image_with_faulty_thumbnail.jpg -a -u -g1 {code}
gives me:

 
{code:java}
---- IFD1 ----
Y Resolution                    : 72
Compression                     : JPEG (old-style)
Thumbnail Offset                : 1082
Thumbnail Length                : 0
X Resolution                    : 72
Resolution Unit                 : inches {code}
The thumbnail length of 0 seems to be the issue. Removing the thumbnail 
altogether using 

 
{code:java}
exiftool /path/to/image_with_faulty_thumbnail.jpg -thumbnailimage= {code}
makes the image file work with Commons Imaging.

So while this issue seems to be technically a faulty image file, not a bug in 
Commons Imaging in the strict sense, I wonder if Commons Imaging should be a 
bit more lenient here, especially since *exiftool* handles the file just fine.

I have attached the image to the issue.

 

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to