Hello @adityapatadia,

This sounds sensible. I'm reluctant to add /every/ parameter, since we will have to support and maintain them years into the future, and many are likely to be removed / added to / changed as AVIF evolves.

Is there a list of core, or essential parameters? We should certainly make sure we support all of them.

There is also a library libavif which has official support so may be that can be used to support encoding of AVIF images and libheif can be used to encode HEVC only. https://github.com/AOMediaCodec/libavif

Is there a list of core, or essential parameters? We should certainly make sure we support all of them

From the link heif_encoder_aom.cc file, it seems essential parameters are speed, threads, chroma_subsampling, quality and realtime. They can greatly change the output type, quality, speed and are likely going to be supported forever.

Currently 3 parameters are supported: https://libvips.github.io/libvips/API/current/VipsForeignSave.html#vips-heifsave

libheif uses a plugin-based approach for its encoders/decoders so there are already a number of optional string/integer/boolean parameters (using libheif's own type system) for x265, de265, aom and rav1e, plus soon will be further optional parameters for dav1d and svt-av1.

The current (exhaustive) list of encoder parameters in svt-av1, which I suspect may be become the defacto AVIF encoder on x64, can be seen at https://github.com/OpenVisualCloud/SVT-AV1/blob/master/Docs/svt-av1_encoder_user_guide.md#list-of-all-configuration-parameters

I would agree that "speed" and "chroma" are good candidates to add as they have equivalents in the WebP and JPEG savers respectively. The "realtime" setting appears to produce file sizes much larger than the JPEG equivalent, so would question its value.

One thing to note however is that "speed" is not entirely straightforward as each libheif encoder plugin accepts different values; aom is 0-8 whereas rav1e is 0-10 whereas x265 is "superfast" to "veryslow".

The "realtime" setting appears to produce file sizes much larger than the JPEG equivalent, so would question its value.

Agree.

One thing to note however is that "speed" is not entirely straightforward as each libheif encoder plugin accepts different values; aom is 0-8 whereas rav1e is 0-10 whereas x265 is "superfast" to "veryslow".

Yes this can create issues. May be we can create different functions for AV1 and HEIF? Still that AOM vs Rav1e issues will remain :(

Another approach of mapping speed is taken here by libavif: https://github.com/AOMediaCodec/libavif/blob/07cdae3d036aec69fc231bd95cd3b69210982a37/src/codec_aom.c#L226