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).
Maybe the problem you're talking about can be fixed by selecting another
coefficients from the table?
