Order of Exif tags in modified files

[francois]

Exif specs: "Note that field Interoperability shall be recorded in sequence starting from the smallest tag number."

I was looking a the hex dump of a JPEG file from my Android phone, before and after a modification by ExifTool.

Order was not correct in the original file. In my sample the tags were declared in this order (hex numbers):

11
00
10
01
02
03
04
05
06
07
1B
1D

I.e. 11 (GPSImgDirection) and 10 (GPSImgDirectionRef) are out of order here for some reason.

When writing a new modified file (e.g. after I modify, add or delete a tag value), I noticed ExifTool nicely restored a correct order, but wrote tag 0 last:

01
02
03
04
05
06
07
10
11
1B
1D
00

Is there a reason why ExifTool writes tags with ID 0 last? Zero is smaller than 1 and should come first IMHO.

[Phil Harvey]

The tag ID is 2 bytes long.  Take a look at the high-order byte.

- Phil

[francois]

The tag ID is 2 bytes long.  Take a look at the high-order byte.

- Phil

Correct, it's 2 byte long, but in my sample file the high order byte is always 0 and I omitted it in my text. Tag 0000 (GPSVersionID) is written last, but should be first.

If I write more tags in a second command line, ExifTool itself will complain about this problem (about a file it wrote itself):

Code Select Expand

Warning: GPSVersionID tag out of sequence in GPS - 2013-11-24 15.06.44.jpg

Reading the documentation, I understand tag GPSVersionID is treated specially (e.g. automatically added if not already present). This hints a bug

Further discussing about this GPSVersionID tag, another comment. When a photo has version 2.2 set, and I write a new tag that does not exist in Exif 2.2 (say GPSHPositioningError which is new in Exif 2.3), shouldn't ExifTool automatically increase the version number for me? Because now I have a file which says version 2.2 but contains tags not defined in 2.2 spec.

[Phil Harvey]

Please send me the original sample and I'll take a look.  My email is philharvey66 at gmail.com

When a photo has version 2.2 set, and I write a new tag that does not exist in Exif 2.2 (say GPSHPositioningError which is new in Exif 2.3), shouldn't ExifTool automatically increase the version number for me?

No.  ExifTool only writes what you tell it to.  You are free to write EXIFVersion or GPSVersionID with whatever value you want.

It is true that ExifTool writes default values for these tags when creating a new EXIF or GPS IFD (because these tags are mandatory), but in this case it writes the most recent version number.

- Phil

[Phil Harvey]

Hi François,

I got the file, thanks.  I see this behaviour:

Code Select Expand

> exiftool -ver
9.56
> cp ~/Desktop/2013-11-24\ 15.06.44.jpg a.jpg
> exiftool -GPSAreaInformation=foo a.jpg
Warning: GPSVersionID tag out of sequence in GPS - a.jpg
    1 image files updated
> exiftool -GPSAreaInformation=bar a.jpg
Warning: GPSVersionID tag out of sequence in GPS - a.jpg
    1 image files updated

So you are correct that ExifTool does not fix the improper tag order for GPSVersionID.  I did some debugging and now understand this.  The tag ID of 0 is treated specially because some software sets the ID to zero to indicate unused IFD entries.  So although this isn't part of the TIFF format, ExifTool will allow tags with ID 0 to exist at the end of the IFD.

It is just bad luck that this patch is triggered by a different type of problem in your file.

I'm not sure if there is anything I can do to improve ExifTool's response in this situation.

- Phil

Edit: Reading your original post, you say that the tag ID 0 in the original image was not last.  Apparently you didn't send me the original image.  So maybe there is something I can do to help after all.  Send me the original image and I'll take another look.

[Phil Harvey]

I have done more testing/thinking about this.  I think the thing to do is to disable this patch when processing the GPS IFD.  Changing this behaviour for only the GPS IFD shouldn't cause compatibility problems, and the GPS IFD is the only standard IFD where a tag ID of zero is valid.

This patch will appear in ExifTool 9.57.

Thanks for reporting this.

- Phil

[francois]

Edit: Reading your original post, you say that the tag ID 0 in the original image was not last.  Apparently you didn't send me the original image.  So maybe there is something I can do to help after all.  Send me the original image and I'll take another look.

You're extremely right, I sent the wrong file, AFTER editing with ExifTool. Original file now sent by email.

I agree with your proposal to disable this patch when processing the GPS IFD. Another solution, if you think it's working as intended, is to get rid of the "out of sequence" warning for GPSVersionID at the end, so the user is not given a wrong warning.

[Phil Harvey]

I got the original file, thanks:

Code Select Expand

> cp ~/Desktop/2013-11-24\ 15.06.44.jpg a.jpg
> exiftool -ver
9.56
> exiftool a.jpg -GPSAreaInformation=foo -a
Warning: [minor] Entries in IFD0 were out of sequence. Fixed. - a.jpg
Warning: [minor] Entries in ExifIFD were out of sequence. Fixed. - a.jpg
Warning: [minor] Entries in GPS were out of sequence. Fixed. - a.jpg
Warning: GPSVersionID tag out of sequence in GPS - a.jpg
Warning: [minor] Entries in IFD1 were out of sequence. Fixed. - a.jpg
    1 image files updated
> exiftool a.jpg -GPSAreaInformation=bar -a
Warning: GPSVersionID tag out of sequence in GPS - a.jpg
    1 image files updated


Whatever software wrote this image needs to be fixed.

Anyway, with ExifTool 9.57 (to be released tomorrow) the GPS IFD will be properly repaired:

Code Select Expand

> cp ~/Desktop/2013-11-24\ 15.06.44.jpg a.jpg
> exiftool -ver
9.57
> exiftool a.jpg -GPSAreaInformation=foo -a
Warning: [minor] Entries in IFD0 were out of sequence. Fixed. - a.jpg
Warning: [minor] Entries in ExifIFD were out of sequence. Fixed. - a.jpg
Warning: [minor] Entries in GPS were out of sequence. Fixed. - a.jpg
Warning: [minor] Entries in IFD1 were out of sequence. Fixed. - a.jpg
    1 image files updated
> exiftool a.jpg -GPSAreaInformation=bar -a
    1 image files updated

- Phil

[francois]

Whatever software wrote this image needs to be fixed.

Filed Android bug https://code.google.com/p/android/issues/detail?id=68454

[Phil Harvey]

While you are filing bugs, I also noticed that tag values were not all on even-byte boundaries, which they must be according to the TIFF specification.

- Phil

[francois]

While you are filing bugs, I also noticed that tag values were not all on even-byte boundaries, which they must be according to the TIFF specification.

Done.
https://code.google.com/p/android/issues/detail?id=68454#c1