[sane-devel] "gamma" and "bayer" ? What are they?

[Theodore Kilgore]

Henning,

Perhaps you would be one to know this, or it is fine if someone else
answers the question, too. I want this information because I am trying to
write a driver for a camera, as a summer project (specifically for the
lots of cameras which call themselves USB vendor:product 0x2770:0x9120 and
belong to Class ff, Subclass ff, Protocol ff.
These are some really cheap cameras (352x288 max resolution) so I took
it on as a summer project, to learn how they work and to write a driver.

My question is sufficiently on topic that I feel comfortable asking it
from the sane-devel mailing list. Perhaps the gphoto-devel list would be a
more appropriate place to ask, but I am sorry to say that the gphoto-devel
mailing list seems unable to add me as a subscriber in spite of my
attempts, over the past several weeks, to subscribe to it.

My question:

What are "gamma" and "bayer" and where can I find some literature to read
up on such topics?

I ask this because I am at this point able to get a picture out of the
camera by the very primitive procedure of editing a debug log file. I know
that both the Windows driver and the gphoto camlib program which I have
written give identical data output. But

a. the actual output is exactly one byte per pixel, and saving it as a
"raw" file leads nowhere except to error messages when one tries to open
them.

b. The log output for one picture is much larger (because of whitespace),
and putting a BMP or a PPM header on it actually turns the log output
(after suitable editing to remove everything but the actual data) into a
picture which roughly approximates the actual picture taken but is of
quite low quality.

So I suspect that some kind of interpolation routine is going on, in order
to fill up the whitespace. The point is, what kind of interpolation? What
different kinds are there? And how are they implemented?

One can obviously confront similar problems when dealing with scanner
output, and my questions relate to basic techniques in video imaging.
Therefore, on the grounds that I do subscribe to the sane-devel
list and am apparently unable to subscribe to the gphoto-devel list in
spite of strenuous efforts to do so, I ask about the problems here,
instead.

I hope, as I said already, that these questions are considered of general
interest. I would welcome any information, explanations, or references for
reading about the relevant topics. I don't seem to find very much about
this with Google, or perhaps I don't know exactly what to search for, so
even the right words for a search would help, I think.

Thank you very much,

Theodore Kilgore

[Henning Meier-Geinitz]

Hi,

Post by Theodore Kilgore
What are "gamma"

Very much simplified: A gamma table is used to transfer the color
space used by your input device (scanner, camera) to the color space
of your output device (display, printer). A gamma value (or factor)
can be used to create a gamma table.

Search for "gamma table" and "gamma factor" at google and you'll find
lots of documentation.

Post by Theodore Kilgore
and "bayer"

I think that's a kind of halftoning (transferring gray/color imagaes
to black/white).

Post by Theodore Kilgore
So I suspect that some kind of interpolation routine is going on, in order
to fill up the whitespace. The point is, what kind of interpolation? What
different kinds are there? And how are they implemented?

I don't really understand what you mean by "whitespace".

Interpolation is usually used to create resolutions higher than
supported by hardware. It's just a marketing gag, you don't get better
images, just bigger ones. Example:

You have a gray image with 2x2 pixels:

100 200
50 100

To expand it by 50% in both directions you'd interpolate like this:

100 150 200
75 112 150
50 75 100

Post by Theodore Kilgore
One can obviously confront similar problems when dealing with scanner
output, and my questions relate to basic techniques in video imaging.

The scanners return image data in lots of differnt formats. E.g. 8,
10, 12, 16 bits/color, all the pixels of one color after each other,
or all the colors of one pixel after each other and so on.

Maybe your data is also compressed? Or it's transferred as a jpeg?

bye,
Henning

[Laurent-jan]

Post by Henning Meier-Geinitz
Hi,

Post by Theodore Kilgore
What are "gamma"

Very much simplified: A gamma table is used to transfer the color
space used by your input device (scanner, camera) to the color space
of your output device (display, printer). A gamma value (or factor)
can be used to create a gamma table.
Search for "gamma table" and "gamma factor" at google and you'll find
lots of documentation.

There is a link in the SANE-FAQ to the colorspace FAQ. If you want to
know more about gamma, look at Carles Poynton's FAQs on color and gamma.

Post by Henning Meier-Geinitz

Post by Theodore Kilgore
and "bayer"

Bayer is a dithering algoritm; it uses fixed paterns. For an example of
the 4x4 patterns see:
http://tiger.technion.ac.il/~cgcourse/lectures/4-intensity/sld007.htm
<..>

[Peter Fales]

Post by Henning Meier-Geinitz
Maybe your data is also compressed? Or it's transferred as a jpeg?

For a toy camera like this, it's most likely the raw output of the CCD
device and needs a fair amount of processing of the raw pixel data. The
dc25 backend shows an example of this kind of processing. (It's not likely
that you'll be able to use that kind - just an example of that type of
processing.)

My guess is that the most effective technique would be to open up the camera
and try to identify the manufacturer of the CCD. Then see if you can get
anything from them. I think that's how the dc-25 algorithms were
originally developed (not by me!)

--
Pete Fales

[Theodore Kilgore]

Henning,

Well, it seems that my inquiry got some interest, for which I thank
everyone who responded. I will try to follow down some of the leads, after
writing the Calculus III test I have to give tomorrow. Meanwhile, a

Post by Henning Meier-Geinitz

Post by Theodore Kilgore
What are "gamma"

Matter of fact, I did do soem searching about "gamma" and I did come up
with an impression, at least: It seems to be a correction for
non-linearity of gain in the hardware (i.e. hardware does not respond in
linear fashion to a certain kind of stimulus, so we do something to fix
that).

Post by Henning Meier-Geinitz

Post by Theodore Kilgore
and "bayer"

(cut)

Post by Henning Meier-Geinitz
I don't really understand what you mean by "whitespace".

What I meant by "whitespace" is the blank spots between bytes in a file.
For example,

bc 3f

and what is between the c and the 3 I am calling "whitespace."

Post by Henning Meier-Geinitz
Interpolation is usually used to create resolutions higher than
supported by hardware. It's just a marketing gag, you don't get better
images, just bigger ones.

Maybe so, but:

The raw downloaded data for one 352x288 picture is exactly 352x128=101376
bytes. If you put this directly into a file, you get a file of exactly
101376 bytes. If you stick a ppm header on it you have a file with a ppm
header on it, and you get an error message if you try to view it.

However, if you take the log data output containing the same 101376
bytes, then you have the bytes represented in the form of text as two
characters each, with a space between each two successive bytes.

So when you remove all material from the log file except the actual
data downloaded for a picture you have 101376 bytes of data, which
now get saved as a file. The actual size of the file thus created is
3x101376 = 304128 bytes, which presumably happens because now each byte is
represented by two characters (requiring one byte each) plus one empty
space (the third byte).

Addition of a ppm header to the edited log output then creates a .ppm file
of size 304143 bytes, which is then a viewable picture. Just not a very
good one.

Addition of a bmp header instead of a ppm header produces ( after
adjustment by, for example, removing the last byte of empty space) a file
of size 304182 bytes, which is the size identical to the file size
produced by the Windows driver software. Again, it is a viewable picture,
which looks the same as the ppm file but with some colors switched seems
that ppm and bmp handle endian-ness differently; the colors come out
closer to right in the ppm version).

Whether the bmp file is viewed with the Windows software or with Linux
software is also immaterial. Also it does not matter whether the bytes
from the log file were downloaded with the stock driver or with my own
programming. I have checked this.
(Example was clear, thanks)

Post by Henning Meier-Geinitz
The scanners return image data in lots of differnt formats. E.g. 8,
10, 12, 16 bits/color, all the pixels of one color after each other,
or all the colors of one pixel after each other and so on.

If I am not mistaken, this is 8-bit color, since I recall somewhere seeing
that the camera gives 256 colors. Also this would fundamentally make sense
to me because the actual data gives exactly one pixel per byte. So I
guess a natural question might be, that how many "standard" ways are there
by which 8-bit color at one pixel can be represented by one byte?


And as to this particular instance, I suspect the order RGB is the one
being used, not GRB or GBR or such.

Post by Henning Meier-Geinitz
Maybe your data is also compressed?

Possibly, but the way it is compressed it is exactly 1/3 the size and it
is also possible to get a picture resembling the original out of the log
output, so my instincts would be against this. Of course, I have been
wrong on occasions.

Post by Henning Meier-Geinitz
Or it's transferred as a jpeg?

I really don't expect this. The camera is really an el cheapo. If I told
you how it downloads data you would probably not believe me. Thomas, my
13-year-old, says it is "brain dead." So I don't think it knows how to
pronounce "jpeg." Besides, exactly one byte per pixel ???


Thanks for the help.


Ted Kilgore

[abel deuring]

Post by Theodore Kilgore
Matter of fact, I did do soem searching about "gamma" and I did come up
with an impression, at least: It seems to be a correction for
non-linearity of gain in the hardware (i.e. hardware does not respond in
linear fashion to a certain kind of stimulus, so we do something to fix
that).

Right, that's probably the most common description. Often an arbitrary
table or function is used for gamma correction, sometimes a function
like out = pow(in, x) is called "gamme correction" and x is called the
"gamma value". Occasionally, one can find 1/x being called the gamma value.

Post by Theodore Kilgore
The raw downloaded data for one 352x288 picture is exactly 352x128=101376
bytes. If you put this directly into a file, you get a file of exactly
101376 bytes. If you stick a ppm header on it you have a file with a ppm
header on it, and you get an error message if you try to view it.

For a PPM file of 352x288 pxiels you'll need 352x288x3 bytes. (1 byte
for red, one for green, one for blue)

Post by Theodore Kilgore
If I am not mistaken, this is 8-bit color, since I recall somewhere seeing
that the camera gives 256 colors. Also this would fundamentally make sense
to me because the actual data gives exactly one pixel per byte. So I
guess a natural question might be, that how many "standard" ways are there
by which 8-bit color at one pixel can be represented by one byte?

As far as i know, most if not all CCD sensors have a color filter in
front of each sensor element, so that one element "sees" only red light,
and another one only green or blue light. A camera with better firmware
will build some interpolated values for the "missing colors" of a pixel,
or the data from three sensor elements may be merged into one pixle
value. I would that your camera simply delivers the raw data.

Post by Theodore Kilgore
And as to this particular instance, I suspect the order RGB is the one
being used, not GRB or GBR or such.

Peter already mentioned that the best way to get a clue about the color
representation within the scan data is to make photos of pure
red/green/blue areas. This should show data with repeate sequences of
two bytes with smaller values and one byte with a larger value, if my
guess is right. And if data for all colors is stored in one byte, you'll
also quickly get a clue, which bits represents which colors. But I wold
bet a few virtual beers that the camera delivers one color channel per byte.

Abel

[Theodore Kilgore]

Post by Peter Fales

Post by Henning Meier-Geinitz
Maybe your data is also compressed? Or it's transferred as a jpeg?

For a toy camera like this, it's most likely the raw output of the CCD
device and needs a fair amount of processing of the raw pixel data.

Actually, I suspect it is a CMOS chip. The camera really is cheap.

Post by Peter Fales
The
dc25 backend shows an example of this kind of processing. (It's not likely
that you'll be able to use that kind - just an example of that type of
processing.)
My guess is that the most effective technique would be to open up the camera
and try to identify the manufacturer of the CCD.

And how would I do that identification if there is nothing written on
said chip? Since I have already destroyed one of these things trying to
look inside, I would be glad to look in it again (can't kill it twice,
after all) if it would really help.

And anyway the USB vendor:product number is 0x2770:0x9120, which tells us
that the chip is from SQ Technologies ( website at www.sq.com.tw ) and
they do claim to make video capture chips. They make an SQ905 and an SQ913
in particular. I suspect the one in this camera is the SQ905 (there is no
912) They have publicly available "data sheets" which are nothing but
glossy sales brochures.

Then see if you can get

Post by Peter Fales
anything from them.

Good idea. They don't answer my e-mail.


I think that's how the dc-25 algorithms were

Post by Peter Fales
originally developed (not by me!)

Hmmm. I will have a look.

Thanks.

Ted Kilgore

[Peter Fales]

Post by Theodore Kilgore
And anyway the USB vendor:product number is 0x2770:0x9120, which tells us
that the chip is from SQ Technologies ( website at www.sq.com.tw ) and
they do claim to make video capture chips. They make an SQ905 and an SQ913
in particular. I suspect the one in this camera is the SQ905 (there is no
912) They have publicly available "data sheets" which are nothing but
glossy sales brochures.

The second page of the SQ905 data sheet implies that the sensor is actually
not part of the SQ905, but is separate component. Do you think that is
the case?

--
Pete Fales

[Peter Fales]

Try taking a picture of solid red, green, and blue images. (As close
to pure saturated colors as you can get). How does that affect the resulting
data?
--
Peter Fales Lucent Technologies, Room 1C-436
N9IYJ 2000 N Naperville Rd PO Box 3033
internet: ***@lucent.com Naperville, IL 60566-7033
work: [phone]

Post by Theodore Kilgore

Post by Peter Fales

Post by Henning Meier-Geinitz
Maybe your data is also compressed? Or it's transferred as a jpeg?

For a toy camera like this, it's most likely the raw output of the CCD
device and needs a fair amount of processing of the raw pixel data.

Actually, I suspect it is a CMOS chip. The camera really is cheap.

Post by Peter Fales
The
dc25 backend shows an example of this kind of processing. (It's not likely
that you'll be able to use that kind - just an example of that type of
processing.)
My guess is that the most effective technique would be to open up the camera
and try to identify the manufacturer of the CCD.

And how would I do that identification if there is nothing written on
said chip? Since I have already destroyed one of these things trying to
look inside, I would be glad to look in it again (can't kill it twice,
after all) if it would really help.
And anyway the USB vendor:product number is 0x2770:0x9120, which tells us
that the chip is from SQ Technologies ( website at www.sq.com.tw ) and
they do claim to make video capture chips. They make an SQ905 and an SQ913
in particular. I suspect the one in this camera is the SQ905 (there is no
912) They have publicly available "data sheets" which are nothing but
glossy sales brochures.
Then see if you can get

Post by Peter Fales
anything from them.

Good idea. They don't answer my e-mail.
I think that's how the dc-25 algorithms were

Post by Peter Fales
originally developed (not by me!)

Hmmm. I will have a look.
Thanks.
Ted Kilgore
_______________________________________________
Sane-devel mailing list
http://www.mostang.com/mailman/listinfo/sane-devel

[Thomas VIAL]

Hi,

Post by Theodore Kilgore
What I meant by "whitespace" is the blank spots
between bytes in a file.
For example,
bc 3f
and what is between the c and the 3 I am calling
"whitespace."

Er, "bc" and "3f" are just two distinct bytes in
hexadecimal, 188 and 63 respectively. It seems you are
interpreting the hex dump as raw data...
One byte is 2 hex digit, and the whitespace is here
for readability.

Once correctly interpreted as a sequence of hex bytes,
my guess is that the log data is strictly equivalent
to the raw data, since the final number of bytes is
the same.

With a correct bmp header the raw data should be ok
(maybe upside down).
But with 1 byte per pixel the image should be
interpreted as greyscale I think -- unless it uses a
palette?


Thomas

=====
------------------------------
Si vos aist Diex !

http://www.el-profesor.net/
------------------------------

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

[Theodore Kilgore]

Post by Thomas VIAL
Hi,

Post by Theodore Kilgore
What I meant by "whitespace" is the blank spots
between bytes in a file.
For example,
bc 3f
and what is between the c and the 3 I am calling
"whitespace."

Er, "bc" and "3f" are just two distinct bytes in
hexadecimal, 188 and 63 respectively.

Yes. I know that.

Post by Thomas VIAL
It seems you are
interpreting the hex dump as raw data...
One byte is 2 hex digit, and the whitespace is here
for readability.

Again, yes. My point was that a string of bytes equal in number to the
number of pixels in the picture will give precisely no good result, but
that on the other hand putting the text fomat of same data, obtained by
suitable editing of the log file, will give a picture provided one only
puts a ppm header on the top. In other words, if you read (for example) bc
as one byte, and not as three bytes (one for b, one for c, and one for the
space after it, and so on through the rest of the file) you do get a file
but it is not a picture, but if you do it the second way (stupid as that
may look) you do get a picture.

Post by Thomas VIAL
Once correctly interpreted as a sequence of hex bytes,
my guess is that the log data is strictly equivalent
to the raw data, since the final number of bytes is
the same.

No it isn't. The "final number of bytes" in the text file is equal to the
number of bytes dumped, times exactly three. And it is the text file with
appropriate header which gives a picture.

Post by Thomas VIAL
With a correct bmp header the raw data should be ok
(maybe upside down).

Well, actually, it is more complicated. The ppm format only turns the
picture upside down, but leaves the colors approximately correct. The bmp
format gives you the picture right-side up, mirror-imaged left to right,
and seems to reverse red and blue or red and green.

Post by Thomas VIAL
But with 1 byte per pixel the image should be
interpreted as greyscale I think

This is not what happens. I judge by the results.

Post by Thomas VIAL
-- unless it uses a
palette?

Well, I did not introduce any palette. So if it is using one it is
built-in in ImageMagick, GIMP, and in the Windows software, all three. I
just dumped the log data into a file, stuck a header on it, and viewed it.
Looking at things positively, I did get the data out of the camera by hook
or by crook, and nobody told me how to do it.

This is fun, isn't it? After all, I am only doing this because the problem
is there to solve, and the camera seemed simple enough for a beginner in
device support like me, that I could fool with it and learn something.
after all, unlike a scanner it has no moving parts.

Ted Kilgore

[david stevenson]

Post by Theodore Kilgore

Hi,

Again, yes. My point was that a string of bytes equal in number to the
number of pixels in the picture will give precisely no good result, but
that on the other hand putting the text fomat of same data, obtained by
suitable editing of the log file, will give a picture provided one only
puts a ppm header on the top. In other words, if you read (for example) bc
as one byte, and not as three bytes (one for b, one for c, and one for the
space after it, and so on through the rest of the file) you do get a file
but it is not a picture, but if you do it the second way (stupid as that
may look) you do get a picture.

An interesting way to process data, but if it works.......
In converting a byte to hex it is effectivly split into 2 nibbles of 4bits and
a fixed value of 0x30 added to each. (or 0x37 if the nibble value is more
than 9)
So using the ascii file as data should be twice the size (having ignored the
spaces). The question then is what headers have you added to make the bitmap.
Most headers include information on bits per pixel, pixels per line ...

David

[der Mouse]

Post by Theodore Kilgore

It seems you are interpreting the hex dump as raw data...
One byte is 2 hex digit, and the whitespace is here for readability.

Again, yes. My point was that a string of bytes equal in number to
the number of pixels in the picture will give precisely no good
result, but that on the other hand putting the text fomat of same
data, obtained by suitable editing of the log file, will give a
picture provided one only puts a ppm header on the top.

Your previous description made no sense to me. While reading this, I
had a brainflash, and I think I know what's going on.

When you have one byte per pixel, you _do_ have a picture, it's just
that it's a colourmapped picture, and you don't have the colourmap to
go with it, so it makes no sense. Prepend a pgm (not ppm) header and
it will be displayable, but it will make little sense - it may or may
not be possible to see the original image in it; this amounts to using
a gray-ramp colourmap instead of the colourmap the image should have.

When you expand it to three bytes per pixel and prepend a ppm header,
ppm takes those three bytes as the red, green, and blue bytes for that
pixel, so you get one ppm pixel per picture pixel and you get
something. This amounts to imposing a different colourmap, one that
looks like

index red green blue
0 48 48 32 ("00 ")
1 48 49 32 ("01 ")
...
185 98 57 32 ("b9 ")
...
255 102 102 32 ("ff ")

which is why the picture looks as though its colours have been
scrambled: they have been!

Some of pixels may effectively use colourmap entries with 10 instead of
32 for the blue value, if you use newlines instead of spaces for some
of the inter-byte spacing.

Post by Theodore Kilgore

But with 1 byte per pixel the image should be interpreted as
greyscale I think

This is not what happens. I judge by the results.

If you prepend a ppm header, no, it will perforce be taken as colour.
But if you use a pgm header, it will be taken as grayscale and you
should get something semi-sensible. (I don't know enough about bmp to
comment on the results you get with bmp headers.)

There unfortunately is no format in the pbm/pgm/ppm series that handles
colourmapped images, as far as I know. To get sensible pictures in p*m
format, you'll need to figure out what the colourmap the camera is
assuming the image will be used with is. You may be able to do this by
taking pictures of washes of each primary, from black to full
brightness, and watching how the byte values change....

/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

[Theodore Kilgore]

Henning,

Thank you very much for the space on the sane-devel mailing list for a
discussion about gamma correction and bayer interpolation/decoding.

To everyone who has responded about the topic, I also want to say thanks,
because I have gotten several useful suggestions out of it. At this point
I need at least a weekend, probably more, to absorb all of the suggestions
and to try them out in various ways, whether by incorporating them in
code, or by running more experiments with the camera, taking pictures of
"pure" red, green, blue, black, white, and so on.

So, again, thanks. I may respond to some of you privately, too, but give
me time. And probably Henning thinks that enough room and bandwidth have
been already taken up. I do hope the discussion has benefitted those
trying to deal with scanners as well as with cameras; otherwise I can only
admire the altruism of the list maintainers!

Theodore Kilgore

[Henning Meier-Geinitz]

Hi,

Post by Theodore Kilgore
So, again, thanks. I may respond to some of you privately, too, but give
me time. And probably Henning thinks that enough room and bandwidth have
been already taken up. I do hope the discussion has benefitted those
trying to deal with scanners as well as with cameras; otherwise I can only
admire the altruism of the list maintainers!

Color space/gamma table questions are ontopic on this list. As you
have seen I don't know much of this stuff myself and learned quite a
bit.

And to avoid any misconceptions: I'm neither the list maintainer nor
the inventor of SANE but simply know about how SANE works in general a
little bit :-)

Bye,
Henning

[Erik Inge Bolsø]

Post by Henning Meier-Geinitz
And to avoid any misconceptions: I'm neither the list maintainer nor
the inventor of SANE but simply know about how SANE works in general a
little bit :-)

And you announce releases and timetables, which just might lead to people
perceiving you as "the boss" :)

--
Erik I. Bolsø | email: <knan at mo.himolde.no>
The UNIX philosophy basically involves giving you enough rope to
hang yourself. And then a couple of feet more, just to be sure.

[Theodore Kilgore]

Briefly:

I had to make the "stock" bayer and gamma routines from gphoto2 to work in
my program. The color map is standard, too. I want to thank everyone for
helping me focus on exactly what was needed and on what I should at least
try out.

My program is very primitive at this point. It will sense the resolution
setting and will download all of the pictures on the camera, directly into
files on the hard drive. It is primitive because I really don't know very
well yet to divide everything into different functions, and I also have
not figured out yet how the gphoto "filesystem" functions fit together, so
every time I try to incorporate them, I get C code which gives ten
thousand error messages.

The code will probably not work on low resolution, either. I haven't
tested that yet. Also this camera can be used as a PC cam to download
something like 10 frames per second. I have not addressed this at all,
yet. All of this will take a little bit more time, but the camera
assuredly works.

Post by Henning Meier-Geinitz
Color space/gamma table questions are ontopic on this list.

Whew! I would have thought, myself, that the gphoto-devel list would be
more appropriate, but I seem to be unable to subscribe to it. Does anyone
know if the instructions at gphoto.org for subscribing to the list are out
of date, or what?

Post by Henning Meier-Geinitz
As you
have seen I don't know much of this stuff myself and learned quite a
bit.

Well, it is one of my acquired skills as a professor, that I know how to
ask good questions even if I don't have the answers ;-)

Post by Henning Meier-Geinitz
And to avoid any misconceptions: I'm neither the list maintainer nor
the inventor of SANE but simply know about how SANE works in general a
little bit :-)
Bye,
Henning

I will try to send a picture to those who have responded to my questions,
because I do not feel it is right to send it here. I will be glad to do
that, though, if someone in charge (who, then?) sends me an e-mail saying
it is OK to do that.

The picture is slightly retouched with "sharpen" under GIMP. Nothing else
done to it (except to turn it right-side up). It looked almost as good as
the Windows-produced BMP file before, and my retouched picture looks
better than the Windows-produced picture when similarly retouched, too.
Funny thing is, out of 20 pictures I took, some of them looked better
as-is with my program, and some of them looked better with the Windows
software issued with the camera.

Theodore Kilgore