Any way to get width/height/size in the correct orientation, quickly?

[dseomn]

Normally, getting the width and height (or equivalently, size) attributes of an Image is fast because it doesn't need to load the actual image data. However, those attributes seem to be incorrect-ish for images that have some exif orientations. I tried out PIL.ImageOps.exif_transpose, but that seems to load the image data even when no rotation is needed.

Is there any fast way to get the dimensions of an image that takes the exif orientation into account but doesn't load the image data?

[radarhere]

Hi. My suggestion would be

from PIL import ExifTags

def get_size_with_exif_orientation_applied(im):
  size = im.size
  if im.getexif().get(ExifTags.Base.Orientation) in (5, 6, 7, 8):
    size = (im.height, im.width)
  return size

[dseomn]

Makes sense, thanks. Any chance of getting something built in to PIL though so I don't have to hardcode that list everywhere? Maybe an oriented_size attribute or something? (Possibly using functools.cached_property to only do the calculation when needed.)

[radarhere]

While I expect this will work for you on a practical level, on a theoretical level, I don't think we can guarantee that it will be correct without first loading the image - PNG images may contain tEXT chunks after the image data, and those tEXT chunks may contain EXIF data.

[dseomn]

Oh, good to know, thanks. In that case I think I'll use exif_transpose, but cache the metadata I need so that I don't need to wait for that every time I look up metadata. It's a good deal more work, but it sounds like that's the only way to get correct metadata?

Mostly out of curiosity, is that a fundamental limitation of the image formats, or just something that's not easy to do with the current code? E.g., do the image data chunk(s) have length fields at the beginning that make it easy to skip over them to find the tEXT chunks at the end?

[radarhere]

PNG chunks do have lengths, yes.

https://en.wikipedia.org/wiki/PNG

A chunk consists of four parts: length (4 bytes,[21] big-endian), ...

So I expect you would be able to skip over them, yes. In the case of Pillow though, I don't think we would be on board with the idea of reading to the end of the file if not for the purpose of loading the image.

[dseomn]

Makes sense, it's extra complication, and could be a problem for file objects that aren't backed by easily seekable files. And getting the security right could be tricky if there's any chance of different results depending on whether the image data was parsed or skipped, e.g., because of errors in the image data causing the trailing metadata to be ignored if the image data is parsed. Thanks for all the explanations!