Tuukka Toivonen (tuukkat@xxxxxxxxxx):
> On Tue, 5 Aug 2003, Billy Biggs wrote:
>
> >> No, the function is right, I was just reading it wrong.
> > I was referring to the extents. If you're using this MPEG2 conversion
> >function to convert JPEG data to RGB, then you're likely using the
> >wrong conversion function (your colours will be slightly wrong).
>
> Ah, I see. You mean that if camera delivers pixel values between 0 and 255
> and if the YUV->RGB conversion routine assumes the range is less, it will
> have wrong colors.
>
> Well, I wouldn't worry about this. The colors *are* wrong, and very much,
> and this happens because the camera color filter is so bad. Nevertheless,
> the color conversion routine supports different color spaces:
>
> static const u32 matrix_coefficients = 6;
>
> static const s32 Inverse_Table_6_9[8][4] = {
> { 117504, 138453, 13954, 34903 }, /* 0: no sequence_display_extension */
> { 117504, 138453, 13954, 34903 }, /* 1: ITU-R Rec. 709 (1990) */
> { 104597, 132201, 25675, 53279 }, /* 2: unspecified */
> { 104597, 132201, 25675, 53279 }, /* 3: reserved */
> { 104448, 132798, 24759, 53109 }, /* 4: FCC */
> { 104597, 132201, 25675, 53279 }, /* 5: ITU-R Rec. 624-4 System B, G */
> { 104597, 132201, 25675, 53279 }, /* 6: SMPTE 170M */
> { 117579, 136230, 16907, 35559 } /* 7: SMPTE 240M (1987) */
> };
>
> I haven't changed this from the original (which was probably chosen by
> Jochen Hoenicke).
Those are all from mpeg2dec. They're not different extents, they're
different RGB chromaticity values from the MPEG2 spec. They will not
help with with the range problem.
> Maybe the problem you're talking about can be fixed by selecting another
> coefficients from the table?
I don't think so.
-Billy
