After decoding Image dimensions not equal the one in the headers

[bigcat88]

Discussed in #85

^{Originally posted by Soooda March 17, 2023}
Hello all,

I tried to convert some of my HIF images into JPGs and found some of the images were throwing the below error:

ValueError: corrupted image(dimensions in header: (7008, 4672), decoded dimensions: (4672, 7008)

The root cause was that I had applied rotation to my images and on the IOS system, the rotation was applied to the EXIF rather than the image data itself.

I made use of exif_transpose() to compensate for that. But the error is still popping up. It looks like pillow_heif does not support exif_transpose() and I wonder if this is an intended behaviour?

from PIL import Image, ImageOps
from pillow_heif import register_heif_opener

register_heif_opener()

def save_jpg(path, quality=100, subsampling=0):
    temp, _ = path.split(".")
    temp += ".jpg"

    im = Image.open(path)
    im = ImageOps.exif_transpose(im)

    print(f"Saving to {temp}")
    im.save(temp, quality=quality, subsampling=subsampling)

# for filename in sys.argv[1:]:
#     save_jpg(filename)

name = "DSC03260.HIF"
save_jpg(name)

[bigcat88]

I will try to change code, so it will change Image.size after decoding to one it got from libheif after decoding and not to throw an error.
Do not know will it be default behaviour or should be done only when some option is set(for me such images looks like violation of HEIF standard)

[Soooda]

I will try to change code, so it will change Image.size after decoding to one it got from libheif after decoding and not to throw an error. Do not know will it be default behaviour or should be done only when some option is set(for me such images looks like violation of HEIF standard)

Personally speaking, at least, in this case, I intuitively believed that pillow_heif comply with the desired behaviours of PIL and expected my code to work straightforwardly. So I guess, this should be a default behaviour?

PS: I totally agree with your sayings. In fact, I literally learned this EXIF orientation thing thanks to this incident. I always thought IOS image rotation directly applied transposition to the data.

[bigcat88]

Yes, the image you posted will work in the next version. But for some reason it loads very slowly (I see such themes in the libeheif repository, but all of their samples worked well for me).
Can you post an image taken with the same camera but without rotation? Just for research in my spare time (and maybe I'll publish it in the libheif repo in issue if you'll allow it).

[Soooda]

Yes, the image you posted will work in the next version. But for some reason it loads very slowly (I see such themes in the libeheif repository, but all of their samples worked well for me). Can you post an image taken with the same camera but without rotation? Just for research in my spare time (and maybe I'll publish it in the libheif repo in issue if you'll allow it).

Sure thing, m8. Feel free to use them as you like.

I didn't mention it but have managed to use the code snippet to convert all the others without rotation applied to JPGs like a charm. You can keep me up to date, I am also interested in this after totally switching my photography workflow into HEIF format. Maybe I can help and fire some PRs as well if I got time xD

https://drive.google.com/file/d/1tNkNp7a8ecpQrxopxYm7a9tnXZBDAfKA/view?usp=sharing

[bigcat88]

from pillow_heif import register_heif_opener

register_heif_opener(allow_incorrect_headers=True)

Will do the job for such files.
Can't do that behaviour by default, as no-one will expect from Pillow Image that size will change.

[bigcat88]

@Soooda done!

[Soooda]

@Soooda done!

Confirmed fixed! Work like a charm from my end, cheers bro~