linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hans Verkuil <hverkuil@xs4all.nl>
To: Tim Harvey <tharvey@gateworks.com>
Cc: linux-media <linux-media@vger.kernel.org>,
	alsa-devel@alsa-project.org,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Shawn Guo <shawnguo@kernel.org>,
	Steve Longerbeam <slongerbeam@gmail.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Hans Verkuil <hansverk@cisco.com>,
	Mauro Carvalho Chehab <mchehab@s-opensource.com>
Subject: Re: [PATCH v2 3/4] media: i2c: Add TDA1997x HDMI receiver driver
Date: Sat, 4 Nov 2017 10:53:31 +0100	[thread overview]
Message-ID: <fbb14b36-73cd-e81f-11f4-26cd488d567d@xs4all.nl> (raw)
In-Reply-To: <CAJ+vNU1ipKzm5AX4HY0ckrBM3aMC1mn0Dp7nQfsjzJcEYgBV5Q@mail.gmail.com>

On 11/04/2017 01:17 AM, Tim Harvey wrote:
> On Mon, Oct 23, 2017 at 10:05 AM, Tim Harvey <tharvey@gateworks.com> wrote:
>>
>> On Fri, Oct 20, 2017 at 9:23 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>
>>>>
>>>> I see the AVI infoframe has hdmi_quantization_range and
>>>> hdmi_ycc_quantization_range along with vid_code.
>>>>
>>>> I'm not at all clear what to do with this information. Is there
>>>> anything you see in the datasheet [1] that points to something I need
>>>> to be doing?
>>>
>>> You can ignore hdmi_ycc_quantization_range, it is the hdmi_quantization_range
>>> that you need to read out.
>>>
>>> The TDA can receive the following formats:
>>>
>>> RGB Full Range
>>> RGB Limited Range
>>> YUV Bt.601 (aka SMPTE 170M)
>>> YUV Rec.709
>>>
>>> The YUV formats are always limited range.
>>>
>>> The TDA can transmit RGB and YUV to the SoC. You want RGB to be full range and
>>> YUV to be limited range. YUV can be either 601 or 709.
>>>
>>> So if the TDA transmits RGB then you need to support the following conversions:
>>>
>>> RGB Full -> RGB Full
>>> RGB Limited -> RGB Full
>>> YUV 601 -> RGB Full
>>> YUV 709 -> RGB Full
>>>
>>> And if the TDA transmits YUV then you need these conversions:
>>>
>>> RGB Full -> YUV601 or YUV709
>>> RGB Limited -> YUV601 or YUV709
>>> YUV601 -> YUV601
>>> YUV709 -> YUV709
>>>
>>> For the RGB to YUV conversion you have a choice of converting to YUV601 or 709.
>>> I recommend to either always convert to YUV601 or to let it depend on the resolution
>>> (SDTV YUV601, HDTV YUV709).
>>>
>>
>> Ok - this is a good explanation that I should be able to follow. I
>> will make sure to take into account hdmi_quantization_range when I
>> setup the colorspace conversion matrix for v3.
> 
> Hans,
> 
> I'm having trouble figuring out the conversion matrix to use between
> limited and full.
> 
> Currently I have the following conversion matrices, the values which
> came from some old vendor code:
> 
>         /* Colorspace conversion matrix coefficients and offsets */
>         struct color_matrix_coefs {
>                 /* Input offsets */
>                 s16 offint1;
>                 s16 offint2;
>                 s16 offint3;
>                 /* Coeficients */
>                 s16 p11coef;
>                 s16 p12coef;
>                 s16 p13coef;
>                 s16 p21coef;
>                 s16 p22coef;
>                 s16 p23coef;
>                 s16 p31coef;
>                 s16 p32coef;
>                 s16 p33coef;
>                 /* Output offsets */
>                 s16 offout1;
>                 s16 offout2;
>                 s16 offout3;
>         };
>         /* Conversion matrixes */
>         enum {
>                 ITU709_RGBLIMITED,
>                 ITU601_RGBLIMITED,
>                 RGBLIMITED_ITU601,
>        };
>        static const struct color_matrix_coefs conv_matrix[] = {
>                 /* ITU709 -> RGBLimited */
>                 {
>                         -256, -2048,  -2048,
>                         4096, -1875,   -750,
>                         4096,  6307,      0,
>                         4096,     0,   7431,
>                          256,   256,    256,
>                 },
>                 /* YUV601 limited -> RGB limited */
>                 {
>                         -256, -2048,  -2048,
>                         4096, -2860,  -1378,
>                         4096,  5615,      0,
>                         4096,     0,   7097,
>                         256,    256,    256,
>                 },
>                 /* RGB limited -> ITU601 */
>                 {
>                         -256,  -256,   -256,
>                         2404,  1225,    467,
>                         -1754, 2095,   -341,
>                         -1388, -707,   2095,
>                         256,   2048,   2048,
>                 },
>         };
> 
> Assuming the above are correct this leaves me missing RGB limitted ->
> RGB full, YUV601 -> RGB full, YUV709 -> RGB full, and RGB Full ->
> YUV601.
> 
> I don't have documentation for the registers but I'm assuming the
> input offset is applied first, then the multiplication by the coef,
> then the output offset is applied. I'm looking over
> https://en.wikipedia.org/wiki/YUV for colorspace conversion matrices
> but I'm unable to figure out how to apply those to the above. Any
> ideas?

For the YUV to RGB full conversions all you need to do is to change
the last row to 0, 0, 0 (since you no longer apply an offset) and
multiply all matrix coefficients by (255 / 219) to ensure the matrix
result is in the range [0-255] instead of [0-219].

For the RGB lim to RGB full conversion you need this matrix:

-256, -256, -256,
S, 0, 0,
0, S, 0,
0, 0, S,
0, 0, 0

Where S = 4096 * 255 / 219. I'm assuming 4096 equals 1.0 using fixed
point format.

Actually, looking at the order of the matrix values I suspect it might
be:

-256, -256, -256,
0, S, 0,
0, 0, S,
S, 0, 0,
0, 0, 0

You'll have to test this to verify which of the two is the right one.

For RGB Full to YUV you use the RGB lim to YUV values but replace the
first line by 0, 0, 0 and multiply the 3x3 matrix values with (219 / 255).

That should do it.

Regards,

	Hans

  reply	other threads:[~2017-11-04  9:53 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-12  4:45 [PATCH v2 0/4] TDA1997x HDMI video receiver Tim Harvey
2017-10-12  4:45 ` [PATCH v2 1/4] MAINTAINERS: add entry for NXP TDA1997x driver Tim Harvey
2017-10-12  4:45 ` [PATCH v2 2/4] media: dt-bindings: Add bindings for TDA1997X Tim Harvey
2017-10-23 22:22   ` Rob Herring
2017-10-12  4:45 ` [PATCH v2 3/4] media: i2c: Add TDA1997x HDMI receiver driver Tim Harvey
2017-10-18 12:04   ` Hans Verkuil
2017-10-19  6:59     ` Hans Verkuil
2017-10-19  7:20     ` Tim Harvey
2017-10-19  7:39       ` Hans Verkuil
2017-10-20 14:00         ` Tim Harvey
2017-10-20 16:23           ` Hans Verkuil
2017-10-23 17:05             ` Tim Harvey
2017-11-04  0:17               ` Tim Harvey
2017-11-04  9:53                 ` Hans Verkuil [this message]
2017-11-07  6:04           ` Tim Harvey
2017-11-07  7:47             ` Hans Verkuil
2017-11-07 22:12               ` Tim Harvey
2017-10-12  4:45 ` [PATCH v2 4/4] ARM: dts: imx: Add TDA19971 HDMI Receiver to GW54xx Tim Harvey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fbb14b36-73cd-e81f-11f4-26cd488d567d@xs4all.nl \
    --to=hverkuil@xs4all.nl \
    --cc=alsa-devel@alsa-project.org \
    --cc=devicetree@vger.kernel.org \
    --cc=hansverk@cisco.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@s-opensource.com \
    --cc=p.zabel@pengutronix.de \
    --cc=shawnguo@kernel.org \
    --cc=slongerbeam@gmail.com \
    --cc=tharvey@gateworks.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).