All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.