JSON output is not consistent with console output

[Bilge]

When there are duplicate tags, ExifTool selects different tags depending on whether output is JSON or not.

Consider the following image which has bad Exif width/height (dimensions are swapped). http://i.imgur.com/YfLW5h7.jpg

With -g2 output we can observe the following tags:
Image Width                     : 351
Image Height                    : 3840
Exif Image Width                : 3840
Exif Image Height               : 351

If we throw -j into the mix we can observe the following tags:
"ImageWidth": 3840,
"ImageHeight": 1200,
"ExifImageWidth": 3840,
"ExifImageHeight": 351,

Why did the values change? Where did 1200 come from?

If we inspect the image with -g2 -a we observe the following tags:
Image Width                     : 3840
Image Height                    : 1200
Exif Image Width                : 3840
Exif Image Height               : 351
Image Width                     : 351
Image Height                    : 3840

For some reason ExifTool creates two sets of ImageWidth/ImageHeight, the latter of which is used in console output and the former of which is used for JSON output. Only the latter is correct and I still have no idea where 1200 comes from.

Regardless of whether this image is in a good state I believe the console output should be consistent with the JSON output by selecting the same tags for each.

[Phil Harvey]

Interesting.  I get this:

Code Select Expand

> exiftool -ver
9.17
> exiftool ~/Desktop/YfLW5h7.jpg -imagewidth -imageheight
Image Width                     : 351
Image Height                    : 3840
> exiftool ~/Desktop/YfLW5h7.jpg -imagewidth -imageheight -j
[{
  "SourceFile": "/Users/phil/Desktop/YfLW5h7.jpg",
  "ImageWidth": 351,
  "ImageHeight": 3840
}]

Are you sure you are running the 2 commands on the same image?  The image you posted doesn't have a 1200 dimension anywhere.

- Phil

[Bilge]

You must always pass -g2.

[Phil Harvey]

Code Select Expand

> exiftool ~/Desktop/YfLW5h7.jpg -imagewidth -imageheight -g2
---- Image ----
Image Width                     : 351
Image Height                    : 3840
> exiftool ~/Desktop/YfLW5h7.jpg -imagewidth -imageheight -g2 -j
[{
  "SourceFile": "/Users/phil/Desktop/YfLW5h7.jpg",
  "Image": {
    "ImageWidth": 351,
    "ImageHeight": 3840
  }
}]

[Bilge]

Uh... OK. Is this something that changed recently? Because I'm on 9.14.

[Phil Harvey]

Nothing changed recently that should affect this.

Paste your console session that shows this problem (and include a "-ver" command).  Be sure to use the same image that you uploaded.  There may be something else going on.

- Phil

[Bilge]

$ exiftool -ver
9.14
$ exiftool -imagewidth -imageheight -g2 test.jpg
---- Image ----
Image Width                     : 351
Image Height                    : 3840
$ exiftool -imagewidth -imageheight -g2 -j test.jpg
[{
  "SourceFile": "test.jpg",
  "Image": {
    "ImageWidth": 3840,
    "ImageHeight": 1200
  }
}]

[Bilge]

Oh, this is silly, imgur modifies the image! Here is the unmodified image: http://s3.postimage.org/b4sn2ptqr/jaypeg.jpg

[Phil Harvey]

I can finally reproduce what you observed.

This one is a bit tricky.  In this image, there are incorrect ImageWidth/Height tags in the EXIF information.  You can see both when you use the -a option:

Code Select Expand

> exiftool ~/Desktop/jaypeg.jpg -imagewidth -imageheight -g -a
---- EXIF ----
Image Width                     : 3840
Image Height                    : 1200
---- File ----
Image Width                     : 351
Image Height                    : 3840

With duplicates suppressed, the JPEG file ImageWidth/Height (351x3840) are displayed by default:

Code Select Expand

> exiftool ~/Desktop/jaypeg.jpg -imagewidth -imageheight -g
---- File ----
Image Width                     : 351
Image Height                    : 3840

In JSON output, duplicates are enabled implicitly with the -g option, and you would normally see both values:

Code Select Expand

> exiftool ~/Desktop/jaypeg.jpg -imagewidth -imageheight -j -g
[{
  "SourceFile": "/Users/phil/Desktop/jaypeg.jpg",
  "EXIF": {
    "ImageWidth": 3840,
    "ImageHeight": 1200
  },
  "File": {
    "ImageWidth": 351,
    "ImageHeight": 3840
  }
}]

However, if you use -g2 instead of -g, all of these tags are in the same group, and even though duplicates are enabled, some of the tags must be suppressed because JSON doesn't allow same-named fields in a hash.  Unfortunately though, since the first tag was already printed (and can't be un-printed), the only thing to do is suppress the 2nd one, which is different than the one suppressed by default.

The work-around is to add a --a after -g2 in your -j command to suppress duplicates before the output phase so the output will be the same as without the -j option.

I would like to change ExifTool's behaviour to make it more consistent, but the only way I can think of doing this right now wouldn't be very pretty or efficient.  I'll think about this some more though.

- Phil

[Bilge]

--a has to appear after -g2 and -j. I'm still curious as to where 1200 comes from.

[Phil Harvey]

The 1200 comes from the EXIF information as I stated.  There are 2 problems relating to this in your image: 1) The EXIF image dimensions are not consistent with the actual image, and 2) The EXIF specification states that the ImageWidth/Height tags should not be used for a JPEG image.  So these should really be deleted.

However, I still don't like the way ExifTool was inconsistent with its handling of the duplicate tags, so I looked into this in more detail...

It seems that I anticipated this problem when I added the -j option because I found some code that tries to look ahead to see if there is another same-named tag in each group.  The problem was that this code was not working properly.  I have fixed this and released ExifTool 9.18 with this update.  With this version, the priority tag shouldn't be hidden by another lower-priority tag in the same group.

Thanks for pointing out this problem.  You found a real bug, and I always love squashing bugs.

- Phil

[Bilge]

That's great news, Phil, thanks for the fix.