Only use aom codec for AVIF

[radarhere]

Helps #8856. Alternative to #8858

If there is debate about which codecs to include and exclude, then maybe the quickest solution is to prevent the user from setting the codec at all for the moment, and save that feature for the next release?

[fdintino]

With the changes in #8858, it would still be possible for people to build pillow for themselves from source with AVIF support for other codecs. What would be the point of foreclosing that possibility?

And is there debate about which codecs to include? I think aom is a no-brainer for the encoder, but dav1d is basically the industry standard decoder. It is the decoder used by every major browser: Edge, Safari, Chrome, and Firefox.

[wantehchang]

We should only consider removing dav1d as a last resort. Although the decoder in libaom is the reference implementation and we test it with open-source and commercial AV1 test vectors and fuzzing regularly at Google, dav1d is likely to have better software security because it is being used in far more applications, including some that perform additional fuzzing of dav1d.

[radarhere]

With the changes in #8858, it would still be possible for people to build pillow for themselves from source with AVIF support for other codecs. What would be the point of foreclosing that possibility?

It was suggested internally, with the thinking that perhaps there are only a small number of people who compile Pillow from source. So I suppose the answer is lessening the maintenance burden.

I don’t want to close the door on other libavif codecs. I’m primarily interested in releasing Pillow 11.2.0 (as it’s been delayed for 4 days so far by this issue), while being confident that we’re not going to release a feature and then remove it. If #8858 is selected instead, fine - I just want to make sure that if someone decides that this strategy the solution, then there is a PR ready.

[fdintino]

I don't know if the aom decoder is still being considered, but if it is I would like to state plainly that I think it's a bad idea. In addition to the security consideration that @wantehchang noted, dav1d is much faster than AOM. This is largely the reason that the binaries with the AOM decoder are smaller: it doesn't have any hardware optimizations. It would be incorrect to say that the AOM decoder has poor performance. It is simply unconcerned with performance. That is why every application that ships with an AVIF decoder uses dav1d.

[aclark4life]

@fdintino @hugovk @radarhere It's mid-this-week … are we close to a consensus on #8858 over #8869 to resolve #8856? I agree with @radarhere that we don't want to release a feature and then remove it, so if the decision requires more time, so be it. Just wanted to make sure our process to resolve #8856 keeps moving so we can close #8722! Thanks folks 🙏

[radarhere]

I raise no objections to the current state of #8858. It is 523mb at the moment. That is significantly smaller (half) than our first attempt at 11.2.0.

I'm not advocating #8869 over #8858, it is just my 'In case of emergency, it's better than removing AVIF completely' PR. It is 473mb at the moment.

Just as long as we are willing to stick to including AVIF support in wheels, and don't feel that 523mb is still problematic. There's no clearly defined target that we're aiming for.

[aclark4life]

Just as long as we are willing to stick to including AVIF support in wheels, and don't feel that 523mb is still problematic. There's no clearly defined target that we're aiming for.

It's clearly a problem for some … so I'm inclined to say let's not include them now, especially if we haven't included them in previous releases. If that's a viable option, then that's probably the best way to resolve this for now.

[fdintino]

The existence of PIL.AvifImagePlugin doesn't prevent someone from using pillow-avif-plugin; the registered open function fails over correctly. So that option is still available to anyone who wants AVIF support but doesn't want to compile anything themselves. I have parity there with the platforms, architectures, and python versions currently in Pillow.

I'm keeping an eye on PEP-771, which would provide a nice path forward that would allow size-conscious users the ability to opt-out of features they don't need (not only AVIF).

Also, I'm not necessarily recommending this (though I wouldn't be entirely opposed), but: if we were to change the lines

try:
    from . import _avif

    SUPPORTED = True
except ImportError:
    SUPPORTED = False

to

try:
    from . import _avif

    SUPPORTED = True
except ImportError:
    try:
        from pillow_avif import _avif

        SUPPORTED = True
    except ImportError:    
        SUPPORTED = False

and added the following to pyproject.toml

optional-dependencies.avif = [
  "pillow-avif-plugin>=1.6.0",
]

We would have support for AVIF as an "extra." There is not yet a 1.6.0 release of pillow-avif-plugin. One of the functions in pillow_avif._avif has an extra argument in its signature than the one currently in Pillow. I would need to make a new release to have compatibility between the two. I don't think that would be feasible for an 11.2.0 release, but perhaps for the next one. Though that would be a half-measure; if you were to pursue that route I think it would be better to have pillow_whatever._avif built and packaged from this repository.

[hugovk]

I also prefer #8858 over this one, but am thinking we do #8876 to get 11.2 out the door, and can consider #8858 after that.

I'm keeping an eye on PEP-771, which would provide a nice path forward that would allow size-conscious users the ability to opt-out of features they don't need (not only AVIF).

👍

Until then, Pillow always is going to be quite big, and #8858 is a big improvement over the first attempt. For those creating space-constrained images, removing unnecessary files during image creation is an option. We can also compare other packages like NumPy at ~5-15 MB.