The typical clock frequency mentioned in the datasheet is 8 MHz. I haven't used an ATMega but I expect the onboard ADC has a maximum rate of < 1Msps.
You could probably drop the frequency but then your scanning would be slow. The datasheet doesn't mention minimums/maximums, so I'd be wary of doing anything other than what it does mention (not a lot) without confirming with Rohm. Maybe there is a separate app note that covers this stuff.
Anyway, you would be best off with a flash ADC with parallel interface, and a uC fast enough to read it comfortably (say at least 20 MIPS, maybe with a parallel port peripheral/DMA)
The datasheet gives no info in the analogue output quality, but I wouldn't expect it to be great so an 8/10 bit ADC will probably be suitable.
Then it looks like a simple case of pulse the SP input, wait 65 cycles and read just after the negative edge for 144 cycles. You may need an inverter with a slight delay (low pass RC would probably do to trim) on the ADC clock if it samples on the rising edge and you are driving both ADC/Module from same output pin.
If the pattern of the column is the same whenever they appear, the problem is called fixed-pattern noise. This is just something you need to deal with, especially when dealing with a raw sensor. The sensor vendor should be able to help with characterizing it.
To deal with it, you can either go through a manual calibration procedure that allows you to derive offset and gain correction factors for each column, which you then store in nonvolatile memory, or you can develop an adaptive algorithm that can recognize and compensate for FPN in live images on the fly.
To characterize the FPN, you'll need to take a series of flat-field images (same amount of light on each pixel) at various light levels (including completely dark) and various exposure times. For each combination of light level and exposure, take the average value of the pixels in each column, and average these values over many frames (to eliminate thermal noise).
From this set of data for each sensor column, you will be able to determine what gain and offset values to apply to that column to eliminate the fixed pattern. You will also be able to determine whether the correction values need to be different for different exposure times, or a common set of values will work well enough for all exposure settings.
You'll also want to do this across a number of individual sensors, to make sure that the statistical variations among sensors don't invalidate the solution you come up with.
Best Answer
A top quality demosaic process is fraught with subtlety, but very cheap answer can be had if you can accept a 50% loss in spacial resolution. Simply sum groups of four sensor pixels to get a single grey pixel. Assuming your sensor has a "typical" Bayer filter pattern, there will be twice as many green sensors as either red or blue. Summing square groups of four pixels will then make
Y = 2*G + R + B, which does over-emphasize the blue component but for simple cases like verifying optical system focus that will not be an issue.So for a typical arrangement of pixels which looks like this:
You would get one Y output for each group of four, at a lower spacial resolution:
The implementation of this can be done in hardware (as in an FPGA) with only enough memory to store half a scan line, as you can sum the input pixels in pairs the first line, then in pairs and including the previous line's sum on each second line.
You could also generate as many Y pixels as inputs by doing a sliding window, that would require a full scan line's worth of memory in hardware.
Doing it "right" involves a number of processing steps, but the core operation is to apply spacial filters to estimate separate
R,G, andBmonochrome images at identical resolution, with care taken to align them properly. Given those aligned images, it is straightforward to computeYat each pixel.An implementation of a fairly sophisticated demosaic system can be found in dcraw, which consumes raw sensor data and emits JPG images. Raw sensor data can be had from many higher end digital cameras, but usually encumbered by trade secrets making its interpretation difficult for third parties. Coffin and his user community have put a great deal of effort into reverse engineering the raw file formats written by such cameras. But it can also be used in your context.
When developing camera projects in the past, I have taken raw pixels straight from CMOS sensors as captured in RAM, dumped them to a file, and passed the file through dcraw.
The related problem for a prototype camera is getting your first prototype optics in focus, in order to have pixels that could mean something and thus prove that the whole thing works by showing a finished JPG of your bench.
The first step is to find and use the test-pattern modes in your sensor. With that, you can usually get reference patterns with known content to test your electronics and data flow. Then you can switch to real optics with some confidence that the raw pixels are meaningful and concentrate on getting the optics to give you an in-focus image.
A technique I've used in the past for a camera based on an M12 mount lens holder was to bring the lens into fairly decent focus with the lens holder mounted on an evaluation board that had software that provided a live view on a PC. Then I locked down the lens, and moved the whole lens holder to my prototype. Due to slight variations in sensor position relative to the PCB and mounting hole it wasn't perfect, but it was good enough to get a recognizable image.