Closed pkulak closed 2 years ago
Just tested this. It worked, but the image orientation was wrong. Seems like iOS autorotates the image based on some algorithm which is lost when the file is converted. Is there metadata in the HEIF file that could be used to insure correct rotation?
Just tested this. It worked, but the image orientation was wrong. Seems like iOS autorotates the image based on some algorithm which is lost when the file is converted. Is there metadata in the HEIF file that could be used to insure correct rotation?
Aw, this must be because I'm stripping all the EXIF information. I can keep it, it'll just be a bit more work. I'll see what I can do.
Arg. Just rebuilt it using heif-convert and it still doesn't work. Looks like rotation is a huge PITA with Apple's HEIF implimentation:
https://github.com/strukturag/libheif/issues/227
I'm gonna keep my fork as is, since the occasional bad rotation is better than not working at all, but I'll close this PR if I can't get it working properly.
Alright, I have it working, but only by adding yet another external dependency. libexif and libheif both have Go bindings, so this is definitely a hack.
Got it! Much better. And when I use libheif directly, it seems to figure out all the rotation issues. Calling this PR ready. Sorry for all the commits!
Latest patch worked for me with correct rotation. Great work!
Could we put this behind a feature flag? HEIF as a format can include multiple subpictures in different colorspaces layered on top of each other, animation, and more, hence converting to jpeg is almost always a "downgrade" in picture information / quality, while increasing compatibility though. However, if you are only using clients that support HEIF, then keeping images as HEIF would be preferable imho.
No idea if this is even something you guys have an interest in (does Beeper handle HEIF better than my client?), but I figured I'd offer it upstream just in case.