IMAGING-319: Correct length calculation in EXIF rewriter #203
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I added comments to the JIRA ticket on this item at IMAGING-319
Unfortunately, it will be hard for me to create a JUnit test to specifically test this change without actually adding the user's original file (which is large) to our code distribution.
The following text shows the problem.
The users' test program read the data and then re-wrote it using the Commons Imaging library. In the code below, his original File variable is named "source" and the rewritten version is named "result".
The printout for the original EXIF block (with many elements removed) comes up as:
Exif:
ExifVersion: 48, 50, 51, 50
DateTimeOriginal: '2021:10:28 13:47:07'
DateTimeDigitized: '2021:10:28 13:47:07'
Unknown Tag (0x9010): '-05:00'
Unknown Tag (0x9011): '-05:00'
Unknown Tag (0x9012): '-05:00'
Unknown tag 0x9010 is fine. But if you perform the same thing on this result, it comes up with the first character in Tag 0x9010 as a comma rather than a negative sign as shown below:
The attached fix repairs the problem and causes the EXIF tag to be printed correctly.
Here's the full code for the test program: