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
