exif_transpose errors out on some images

[okor]

What did you do?

Used new exif_transpose method.

What did you expect to happen?

I expected a transposed image to be returned, without error.

What actually happened?

An error was raised.

/Users/okor/thumbor/lib/python2.7/site-packages/PIL/TiffImagePlugin.py:612: UserWarning: Metadata Warning, tag 282 had too many entries: 2, expected 1
  tag, len(values)))
/Users/okor/thumbor/lib/python2.7/site-packages/PIL/TiffImagePlugin.py:612: UserWarning: Metadata Warning, tag 283 had too many entries: 2, expected 1
  tag, len(values)))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/okor/thumbor/lib/python2.7/site-packages/PIL/ImageOps.py", line 549, in exif_transpose
    transposed_image.info["exif"] = exif.tobytes()
  File "/Users/okor/thumbor/lib/python2.7/site-packages/PIL/Image.py", line 3087, in tobytes
    return b"Exif\x00\x00"+head+ifd.tobytes(offset)
  File "/Users/okor/thumbor/lib/python2.7/site-packages/PIL/TiffImagePlugin.py", line 818, in tobytes
    count = len(data)
TypeError: object of type 'int' has no len()

Note that this error is not raised for all images. Only some. I'm not sure how the EXIF data differs.

What are your OS, Python and Pillow versions?

• OS: macOS Mojave 10.14.5
• Python: 2.7.16
• Pillow: 6.0.0

from PIL import Image, ImageOps

im = Image.open('10_years_of_Wikipedia_by_Guillaume_Paumier.jpg')
im = ImageOps.exif_transpose(im)

10_years_of_Wikipedia_by_Guillaume_Paumier.jpg.zip

---

This error was encountered when attempting to replace piexif exif functionality with new Pillow functionality. The PR and conversation is here thumbor/thumbor#1209

[kkopachev]

There are multiple issues in there, all with saving back exif info.
Reproducible with pillow's own images:

im = Image.open('Tests/images/exif_gps_typeerror.jpg')
# or use another one for different error
# im = Image.open('Tests/images/exif_gps.jpg')

# TypeError thrown
im.getexif().tobytes()

I figured few of the issues and working on a fix.
To outline what I've found:

• Wrong type for GPSInfoIFD field in TiffTags
• Usage of ImageFileDirectory_v1 which does not support saving RATIONAL/SRATIONAL as saving are done in ImageFileDirectory_v2 which expects different format - not tuple, but IFDRational.
• Wrong handling of SRATIONAL type both with decoding and encoding
• Wrong limitations for handling RATIONAL type
• All other IFDs are silently dropped on save. Only saves Exif.

[hayzem]

run into the same error but seems like there is already a fix for it. #4009
I will check if it is resolving my issue.

[radarhere]

The original error should be fixed now that #4009 is merged.

[thuzhf]

@radarhere The original error is still not fixed in version 6.2.1. I encountered the same error when I upgraded pillow to version 6.2.1 (python version is 3.7.3).

[radarhere]

@thuzhf it is fixed in master, and will be a part of Pillow 7.0.0 when it is released on January 1.

[thuzhf]

I see. Thanks.

[radarhere]

From the earlier list -

• GPSInfoIFD was fixed in Corrected tag types #4009
• The RATIONAL/SRATIONAL type handling should have been fixed with Exif writing fixes: Rational boundaries and signed/unsigned types #3980

@kkopachev can this issue be closed, or would you like to provide some more detail on any work you think is left to be done here?

[kkopachev]

I think one item remains:

• All other IFDs are silently dropped on save. Only saves Exif.

So saving is still broken, it does not respect nested IFDs structure. Given the file attached to this issue, there are some value-only tags in IFD0 as well as pointer to ExifIFD, with EXIF private tags, which in turns include GPSInfoIFD pointer. Saving loaded exif essentially flattens nested IFD structure making it invalid.

Example code:

from PIL import Image
from PIL.Image import Exif

im = Image.open('10_years_of_Wikipedia_by_Guillaume_Paumier.jpg')
good_exif = im.getexif()

bad_bytes = good_exif.tobytes()

bad_exif = Exif()
bad_exif.load(bad_bytes)

print("Good exif dictionary size: %d" % len(good_exif.get_ifd(34665)))
print(" Bad exif dictionary size: %d" % len(bad_exif.get_ifd(34665)))

assert(len(bad_exif.get_ifd(34665)) == len(good_exif.get_ifd(34665)))

Prints a bunch of warnings complaining about corrupt exif data in second load and at the end prints:

Good exif dictionary size: 26
 Bad exif dictionary size: 1

[radarhere]

I've created #4862 to save subIFDs. However, it does not address the flattening issue.

[kkopachev]

@radarhere Got my hands on testing saving subIFDs and it looks great.
However, resaving exif data is still broken, because data from ExifIFD is unpacked into values of 0th IFD on Exif object. https://github.com/python-pillow/Pillow/blob/master/src/PIL/Image.py#L3337 . So the structure is:

0th IFD
|- tag1
|- tag2
|- ExifIFD
   | - orientation
   | - another_tag

Current code unpacks it into:

0th IFD
|- tag1
|- tag2
|- ExifIFD (this becomes just LONG of position of ExifIFD)
| - orientation
| - another_tag

So now, when dumping it back to bytes, it's all flattened.

Simple fix would be to to stop doing that and treat ExifIFD as indeed sub IFD

Index: src/PIL/Image.py
<+>UTF-8
===================================================================
--- src/PIL/Image.py	(revision c2367400fa8aab47d7752f3780681fced044f0d2)
+++ src/PIL/Image.py	(date 1600885150704)
@@ -3334,7 +3334,7 @@
         # get EXIF extension
         ifd = self._get_ifd_dict(0x8769)
         if ifd:
-            self._data.update(ifd)
+            self._data[0x8769] = ifd
             self._ifds[0x8769] = ifd
 
     def tobytes(self, offset=8):

But that would break backward compatibility, since in order to read orientation one would need to read ExifIFD first.

Or another option would be to try reading from 0th IFD for a tag and if that does not exist fallback to reading from ExifIFD.

What do you think would be desired approach to fix this problem?

[radarhere]

It does break backwards compatibility, but the current behaviour loses information, and so I would hold that it's ultimately incorrect.

However, I also think that you're wrong about orientation? I think it's not part of the EXIF IFD, and is there with or without flattening.

See what you think of #4947. It fixes the flattening for getexif(), while keeping things as they are for _getexif().