[gphoto-devel] Re: { SPAM 1 }::Re: [sane-devel] Getting Clever CAM 360 IS NOW WORKING PARTIALLY - running gphoto2 version 2.1.6

[kilgota at banach.math.auburn.edu]

On Fri, 16 Sep 2005, Martin wrote:

> I got this camera communicating with gphoto2 but the pictures are very under 
> exposed.
> When I had my work laptop running Windoze XP, there were proper exposure and 
> clear to view and print.
> So I'm not sure why the pictures are low brightness - and also appears to be 
> no color in them either?
> Regards,
> -Martin
>

Martin,

As you say that there are problems with the color and brightness, I have 
an obvious question:

Since we just got this camera working today, how do you know that the 
colors are being processed right, instead of being switched around?

Answer:

You don't, and none of us know, either, because we have not yet seen any 
output of photos. Remember, where we are right now is that an educated 
guess was made that driver X might support previously-unknown camera Y, 
and lo and behold after some source-code cut-and-paste and some 
configuration difficulties and library path upgrades and battery 
replacement, the camera worked, in the sense that it actually emitted data 
and the data could be processed into something recognizable.

One thing which could be going wrong here is the color mapping, at which, 
clearly, we were purely guessing. What happens with most cameras (and 
it seems to apply here in particular) is that the colors are 
arranged in an order like one of the following, in which each capital 
letter :

RGRGRG ... all the way across row 0 (until column = width-1 is reached)
GBGBGB ... all the way across row 1

the two-line pattern repeats until the bottom of the photo is reached, at 
row = height -1.

This pattern is called RGGB (look at the first two pixels in the two 
lines). It is obvious that this fundamental scheme can be done in some 
other different ways, for example

GBGBGB ...
RGRGRG ...

which is called GBRG

or

BGBGBG ...
GRGRGR ...

which is called BGGR

and one more permissible variant, which I leave to you to see.

Now, this all goes back to the actual sensing hardware. You have a lens in 
front of the camera, and right behind it is a video sensor chip. On the 
video sensor chip there are literally width times height number of little 
microsensors, in a rectangular array on it. Each physical pixel location 
(equal to one tiny microsensor) on the sensor chip behind the lens can 
measure only the intensity of the light. The intensity reading gets turned 
into a color reading by having a tiny color filter on top of it. Then in 
order to get a photo image, the software must provide at each pixel a 
triple reading (R,G,B) of which only one is a real reading, and the other 
two are some kind of average of nearest neigbors where the color really 
was sampled. The arrangement of the color sensors in the rectangular array 
on the sensor chip is called a "Bayer array" and to compute the missing 
color values at each pixel is called variously "de-Bayering" or 
"demosaicing" or "demosaicking" and there exist several methods, ranging 
from the obvious to the secret, proprietary, and patented for computing 
the missing values.

With this explanation, I think you can judge for yourself what will happen 
if for example you treat a photo which was supposed to be GRBG under the 
false assumption that it is RGGB or some other pattern. So this could be 
the problem. Here, remember that nobody knows yet which setting is 
right for your camera, neither any of us, nor you. And nobody is to blame 
for that. You, you may recall, had to make a guess at that in order to get 
the camera to spit out anything at all.

I think that the quickest way to find out whether this could be the 
problem which is causing bad-looking images would be to experiment, and 
the best person to do that is yourself, since you have the camera and you 
have the source code:

Your config entry says

> Edited the source file pdc640.c in the directory,
libgphoto2-2.1.6/camlibs/polaroid/
> and added the lines,
>
> {"Clever CAM 360", 0x797, 0x8001, {
> jd350e,
> BAYER_TILE_BGGR,
> &jd350e_postprocessing_and_flip,
> "scope%04i.ppm"
> }
> },

so my advice would be to change

BAYER_TILE_BGGR,

to be something else. Try all the possibilities. One of them might offer a 
dramatic improvement. The entire list of possibilities is to be seen in 
the first few lines of libgphoto2-2.1.6/libgphoto2/bayer.h.

Now, if you do this, remember that you do _not_ need to re-make and 
re-install the entire libgphoto2 package. It will suffice if you go into 
libgphoto2-2.1.6/camlibs/polaroid, change the one line of source code, and 
then do make followed by make install, without leaving the directory. Then 
download some photos. Make a directory for yourself called camera/test or 
something like that, and create subdirectories RGGB, BRRG, ... and 
download the same photos into each after making the appropriate change and 
re-installation of camlibs/polaroid. Then look at the photos side by side.

Though I obviously cannot guarantee results, I do hope and I strongly 
suspect that one of the listed possibilities will give you a dramatic 
improvement.

Theodore Kilgore