YUV Framebuffer

YUV Framebuffer

[Rhee, C. Joon]

[-- Attachment #1.1: Type: text/plain, Size: 228 bytes --]

Is it possible to create framebuffer color format in YUV (eg. YUV422
interleaved) and expose it through /dev/fb?

What would be fb_info type?  

And how about about fb_var_screeninfo.green/blue/red offset? 

 

Joon


[-- Attachment #1.2: Type: text/html, Size: 2046 bytes --]

[-- Attachment #2: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 182 bytes --]

_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: YUV Framebuffer

[Geert Uytterhoeven]

On Tue, 16 Oct 2007, Rhee, C. Joon wrote:
> Is it possible to create framebuffer color format in YUV (eg. YUV422
> interleaved) and expose it through /dev/fb?
> 
> What would be fb_info type?  

What do you mean with `interleaved'?
Even and odd frames are separate (interlace)?

For YUV422, you have to add a new visual type.

A long time ago, I used this for a non-public test project:

#define FB_TYPE_PACKED_PIXELS_LACED     5       /* Interlaced Packed Pixels */
#define FB_TYPE_PACKED_PIXELS_4AREAS    6       /* 4 areas of Packed Pixels */

#define FB_VISUAL_YCBCR422              6       /* YCbCr 4:2:2 */
#define FB_VISUAL_YCBCR420              7       /* YCbCr 4:2:0 */

> And how about about fb_var_screeninfo.green/blue/red offset? 

Just assume red, green, and blue mean Y, U, and V?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: YUV Framebuffer

[Rhee, C. Joon]

Hi,

Interleaved means YCBCR is on the same plane in this order.
Y CB Y CR Y CB Y CR.... (TV-Out)

The problem of matching Y=G, CB=B and CR=R for RGB offset is that the
pixel cannot be represented directly since CB/CR gets shared between Ys.

So, bitsperpixel would be 16 bit and both B and R offset will be 8.

Joon

-----Original Message-----
From: geert@linux-m68k.org [mailto:geert@linux-m68k.org] 
Sent: Tuesday, October 16, 2007 11:58 PM
To: Rhee, C. Joon
Cc: Linux Frame Buffer Device Development
Subject: Re: [Linux-fbdev-devel] YUV Framebuffer

On Tue, 16 Oct 2007, Rhee, C. Joon wrote:
> Is it possible to create framebuffer color format in YUV (eg. YUV422
> interleaved) and expose it through /dev/fb?
> 
> What would be fb_info type?  

What do you mean with `interleaved'?
Even and odd frames are separate (interlace)?

For YUV422, you have to add a new visual type.

A long time ago, I used this for a non-public test project:

#define FB_TYPE_PACKED_PIXELS_LACED     5       /* Interlaced Packed
Pixels */
#define FB_TYPE_PACKED_PIXELS_4AREAS    6       /* 4 areas of Packed
Pixels */

#define FB_VISUAL_YCBCR422              6       /* YCbCr 4:2:2 */
#define FB_VISUAL_YCBCR420              7       /* YCbCr 4:2:0 */

> And how about about fb_var_screeninfo.green/blue/red offset? 

Just assume red, green, and blue mean Y, U, and V?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker.
But
when I'm talking to journalists I just say "programmer" or something
like that.
							    -- Linus
Torvalds

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: YUV Framebuffer

[Geert Uytterhoeven]

On Wed, 17 Oct 2007, Rhee, C. Joon wrote:
> Interleaved means YCBCR is on the same plane in this order.
> Y CB Y CR Y CB Y CR.... (TV-Out)

So it's still FB_TYPE_PACKED_PIXELS.

> The problem of matching Y=G, CB=B and CR=R for RGB offset is that the
> pixel cannot be represented directly since CB/CR gets shared between Ys.
> 
> So, bitsperpixel would be 16 bit and both B and R offset will be 8.

Doesn't sound that bad to me, if you introduce a FB_VISUAL_YCBYCR
visual. Even pixels have a Cb, odd have a Cr component.

The alternative is to sets bits_per_pixel = 32, but then you get more
illogical component offsets.

Anyone with a better suggestion?

> -----Original Message-----
> From: geert@linux-m68k.org [mailto:geert@linux-m68k.org] 
> Sent: Tuesday, October 16, 2007 11:58 PM
> To: Rhee, C. Joon
> Cc: Linux Frame Buffer Device Development
> Subject: Re: [Linux-fbdev-devel] YUV Framebuffer
> 
> On Tue, 16 Oct 2007, Rhee, C. Joon wrote:
> > Is it possible to create framebuffer color format in YUV (eg. YUV422
> > interleaved) and expose it through /dev/fb?
> > 
> > What would be fb_info type?  
> 
> What do you mean with `interleaved'?
> Even and odd frames are separate (interlace)?
> 
> For YUV422, you have to add a new visual type.
> 
> A long time ago, I used this for a non-public test project:
> 
> #define FB_TYPE_PACKED_PIXELS_LACED     5       /* Interlaced Packed
> Pixels */
> #define FB_TYPE_PACKED_PIXELS_4AREAS    6       /* 4 areas of Packed
> Pixels */
> 
> #define FB_VISUAL_YCBCR422              6       /* YCbCr 4:2:2 */
> #define FB_VISUAL_YCBCR420              7       /* YCbCr 4:2:0 */
> 
> > And how about about fb_var_screeninfo.green/blue/red offset? 
> 
> Just assume red, green, and blue mean Y, U, and V?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: YUV Framebuffer

[Antonino A. Daplas]

On Wed, 2007-10-17 at 21:45 +0200, Geert Uytterhoeven wrote:
> On Wed, 17 Oct 2007, Rhee, C. Joon wrote:
> > Interleaved means YCBCR is on the same plane in this order.
> > Y CB Y CR Y CB Y CR.... (TV-Out)
> 
> So it's still FB_TYPE_PACKED_PIXELS.
> 
> > The problem of matching Y=G, CB=B and CR=R for RGB offset is that the
> > pixel cannot be represented directly since CB/CR gets shared between Ys.
> > 
> > So, bitsperpixel would be 16 bit and both B and R offset will be 8.
> 
> Doesn't sound that bad to me, if you introduce a FB_VISUAL_YCBYCR
> visual. Even pixels have a Cb, odd have a Cr component.

We need at least 3 fields to describe YUV.

1. The component size - fb_bitfield.length
2. The sample period - fb_bitfield.offset
3. The component ordering - fb_bitfield.msb_right

So if Y = red, U = green, V = blue

YUV422

red|green|blue.length = 8 /* 8 bits per component */
red.offset = 1 /* sampled every pixel */
green.offset = blue.offset = 2 /* sampled every 2 pixels */
red.msb_right = 1, green.msb_right = 2, blue.msb_right = 3
(Y U V order)

UVY411

red|green|blue.length = 8;
red.offset = 1;
green.offset = blue.offset = 4;
red.msb_right = 3, green.msb_right = 2, blue.msb_right = 1;

The FB_VISUAL_* will differentiate if the bitfields are interpreted as
RGB or YUV.

That's the only way I can think of describing YUV packed pixel formats
without adding new fields, or modifying our user-visible structures.

We will need separate drawing functions for fbcon's use.

Of course, the simplest way is to use fourcc naming for our FB_VISUAL_*
constants. But that will become too unwieldy over time.

Tony




-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: YUV Framebuffer

[Geert Uytterhoeven]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2874 bytes --]

On Thu, 18 Oct 2007, Antonino A. Daplas wrote:
> On Wed, 2007-10-17 at 21:45 +0200, Geert Uytterhoeven wrote:
> > On Wed, 17 Oct 2007, Rhee, C. Joon wrote:
> > > Interleaved means YCBCR is on the same plane in this order.
> > > Y CB Y CR Y CB Y CR.... (TV-Out)
> > 
> > So it's still FB_TYPE_PACKED_PIXELS.
> > 
> > > The problem of matching Y=G, CB=B and CR=R for RGB offset is that the
> > > pixel cannot be represented directly since CB/CR gets shared between Ys.
> > > 
> > > So, bitsperpixel would be 16 bit and both B and R offset will be 8.
> > 
> > Doesn't sound that bad to me, if you introduce a FB_VISUAL_YCBYCR
> > visual. Even pixels have a Cb, odd have a Cr component.
> 
> We need at least 3 fields to describe YUV.
> 
> 1. The component size - fb_bitfield.length
> 2. The sample period - fb_bitfield.offset
> 3. The component ordering - fb_bitfield.msb_right

This completely changes the meaning of the latter 2 fields...

> So if Y = red, U = green, V = blue
> 
> YUV422
> 
> red|green|blue.length = 8 /* 8 bits per component */
> red.offset = 1 /* sampled every pixel */
> green.offset = blue.offset = 2 /* sampled every 2 pixels */
> red.msb_right = 1, green.msb_right = 2, blue.msb_right = 3
> (Y U V order)
> 
> UVY411
> 
> red|green|blue.length = 8;
> red.offset = 1;
> green.offset = blue.offset = 4;
> red.msb_right = 3, green.msb_right = 2, blue.msb_right = 1;

And you would use bits_per_pixel = 8, as you no longer have access to the
fb_bitfield.offsets (in the sense of `offsets within a pixel')?

How would you express YUV420?

Alternatively:
  - YUV422 really is 16 bits per pixel.
  - YUV411 and YUV420 really are 12 bits per pixel.
But I don't think this makes things easier, especially not for the 12 bpp
variants.

> The FB_VISUAL_* will differentiate if the bitfields are interpreted as
> RGB or YUV.
> 
> That's the only way I can think of describing YUV packed pixel formats
> without adding new fields, or modifying our user-visible structures.
> 
> We will need separate drawing functions for fbcon's use.

Of course.

> Of course, the simplest way is to use fourcc naming for our FB_VISUAL_*
> constants. But that will become too unwieldy over time.

With kind regards,
 
Geert Uytterhoeven
Software Architect

Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
 
Phone:    +32 (0)2 700 8453	
Fax:      +32 (0)2 700 8622	
E-mail:   Geert.Uytterhoeven@sonycom.com	
Internet: http://www.sony-europe.com/
 	
Sony Network and Software Technology Center Europe	
A division of Sony Service Centre (Europe) N.V.	
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium	
VAT BE 0413.825.160 · RPR Brussels	
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619

[-- Attachment #2: Type: text/plain, Size: 314 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 182 bytes --]

_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: YUV Framebuffer

[Antonino A. Daplas]

On Thu, 2007-10-18 at 15:41 +0200, Geert Uytterhoeven wrote:
> On Thu, 18 Oct 2007, Antonino A. Daplas wrote:
> > On Wed, 2007-10-17 at 21:45 +0200, Geert Uytterhoeven wrote:
> > > On Wed, 17 Oct 2007, Rhee, C. Joon wrote:
> > > > Interleaved means YCBCR is on the same plane in this order.
> > > > Y CB Y CR Y CB Y CR.... (TV-Out)
> > > 
> > > So it's still FB_TYPE_PACKED_PIXELS.
> > > 
> > > > The problem of matching Y=G, CB=B and CR=R for RGB offset is that the
> > > > pixel cannot be represented directly since CB/CR gets shared between Ys.
> > > > 
> > > > So, bitsperpixel would be 16 bit and both B and R offset will be 8.
> > > 
> > > Doesn't sound that bad to me, if you introduce a FB_VISUAL_YCBYCR
> > > visual. Even pixels have a Cb, odd have a Cr component.
> > 
> > We need at least 3 fields to describe YUV.
> > 
> > 1. The component size - fb_bitfield.length
> > 2. The sample period - fb_bitfield.offset
> > 3. The component ordering - fb_bitfield.msb_right
> 
> This completely changes the meaning of the latter 2 fields...
> 

Yes, the intent was to reuse the already present fields to express YUV
formats.

> > So if Y = red, U = green, V = blue
> > 
> > YUV422
> > 
> > red|green|blue.length = 8 /* 8 bits per component */
> > red.offset = 1 /* sampled every pixel */
> > green.offset = blue.offset = 2 /* sampled every 2 pixels */
> > red.msb_right = 1, green.msb_right = 2, blue.msb_right = 3
> > (Y U V order)
> > 
> > UVY411
> > 
> > red|green|blue.length = 8;
> > red.offset = 1;
> > green.offset = blue.offset = 4;
> > red.msb_right = 3, green.msb_right = 2, blue.msb_right = 1;
> 
> And you would use bits_per_pixel = 8, as you no longer have access to the
> fb_bitfield.offsets (in the sense of `offsets within a pixel')?

We can define the bits_per_pixel as the effective pixel size. For 422,
that would be 16. For 411, that would be 12.

> 
> How would you express YUV420?

We can't. We need another set of fields in the vertical axis.

> 
> Alternatively:
>   - YUV422 really is 16 bits per pixel.
>   - YUV411 and YUV420 really are 12 bits per pixel.
> But I don't think this makes things easier, especially not for the 12 bpp
> variants.
> 
> > The FB_VISUAL_* will differentiate if the bitfields are interpreted as
> > RGB or YUV.
> > 
> > That's the only way I can think of describing YUV packed pixel formats
> > without adding new fields, or modifying our user-visible structures.
> > 
> > We will need separate drawing functions for fbcon's use.
> 
> Of course.

Basically, since most YUV formats are fundamentally different from RGB
(where all components are sampled per pixel), our best bet is to revive
the framebuffer overlay support that was proposed several years ago.

Or, if we do not want this in the kernel, we can always tell them to use
the DirectFB library instead.

What do you think? Should we extend the fb system to support YUV
formats?

Tony



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: YUV Framebuffer

[Geert Uytterhoeven]

On Fri, 19 Oct 2007, Antonino A. Daplas wrote:
> On Thu, 2007-10-18 at 15:41 +0200, Geert Uytterhoeven wrote:
> > On Thu, 18 Oct 2007, Antonino A. Daplas wrote:
> > > On Wed, 2007-10-17 at 21:45 +0200, Geert Uytterhoeven wrote:
> > > > On Wed, 17 Oct 2007, Rhee, C. Joon wrote:
> > > > > Interleaved means YCBCR is on the same plane in this order.
> > > > > Y CB Y CR Y CB Y CR.... (TV-Out)
> > > > 
> > > > So it's still FB_TYPE_PACKED_PIXELS.
> > > > 
> > > > > The problem of matching Y=G, CB=B and CR=R for RGB offset is that the
> > > > > pixel cannot be represented directly since CB/CR gets shared between Ys.
> > > > > 
> > > > > So, bitsperpixel would be 16 bit and both B and R offset will be 8.
> > > > 
> > > > Doesn't sound that bad to me, if you introduce a FB_VISUAL_YCBYCR
> > > > visual. Even pixels have a Cb, odd have a Cr component.
> > > 
> > > We need at least 3 fields to describe YUV.
> > > 
> > > 1. The component size - fb_bitfield.length
> > > 2. The sample period - fb_bitfield.offset
> > > 3. The component ordering - fb_bitfield.msb_right
> > 
> > This completely changes the meaning of the latter 2 fields...
> 
> Yes, the intent was to reuse the already present fields to express YUV
> formats.

IC.

> > > So if Y = red, U = green, V = blue
> > > 
> > > YUV422
> > > 
> > > red|green|blue.length = 8 /* 8 bits per component */
> > > red.offset = 1 /* sampled every pixel */
> > > green.offset = blue.offset = 2 /* sampled every 2 pixels */
> > > red.msb_right = 1, green.msb_right = 2, blue.msb_right = 3
> > > (Y U V order)
> > > 
> > > UVY411
> > > 
> > > red|green|blue.length = 8;
> > > red.offset = 1;
> > > green.offset = blue.offset = 4;
> > > red.msb_right = 3, green.msb_right = 2, blue.msb_right = 1;
> > 
> > And you would use bits_per_pixel = 8, as you no longer have access to the
> > fb_bitfield.offsets (in the sense of `offsets within a pixel')?
> 
> We can define the bits_per_pixel as the effective pixel size. For 422,
> that would be 16. For 411, that would be 12.
> 
> > How would you express YUV420?
> 
> We can't. We need another set of fields in the vertical axis.
> 
> > Alternatively:
> >   - YUV422 really is 16 bits per pixel.
> >   - YUV411 and YUV420 really are 12 bits per pixel.
> > But I don't think this makes things easier, especially not for the 12 bpp
> > variants.
> > 
> > > The FB_VISUAL_* will differentiate if the bitfields are interpreted as
> > > RGB or YUV.
> > > 
> > > That's the only way I can think of describing YUV packed pixel formats
> > > without adding new fields, or modifying our user-visible structures.
> > > 
> > > We will need separate drawing functions for fbcon's use.
> > 
> > Of course.
> 
> Basically, since most YUV formats are fundamentally different from RGB
> (where all components are sampled per pixel), our best bet is to revive
> the framebuffer overlay support that was proposed several years ago.

What with frame buffers where there's no overlay, i.e. the YUV buffer is
the single frame buffer?

> Or, if we do not want this in the kernel, we can always tell them to use
> the DirectFB library instead.
> 
> What do you think? Should we extend the fb system to support YUV
> formats?

It's definitely needed for single YUV frame buffers.

What about:
  - fb_fix_screeninfo.visual = FB_VISUAL_YUV
  - fb_var_screeninfo.nonstd = FB_NONSTD_YUV
  - use an additional struct fb_yuv_screeninfo for the other parameters?
    or maybe better, put them in fb_var_screeninfo.reserved[]?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/