tree dd2b589144d2c632c40f527c0c867afed19a06c4
parent bca9f54b79d6a8ab883b917f731f6892d0bb8f1d
author Yannis Guyon <yguyon@google.com> 1659602233 +0200
committer GitHub <noreply@github.com> 1659602233 +0200
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJi64U5CRBK7hj4Ov3rIwAARXAIAALrH71/Y4ffy70SyM8RRgjk
 srChB482OEK8mKNrLDYCZVH9mw7NejquIhDnjIWU865rgVivSlI6fXntjZ59AzYr
 DQ3SOiP+f5WOxCMlkU3xgctn6cQSry4MBVx3EQQykuPOWtg9cJOKTyRuyNquNUkf
 zqUu6w9Wl5j9HnxYeINXg80B1UDAvukn//KujzFjXaRyfLmnN8dnQ8mpuNxO9zsy
 fn0L8+BUxJOis3DnEq6skQNBqpPHwvOOtpt9bU46cYE7Q/+dIEeGYocVG+ch3Jkx
 P3IrIfoomB28ntGalbUzYWLbjAAThvKNmj6C/o7hdIfZiJlQMqLqvMvMtp5667M=
 =FHZf
 -----END PGP SIGNATURE-----
 

Add avifImageRGBToYUVLibYUV()

Add avifRGBImage::chromaDownsampling.

Use libyuv for RGB to YUV conversion when possible. For now only 8-bit
BT.601 is handled and only for some RGB and YUV layouts.
The conversion itself can be several times faster than the current
built-in floating point conversion. For example, avifImageRGBToYUV()
took 1.6s (built-in) vs 0.2s (libyuv) during a local test.

The full range loss is comparable to the precision loss between built-in
and libyuv YUV to RGB conversion, both being used by libavif already.

See also https://bugs.chromium.org/p/libyuv/issues/detail?id=936.

This change does not impact the core library. Only the tooling dealing
with non-YUV color spaces should be faster in some cases. For example,
avifenc is expected to be up to 7% faster when encoding PNG images at
AVIF_SPEED_FASTEST for available libyuv conversions.

Update CHANGELOG.md.