Copy of email about Robot Vision

I've got the images properly coming out, in their proper colours, now. And as we suspected, I've had no problems with getting images - so it was the fact I hadn't set up the ports before initializing the camera. I've attached an image for your interest.

(it's a bit yellow because of the lighting)

As for the colour order, well, I was trying to understand why it wasn't BGRG as per the manual, but GRGB...

Additionally I noticed we are getting a yellow last vertical pixel row (when looking at white). Magnify attached if you want to see. I suspected that this had something to do with the fact that the colour order (RGB order) wasn't what thought it should be, i.e. we were a sub-pixel out. This bug was complicated by the fact that my bitmap (BMP) image converter had a minor buggette in it (BMP format stores the pixels as BGR for Intel/little endian reasons) .... .

The text below the dashed line explains what I saw when I looked at the raw HEX file and what I conclude from this.

After reading the text below you might think 'why does this matter since the image looks ok?'. Well, one thing is that since we are proposing to do colour detect ... if we end up needing every single bit of resolution we need to understand what we are actually getting in terms of colour pixel position. That Bayer filter is bad enough without having shifted colour pixels we don't understand...

If resolution turns out not to be a problem then it's probably irrelevant.


--------------

Suspected hardware bug ...
When CCIR656 mode is off (CCIR601 mode) we get the last byte of the line (1280 wide line) as 0x10 (i.e. black level)
When CCIR656 mode is on we get the last byte of the line as 0xff

CCIR656 mode puts a 4 byte start header and end header which is FF 00 00 xx although these don't appear in the fifo data (normally) since they are outside of the HREF window.

Therefore it looks like we are dropping the first pixel written to the FIFO.

We also see this "feature" in their code, where they read green first (GRGB) even though the data sheet clearly says BGRG ... (We have to do this as well)

I *suspect* this has something to do with the HREF/NAND gate hack (rather than, say, the pixel clock which appears to be set as rising both in the FIFO and the camera for data valid).

However, since it really only effects the last pixel it probably doesn't effect us as long as we keep in mind that the pixel positions are moved for blue pixels, and I'm not going to spend any more time on this.


Regards,
Rob