[jira] [Commented] (IMAGING-179) Adding a directory causes "APP1 Segment is too long"

["Damjan Jovanovic (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IMAGING-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15469184#comment-15469184 ] 

Damjan Jovanovic commented on IMAGING-179:
------------------------------------------

The way that lossless rewriting currently works is we blacklist every EXIF byte, and then traverse the directory structure, whitelisting bytes occupied by *known* tags. Every whitelisted byte can then be overwritten, since its contents are already known and can be rewritten.

Since images can have tags with unknown contents (such as this particular image's enormous "Maker Note" tag 927c using up 01008-35518) we can't whitelist any bytes that appear unused, as those tags can contain anything, including arbitrary numbers of recursive references to other directories and their tags, using up space elsewhere in the EXIF data, and can even be encrypted.

That only leaves growing the EXIF field, but this one is already using 65526 bytes, leaving only another 9 bytes to use, which is not enough.

As a workaround you could try save space by deleting the thumbnail, or, if you don't care about unknown tags, use lossy rewriting instead (which can corrupt them).

We would have to parse the "Maker Note" to extract more space. This is manufacturer-specific :-/.

> Adding a directory causes "APP1 Segment is too long"
> ----------------------------------------------------
>
>                 Key: IMAGING-179
>                 URL: https://issues.apache.org/jira/browse/IMAGING-179
>             Project: Commons Imaging
>          Issue Type: Bug
>          Components: Format: JPEG
>            Reporter: Simon Legner
>         Attachments: 123.jpg
>
>
> SVN revision: 1696444
> The following snippet causes {{ExifRewriter$ExifOverflowException: APP1 Segment is too long: 65548}}
> {code:java}
> final File in = new File("123.jpg");
> final TiffImageMetadata exif = ((JpegImageMetadata) Imaging.getMetadata(in)).getExif();
> final TiffOutputSet outputSet = exif.getOutputSet();
> outputSet.getOrCreateGPSDirectory().add(GpsTagConstants.GPS_TAG_GPS_IMG_DIRECTION, RationalNumber.valueOf(123));
> new ExifRewriter().updateExifMetadataLossless(in, new ByteArrayOutputStream(), outputSet);
> {code}
> When inspecting the EXIF data using {{jhead -exifmap 123.jpg}}, the header reveals unfilled space between 47198 and 65526. Nevertheless, this space is not used, but instead the GPS directory is being appended starting at offset 65526.
> {code}
> Map: 00008-00182: Directory
> Map: 00184-00202:   Data for tag 010f
> Map: 00204-00214:   Data for tag 0110
> Map: 00216-00224:   Data for tag 011a
> Map: 00224-00232:   Data for tag 011b
> Map: 00232-00242:   Data for tag 0131
> Map: 00244-00264:   Data for tag 0132
> Map: 00264-00280:   Data for tag 013e
> Map: 00280-00328:   Data for tag 013f
> Map: 00328-00352:   Data for tag 0211
> Map: 00352-00850: Directory
> Map: 00852-00860:   Data for tag 829a
> Map: 00860-00868:   Data for tag 829d
> Map: 00868-00888:   Data for tag 9003
> Map: 00888-00908:   Data for tag 9004
> Map: 00908-00916:   Data for tag 9102
> Map: 00916-00924:   Data for tag 9204
> Map: 00924-00932:   Data for tag 9205
> Map: 00932-00940:   Data for tag 920a
> Map: 01008-35518:   Data for tag 927c
> Map: 00940-00984:   Data for tag 9286
> Map: 35518-35548: Directory
> Map: 00984-00992:   Data for tag a302
> Map: 00992-01000:   Data for tag a404
> Map: 01000-01008:   Data for tag a500
> Map: 35568-35658: Directory
> Map: 35660-35668:   Data for tag 011a
> Map: 35668-35676:   Data for tag 011b
> Map: 35676-47197: Thumbnail
> Map: 65526- End of exif
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)