commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruno P. Kinoshita (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IMAGING-221) updateExifMetadataLossless restructures meta data (and problems with Maker Notes)
Date Tue, 14 May 2019 09:39:00 GMT

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

Bruno P. Kinoshita commented on IMAGING-221:
--------------------------------------------

>However, does the reordering come from "internal" Imaging code, or "external" code (i.e.
the code used to invoke/call Imaging)?

 

I believe the reordering comes from internal Imaging code. No dependencies in Imaging (other
than those used for testing). So the only code changing metadata and data is in our own project.

 

>And, finally, does such reordering matter at all?

 

Should not matter IMO. As far as I know, the standards specify data containers such as directories,
segments, fields, etc. And they allow users to organize them sequentially by providing offsets.
But without enforcing that one field comes before the other. There are segments that may need
to come before, but I haven't seen any issues with that in Imaging.

 

I believe it would be easier for you to use the code if the metadata order was kept in place.
I haven't investigated where/why it happens.

> updateExifMetadataLossless restructures meta data (and problems with Maker Notes)
> ---------------------------------------------------------------------------------
>
>                 Key: IMAGING-221
>                 URL: https://issues.apache.org/jira/browse/IMAGING-221
>             Project: Commons Imaging
>          Issue Type: Bug
>            Reporter: Joakim Knudsen
>            Assignee: Bruno P. Kinoshita
>            Priority: Major
>             Fix For: 1.0-alpha2
>
>         Attachments: mine.JPG, mine.JPG.html, original.JPG, original.html, test.JPG,
test.html
>
>
> ExifRewriter's *updateExifMetadataLossless* method causes the meta data of the JPEG
to be completely reordered after writing. This, in itself, might not be a big concern, but
it's a bit unexpected when the method is named "lossless". More worryingly, I also find problems
are introduced wrt. the Maker Notes tag (odd offset). 
> I've produced an example of the problem in the attached JPEG file, using ExifTool to
validate/analyze the images before and after. The image is taken by a Sony Xperia Z5 phone,
and the "original.JPG" validates OK. After modifying the contents of the UserComments tag
(value: "Test") the modified image produces a warning:
> Verifying the attached photo using ExifTool gives the following output:
> $ ./exiftool\(-k\).exe -validate -warning -a ../test.JPG
> -- press RETURN --
>  
> Validate                        : 1 Warning (all minor)
> Warning                         : [minor] Possibly incorrect maker notes
offsets (fix by -628?)
>  
> Using ExifTool's -htmldump option, it is easy to see how the meta data has been affected.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message