I changed Unspecified to Bt.601.

Even here it is marked as Bt.709 (what is a bug I consider )

Actually ravif is using Bt.601 as default, so to not create gaps in implementation I think it is better to go this way.

Left a few comments, but I had a hard time reviewing the PR. I've started reading through like three times and every time I get lost trying to keep all the different cases in my head.

I'd encourage finding ways to consolidate different cases. As one example, if yuv400_to_rgba8 took a YuvPlanarImage with u_plane and v_plane set to &[] then you wouldn't need a completely separate code path to deal with it.

Sorry, I tried to keep it small, but all these takes some space.

Yes, using YuvPlanarImage for YUV 4:0:0 will remove some code. However, if you'll decide to expose this method to whole create it will be definitely not clear how to use this.
If it is fine to you it is fine by me.

This is more clean now.

However, actual complexity just became obscured instead of explicit.
If someone we’ll try to use those methods better to think twice about what he’s doing.

Perhaps, I can do some simple strategy pattern here, for each case GBR, 4:0:0, or other, something like that.

trait AvifResolutionStrategy {
    fn is_supported(&self, picture: Picture) -> bool;
    fn process<R: Read>(picture: Picture, buf: &mut [u8]) -> ImageResult<()>;
}

This will also keep everything clear, but will notably increase amount of code.

Otherwise, if you don't like that one, I think at the moment there is the best code at least in AvifDecoder, for a price that YUV converters magically accept or not accept some arguments.

I also splat a little 4:2:0 and 4:2:2 processing, I think it'd make quite easier to understand what's going on there.

So, as there again was raised a concern about what actually targets are,
I would like to hear what matrix should be set on Unspecified.

To simplify a question, if the compatibility with ravif is preferred then Bt.601 should be kept, if compatibility with browsers is a goal then Bt.709.

I'd say we should probably match web browsers. Plus, we tend to assume sRGB throughout the crate, so this wouldn't be a big departure

Now that this PR is approved I'm going to hit the merge button, unless @fintelia objects?

I'll also start preparing a point release because we have plenty of fixes and improvements in git already.

@Shnatsel You can press the merge button next time. As far as I understood @fintelia had already deferred the remaining review to me. I just got side tracked between the LGTM and merging with #dayjob work. Thanks for preparing the release notes already 👍