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
next prev parent 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