Re: [PATCH v4 03/11] drm/fourcc: Add DRM_FORMAT_Y8
From: Tomi Valkeinen
Date: Wed Apr 16 2025 - 05:00:00 EST
Hi,
On 01/04/2025 16:27, Pekka Paalanen wrote:
On Mon, 31 Mar 2025 13:53:37 +0300
Pekka Paalanen <pekka.paalanen@xxxxxxxxxxxxx> wrote:
On Mon, 31 Mar 2025 11:21:35 +0300
Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote:
On Mon, Mar 31, 2025 at 10:54:46AM +0300, Pekka Paalanen wrote:
On Thu, 27 Mar 2025 17:35:39 +0100
Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
Hi Pekka,
On Thu, 27 Mar 2025 at 16:59, Pekka Paalanen
<pekka.paalanen@xxxxxxxxxxxxx> wrote:
On Thu, 27 Mar 2025 16:21:16 +0200
Tomi Valkeinen <tomi.valkeinen@xxxxxxxxxxxxxxxx> wrote:
On 27/03/2025 11:20, Pekka Paalanen wrote:
On Wed, 26 Mar 2025 15:55:18 +0200
Tomi Valkeinen <tomi.valkeinen@xxxxxxxxxxxxxxxx> wrote:
On 26/03/2025 15:52, Geert Uytterhoeven wrote:
On Wed, 26 Mar 2025 at 14:23, Tomi Valkeinen
<tomi.valkeinen@xxxxxxxxxxxxxxxx> wrote:
Add greyscale Y8 format.
Acked-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@xxxxxxxxxxxxxxxx>
Thanks for your patch!
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -405,6 +405,9 @@ extern "C" {
#define DRM_FORMAT_YUV444 fourcc_code('Y', 'U', '2', '4') /* non-subsampled Cb (1) and Cr (2) planes */
#define DRM_FORMAT_YVU444 fourcc_code('Y', 'V', '2', '4') /* non-subsampled Cr (1) and Cb (2) planes */
+/* Greyscale formats */
+
+#define DRM_FORMAT_Y8 fourcc_code('G', 'R', 'E', 'Y') /* 8-bit Y-only */
This format differs from e.g. DRM_FORMAT_R8, which encodes
the number of bits in the FOURCC format. What do you envision
for e.g. DRM_FORMAT_Y16? fourcc_code('G', 'R', '1', '6')?
I wanted to use the same fourcc as on V4L2 side. Strictly speaking it's
not required, but different fourccs for the same formats do confuse.
So, generally speaking, I'd pick an existing fourcc from v4l2 side if
possible, and if not, invent a new one.
what's the actual difference between DRM_FORMAT_R8 and DRM_FORMAT_Y8?
Is the difference that when R8 gets expanded to RGB, it becomes (R, 0,
0), but Y8 gets expanded to (c1 * Y, c2 * Y, c3 * Y) where c1..c3 are
defined by MatrixCoefficients (H.273 terminology)?
That would be my intuitive assumption following how YCbCr is handled.
Is it obvious enough, or should there be a comment to that effect?
You raise an interesting point. Is it defined how a display driver, that
supports R8 as a format, shows R8 on screen? I came into this in the
context of grayscale formats, so I thought R8 would be handled as (R, R,
R) in RGB. But you say (R, 0, 0), which... also makes sense.
That is a good question too. I based my assumption on OpenGL behavior
of R8.
Single channel displays do exist I believe, but being single-channel,
expansion on the other channels is likely meaningless. Hm, but for the
KMS color pipeline, it would be meaningful, like with a CTM.
Interesting.
I don't know. Maybe Geert does?
I did some digging, and was a bit surprised that it was you who told
me to use R8 instead of Y8?
https://lore.kernel.org/all/20220202111954.6ee9a10c@eldfell
Hi Geert,
indeed I did. I never thought of the question of expansion to R,G,B
before. Maybe that expansion is what spells R8 and Y8 apart?
I do think that expansion needs to be specified, so that the KMS color
pipeline computations are defined. There is a big difference between
multiplying these with an arbitrary 3x3 matrix (e.g. CTM):
- (R, 0, 0)
- (R, R, R)
- (c1 * Y, c2 * Y, c3 * Y)
I'd be very surprised by an YUV to RGB conversion matrix where the first
column would contain different values. What we need to take into account
though is quantization (full vs. limited range).
Quantization range is indeed good to note. R8 would be always full
range, but Y8 would follow COLOR_RANGE property.
That makes Y8 produce (Y, Y, Y), and we have our answer: R8 should be
(R, 0, 0), so we have both variants.
Can we specify Y, R, G and B be nominal values in the range 0.0 - 1.0
in the KMS color processing?
I think this 0.0 - 1.0 nominal range definition for the abstract KMS
color processing is necessary.
It also means that limited range Y8 data, when containing values 0-15
or 240-255, would produce negative and greater than 1.0 values,
respectively. They might get immediately clamped to 0.0 - 1.0 with the
first color operation they face, though, but the concept seems
important and carrying over to the new color pipelines UAPI which might
choose not to clamp.
Is the behavior of values outside the limited range something that needs
to be defined? We can't know how each piece of HW behaves with
"undefined" input, so should we not just define the behavior as platform
specific?
In any case: I can't say I fully understood all the discussions wrt.
color spaces. But my immediate interest is, of course, this series =).
So is there something that you think should be improved here?
My understanding is that the Y-only pixel formats behave in a well
defined way (or, as well defined as the YUV formats), and there's
nothing more to add here. Is that right?
Tomi