Support for HEIF

[pythonicrubyist]

Do you have any plans to support HEIF image format, recently introduced by apple?

[wiredfool]

I would welcome support, but I'm not aware of any appropriately licensed HEIF or HEVC libraries to do encoding/decoding.

[CounterPillow]

The reference HEVC encoder/decoder is licensed as BSD 3-clause (but obviously extremely slow and tuned for PSNR), the openHEVC decoder is licensed as LGPL2.1.

Patent licenses are the bigger issue; the current patent licensing situation with 3 competing pools means that it'd be practically impossible for any FOSS project to produce binaries including a HEVC decoder which don't violate some patents.

So even if someone were to do the work to implement it, you wouldn't find it in most Pillow builds, because nobody wants to get harassed by the patent trolls.

[wiredfool]

The HEIF container decoder is also not a free license: https://github.com/nokiatech/heif/blob/master/LICENSE.TXT .

[CounterPillow]

There's an initial HEIF support patch for FFmpeg floating around on their mailing list, but as the post itself says, it's early work and the whole format is batshit insane. The container is based off of MP4 for a start.

I don't think it'll be possible to support HEIF in Pillow in a sane manner based on the container and codec complexity alone, and even if someone were to make a demuxer+decoder in one library with a license Pillow could use, you wouldn't be able to build a product on it for around 30 more years, assuming the patents remain unlicenseable for anyone without big money lawyers.

[wiredfool]

I'm definitely -1 on batshit insane.

I think that the only way it could work is if we shipped support that was dynamically linked and based off of OS libraries, e.g. CoreImage on OSX. But it's not clear that would work, and it would only be the one platform at this point.

I'm going to close this, if the world comes around to the point that it's reasonable, we can look at it.

[rspeed]

What about libheif? It takes care of the packaging while using libde265 for reading and x265 for writing. All three libraries are LGPL.

My understanding is that there would be no patent issues whatsoever for Pillow. The HEIF container itself has a blanket patent waiver, and the HEVC licensing authority doesn't require a license for software that isn't bundled with devices.

Under the software initiative, HEVC Advance will not seek a license or royalties on HEVC functionality implemented in application layer software downloaded to mobile devices or personal computers after the initial sale of the device, where the HEVC encoding or decoding is fully executed in software on a general purpose CPU. Examples of the types of software within the policy include browsers, media players and various software applications.

As far as I can tell, there's nothing blocking this other than the current instability of libheif's API.

Edit: Found a better link for the royalty-free license announcement and added a summary.

[farindk]

libheif encoder API is stable since version 1.1.0. It will appear in Debian testing in a few days:
https://packages.qa.debian.org/libh/libheif.html

I have not much experience with python, but if you need any assistance, feel free to contact me (I'm the libheif author).

[CounterPillow]

@rspeed HEVC Advance is only one of three competing HEVC licensing authorities.

[rspeed]

@CounterPillow So we'd need similar guarantees from the others?

[CounterPillow]

Yes, or just hope none of them feel like trying to enforce their patents against you. Though I don't think patent issues should prevent HEIF support from being added to Pillow. It's up to the companies or individuals building commercials products using Pillow to ensure their product doesn't infringe on any patents; I was simply pointing out that Linux distros like RedHat or OpenSuSE likely will want to ship Pillow without HEIF support.