non-even sizes possible in yuv/i420?

[toby]

Hi,

I have an extremely basic question about YUV format as consumed and
produced by the vp8 codec.

Is the format of u,v planes well defined if the Y plane is an odd
number of pixels in either dimension? Or is that simply forbidden? I
haven't looked for an answer in the source, and YUV/I420 seem to be
without a formal definition that answers this (?). But I am sure this
is something someone on the team can quickly clarify.

(I'm working on WebP related stuff, not video.)

[John Koleszar]

It's not well defined, but libvpx has a convention. when encoding, you
need to provide (n+1)/2 chroma samples for n luma samples in each
direction.. ie for 13x13 each chroma plane would be 7x7.

[nandan amar]

and this convention is followed almost every where considering the fact that normal  human eyes are more sensitive to luma (y) component as compared to  chroma(u &v).

--
You received this message because you are subscribed to the Google Groups "WebM Discussion" group.
To post to this group, send email to webm-d...@webmproject.org.
To unsubscribe from this group, send email to webm-discuss...@webmproject.org.
For more options, visit this group at http://groups.google.com/a/webmproject.org/group/webm-discuss/?hl=en.

--
Amar Kumar Nandan

http://aknandan.co.nr

[toby]

On Nov 14, 8:35 am, nandan amar <nandan.a...@gmail.com> wrote:
> and this convention is followed almost every where considering the fact that
> normal  human eyes are more sensitive to luma (y) component as compared to
> chroma(u &v).

Nandan

I'm familiar with this rationale for YUV. I was asking about the u,v
consequence for Y planes with odd sizes, which John has sufficiently
clarified for me.

>
> On 14 November 2010 18:31, John Koleszar <jkoles...@google.com> wrote:

>
>
>
>
>
> > On Sun, Nov 14, 2010 at 3:22 AM, toby <t...@telegraphics.com.au> wrote:
> > > Hi,
>
> > > I have an extremely basic question about YUV format as consumed and
> > > produced by the vp8 codec.
>
> > > Is the format of u,v planes well defined if the Y plane is an odd
> > > number of pixels in either dimension? Or is that simply forbidden? I
> > > haven't looked for an answer in the source, and YUV/I420 seem to be
> > > without a formal definition that answers this (?). But I am sure this
> > > is something someone on the team can quickly clarify.
>
> > > (I'm working on WebP related stuff, not video.)
>
> > It's not well defined, but libvpx has a convention. when encoding, you
> > need to provide (n+1)/2 chroma samples for n luma samples in each
> > direction.. ie for 13x13 each chroma plane would be 7x7.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "WebM Discussion" group.

> > To post to this group, send email to webm-disc...@webmproject.org.

> > To unsubscribe from this group, send email to

> > webm-discuss+unsubscr...@webmproject.org<webm-discuss%2Bunsubscr...@webmproject.org>
> > .

[toby]

On Nov 14, 8:01 am, John Koleszar <jkoles...@google.com> wrote:

Exactly what I needed to know, thanks John.

[toby]

On Nov 14, 8:01 am, John Koleszar <jkoles...@google.com> wrote:

> On Sun, Nov 14, 2010 at 3:22 AM, toby <t...@telegraphics.com.au> wrote:
> > ...

> > Is the format of u,v planes well defined if the Y plane is an odd

> > number of pixels in either dimension? ...

>
> It's not well defined, but libvpx has a convention. when encoding, you
> need to provide (n+1)/2 chroma samples for n luma samples in each
> direction.. ie for 13x13 each chroma plane would be 7x7.

Hi John

I've done some experimentation and this isn't the behaviour I am
seeing. I'm providing an odd-sized Y plane (g_w and g_h are the odd
numbered Y sample counts), and u,v sized per your round-up rule, but
the encoding is corrupt.

On decode I am seeing a sheared Y and garbled u,v apparently
indicating an off by one error somewhere. I have not dived into its
code, but is it possible that libvpx doesn't actually support odd
sizes?

[John Koleszar]

You need to obey the strides in the image descriptor. The decode Y
stride will be 64+((d_w+15)&~15) if you try to use the width directly
you'll get the shearing effect you describe, regardless of whether the
width is odd or not. The stride is the number of pixels to add to get
from one row to the next, if you're not familiar with the term. Make
sure you can decode a multiple of 16x16 image properly first, or feed
your encode into vpxdec by writing it to a raw file[1] to take the
decoder out of the equation. If the decoder seems good and your image
is still corrupt, then you need to check all the parameters of the
image descriptor you're passing to the encoder.

[1]: raw file: for each frame, write a 4 byte little endian int with
the size of the compressed data, followed by the compressed data.

[toby]

On Nov 17, 6:42 am, John Koleszar <jkoles...@google.com> wrote:

> On Tue, Nov 16, 2010 at 9:23 PM, toby <t...@telegraphics.com.au> wrote:
>
> > On Nov 14, 8:01 am, John Koleszar <jkoles...@google.com> wrote:
> >> On Sun, Nov 14, 2010 at 3:22 AM, toby <t...@telegraphics.com.au> wrote:
> >> > ...
> >> > Is the format of u,v planes well defined if the Y plane is an odd
> >> > number of pixels in either dimension? ...
>
> >> It's not well defined, but libvpx has a convention. when encoding, you
> >> need to provide (n+1)/2 chroma samples for n luma samples in each
> >> direction.. ie for 13x13 each chroma plane would be 7x7.
>
> > Hi John
>
> > I've done some experimentation and this isn't the behaviour I am
> > seeing. I'm providing an odd-sized Y plane (g_w and g_h are the odd
> > numbered Y sample counts), and u,v sized per your round-up rule, but
> > the encoding is corrupt.
>
> > On decode I am seeing a sheared Y and garbled u,v apparently
> > indicating an off by one error somewhere. I have not dived into its
> > code, but is it possible that libvpx doesn't actually support odd
> > sizes?
>
> You need to obey the strides in the image descriptor. The decode Y
> stride will be 64+((d_w+15)&~15) if you try to use the width directly
> you'll get the shearing effect you describe, regardless of whether the
> width is odd or not. The stride is the number of pixels to add to get
> from one row to the next, if you're not familiar with the term. Make
> sure you can decode a multiple of 16x16 image properly first,

Yes, even-sized images are working perfectly. For this plugin I began
by simply masking dimensions down to even, then began to wonder if
libvpx was able to support odd-sized, and so started this thread to
explore that.

> or feed
> your encode into vpxdec by writing it to a raw file[1] to take the
> decoder out of the equation. If the decoder seems good and your image
> is still corrupt, then you need to check all the parameters of the
> image descriptor you're passing to the encoder.

Right, it's not a problem in the decoding step; I am already obeying
all strides and dwebp produces the same result as my own decoder.

I'll review the image descriptor, thanks.

[toby]

On Nov 17, 6:42 am, John Koleszar <jkoles...@google.com> wrote:
> ... If the decoder seems good and your image

> is still corrupt, then you need to check all the parameters of the
> image descriptor you're passing to the encoder.

Hi John

It turns out, reading vpx_image.c, that the implicit Y row stride must
be even, when chroma is decimated. By respecting that, I can get a
correct encoding.

Since the library user has to be aware of this rule, in constructing
the image buffer passed to vpx_image_wrap(), can I suggest that it be
mentioned in external library documentation?

Thanks for your helpful pointers.
--Toby

[vikas mk]

It's not well defined, but libvpx has a convention. when encoding, you
need to provide (n+1)/2 chroma samples for n luma samples in each
direction.. ie for 13x13 each chroma plane would be 7x7.

Hi , 

Can somebody point out where exactly this gets enforced in the libvpx ? 

I need to run 201x201 resolutions on the encoder and i'm getting some strange results.