<div dir="ltr">Hi,<div><br></div><div>On a related note, we are also getting this warning on the Raspberry Pi platform with commit e297673e7686:</div><div><br></div><div>WARN V4L2 v4l2_subdevice.cpp:512 'imx477 10-001a': Unknown subdev format 0x7002, defaulting to RGB encoding<br></div><div><br></div><div>This is because the embedded buffer stream format (i.e. a non-image data format) does not map to a libcamera PixelFormat* at present.  In the past, we've had similar issues and decided not to use WARN level to flag this.  Can we do the same here please? </div><div><br></div><div>Not directly related to the logging message, but I suppose the same question should also be asked here - should we be overwriting the colorEncoding in these circumstances?</div><div><br></div><div>Regards,</div><div>Naush</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 5 Sept 2022 at 13:25, David Plowman via libcamera-devel <<a href="mailto:libcamera-devel@lists.libcamera.org">libcamera-devel@lists.libcamera.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi everyone<div><br></div><div>We've recently checked out the latest version of libcamera and are having a few colour space issues. Obviously I'm sorry to be raising this at a stage where the commits have already been applied, but maybe we can think of some kind of acceptable workaround.</div><div><br></div><div>The problems come with commit 4aa71c ("libcamera: color_space: Move color space adjustment to ColorSpace class"). The specific behaviour that causes us grief is where it overwrites the YCbCr encoding matrix to "None" when the pixel format is an RGB one.</div><div><br></div><div>In the Pi's pipeline, pixels fundamentally end up as YUV and there's an extra conversion that happens if you want RGB. So this means we do need to know that YCbCr matrix.</div><div><br></div><div>More generally, I'm not sure how I feel about taking "standard colour spaces" and  then overwriting some parts of them, so that afterwards something that is equivalent to (for example) sYCC is then no longer == Sycc(). Possibly I'm being a bit paranoid here, I'm not sure.</div><div><br></div><div>Anyway, I'm not quite sure what to do about this. Is this behaviour now important to other platforms? I guess we have the option to override the validateColorSpaces method for the RPiCameraConfiguration. Or add another flag "don't-touch-my-colour-spaces". But I'm not sensing great elegance here...</div><div><br></div><div>Any suggestions?</div><div><br></div><div>David</div></div>
</blockquote></div>