lkml.org 
[lkml]   [2019]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v4 1/4] gpu: ipu-v3: ipu-ic: Rename yuv2rgb encoding matrices
Date


On 2/13/19 2:35 AM, Philipp Zabel wrote:
> On Tue, 2019-02-12 at 09:42 -0800, Steve Longerbeam wrote:
> [...]
>>>> But what about this "SAT_MODE" field in the IC task parameter memory?
>>> That just controls the saturation. The result after the matrix
>>> multiplication is either saturated to [0..255] or to [16..235]/[16..240]
>>> when converting from the internal representation to the 8 bit output.
>> By saturation I think you mean clipped to those ranges?
> Yes, thanks. I didn't realize it sounds weird to use saturated this way.
> See:https://en.wikipedia.org/wiki/Saturation_arithmetic

Ok, saturation can mean the same thing as clipping/clamping. Thanks for
the article.

I tested a RGB->YUV pipeline with the .sat bit set in the BT.601 rgb2yuv
table, with the following pipeline on the SabreSD:

'ov5640 1-003c':0
        [fmt:RGB565_2X8_LE/1024x768@1/30 field:none colorspace:srgb
xfer:srgb ycbcr:601 quantization:full-range]

'imx6-mipi-csi2':0
        [fmt:RGB565_2X8_LE/1024x768 field:none colorspace:srgb
xfer:srgb ycbcr:601 quantization:full-range]

'imx6-mipi-csi2':2
        [fmt:RGB565_2X8_LE/1024x768 field:none colorspace:srgb
xfer:srgb ycbcr:601 quantization:full-range]

'ipu1_csi1':0
        [fmt:RGB565_2X8_LE/1024x768@1/30 field:none colorspace:srgb
xfer:srgb ycbcr:601 quantization:full-range
         crop.bounds:(0,0)/1024x768
         crop:(0,0)/1024x768
         compose.bounds:(0,0)/1024x768
         compose:(0,0)/1024x768]

'ipu1_csi1':1
        [fmt:ARGB8888_1X32/1024x768@1/30 field:none colorspace:srgb
xfer:srgb ycbcr:601 quantization:full-range]

'ipu1_ic_prp':0
        [fmt:ARGB8888_1X32/1024x768@1/30 field:none colorspace:srgb
xfer:srgb ycbcr:601 quantization:full-range]

'ipu1_ic_prp':1
        [fmt:ARGB8888_1X32/1024x768@1/30 field:none colorspace:srgb
xfer:srgb ycbcr:601 quantization:full-range]

'ipu1_ic_prpenc':0
        [fmt:ARGB8888_1X32/1024x768@1/30 field:none colorspace:srgb
xfer:srgb ycbcr:601 quantization:full-range]

'ipu1_ic_prpenc':1
        [fmt:AYUV8_1X32/800x600@1/30 field:none colorspace:srgb
xfer:srgb ycbcr:601 quantization:lim-range]

/dev/video0:0
Format Video Capture:
    Width/Height      : 800/600
    Pixel Format      : 'YV12'
    Field             : None
    Bytes per Line    : 800
    Size Image        : 720000
    Colorspace        : sRGB
    Transfer Function : sRGB
    YCbCr/HSV Encoding: ITU-R 601
    Quantization      : Limited Range
    Flags             :


The result being that the captured image colors are all off (there's a
bright pink shade to the images). But I discovered the init_csc()
function was not setting the saturation bit at the correct bit offset
within the TPMEM. The saturation bit is bit 42, or bit 10 of the second
32-bit word. But the code was writing to bit 9 of the second word. After
correcting this, saturation is working fine. I have added another patch
that fixes this for v5 series.


>
>>> SAT_MODE should be set for conversions to YUV limited range so that the
>>> coefficients can be rounded to the closest value.
>> Well, we have already rounded the coefficients to the nearest int in the
>> tables. Do you mean the final result (coeff * color component + offset)
>> is rounded?
> The manual says so: "The final calculation result is limited according
> to the SAT_MODE parameter and rounded to 8 bits", but that's not what I
> meant. Still, I might have been mistaken.
>
> I think due to the fact that the coefficients are multiplied by up to
> 255 (max pixel value) and then effectively divided by 256 when
> converting to 8 bit, the only way to overflow limited range is if two
> coefficients are rounded away from zero in the calculation of a single
> component. This doesn't seem to happen in practice.
>
> A constructed example, conversion to YUV limited range with carefully
> chosen coefficients.
>
> Y = R * .1817 + G * .6153 + B * .0618 + 16;
>
> Note that .1817 + .6153 + .0618 < 219/255.
> With rounded coefficients though:
>
> Y = (R * 47 + G * 158 + B * 16 + (64 << 6)) / 256 = 236.136

Yes, for a rec.709 conversion and max/worst-case RGB signal = (255,255,255).

But the rec.709 coefficients for Y are actually

Y = (R * 47 + G * 157 + B * 16 + (16 << 8)) / 256


which for RGB = (255,255,255), Y = 235.14, which doesn't overflow
limited range.

Steve

\
 
 \ /
  Last update: 2019-02-14 19:54    [W:0.073 / U:1.428 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site