[cpia] Vision File Format

[Jeff Laing]

> i have the camera working completely under gPhoto (taking pictures,
> transferring images, etc...) but i just need to convert the image format
> to something know :P then the library gets committed to CVS and the barbie
> cam is supported :)

I don't know how much you already know about the camera image format so
here's a brain-dump of all I know currently.

First, my camera seems to be using the horizontal shuffle mode so you need
to unshuffle the pixels on each row.  ie,  the pixels returned by the camera
are actually numbered

<00><02><04><06>......<01><03><05>.....

My loop to unshuffle them is in evk2.c, as I recall.

The second thing to consider is that the doc on the VV6300 suggests that the
CCD array looks like:

GRGRGRGR
BGBGBGBG
GRgRGRGR

but the actual image starts at an "R", not a "G".  Also, watch the PDF's use
of "odd" and "even".  At times, it suggests the ODD columns are 0,2,4,...

So, the raw camera data is more like:

RRRRRR.....GGGGG...
GGGGGG.....BBBBB...

The shuffled data is therefore

<r00><r02><r04><r06>......<g01><g03><g05><g07>....
<g00><g02><g04><g06>......<b01><b03><b05><b07>....
...

Getting this unshuffled was my first step in getting an image on-screen.
Colors were all shot to hell but all I did was set a GRAY at the same
intensity as the color for any given pixel.  (ie, put the pixel value into
all of R, G and B)  I improved this by using the "lum=22%R + 71%G + 7%B"
(from memory!)

For quite a while, I had a bad horizontal banding problem where the image
was in bunches of four rows, where the third and fourth row were noticably
darker than the first two.  This turned out to be caused by (a) a bad
unshuffle (b) thinking that the image data started with "G" instead of "R".

Now, the next problem is trying to work out what RGB values to use in each
pixel space, and this is the area where the image processing stuff comes in.
My first guess was to shift the image left and down by half-a-pixel.  ie,
for each pixel in the result image, I apply some algorithm to the values
that are immediately NW, SW, NE and SE of it.  For, image(0,0) is the result
of processing red(0,0), green(0,1), green(1,0) and blue(1,1).  There are
four possibly permutations you have to deal with in this approach:

	RG	GR	GB	BG
	GB	BG	RG	GR

My approach was to just take the Red and Blue values verbatim and average
the Green values.  Not a brilliant image.

My next thought was to just treat each of the colors seperately.  If you
look at the red CCD array, it must look something like:

R.R.R.R.R.R.R.R..
.................
R.R.R.R.R.R.R.R..
:::::::::::::::

I thought that it was probably reasonable to assume linear averaging down
the image, so I populated those values first:

R.R.R.R.R.R.R.R..
r.r.r.r.r.r.r.r..
R.R.R.R.R.R.R.R..
:::::::::::::::

then assume linear averaging across the image as well gives:

RrRrRrRrRrRrRrR..
rrrrrrrrrrrrrrr..
RrRrRrRrRrRrRrR..
:::::::::::::::

then just treat construct image(0,0) from red(0,0), green(0,0), blue(0,0)

The blue array is slightly different (ie, its offset +1,+1) but can use the
same approach.

The green array is better populated:

.G.G.G.G.G.G.G...
G.G.G.G.G.G.G....
.G.G.G.G.G.G.G...
::::::::::::::

I think, at this point, I have tried a couple of different approaches,
trying to average the four surrounding cells for each hole.

My main problem at this point is that I get a "ghosting" effect, about six
or so pixels across where it looks like the Red is being offset from the
Blue, for some reason.  No idea why.

Henry has hinted:
> You'll get some help from "A technical introduction to digital video" by 
> Charles A Poynton, page 177, Equation 9.10.

Now, I don't have a copy, but from browsing the online table of contents at
http://www.inforamp.net/~poynton/notes/TIDV/TIDV_toc.html it's possible it's
something to do with converting between Y'CbCr and RGB.

I'm assuming that perhaps the camera isn't returning RGB at all, although
the datasheet says otherwise.  Instead, perhaps its returning YCbCr.
Alternately, you might need to massage the R,G,G,B quad into a YCbCr value,
then convert it back to RGB space.

Anyway, thats all I have for now,

Jeff Laing <jeffl@spatialinfo.com>
------------------------------------------------------------------
I got a lot of ideas. Trouble is, most of them suck.
                                                  ---George Carlin