Is V4L2_PIX_FMT_RGB656 RGB or BGR ?

Is V4L2_PIX_FMT_RGB656 RGB or BGR ?

[Laurent Pinchart]

According to http://linuxtv.org/downloads/v4l-dvb-apis/packed-rgb.html, 
V4L2_PIX_FMT_RGB565 is defined as

 Identifier           Byte 0 in memory         Byte 1 
                  Bit  7  6  5  4  3  2  1  0    7  6  5  4  3  2  1  0
 V4L2_PIX_FMT_RGB565  g2 g1 g0 r4 r3 r2 r1 r0   b4 b3 b2 b1 b0 g5 g4 g3

As this is stored in little-endian, the color word is thus

b4 b3 b2 b1 b0 g5 g4 g3 g2 g1 g0 r4 r3 r2 r1 r0

This looks awfully like BGR to me, not RGB.

I need to define a FOURCC for the corresponding RGB format

 Identifier           Byte 0 in memory         Byte 1 
                  Bit  7  6  5  4  3  2  1  0    7  6  5  4  3  2  1  0
 V4L2_PIX_FMT_RGB565  g2 g1 g0 b4 b3 b2 b1 b0   r4 r3 r2 r1 r0 g5 g4 g3

Should I call it V4L2_PIX_FMT_BGR565 ? :-)

-- 
Regards,

Laurent Pinchart

Re: Is V4L2_PIX_FMT_RGB656 RGB or BGR ?

[Mauro Carvalho Chehab]

Em 12-08-2011 13:26, Laurent Pinchart escreveu:
> According to http://linuxtv.org/downloads/v4l-dvb-apis/packed-rgb.html, 
> V4L2_PIX_FMT_RGB565 is defined as
> 
>  Identifier           Byte 0 in memory         Byte 1 
>                   Bit  7  6  5  4  3  2  1  0    7  6  5  4  3  2  1  0
>  V4L2_PIX_FMT_RGB565  g2 g1 g0 r4 r3 r2 r1 r0   b4 b3 b2 b1 b0 g5 g4 g3
> 
> As this is stored in little-endian, the color word is thus
> 
> b4 b3 b2 b1 b0 g5 g4 g3 g2 g1 g0 r4 r3 r2 r1 r0
> 
> This looks awfully like BGR to me, not RGB.
> 
> I need to define a FOURCC for the corresponding RGB format
> 
>  Identifier           Byte 0 in memory         Byte 1 
>                   Bit  7  6  5  4  3  2  1  0    7  6  5  4  3  2  1  0
>  V4L2_PIX_FMT_RGB565  g2 g1 g0 b4 b3 b2 b1 b0   r4 r3 r2 r1 r0 g5 g4 g3
> 
> Should I call it V4L2_PIX_FMT_BGR565 ? :-)
> 

Had you seen both Tables 2.6 and 2.7?

http://linuxtv.org/downloads/v4l-dvb-apis/packed-rgb.html#rgb-formats-corrected

The format you're looking for is "table 2.7" version of V4L2_PIX_FMT_BGR565.

Yeah, this looks crazy. Basically, some drivers were using it on one way, while
other drivers were using it the other way. I suspect that this trouble were there
since V4L1 times.

See at the changelogs (http://linuxtv.org/downloads/v4l-dvb-apis/hist-v4l2.html),
in particular the one on 2003:

1998-11-14: V4L2_PIX_FMT_RGB24 changed to V4L2_PIX_FMT_BGR24, and V4L2_PIX_FMT_RGB32 changed to V4L2_PIX_FMT_BGR32. Audio controls are now accessible with the VIDIOC_G_CTRL and VIDIOC_S_CTRL ioctls under names starting with V4L2_CID_AUDIO. The V4L2_MAJOR define was removed from videodev.h since it was only used once in the videodev kernel module. The YUV422 and YUV411 planar image formats were added.

2001-04-13: Big endian 16-bit RGB formats were added.

V4L2 2003-11-05:

  In the section called “RGB Formats” the following pixel formats were incorrectly transferred from Bill Dirks' V4L2 specification. Descriptions below refer to bytes in memory, in ascending address order.
  In the section called “Image Properties” the mapping of the V4L VIDEO_PALETTE_RGB24 and VIDEO_PALETTE_RGB32 formats to V4L2 pixel formats was accordingly corrected.
  Unrelated to the fixes above, drivers may still interpret some V4L2 RGB pixel formats differently. These issues have yet to be addressed, for details see the section called “RGB Formats”.


Mauro.

Re: Is V4L2_PIX_FMT_RGB656 RGB or BGR ?

[Laurent Pinchart]

Hi Mauro,

On Friday 12 August 2011 21:18:32 Mauro Carvalho Chehab wrote:
> Em 12-08-2011 13:26, Laurent Pinchart escreveu:
> > According to http://linuxtv.org/downloads/v4l-dvb-apis/packed-rgb.html,
> > V4L2_PIX_FMT_RGB565 is defined as
> > 
> >  Identifier           Byte 0 in memory         Byte 1
> >  
> >                   Bit  7  6  5  4  3  2  1  0    7  6  5  4  3  2  1  0
> >  
> >  V4L2_PIX_FMT_RGB565  g2 g1 g0 r4 r3 r2 r1 r0   b4 b3 b2 b1 b0 g5 g4 g3
> > 
> > As this is stored in little-endian, the color word is thus
> > 
> > b4 b3 b2 b1 b0 g5 g4 g3 g2 g1 g0 r4 r3 r2 r1 r0
> > 
> > This looks awfully like BGR to me, not RGB.
> > 
> > I need to define a FOURCC for the corresponding RGB format
> > 
> >  Identifier           Byte 0 in memory         Byte 1
> >  
> >                   Bit  7  6  5  4  3  2  1  0    7  6  5  4  3  2  1  0
> >  
> >  V4L2_PIX_FMT_RGB565  g2 g1 g0 b4 b3 b2 b1 b0   r4 r3 r2 r1 r0 g5 g4 g3
> > 
> > Should I call it V4L2_PIX_FMT_BGR565 ? :-)
> 
> Had you seen both Tables 2.6 and 2.7?
> 
> http://linuxtv.org/downloads/v4l-dvb-apis/packed-rgb.html#rgb-formats-corre
> cted

Good point, I missed 2.7. Thank you.

> The format you're looking for is "table 2.7" version of
> V4L2_PIX_FMT_BGR565.
> 
> Yeah, this looks crazy. Basically, some drivers were using it on one way,
> while other drivers were using it the other way. I suspect that this
> trouble were there since V4L1 times.
> 
> See at the changelogs
> (http://linuxtv.org/downloads/v4l-dvb-apis/hist-v4l2.html), in particular
> the one on 2003:
> 
> 1998-11-14: V4L2_PIX_FMT_RGB24 changed to V4L2_PIX_FMT_BGR24, and
> V4L2_PIX_FMT_RGB32 changed to V4L2_PIX_FMT_BGR32. Audio controls are now
> accessible with the VIDIOC_G_CTRL and VIDIOC_S_CTRL ioctls under names
> starting with V4L2_CID_AUDIO. The V4L2_MAJOR define was removed from
> videodev.h since it was only used once in the videodev kernel module. The
> YUV422 and YUV411 planar image formats were added.

Thinking some more about this, there might be a reason why RGB24/32 and 
BGR24/32 were mixed.

If you look at the RGB565 format, a pixel is stored as

Bit 15 14 13 12 11 10  9  8  7  6  5  4  3  2  1  0
    r4 r3 r2 r1 r0 g5 g4 g3 g2 g1 g0 b4 b3 b2 b1 b0

in a 16-bit word. Storing that to memory on a little endian system, we then 
get

Byte 0                        1
Bit  7  6  5  4  3  2  1  0   7  6  5  4  3  2  1  0
    g2 g1 g0 b4 b3 b2 b1 b0   r4 r3 r2 r1 r0 g5 g4 g3

This is logical, and is what table 2.7 defines. If we apply the same reasoning 
to an  RGB24 format, a pixel should be stored in a 24-bit word as 

Bit 23 22 21 20 19 18 17 16 15 14 13 12 11 10  9  8  7  6  5  4  3  2  1  0
    r7 r6 r5 r4 r3 r2 r1 r0 g7 g6 g5 g4 g3 g2 g1 g0 b7 b6 b5 b4 b3 b2 b1 b0

Storing that to memory on a little endian system, we would get

Byte 0                         1                         2
Bit  7  6  5  4  3  2  1  0   7  6  5  4  3  2  1  0   7  6  5  4  3  2  1  0
    b7 b6 b5 b4 b3 b2 b1 b0  g7 g6 g5 g4 g3 g2 g1 g0  r7 r6 r5 r4 r3 r2 r1 r0

We call this BGR24 in table 2.7. This makes sense, as bytes are stored in BGR 
order in memory. However, this is inconsistent with the way we name RGB565. 
The RGB565 name is defined by the pixel layout in a 16-bit word, while the 
RGB24 and (RGB32) names are defined by the pixel layout in memory.

This is obviously something we can live with, but it's worth understanding 
where we come from and how we name formats to avoid confusions.

> 2001-04-13: Big endian 16-bit RGB formats were added.
> 
> V4L2 2003-11-05:
> 
>   In the section called “RGB Formats” the following pixel formats were
> incorrectly transferred from Bill Dirks' V4L2 specification. Descriptions
> below refer to bytes in memory, in ascending address order. In the section
> called “Image Properties” the mapping of the V4L VIDEO_PALETTE_RGB24 and
> VIDEO_PALETTE_RGB32 formats to V4L2 pixel formats was accordingly
> corrected. Unrelated to the fixes above, drivers may still interpret some
> V4L2 RGB pixel formats differently. These issues have yet to be addressed,
> for details see the section called “RGB Formats”.

-- 
Regards,

Laurent Pinchart