[
https://issues.apache.org/jira/browse/IMAGING-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17790724#comment-17790724
]
Stefan Oltmann commented on IMAGING-370:
----------------------------------------
Another noteworthy problem with the re-ordering here is, that the IFD1
(thumbnail) block and actual thumbnail data get split. ExifTool keeps them
together.
I don't know why, but this seems to have an effect at least on Apple Finder not
displaying the embedded thumbnail and generating it's own. It would be great to
have that fixed that IFD1 is moved somewhere, where it's not disconnected to
the data block.
Maybe this is worth it's own issue, maybe it's the same problem. I don't know.
> TiffImageWriterLossless reorders directories even if not necessary
> ------------------------------------------------------------------
>
> Key: IMAGING-370
> URL: https://issues.apache.org/jira/browse/IMAGING-370
> Project: Commons Imaging
> Issue Type: Bug
> Reporter: Stefan Oltmann
> Priority: Major
> Attachments: new_taken_date.html, new_taken_date.jpg, original.html,
> original.jpg
>
>
> When updating the metadata of a JPG file, such as modifying the taken date,
> using Commons Imaging version 1.0-alpha3, the EXIF directories are
> re-ordered, even when unnecessary. I anticipate that the directories should
> maintain the "normal" order, similar to how ExifTool preserves it during file
> writing.
> Upon inspecting the source code at
> [https://github.com/apache/commons-imaging/blob/2144780f0171c4af1e79b598f0a75a37ba4c1308/src/main/java/org/apache/commons/imaging/formats/tiff/write/TiffImageWriterLossless.java],
> I observed a sophisticated logic for sorting elements to save space while
> preserving MakerNotes.
> However, it seems there might be an issue with this logic because both IFD0
> and ExifIFD appear to have sufficient space to precede MakerNotes. Notably,
> manipulating the taken date using ExifTool maintains the expected order, but
> Commons Imaging alters it.
> I have spent considerable time attempting to understand the logic to rectify
> this problem. Unfortunately, I haven't been able to grasp it well enough to
> implement a fix.
> To provide context on why I consider this a bug: In some manipulated files,
> IFD0 has a substantial offset after manipulation. In my application, I rely
> on reading the orientation flag from each file, necessitating it to be among
> the first bytes to minimize unnecessary loading of the file header from a
> cloud source.
> [~gwlucas] , I noticed your recent involvement in a related logic deep dive
> (IMAGING-319). Could you guide me on what needs to be changed to achieve the
> desired behavior of having IFD0 come first?
> [~damjan] , I saw your explanation on another issue regarding this process.
> Could you provide assistance in understanding and resolving this issue?
> I have attempted various changes, but none have yielded the expected results
> so far. :(
> For additional information, an HTML dump of the files for debug can be
> generated using ExifTool: {{exiftool -htmlDump original.jpg > original.html}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
