[cpia] The Sensor defined Resolution Mode
Tobias Gogolin
tobias@ing.ens.uabc.mx
Mon, 17 Jul 2000 12:18:22 -0700
640 x 480
> > The informed may know it is the real mode the highest supported by
hardware
> > ...
>
> I am informed and I can tell you that the CPiA hardware we have
> written the drivers for cannot go 640x480.
Yes sure and that is why Logitech doesnt want to give out the specs of theyr
new Interface Mode
Point is
Is the sensor used to its fullest potential ?
If it is a 300 k pixel sensor its not
But every image ever captured with a cpia camera still contains the higher
resolution data :
Let me Quote some of the comunication I previously led with Jan
:============================================================
Looking about what cameras are available out there I think
I got a usefull step in understanding more about how these cameras really
work ...
One Manufacturer (Ezcam USB webcam )
http://www.ezonics.com/dual.html
was advertizing 320 000 pixels cmos sensor
and resolutions of
640 x 480 = 307200 That mapes pixel to pixel
However color is needed
353 x 288 = 101376
I asume there is a filter mask either RGB or CMY
So in this mode 3 proximate sensors with individual colors are combined
to give one real color aproximation of the light that hits the 3 sensors
required
---------------------------
I believe the actual sensor is pretty much identical with the Logitech!
Logitech is not relaesing its specs because they are more or less the same
as others
However they figured out - what I am trying to share with you now:
> >640 x 480 = 307200 That mapes pixel to pixel
...
> >In the highest resolution mode the filter is still in place
...
> >Therefore in this mode the camera must try to extract the luminance from
> >each pixel
Lets Asume
Pr = red filtered pixel
Pg = green
Pb = blue
Pr(Pg, Pb) is really also going active with white and grays to black
therefore each pixel contains luminance information as well
after the capture data is available in a raster with
352 x 288 x 3 x 8 Bit color values
We will need some insight of the allignment of the filter masks
(you may want to put one under the Microscope :)
If you take a lens and look at a delta screen mask of a color Tv every Red
is surounded with 3 Pairs of GB
same for Green and Blue
Because I am concerned sensor makers may have found limitations in
chiplayout to rectangular patterns
its probably more likely chances are the filter is simply aligned
RGBRGBRGBRGRB
RGBRGBRGBRGRB
RGBRGBRGBRGRB
But that would be pretty ineficient especially for what I am saying could be
done (or is done by logitech
Maybe
RGBRGBRGBRGRB
BRGBRGBRGBRGRB
GBRGBRGBRGRB
RG
B
GB
R
BR
G
every block of 3 pixels is complete in itself
if we could find out about the physical layout in rows and columns of the
sensor
or maybe there is even a spec about the filtered sensor
-------------------------
Per software it is possible (the logitech implementation proves (not without
little failures)) to remap the aquired 352 x 288 data onto a 640 x 480 map
Its serious math to do it well :
one would best distribute the color info on an area around the location of
each filterd sensor (in the expanded file) - then one would go and see how
much deviation from the low pass color area one has in an individual sensor
cell and create a luminace vector out of the local deviation (cosidering
filter color and low pass area color)(and initialy put that in a seperate
map) when done combine the maps and have a full color 640 x 480 output ?
Some examples:
http://ultra.ens.uabc.mx/lvp/visdat/ciaA0473.jpg
see the / slanted line on the left where high definition light and color
changes get misrepresented into colorful ladders
- clear evidence that they are using the technology I am describing
http://ultra.ens.uabc.mx/lvp/visdat/d109102851430.jpg
see how great it works to get the real detail out of low colorchange images
look at the masoned stonewall lines. Again a high contrast /(slant) causes
the seperationfaults
http://vidar.ens.uabc.mx/lvp/visdat/d001902721500.jpg
in comparison the low format analizis causes grainy
and unaliased looking effects sometimes
ladders apear not to have the color seperation fault
However take the time and load the image with a zoomtool
and look at the balcony and the luminance jagies those actually
contain data that when properly layed out becomes valuable detail
==========================================================
Anyhow I am glad to hear that I am talking to the developers themselve :)
> I am informed and I can tell you that the CPiA hardware we have
> written the drivers for
I am looking forward to work with you on implementing the higher Resolution
Mode !
If you consider It enough of a challenge that is ...
cheers
Tobias
----- Original Message -----
From: Peter Pregler <Peter_Pregler@email.com>
To: Tobias Gogolin <tgogolin@web.de>; <cpia@risc.uni-linz.ac.at>
Sent: Monday, July 17, 2000 01:45
Subject: Re: [cpia] The Sensor defined Resolution Mode
> On Mon, Jul 17, 2000 at 10:35:01AM +0200, Peter Pregler wrote:
> >
> > /* Is it a CPiA? */
> > if (!((udev->descriptor.idVendor == 0x0553 &&
> > udev->descriptor.idProduct == 0x0002) ||
> > (udev->descriptor.idVendor == 0x0813 &&
> > udev->descriptor.idProduct == 0x0001))) /* GA 04/14/00 */
> > return NULL;
> >
> > The first one is a normal CPiA such as the Creative Webcam II, the
> > second one is the Barbycam. In any case the highest resolution the
> > chip can do is CIF.
>
> Ahem, the second one is the Intel Play QX3 Microscope. Silly me.
>
> -Peter
>
> --
> I will not waste chalk. --Bart Simpson at the blackboard
> --------------------------------------------------------
> Email: Peter_Pregler@email.com
> WWW: http://www.risc.uni-linz.ac.at/people/ppregler
> ICQ: 61011460
>
> _______________________________________________
> cpia mailing list - cpia@risc.uni-linz.ac.at
> http://mailman.risc.uni-linz.ac.at/mailman/cgi-bin/listinfo/cpia