Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1444801 > unrolled thread
| Started by | Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> |
|---|---|
| First post | 2016-07-16 12:50 +0200 |
| Last post | 2016-07-18 11:10 +0200 |
| Articles | 3 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
[PATCH v3 8/9] [media] vivid: Fix YUV555 and YUV565 handling Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> - 2016-07-16 12:50 +0200
Re: [PATCH v3 8/9] [media] vivid: Fix YUV555 and YUV565 handling Hans Verkuil <hverkuil@xs4all.nl> - 2016-07-18 11:00 +0200
Re: [PATCH v3 8/9] [media] vivid: Fix YUV555 and YUV565 handling Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> - 2016-07-18 11:10 +0200
| From | Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> |
|---|---|
| Date | 2016-07-16 12:50 +0200 |
| Subject | [PATCH v3 8/9] [media] vivid: Fix YUV555 and YUV565 handling |
| Message-ID | <rVvkt-2JU-3@gated-at.bofh.it> |
precalculate_color() had a optimization that avoided duplicated
conversion for YUV formats. This optimization did not take into
consideration YUV444, YUV555, YUV565 or limited range quantization.
This patch keeps the optimization, but fixes the wrong handling.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
---
drivers/media/common/v4l2-tpg/v4l2-tpg-core.c | 19 ++++++++-----------
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
index e91bf3cbaab9..1c862465e335 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
@@ -797,6 +797,8 @@ static void precalculate_color(struct tpg_data *tpg, int k)
int r = tpg_colors[col].r;
int g = tpg_colors[col].g;
int b = tpg_colors[col].b;
+ int y, cb, cr;
+ bool ycbbr_valid = false;
if (k == TPG_COLOR_TEXTBG) {
col = tpg_get_textbg_color(tpg);
@@ -873,7 +875,6 @@ static void precalculate_color(struct tpg_data *tpg, int k)
tpg->saturation != 128 || tpg->hue) &&
tpg->color_enc != TGP_COLOR_ENC_LUMA) {
/* Implement these operations */
- int y, cb, cr;
int tmp_cb, tmp_cr;
/* First convert to YCbCr */
@@ -890,13 +891,10 @@ static void precalculate_color(struct tpg_data *tpg, int k)
cb = (128 << 4) + (tmp_cb * tpg->contrast * tpg->saturation) / (128 * 128);
cr = (128 << 4) + (tmp_cr * tpg->contrast * tpg->saturation) / (128 * 128);
- if (tpg->color_enc == TGP_COLOR_ENC_YUV) {
- tpg->colors[k][0] = clamp(y >> 4, 1, 254);
- tpg->colors[k][1] = clamp(cb >> 4, 1, 254);
- tpg->colors[k][2] = clamp(cr >> 4, 1, 254);
- return;
- }
- ycbcr_to_color(tpg, y, cb, cr, &r, &g, &b);
+ if (tpg->color_enc == TGP_COLOR_ENC_YUV)
+ ycbbr_valid = true;
+ else
+ ycbcr_to_color(tpg, y, cb, cr, &r, &g, &b);
} else if ((tpg->brightness != 128 || tpg->contrast != 128) &&
tpg->color_enc == TGP_COLOR_ENC_LUMA) {
r = (16 << 4) + ((r - (16 << 4)) * tpg->contrast) / 128;
@@ -917,9 +915,8 @@ static void precalculate_color(struct tpg_data *tpg, int k)
case TGP_COLOR_ENC_YUV:
{
/* Convert to YCbCr */
- int y, cb, cr;
-
- color_to_ycbcr(tpg, r, g, b, &y, &cb, &cr);
+ if (!ycbbr_valid)
+ color_to_ycbcr(tpg, r, g, b, &y, &cb, &cr);
if (tpg->real_quantization == V4L2_QUANTIZATION_LIM_RANGE) {
y = clamp(y, 16 << 4, 235 << 4);
--
2.8.1
[toc] | [next] | [standalone]
| From | Hans Verkuil <hverkuil@xs4all.nl> |
|---|---|
| Date | 2016-07-18 11:00 +0200 |
| Message-ID | <rWcz8-3YY-15@gated-at.bofh.it> |
| In reply to | #1444801 |
On 07/16/2016 12:41 PM, Ricardo Ribalda Delgado wrote:
> precalculate_color() had a optimization that avoided duplicated
> conversion for YUV formats. This optimization did not take into
> consideration YUV444, YUV555, YUV565 or limited range quantization.
>
> This patch keeps the optimization, but fixes the wrong handling.
>
> Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
> ---
> drivers/media/common/v4l2-tpg/v4l2-tpg-core.c | 19 ++++++++-----------
> 1 file changed, 8 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> index e91bf3cbaab9..1c862465e335 100644
> --- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> +++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> @@ -797,6 +797,8 @@ static void precalculate_color(struct tpg_data *tpg, int k)
> int r = tpg_colors[col].r;
> int g = tpg_colors[col].g;
> int b = tpg_colors[col].b;
> + int y, cb, cr;
> + bool ycbbr_valid = false;
I guess you mean ycbcr_valid?
Regards,
Hans
>
> if (k == TPG_COLOR_TEXTBG) {
> col = tpg_get_textbg_color(tpg);
> @@ -873,7 +875,6 @@ static void precalculate_color(struct tpg_data *tpg, int k)
> tpg->saturation != 128 || tpg->hue) &&
> tpg->color_enc != TGP_COLOR_ENC_LUMA) {
> /* Implement these operations */
> - int y, cb, cr;
> int tmp_cb, tmp_cr;
>
> /* First convert to YCbCr */
> @@ -890,13 +891,10 @@ static void precalculate_color(struct tpg_data *tpg, int k)
>
> cb = (128 << 4) + (tmp_cb * tpg->contrast * tpg->saturation) / (128 * 128);
> cr = (128 << 4) + (tmp_cr * tpg->contrast * tpg->saturation) / (128 * 128);
> - if (tpg->color_enc == TGP_COLOR_ENC_YUV) {
> - tpg->colors[k][0] = clamp(y >> 4, 1, 254);
> - tpg->colors[k][1] = clamp(cb >> 4, 1, 254);
> - tpg->colors[k][2] = clamp(cr >> 4, 1, 254);
> - return;
> - }
> - ycbcr_to_color(tpg, y, cb, cr, &r, &g, &b);
> + if (tpg->color_enc == TGP_COLOR_ENC_YUV)
> + ycbbr_valid = true;
> + else
> + ycbcr_to_color(tpg, y, cb, cr, &r, &g, &b);
> } else if ((tpg->brightness != 128 || tpg->contrast != 128) &&
> tpg->color_enc == TGP_COLOR_ENC_LUMA) {
> r = (16 << 4) + ((r - (16 << 4)) * tpg->contrast) / 128;
> @@ -917,9 +915,8 @@ static void precalculate_color(struct tpg_data *tpg, int k)
> case TGP_COLOR_ENC_YUV:
> {
> /* Convert to YCbCr */
> - int y, cb, cr;
> -
> - color_to_ycbcr(tpg, r, g, b, &y, &cb, &cr);
> + if (!ycbbr_valid)
> + color_to_ycbcr(tpg, r, g, b, &y, &cb, &cr);
>
> if (tpg->real_quantization == V4L2_QUANTIZATION_LIM_RANGE) {
> y = clamp(y, 16 << 4, 235 << 4);
>
[toc] | [prev] | [next] | [standalone]
| From | Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> |
|---|---|
| Date | 2016-07-18 11:10 +0200 |
| Message-ID | <rWcIN-4ho-5@gated-at.bofh.it> |
| In reply to | #1445315 |
Hi Hans On Mon, Jul 18, 2016 at 10:51 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote: >> + int y, cb, cr; >> + bool ycbbr_valid = false; > > I guess you mean ycbcr_valid? Yes, I think the medical term is Saturday dyslexia :) It is fixed on the next version. Thanks!
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web