Very very small pixels

Researchers at Stanford University are developing a multi-aperture image sensor which groups arrays of 16x16 pixels, then puts a tiny lens on each group. Their 3Mpixel image sensor in this way includes a total of 12,616 lenses, compared to a shabby single lens commonly found in cameras. The benefits are plentiful. The simpler electronic design means the pixels can be 0.7um, much smaller than Kodak's 1.4um pixels that I posted about earlier. Camera modules incorporating this technique can be made even smaller, cheaper, more robust, and, most importantly, grab better pictures. Instead of taking a single snapshot, the camera actually takes 12,616 pictures, which can be combined with digital image processing techniques to capture 3D image data, to accurately control depth of field, focus, etc. With enough image processing power available in the camera, this opens up a whole world of new possibilities.

A high level overview of the work can be found here and their technical ISSCC paper can be found here.

Very small pixels

A few weeks ago, Kodak announced their new 5Mpixel image sensor at the Mobile World Congress. The sensor has a 1.4 micron pixel size (1.4 by 1.4 micron) which means the sensor can fit in a 4x4mm camera module. That is about the size of a regular black ant. I am sure a bigger ant could carry such a camera. The Kodak sensor has some novelties. There is a new color filter pattern, which includes a "white" photocell receptor instead of just measuring the amount of red, green and blue. That will require quite some changes to the image processing algorithms. Another novelty is that the sensor measures darkness instead of light. Apparently that can be more accurately implemented in silicon. Like most new sensor introductions, Kodak promises higher quality images than anyone else.

Micron just announced that it spun its image sensor business out into a new company called Aptina. The business will be run by Micron's Bob Gove, who was previously at VLIW processor company Equator. Micron says they have already sampled an even smaller 1.2 micron pixel, which in the same 4x4mm tiny camera module would yield a 7Mpixel sensor.

Tested pixels

I just ordered a new camera for personal use. It'll be my first SLR. Most cameras I've held, either in the office or at home, I have pointed to this chart to test the camera:


You can get the original from Stephen Westin in pdf here. Simply printing it on any decent laser printer does a pretty good job. If you have an A3 printer, even better. It's interesting to see that most of today's camera phones don't even do a low-pass filter before subsampling on the viewfinder, causing bad aliasing. There's still lots of room for improvement!

Post-processing pixel companies going away?

Recently, two chip makers that focused on post-processing were acquired by bigger companies. Sigma Designs acquires Gennum's image processing business, and ST acquires Genesis Microchip. The acquiring companies provide single-chip video processing solutions which include such post-processing functionality, but until now their post-processing wasn't as good as what the smaller focused companies could deliver. The market demands ever increasing picture quality at ever reducing price points, which these acquiring companies are looking to achieve with their acquisitions.

Crummy pixels on my iPod Touch

I recently bought an iPod Touch. The WiFi integration is neat and worked straight out of the box. I now have a pocketable Internet browser, and it even connects directly to YouTube, using the new H.264 codec instead of YouTube's default and inferior Flash codec that the PC-based website uses.

After playing a few videos something interesting happened. The video codec shows very crude artefacts. See the picture below. I haven't found many other iPod users on the web complaining yet, but it's hard to believe I am the only one. Will Apple be able to fix this with a firmware upgrade? If the rumoured Samsung chip at the heart of this device uses a hard-wired video coding subsystem, they likely won't be able to fix the issue quickly in software. Instead, they will have to respin the chip and people will have to return their devices and get new ones months later. Chip inventory will have to be trashed. A reset fixed the issue for me, but it has shown up again.

Are you an SOC designer that still uses hard-wired video codecs? Can you risk designing an SOC that requires a silicon respin to resolve issues that could have been solved in software if a programmable approach had been chosen?