[PATCH 2/4] media: hantro: Use standard luma quantization table
Ezequiel Garcia
ezequiel at collabora.com
Mon Jan 27 19:46:13 UTC 2020
Hi Andrzej,
On Mon, 2020-01-27 at 15:30 +0100, Andrzej Pietrasiewicz wrote:
> The table is actually different in the document than in this file, so align
> this file with the document.
>
> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p at collabora.com>
> ---
> drivers/staging/media/hantro/hantro_jpeg.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/staging/media/hantro/hantro_jpeg.c b/drivers/staging/media/hantro/hantro_jpeg.c
> index 125eb41f2ede..d3b381d00b23 100644
> --- a/drivers/staging/media/hantro/hantro_jpeg.c
> +++ b/drivers/staging/media/hantro/hantro_jpeg.c
> @@ -23,17 +23,17 @@
> #define HUFF_CHROMA_AC_OFF 409
>
> /* Default tables from JPEG ITU-T.81
> - * (ISO/IEC 10918-1) Annex K.3, I
> + * (ISO/IEC 10918-1) Annex K, tables K.1 and K.2
> */
I wonder if we shouldn't just have these tables
in decimal instead of hexa, so they look exactly
like the ones in the spec.
Thanks,
Ezequiel
> static const unsigned char luma_q_table[] = {
> - 0x10, 0x0b, 0x0a, 0x10, 0x7c, 0x8c, 0x97, 0xa1,
> - 0x0c, 0x0c, 0x0e, 0x13, 0x7e, 0x9e, 0xa0, 0x9b,
> - 0x0e, 0x0d, 0x10, 0x18, 0x8c, 0x9d, 0xa9, 0x9c,
> - 0x0e, 0x11, 0x16, 0x1d, 0x97, 0xbb, 0xb4, 0xa2,
> - 0x12, 0x16, 0x25, 0x38, 0xa8, 0x6d, 0x67, 0xb1,
> - 0x18, 0x23, 0x37, 0x40, 0xb5, 0x68, 0x71, 0xc0,
> + 0x10, 0x0b, 0x0a, 0x10, 0x18, 0x28, 0x33, 0x3d,
> + 0x0c, 0x0c, 0x0e, 0x13, 0x1a, 0x3a, 0x3c, 0x37,
> + 0x0e, 0x0d, 0x10, 0x18, 0x28, 0x39, 0x45, 0x38,
> + 0x0e, 0x11, 0x16, 0x1d, 0x33, 0x57, 0x50, 0x3e,
> + 0x12, 0x16, 0x25, 0x38, 0x44, 0x6d, 0x67, 0x4d,
> + 0x18, 0x23, 0x37, 0x40, 0x51, 0x68, 0x71, 0x5c,
> 0x31, 0x40, 0x4e, 0x57, 0x67, 0x79, 0x78, 0x65,
> - 0x48, 0x5c, 0x5f, 0x62, 0x70, 0x64, 0x67, 0xc7,
> + 0x48, 0x5c, 0x5f, 0x62, 0x70, 0x64, 0x67, 0x63
> };
>
> static const unsigned char chroma_q_table[] = {
> --
> 2.17.1
>
>
More information about the devel
mailing list