[mpeg2-dev] Re: [Mjpeg-developer] jpeg2yuv 4:4:4 and greyscale support

[Gernot Z. <gz...@ly...>]

YUV colorspace discussions, see below ;)

>
>  >Hej Matto !
>  ...
>  >> jpegtopnm | ppmtoy4m  ?
>  >> (And, if you've got 4:4:4 JPEG's, there is no extra super/subsampling loss
>  >>  involved.)
>  >Ok, that didn't exist at the time when I created jpeg2yuv ... :-]
>  >And this one handles the colorspace correctly for standard JPEGs ?
>
> Yep.  (Well, it is supposed to.  You know, bugs happen.)
>
>
>  >OK, so the bottomline is that YUV4MPEG expects a range of 16-235 ?
>
> Yep.  Well, it expects a range of 1-255, where 16 is black and 235 is white.
>
>  >Or that YUV4MPEGs range of 0-255 equals to a "normal" range of 16-235 ?
>  >In the second case: What happens with the pixels "outside" that range ?
>  >Clamp them ?
>
> Yep (when going in the other direction).
>
> See
>   "http://www.mir.com/DMG/ycbcr.html"
> and
>   "mjpeg_play/lavtools/colorspace.h"
>
> -matt m.
>
>

I found the following in the MPEG2 FAQ's link I just posted recently:
Q:What is the sample precision of MPEG ? How many colors can MPEG
represent ?

A: By
definition, MPEG samples have no more and no less than 8-bits uniform
sample precision (256 quantization levels). For luminance (which is
unsigned) data, black corresponds to level 0, white is level 255. However,
in CCIR recommendation 601 chromaticy, luminance (Y) levels 0 through 14
and 236 through 255 are reserved for blanking signal excursions. MPEG
currently has no such clipped excursion restrictions, although decoder
might take care to insure active samples do not exceed these limits. With
three color components per pixel, the total combination is roughly 16.8
million colors (i.e. 24-bits).

So your YUV conversion is following the proposal; now the questions are:
.) Are the pixel values Y:0-16 and others above threshold still encoded in
the MPEG stream, Andrew ?

.) When decoding, do common decoders (libmpeg2 ?) expect 16-240 or 0-255
for the Y values ?

Or is it so that 0-255 is allowed, but 0-16, 240-255 would be cut away in
the final RGB results by clamping (and that can be avoided by this
restricted range) ?


Servus,
  Gernot