search

strukturag / libheif

libheif is an HEIF and AVIF file format decoder and encoder.
Other
1.71k stars 298 forks source link

extra compatible brand "miaf" make MacOS cannot recognize Exif orientation #677

Closed japheth-sh closed 1 year ago

japheth-sh commented 2 years ago

I am use ImageMagick which is using libheif to handle heic files. However, when I convert photos to heic, their exif orientations are always recognized as 1 (no rotate) while Exif orientation is not 1. Here's the example: 43.txt image image See blow 43.heic is not placed correctly. (43ae...ff27.heic is the original photo, I used "convert -define heic:preserve-orientation=true 43ae6f68-7f55-4228-bff3-61c2b383ff27.heic 43.heic")

image

And Preview App says orientation is 1: image

Looks like the m_miaf_compatible is set to true by default and only set to false in some cases. Thus most of heic files will have the "miaf" appended. Is this a bug or Apple's fault? image

image image

bigcat88 commented 2 years ago

It is an Apple "feature". See https://github.com/strukturag/libheif/issues/227

japheth-sh commented 2 years ago

Oh...glad to have a light speed response. I will have a look.

japheth-sh commented 2 years ago

well...If I read #227 correctly, it is related to the battle of exif:orientation and irot, not my case. My 43.heic has no irot, only exif:orientation. If I remove the compatible brand "miaf" manually, the exif:orientation can be recognized correctly by Mac. I believe Mac use the policy "use either irot or exif:orientation, but not both" to handle #227 issue.

japheth-sh commented 2 years ago

See: image then:

image
japheth-sh commented 2 years ago

Is it possible that the photo must be "grided" when "miaf" appears in compatible brands? I see the original photo does.

farindk commented 2 years ago

MIAF only puts some further restrictions on HEIF. It does not change the interpretation. Hence, if the orientation that macOS displays depends on the MIAF compatibility, it looks like a macOS bug to me.

There was a lot of confusion about the fact that unlike JPEG, the EXIF rotation value has no effect for HEIF and many implementations did it wrong. Thus, maybe macOS uses the MIAF in some heuristics on how they interpret the EXIF data instead of strictly following the standard.

bigcat88 commented 2 years ago

I can say more: when a file contains multiple images, the Apple Preview app (on macOS Monterey) doesn't account Exif orientation (tested this June). Exactly the opposite as with one.

japheth-sh commented 2 years ago

Mine contains only one still image. Maybe "miaf" misguided MacOS? Is it possible we have an official patch with no "miaf" when there is only one image?

farindk commented 2 years ago

I don't think it's a good idea to introduce "bugs" into libheif just to compensate bugs in some other software. There may be a set of programs that only accept MIAF images because of their stricter specification.

japheth-sh commented 2 years ago

Ok...so my 43.heic is a correct heic file and we can ignore Mac incorrect orientation, right?

farindk commented 2 years ago

You can attach the two images (43.heic and the original) to here and I'll check whether the file is correct. If it is, it's on Apple to fix their bug.

japheth-sh commented 2 years ago

heics.zip @farindk Here you are. Thanks a lot for checking this.

farindk commented 2 years ago

I had a closer look at 43.heif. There is one unexpected thing in this file: the EXIF Orientation is set to "90 CW", but there is no 'irot' box in the HEIC. The image itself is stored in the rotated orientation. I.e. the HEIC file is stored with a wrong orientation. The EXIF Orientation should probably have been removed somewhere during the conversion and the image rotated.

The combination of a rotation in EXIF Orientation and no irot box is also unexpected by heif_convert, leading to a wrong conversion to JPEG, but which in this case just cancels out the error in the HEIC file. However, this should be corrected (#680).

Concerning the Apple output: The landscape display of 43.heic is correct. I.e. my guess is that when 'miaf' is present, Apple uses the strict standard compliant decoding which (correctly) ignores the EXIF data, while without 'miaf' it switches to a "compatibility" mode that uses the EXIF Orientation because a lot of software got it wrong at the beginning and new software does basically always include 'miaf'.