Use AOM_TUNE_IQ by default

[y-guyon]

Based on #2599.

Note that "(Default: psnr)" was incorrect.

[juliobbv-p]

Thanks for opening this PR, Yannis!

Can tune iq be applied to just the YUV planes, and not alpha? The perceptual optimizations are likely harmful for the alpha channel.

[y-guyon]

I understood "only YUV" as "not RGB", and not "not alpha". But I did not even test for identity MC. Do you know if AOM_TUNE_IQ for all matrix coefficients and color spaces (besides identity I guess)?

Good point for alpha.

[juliobbv-p]

Do you know if AOM_TUNE_IQ for all matrix coefficients and color spaces (besides identity I guess)?

Good question! So, AOM_TUNE_IQ has been tuned for the YCbCr families of matrix coefficients and color spaces. That said, the tune tweaks do generalize (to various degrees) to all matrix coefficients, color spaces, and transfer characteristics that have one luma and two chroma channels.

I think we should be good turning it on globally on still images, except for the identity MC.

[y-guyon]

Should AOM_TUNE_PSNR or AOM_TUNE_SSIM be used for alpha?

[juliobbv-p]

Probably both PSNR or SSIM are fine for alpha, but anecdotally I've seen PSNR ring a bit less on grayscale images, so PSNR might be the better choice of the two for alpha (if the decoder interprets ringing as incorrect alpha values that make the underlying image too opaque or transparent).

[maryla-uc]

WIth this PR, using -a sharpness=0 does nothing because when you set tune=iq it overrides it.
This also happens if you manually set -a sharpness=0 -a tune=iq. It only works as expected with -a tune=iq -a sharpness=0.

[juliobbv-p]

@maryla-uc good catch! tune iq sets up many optimized defaults (including --sharpness), so the codec control call to set tune iq should happen before the -a parameters.

[y-guyon]

@maryla-uc good catch! tune iq sets up many optimized defaults (including --sharpness), so the codec control call to set tune iq should happen before the -a parameters.

Done.

[castano]

Any idea what's holding up this PR?

[y-guyon]

Any idea what's holding up this PR?

There are a few consequences of TUNE=IQ to take into consideration when using it by default:

• The quality encoding setting does not lead to the same file size and visual distortion, so the default encoding settings may end in noticeably different output after this change.
• TUNE=IQ is slower to encode. One option may be to increase the default speed to 7 instead of 6, but that could also have side effects on output file size and decoding time.

[juliobbv-p]

@castano another thing worth mentioning: tune IQ is already considered production quality (on libaom 3.13.1 and newer). If a project doesn't have to worry about specific tune ssim behavior, then said project can just switch to use tune IQ right away.

For example, The Guardian has been using tune IQ for a few months, and we've received positive feedback from the website admin in the form of overall better image quality and consistency. Tune IQ's improvement in bit allocation by itself can be seen as a "bug fix".

I wouldn't wait for this PR to be merged as a sign of feature "readiness". On the contrary, we're just trying to be super thorough in understanding the inherent differences in bitrate allocation and encode time with tune IQ across images, compared to tune SSIM.

[castano]

I think it makes sense to evaluate the consequences of enabling tune IQ before making it the default choice, but it would be helpful to first add support for tune IQ as a user option, and only later make it the default after more users have had the chance to evaluate it and provide feedback.

I have clients interested in using tune IQ, but they won't maintain a custom build of libavif with modifications that they have to merge on every update.

Similarly, tools that use libavif won't offer this option until it's officially supported by libavif, so not having this exposed also delays its upstream adoption.

[juliobbv-p]

@castano you can enable tune IQ in avifenc with the following parameter: -a c:tune=iq. This is the official way to switch between different tunings, so it's guaranteed to never change.

avifenc in turn passes in the parameter to libavif as a key ("tune")/ value ("iq") pair in the following manner:

static avifBool avifCodecSpecificOptionsAdd(avifCodecSpecificOptions * options, const char * keyValue)
{
    const char * value = strchr(keyValue, '=');
    if (value) {
        // Keep the parts on the left and on the right of the equal sign,
        // but not the equal sign itself.
        const size_t keyLength = value - keyValue;
        return avifCodecSpecificOptionsAddKeyValue(options, keyValue, keyLength, value + 1);
    }
    // Pass in a non-NULL, empty string. Codecs can use the mere existence of a key as a boolean value.
    return avifCodecSpecificOptionsAddKeyValue(options, keyValue, strlen(keyValue), "");
}

avifenc.c has the necessary code to talk to libavif, including passing in codec-specific options.

[castano]

Hmm... I haven't tried avifenc, but I didn't see the iq option in the aomOptionDefs struct, so I assumed that would not work without additional changes:

https://github.com/AOMediaCodec/libavif/blob/40cb2c1fbff1e14b6c81816b73a364490b12ffb6/src/codec_aom.c#L397C39-L397C49

Ah, I see it gets routed to aom_codec_set_option, never mind!

[wantehchang]

Ignacio: The aomOptionDefs struct is only used with older versions of libaom that don't have the aom_codec_set_option() function. In that case, the feature detection macro HAVE_AOM_CODEC_SET_OPTION is not defined.

For testing this pull request, please use the latest version of libaom, v3.13.1 if you can. Thanks!