Libheif plugin support about pillow_heif HOT 8 OPEN

The next release will increase the minimum required libheif to 1.14.1 (adding support for writing image orientation to a file and encoding images in YCbCr without converting to RGB), and after that in the next release after the next - your proposal is an excellent candidate for implementation.

from pillow_heif.

I'm ready to increase the minimum required libheif version to 1.17.
If someone can tell me how I can build a libheif for macOS or Ubuntu/ArchLinux/AlmaLinux so that it sees ffmpeg, I'll try to add support.

from pillow_heif.

do not sure that the result will be success, but looks promising.

from pillow_heif.

I do not worry about Windows, cause I am very familiar with how Windows loads libraries and there will be ok.

Now the main question:

What next after -DENABLE_PLUGIN_LOADING=ON ?
How it will be used? Is there need for heif_load_plugin or heif_load_plugins or even both?
Or specifying plugin directory only as ENV var is enough?

@russkel

from pillow_heif.

Hi @bigcat88

This looks great! I will be honest with you, I have not ever used libheif, only your handy library ;).

Or specifying plugin directory only as ENV var is enough?

Are you intending on packaging the plugins with this library? If so then perhaps the plugin directory could be provided in someway in that it will find them without having to provide the path. The Cmake var PLUGIN_DIRECTORY is used for this.

Apart from that it looks like that's all that is required. You then specify the decoder/encoder name as part of normal libheif usage.

from pillow_heif.

Also I wonder why there is no ffmpeg encoder, only decoder. This was what I was interested in 😅

from pillow_heif.

Also I wonder why there is no ffmpeg encoder, only decoder. This was what I was interested in 😅

Because no one has yet made such a plugin and functionality as an ffmpeg encoder for libheif. Only decoder was implemented(and I already tested it locally, it has a limited abilities and can not decode some HDR HEICs currently)

Are you intending on packaging the plugins with this library?

The main reason I started work on this is to move x265 HEIF encoder to a separate python plugin to remove GPL2.0 license from binary wheels as it is hard to me to maintain binary wheels with so many libraries that has different licenses.

Second reason is the upcoming CUDA encoder/decoder for Libheif, as I hope after that also a Intel/AMD plugins will arise a bit later.

I already know before started working on this issue that ffmpeg decoder plugin has currently limited capabilities, that's why I was not rushing it

from pillow_heif.

I was interested in ffmpeg because it has the CUDA/Intel/etc encoders, but if they're going to be directly supported at some point that's great.

from pillow_heif.