Page MenuHomePhabricator

imlib2: Native support for HEIF
Open, Incoming QueuePublic

Description

HEIF is now the default output format on Samsung and Apple's phones. There is even a basic third-party loader for imlib2: imlib2-heic
Adding HEIF natively into imlib2 would greatly benefit all downstream projects, as phone vendors are pushing HEIF as a JPEG replacement.

dllud created this task.Jan 17 2021, 3:16 PM
Colocasian added a subscriber: Colocasian.

I have implemented load2 for now, implementing save right now. Using libheif, as it covers both HEIF and AVIF itself. Here's the revision URI: https://phab.enlightenment.org/D12267

Colocasian added a comment.EditedTue, May 4, 2:56 AM

There is still an issue (I think). If imlib2 is compiled/linked with libheif<1.7.0, then weird issues may arise due to lack of convert_hdr_to_8bit decoding option. If image has > 8 bit per color (which is possible as per HEIF standard), then the wrong colors would be displayed, as it is assumed in code that each color is stored in its respective 8 bits. This would result in completely mangled image data (could not test the same, as I could not install older version of libheif to test it).

There are two ways to solve this. Either,

  • Increase dependency version to libheif>=1.7.0, or
  • Include extra code which would extract the most significant 8 bits out of the color values.

I believe the former (i.e. increasing dependency version) is the better solution, as it seems very unlikely that someone would be using that old of a version of libheif, as well as AVIF support was only added to libheif in version 1.7.0, but I would like some more opinion on that.

Edit: Just checked, Arch Linux (which I'm currently using) has the latest version libheif=1.11.0, but Debian Buster stable still seems to have libheif=1.3. But it also seems to have imlib2=1.5.1 (checked as of 2021-05-04). This just made me quite a lot confused on what to do.

ProhtMeyhet added a subscriber: raster.