[
https://issues.apache.org/jira/browse/IMAGING-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17820303#comment-17820303
]
Stefan Oltmann commented on IMAGING-370:
----------------------------------------
I figured it out myself and fixed the problem in my fork in the mean time.
If you are interested in a solution you can check out
https://github.com/Ashampoo/kim/blob/80028c814de583737f3a95599745d12ca5051df8/src/commonMain/kotlin/com/ashampoo/kim/format/tiff/write/TiffWriterLossless.kt
> 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)
