On Wed, 2020-11-04 at 15:08 +0100, Hans Verkuil wrote:

This was never really well defined. Basically the JPEG standard
doesn't
store colorimetry as metadata, instead it is understood to be sRGB
colorimetry.

So if you take what a HW JPEG encoder creates and want to show it on
another
device, then it will be interpreted as sRGB. Now if userspace adds
some JPEG
extension where it declares the colorimetry to be something else,
then that
is fine, but that's out of scope of a HW JPEG encoder driver, IMHO.

I suspect that the coda patch was actually trying to make coda behave
with
an older version of v4l2-compliance where a JPEG codec was tested in
the
same way as a H264 codec. Later we realized that that didn't make
sense for
JPEG codecs and the test was changed. But now coda fails on that
test.

quoted

Once I clarify on this, I'll include a fix in v5.

I hope this helps.

        Hans

Thanks for clarifying, I fixed the colorspace information to sRGB, for
both capture & output (V4L2_COLORSPACE_SRGB, V4L2_YCBCR_ENC_601 and
V4L2_QUANTIZATION_FULL_RANGE). All pass now. It will be in the next
version.