Re: [PATCH 5/7] media: coda: fix default JPEG colorimetry

[Philipp Zabel <p.zabel@pengutronix.de>]

On Do, 2022-04-21 at 12:02 +0200, Hans Verkuil wrote:
[...]
> > -	if (fmt->pixelformat == V4L2_PIX_FMT_JPEG)
> > -		colorspace = V4L2_COLORSPACE_JPEG;
> 
> It's perfectly fine to keep this, the problem occurs with the raw image side
> (capture for the decoder, output for the encoder).
> 
> There the colorspace must be SRGB, the xfer_func may be 0 or SRGB,

v4l2-compliance doesn't allow xfer_func 0:

		fail: v4l2-test-formats.cpp(835): fmt_jpeg.g_xfer_func() != V4L2_XFER_FUNC_SRGB
	test VIDIOC_S_FMT: FAIL

Is this too strict?

> and the
> ycbcr_enc is 0 (if not a YUV pixelformat) or ENC_601 (if it is a YUV format).

Why does it have to be ENC_601 for YUV formats? Both
V4L2_MAP_YCBCR_ENC_DEFAULT(V4L2_COLORSPACE_JPEG) and
V4L2_MAP_YCBCR_ENC_DEFAULT(V4L2_COLORSPACE_SRGB) map to
V4L2_YCBCR_ENC_601 regardless of the pixel format, so there should be
no difference if 0 was allowed as well.

On the other hand, quantization should be set to
V4L2_QUANTIZATION_FULL_RANGE for YUV formats on the raw image side, as
that defaults to LIM_RANGE for raw YUV images with SRGB colorspace.

Basically, I wonder whether or not it would be a good idea to apply the
following change to v4l2-compliance:

diff --git a/utils/v4l2-compliance/v4l2-test-formats.cpp b/utils/v4l2-compliance/v4l2-test-formats.cpp
index 269a3832fcdf..902c66367ff7 100644
--- a/utils/v4l2-compliance/v4l2-test-formats.cpp
+++ b/utils/v4l2-compliance/v4l2-test-formats.cpp
@@ -832,8 +832,10 @@ static int testJPEGColorspace(const cv4l_fmt &fmt_raw, const cv4l_fmt &fmt_jpeg,
        }
        /* V4L2_COLORSPACE_JPEG is shorthand for these values: */
        fail_on_test(fmt_jpeg.g_colorspace() != V4L2_COLORSPACE_SRGB);
-       fail_on_test(fmt_jpeg.g_xfer_func() != V4L2_XFER_FUNC_SRGB);
-       fail_on_test(fmt_jpeg.g_ycbcr_enc() != V4L2_YCBCR_ENC_601);
+       fail_on_test(fmt_jpeg.g_xfer_func() != V4L2_XFER_FUNC_DEFAULT &&
+                    fmt_jpeg.g_xfer_func() != V4L2_XFER_FUNC_SRGB);
+       fail_on_test(fmt_jpeg.g_ycbcr_enc() != V4L2_YCBCR_ENC_DEFAULT &&
+                    fmt_jpeg.g_ycbcr_enc() != V4L2_YCBCR_ENC_601);
        fail_on_test(fmt_jpeg.g_quantization() != V4L2_QUANTIZATION_FULL_RANGE);
        return 0;
 }

Actually, if the hardware can convert from other YUV encodings such as 709,
then other YUV encodings are valid, but I assume that's not the case.

True, the hardware is completely oblivious to colorimetry.

regards
Philipp