Re: PCDig and JAI CV-L103 colour camera

[Will Lockhart <will@mvhi.com>]

M.Stein writes:
 > I'm not really sure about some problems with the input LUT's. The pcdig
 > has 2 16x16bit LUT's. Till now I only use the lower one, because we don't
 > have cameras with more than 16bit.
 > Also the PIXEL_SIZE=24 entry in the config file will not work. My
 > suggestion is to set PIXEL_SIZE=16, so the lower LUT is filled in a linear
 > manner (that is what you need). Later use the HIOC_PCD_SET_LUT1 to load a
 > self defined mapping into the upper LUT. To do this, define a union
 > pcd_lut_t, fill it with linearized values (0->0 .... 65535->65535), and
 > call the ioctl with the union pointer as argument. There are also some
 > PCD_GET_LUT0|1 calls to verify the loaded mappings.

I can't work out from reading the PCDig hardware reference whether the 
LUTs are even used when the pixel size is greater than 16 bit.

 > ...But not really much of this calls are tested...
 > 
 > The bytes should lay in the memory like
 > 
 > 	RGBRGBRGBRGBRGBRGB
 > 
 > am I right?

Well, this is where things get interesting. It certainly looks as if
the data is three bytes per pixel, because when I display an RGB
image, interpreting the bytes as you suggest above, I get an image of
the correct width, but with incorrect colours. On closer inspection,
it appears that in the first row the B byte is always zero, on the
second row the R byte is always zero and on the third row the G byte
is always zero.

Even more strangely, when I grab a 2048x2048 image, I get three copies 
of the same image arranged vertically, each one is horizontally offset 
from the previous one. It almost looks as if the R, G and B planes
have been separated (the PCDig is capable of doing this), but then
that doesn't explain why the image width is correct.

More seriously, I'm finding that my machine keeps locking up when I
grab (or snap) images and I have to reboot it.

 > 						matthias

Will