public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Kaiser <v4l@kaiser-linux.li>
To: kilgota@banach.math.auburn.edu
Cc: Kyle Guinn <elyk03@gmail.com>,
	Jean-Francois Moine <moinejf@free.fr>,
	Hans de Goede <hdegoede@redhat.com>,
	linux-media@vger.kernel.org
Subject: Re: RFC on proposed patches to mr97310a.c for gspca and v4l
Date: Thu, 05 Mar 2009 21:29:08 +0100	[thread overview]
Message-ID: <49B03614.5020701@kaiser-linux.li> (raw)
In-Reply-To: <alpine.LNX.2.00.0903051337130.27979@banach.math.auburn.edu>

kilgota@banach.math.auburn.edu wrote:
>>> That of course is a guess. OTOH it could be on a scale of 0 to 0x80, 
>>> or it could be that only the digits 0 through 9 are actually used, 
>>> and the basis is then 100, or too many other variations to count. 
>>> Also what is considered a "normal" or an "average" value? The trouble 
>>> with your suggestion of a scale from 0 to 0xff is that it makes 
>>> sense, and in a situation like this one obviously can not assume that.
>>
>> I don't really understand what you try to tell with this sentence:
>> "and in a situation like this one obviously can not assume that."
> 
> I mean, your interpretation of 0 to 0xff is a natural and sensible 
> interpretation (for us). But what one can not assume is, it made sense 
> to those who constructed the system. Perhaps those guys were setting it 
> all up differently.

You are right, we don't know what the developer were thinking, 
unfortunately,

You have to turn yourself in a webcam developer and think how you would 
do it. When you find, by observing/testing the cam, that it looks 
similar as you thought about how to do it, the observation should be true!

> 
>>
>> The values changed from 0x03 (dark) to 0xfc (bright), for me does this 
>> mean that the scale goes from 0x00 to 0xff!? Or I am wrong?
> 
> Well, if you have actual data to back up your impressions about this, 
> then clearly you have evidence. So that is good, obviously.

I will do this again in the next couple of weeks (lens removed).

> 
>>
>>>
>>> What I am suspecting is that these things have some kind of standard 
>>> definitions, which are not necessarily done by logic but by 
>>> convention, and there is a document out there somewhere which lays it 
>>> all down. The document could have been produced by Microsoft, for 
>>> example, which doubtless has its own problems reducing chaos to order 
>>> in the industry, or by some kind of consortium of camera 
>>> manufacturers, or something like that. I really do strongly suspect 
>>> that the interpretation of all of this is written down somewhere. But 
>>> I don't know where to look.
>>
>> I believe that this documents are exists, but not available for 
>> public:-( Just company confidential.
> 
> That may be true. If so, then such documentation is indeed not 
> available. But sometimes a document is published and available, and one 
> just is not aware of the fact.
> 
>>
>> Anyway most of the Linux webcam drivers were done by re-engineering 
>> the Windoz driver (usbsnoop). That said, all information about the 
>> cams is "a guess".
> 
> Very true. Also true about the still cameras that I supported in 
> libgphoto2. There are no secrets kept on the USB bus. But what is done 
> inside the computer does not appear on the USB bus and there is no log 
> of it.
> 
>>
>> For the brightness thing, I just was working with a light and studied 
>> what is changing in the header of the frame. At this time I did this, 
>> I was not aware that I could remove the lens of the webcam to be more 
>> sensible to light change and get more precise results.
>>
>> During the work I did for the PAC7311 Pixart chip I found out that 
>> removing the lens and put light directly to the sensor does help a lot 
>> to figure out how the cam is working.
>>
>> And with this idea in mind, we could even get further to guess the 
>> compression algo from a cam.
>>
>> Assuming that the sensor has a Bayer pattern.
>> - remove lens.
>> - put white light on the sensor
>> - use color filter an put each spectrum (RGB) on the sensor
>> - check the stream and find out what is changing in the stream 
>> according to the different light conditions.
>>
>> Looks like I get off topic, now ;-)
> 
> But it is very interesting nevertheless.

I think so, I didn't try with the color filter :-(

> 
>>
>> Something else comes in my mind. Would it good to document all this 
>> what we are talking bout somewhere on a webpage?
>>
>> Thomas
> 
> Perhaps so. Also a good idea to try to collect some people who have 
> similar interests and are trying to work on similar problems. I have 
> been trying to do that for a while, but with mixed and limited success.

May be, some people read this and have the same felling. Let's see what 
happens.

Thomas

  reply	other threads:[~2009-03-05 20:29 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-17 19:09 MR97310A and other image formats Jean-Francois Moine
2009-02-17 19:35 ` Thomas Kaiser
2009-02-18  9:25   ` Jean-Francois Moine
2009-02-18 12:58     ` Thomas Kaiser
2009-02-18 19:17       ` Jean-Francois Moine
2009-02-17 19:43 ` Thomas Kaiser
2009-02-18  1:07 ` Kyle Guinn
2009-02-19  0:40   ` kilgota
2009-03-04  0:12   ` RFC on proposed patches to mr97310a.c for gspca and v4l kilgota
2009-03-04  2:50     ` Kyle Guinn
2009-03-04  5:21       ` kilgota
2009-03-04  8:41         ` Thomas Kaiser
2009-03-04  8:54           ` Thomas Kaiser
2009-03-04 19:01             ` kilgota
2009-03-05 13:02               ` Thomas Kaiser
2009-03-05 18:29                 ` kilgota
2009-03-05 19:19                   ` Thomas Kaiser
2009-03-05 19:45                     ` kilgota
2009-03-05 20:29                       ` Thomas Kaiser [this message]
2009-03-05 20:55                         ` kilgota
2009-03-05 20:51                           ` Thomas Kaiser
2009-04-15 23:59                 ` Some questions about mr97310 controls (continuing previous thread on mr97310a.c) Theodore Kilgore
2009-04-16 16:10                   ` Thomas Kaiser
2009-04-16 22:50                     ` Theodore Kilgore
2009-04-17  8:36                       ` Hans de Goede
2009-05-02  1:47                   ` Progress with the MR97310A "CIF" cameras Theodore Kilgore
2009-04-16  5:14           ` RFC on proposed patches to mr97310a.c for gspca and v4l Kyle Guinn
2009-04-16 18:22             ` Theodore Kilgore
2009-04-17  4:33               ` Kyle Guinn
2009-04-17 17:50                 ` Theodore Kilgore
2009-04-18  0:04                   ` Kyle Guinn
2009-04-18  0:43                     ` Theodore Kilgore
2009-04-21  1:18                     ` RFC on proposed patches to mr97310a.c for gspca and v4l (headers) Theodore Kilgore
2009-04-21  2:44                       ` Theodore Kilgore
2009-05-15 22:31             ` Preliminary results with an SN9C2028 camera Theodore Kilgore
2009-05-19  7:56               ` Hans de Goede
2009-05-19 18:18                 ` Theodore Kilgore
2009-03-04  8:39       ` RFC on proposed patches to mr97310a.c for gspca and v4l Hans de Goede
2009-03-04 18:46         ` kilgota
2009-03-05  1:33         ` Kyle Guinn
2009-03-05  7:01           ` Hans de Goede
2009-03-04  8:35     ` Hans de Goede
2009-03-05  2:49     ` Kyle Guinn
2009-03-05  4:34       ` kilgota
2009-03-05  5:54         ` Kyle Guinn
2009-03-05  6:47           ` kilgota
2009-03-05  7:00           ` Hans de Goede
2009-03-05 19:08             ` kilgota
2009-03-05 19:07               ` Hans de Goede
2009-03-05 20:42                 ` kilgota
2009-03-05 20:40                   ` Hans de Goede
2009-03-05 20:58                     ` kilgota
2009-03-06  1:21                       ` Kyle Guinn
2009-03-06  1:57                         ` kilgota
2009-03-28 22:42                         ` [PATCH] to add new camera in gspca/mr97310a.c Theodore Kilgore
2009-02-19 18:17 ` MR97310A and other image formats kilgota
2009-02-19 19:17   ` Thomas Kaiser
2009-02-19 21:54     ` kilgota
2009-02-19 22:45       ` Thomas Kaiser
2009-02-19 23:50         ` kilgota
2009-02-20  0:52           ` Thomas Kaiser
2009-02-20  1:32             ` kilgota
2009-02-20  8:00               ` Thomas Kaiser
2009-02-20 18:45                 ` kilgota
2009-02-20 19:05                   ` Thomas Kaiser
2009-02-20 20:26                     ` kilgota

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=49B03614.5020701@kaiser-linux.li \
    --to=v4l@kaiser-linux.li \
    --cc=elyk03@gmail.com \
    --cc=hdegoede@redhat.com \
    --cc=kilgota@banach.math.auburn.edu \
    --cc=linux-media@vger.kernel.org \
    --cc=moinejf@free.fr \
    /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