public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Andy Walls <awalls@radix.net>
Cc: Devin Heitmueller <dheitmueller@kernellabs.com>,
	Hans Verkuil <hverkuil@xs4all.nl>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: How do private controls actually work?
Date: Wed, 03 Mar 2010 00:25:28 -0300	[thread overview]
Message-ID: <4B8DD6A8.6050201@redhat.com> (raw)
In-Reply-To: <1267581446.3070.76.camel@palomino.walls.org>

Andy Walls wrote:
> On Tue, 2010-03-02 at 18:23 -0300, Mauro Carvalho Chehab wrote:
>> Devin Heitmueller wrote:
>>> On Tue, Mar 2, 2010 at 3:28 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>> I had some extended discussion with Mauro on this yesterday on
>>> #linuxtv, and he is now in favor of introducing a standard user
>>                       ===
>>> control for chroma gain, as opposed to doing a private control at all.
>> To be clear: I was never against ;)
>>
>> It is worthy to summarize the discussions we have and the rationale to
>> create another control for it.
>>
>> I've checked the datasheets of some chipsets, and the chroma gain is
>> different than the saturation control: the gain control (chroma or luma)
>> are applied at the analog input (or analog input samples) before the color
>> decoding, while the saturation is applied to the U/V output levels (some
>> datasheets call it as U/V output gain
> 
> Yes, that is correct.
> 
> 
>>  - causing some mess on the interpretation
>> of this value).
> 
> AFAICT, the effect of chroma gain is not really different from a
> saturation control that scales both the U & V components by the same
> factor.
> 
>                _
> A color vector A can be expressed as
> 	_    _   _
> 	A = YW + C
>        _
> Where YW is a white vector that has a luminance component of magnitude
> Y.
> _
> C is the chrominace vector in a constant luuminance plane.  Its phase is
> the hue, and its magnitude is the saturation.
>                            _
> Adjusting the magnitude of C in the analog domain will change the
> saturation.
>           _                                                      _
> Adjusting C's U & V components will adjust only the magnitude of C, if U
> & V are adjusted by the same scale factor.  (You can tweak both the hue
> and saturation by adjusting U & V by different scale factors.)

Makes sense. Yet, provided that the A/D converters have a very limited range
(in general, 8 to 10 bits), and assuming that some designs may adjust the gain 
before A/D conversion, or they do some sort of quantization before adjusting
saturation, by adjusting the analog level, the quantization noise will be reduced.
> 
>> The API spec patch should clearly state that Saturation is for the U/V output
>> level, while gain is for the analog input gain.
> 
> That makes sense.
> 
> Since we're thinking about what to name controls, I will note the
> CX25843, doesn't quite fit the current discussion of an analog "chroma
> gain" independent from "luma gain":
> 
> 1. the CX25843 has at least 3 front end gains well before U/V
> separation:
>    a +12 dB analog boost
>    a analog coarse gain (controlled by an AGC),
>    a digital fine gain (also has an AGC).
> 
> The +12 dB analog boost can be applied separately for Y, C, Pb and/or
> Pr, but the other analog and digital gains cannot.  They will be applied
> to all video signal inputs the same.

CX88 seems similar to cx25843: it has the +12 dB boost and some levels to adjust
the AGC range.

The +12dB boost could be mapped as an analog gain control with just two values on its range:
0 and 12dB.

That's said, I don't think we should map all available controls to the userspace API's.
The only ones that should be exported are the ones that there are some use cases that
justifies its mapping.

> 
> 2. the CX25843 U and V saturation scale factors can be set
> independently, if desired.
> 
> 
> Regards,
> Andy
> 


-- 

Cheers,
Mauro

  reply	other threads:[~2010-03-03  3:25 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-01  2:56 How do private controls actually work? Devin Heitmueller
2010-03-01  8:57 ` Laurent Pinchart
2010-03-01  9:07   ` Devin Heitmueller
2010-03-01  9:58     ` Hans Verkuil
2010-03-01 10:20       ` Devin Heitmueller
2010-03-01 11:18         ` Hans Verkuil
2010-03-01 22:29         ` Mauro Carvalho Chehab
2010-03-02 20:28         ` Hans Verkuil
2010-03-02 20:42           ` Devin Heitmueller
2010-03-02 20:56             ` Hans Verkuil
2010-03-02 21:23             ` Mauro Carvalho Chehab
2010-03-03  1:57               ` Andy Walls
2010-03-03  3:25                 ` Mauro Carvalho Chehab [this message]
2010-03-01 11:47       ` Andy Walls

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=4B8DD6A8.6050201@redhat.com \
    --to=mchehab@redhat.com \
    --cc=awalls@radix.net \
    --cc=dheitmueller@kernellabs.com \
    --cc=hverkuil@xs4all.nl \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    /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