Camera module! (And a picture of JamesH)

The camera interface is limited in length. We have tested a 15cm cable which seems to work. That is the on the picture taken on the Cambridge Raspberry-Jam. (We have not done a lot of experiments yet). But I have used the Pi with a 20! meter HDMI cable.

Do you know what the maximum possible length is as specified by the MIPI CSI? I read something that mentioned it being 30 cm (http://www.faqs.org/patents/app/20120016202).

Did you design the 15 cm flex cable or purchase it from someone else?

[Gert van Loo]

The camera interface is limited in length. We have tested a 15cm cable which seems to work. That is the on the picture taken on the Cambridge Raspberry-Jam. (We have not done a lot of experiments yet). But I have used the Pi with a 20! meter HDMI cable.

Do you know what the maximum possible length is as specified by the MIPI CSI? I read something that mentioned it being 30 cm (http://www.faqs.org/patents/app/20120016202).

Did you design the 15 cm flex cable or purchase it from someone else?

Cable length for those frequencies is mostly a matter of driver quality and impedance matching.
The camera board has its track width and distance to the ground plane such that the impedance matches
even if the track on the board is only a few mm. Biggest problem was that I had to change layer from the
connector to the camera and vias are always a concern for impedance matching.


I bought the cable from www.toby.co.uk.
I'll contact them and ask what their maximum standard length is.
I say standard because you can have these cables made to order.

Hi james/ gert, firstly I, like many thousands of others, would like to thank you for all the work you've been putting into the camera. I think it will accelerate all the different possibilities that the raspberry pi can be used for in the robotics field, in industry, in education, and in pure fun things.

I know you guy are getting close to releasing something, but is it too late to enquiries it will be possible to interchange the lens? E.g a cs mount or an m12 mount lens of which there are many cheap ones available, like the board mount cameras on ebay? This would open up a whole host of possibilities from infrared vision for robotics and maybe even astronomy?

Apologies if this question has already been asked.

Thanks again!

[jamesh]

You might be able to mount that over the current sensor, but you would get some pretty nasty lens weirdness, especially since we are using an EDOF camera to keep the price down and that already has a lens.

What sort of sensor is something like this supposed to mount over?

http://www.ebay.co.uk/itm/S-Mount-M12-B ... 500wt_1180

that looks suspiciously like a webcam lens mount, so small ccd/cmos sensor basically. You could still use that M12 mount and the existing lens in an afocal imaging situation but as you've already mentioned James, it most definitely wouldn't be ideal. The M12 doesn't actually have to be used to hold a lens, you could easily buy an M12 to 1.25" adapter then it could be used on all manner of astrogear/scopes.

For those that aren't aware of what afocal is:
http://en.wikipedia.org/wiki/Afocal_photography

What sort of sensor is something like this supposed to mount over?

http://www.ebay.co.uk/itm/S-Mount-M12-B ... 500wt_1180

You're correct, your eBay link is exactly the type of mount that I was talking about.
Heres the type of sensor (1/3" Sony CCD) that this is usually used with:
http://www.ebay.com/itm/420TVL-1-3-Sony-Super-HAD-CCD-Color-Board-Camera-PAL-/110947545657?pt=US_Security_Cameras&hash=item19d4fd3239

So, what do you think the chances are of someone removing the lens the CSI module comes with and replacing it with one of these, without breaking anything. Possible?

My 2c on camera:

1. Open source.
I am an open source developer and I do not care if the camera fw is open source or not. As long as it fills it promise (what ever the specs will be) and it has reasonable command set. As long as you get images or stream from it on command. It's generally accepted that hardware manufacturer drivers are proprietary sw.

2.Megapixels
I see tons of ppl whining for more pixels, I think 5MP or even 2MP would be good choice. It is the most cost efficient and versatile choce, keeping with the principles of the Raspberry Pi.

3. Release date
I know you are working hard on it.
There is just a lot of confusing and conflicting 3rd party info on this subject. And you'll waste a lot of valuable time on the "is it done yet?" messages. I think it would be a good idea to add camera module release date to FAQ and keep updating it when ever you get new info on it.

I was thinking of using Rasberry with USB camera but the camera module would make it much better for my use so I am waiting for it.

P.S. Twitter feed on the camera module status would be nice.

[jamesh]

It's 5MP.

Release date is pretty up in the air - we have the camera working on the latest PCB's but there is other stuff we also need to get working and some example software to write. I think we hope to have something by Xmas at the latest. However, Gert's very busy, as are many of the others who would be able to work on the board/software.

I don't see any problems with 5 MP. My trusty-rusty Kodak has 5 MP and gives me amazing detail.

You folks keep up the good work. You have our thanks for all the efforts.

Hi,
Hope this might be interesting:

Lots of people have asked about a second camera for doing stereoscopic work. Image splitting using mirrors is another approach. It only needs the one camera so removes the sync problems - although reduces the picture size. See http://www.lhup.edu/~dsimanek/3d/stereo/3dgallery7.htm for an example.

Keep up the good work - can't wait to get my hands on the finished product.

wow - that is really interesting

I can also see these selling like hot cakes

I gues when you're drunk the bit of your brain that stitches the two images together takes a nap.

Here's a response to some posts on the first page: It can't be that hard to get a camera without an IR blocker. Why? I have one sitting next to me, in the form of a spy-camera-night-vision-infra-red-wristwatch-thingy. Just saying.

Liz has mentioned that the camera board will handle composite video in this thread:

http://www.raspberrypi.org/phpBB3/viewtopic.php?p=209166#p209166

Are any further details available on what other features the board will have? For instance will it also handle audio input?

[Gert van Loo]

Liz has mentioned that the camera board will handle composite video in this thread:

http://www.raspberrypi.org/phpBB3/viewtopic.php?p=209166#p209166

Are any further details available on what other features the board will have? For instance will it also handle audio input?

You mean like discussed in this thread:
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=43&t=18526

Are any further details available on what other features the board will have? For instance will it also handle audio input?

You mean like discussed in this thread:
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=43&t=18526

Yeah, that was exactly what I meant. Thanks for pointing me to the thread.

For clarity, when Liz says the board "will deal with composite video" does this mean that there wil be two video input types from the board: input from the camera itself and input from a separate composite video connector? Is this correct? If so, out of curiousity, will there be any other types of video input available from the board?

It's 5MP.

Release date is pretty up in the air - we have the camera working on the latest PCB's but there is other stuff we also need to get working and some example software to write. I think we hope to have something by Xmas at the latest. However, Gert's very busy, as are many of the others who would be able to work on the board/software.

Thanks for the update. Really looking forward to this being released, but I understand (all too well) that it will take as long as it takes. However, Christmas would be wonderful - and not that far away. Yikes!

don't sweat it - my birthday's not til April so you've got a few months yet...

Hi,

I just read most of this thread, as I am very interested in the camera, as a HD video camera for aerial video (FPV). I currently use the GoPro, but would like to use higher bitrates (compression really costs a lot of image quality with fast-moving pictures...), and possibly different lenses. So far most embedded devices that can do HD video are locked down and don't do what I want.
I have a few questions regarding the camera:

- I know people have asked many times about replacing lenses... and also RAW image output. I understand that even if the existing lens could be removed and replaced with an M12/CS mount, the EDOF algorithm will ruin things. However, if we can get RAW output somehow, would the EDOF compensation already be applied, or is it just RAW pixel values from the bayer pattern?

- I am also really interested in RAW output for color-grading in post-production. There is an open source FPGA camera "Elphel" that does a neat trick to compress "RAW" without debayering. They call it JP4: http://wiki.elphel.com/index.php?title=JP4 As you can see in the wiki, there is already a linux streaming solution in place to work with this format.
Essentially they group the r, g, b pixel sites from the bayer mosaic into 4 blocks of 8x8 pixels, and do a (M)JPEG compression then. This way each JPEG 8x8 block is monochrome. The nice thing is that this technique doesn't first triple the data by converting the bayer into RGB values for each pixel, so the data rate remains pretty low. The JP4 files can be decompressed, and one can do a RAW conversion afterwards with various professional or OS RAW converters, which leads to much better image quality and allows for color-corrections.
Is there any possibility to do something similar on the RPi? With RAW output from the sensor I could easily implement it myself, but I guess the ARM might be too slow to compress MJPEG at 1080p 30fps. Would be best to run the grouping and compression on the GPU, but I guess that I cannot access that.

I really appreciate what you're doing, I have been looking for a small, affordable hardware solution for a long time and the RPi is amazing. Some people dismiss what to do with a camera - I think they have no trust in the imagination and creativity of a million people...

One remark I would like to make - I understand that you are bound by Broadcom NDAs and that they have good reason to protect their IP. However, I would like to point out that there are a few people out there that have a lot of experience and similar qualifications as you do. Even if parts of the image processing code are closed, it would therefore be great if you could think of ways how to get to unprocessed data, or keep some parts of the pipeline configurable (e.g. switch some parts off). Obviously most people won't need it, but some people do and they will figure out a way (and hopefully share it) as long as it is possible at all. E.g. many people seem to be interested to change the lens (for good reason I think). I wouldn't worry about the mechanical aspects, there's always a way... but it would require to bypass the EDOF algorithms, which won't be needed with properly focused quality optics. It would be great if you could keep "hackability" in mind My usual problem is that most hardware is optimised for the "average consumer", which I am not... and in my view, there are truly amazing things that people do with new hardware that the original designer didn't think of (which I think does align with the RPi goals somehow...)

It grieves me to say it, but I think you're about to receive one of those very short "sorry but no" replies.

[jamesh]

I'm not sure of the very specifics of the camera, but I think that the EDOF is done inside the sensor before it outputs the Bayer pattern, so its not possible to get the RAW data prior to the EDOF. On the other hand it might be possible to turn off the EDOF. We have extracted RAW data from other sensors using the same ISP and saved it, whether that's in as standard I'm not sure. The board won't have lens mounts, just the sensor, which is on a very short ribbon cable to a socket on the PCB.

I'm pretty sure that eventually we will be able to supply the option to play around with the ISP settings, turning stages on and off etc, and perhaps the tuning as well, as these are text files. However, the content of those files would give away how we do some stuff, so might have to be a less exposing subset!

I seriously doubt the CPU could encode 1080p30 MJPEG, this is usually done on the GPU and the encoded stream sent to the Arm.

On the whole, people need to regard this as a cheap and cheerful camera module that copes with the demands of the vast majority of peoples needs (5MP, 1080p30 record). There will always be people for who it's not enough. Hopefully there will be enough exposed stuff to increase the market even more but we need to get the camera working and out first.

I do hope that you keep SFX42's idea in mind: Allowing to disable steps in the processing allows people to look at the innards of the processing steps.

This all started with the idea that back in the old days, you had a computer where you could experiment with the inner workings. Allowing those children that ARE interested in "digital image processing: from sensor to bitstream" to access the intermediate steps should be a design goal for the raspberry pi.

Keeping this in the back of your head while implementing things, will make it way easier to add this back in later on, even if you don't do it immediately.

Even though the "real-time" throughput won't be achievable, it will be useful to grab intermediate steps, process them "off-line" (non-real-time) and examine the results later. You can (and should~) think about optimising and getting real-time performance later on.

Back in the 1990ies I worked on a project where the University of Leiden had designed an algorithm that would do image processing on video images. I think they did about 1 frame per minute. We, Technical University of Delft (or "Delft institute of technology" if you wish), were tasked of making this "real-time". We built the image pipeline: grab, process, output (back to video).

What's the average power consumption of the camera module??

Richard S.

Disclaimer: I am not a camera engineer.

Looking through the OV5647 datasheet, the closest thing I could find to EDOF is the LENC (Lens compensation) setting, which can be disabled by setting a bit in one of the ISP control registers (0x5000 bit[7]).

I may simply be looking for the wrong thing in the wrong place, though LENC dallying with the RB and G channels separately in 5x5 blocks certainly sounds like EDOF.

[jamesh]

Disclaimer: I am not a camera engineer.

Looking through the OV5647 datasheet, the closest thing I could find to EDOF is the LENC (Lens compensation) setting, which can be disabled by setting a bit in one of the ISP control registers (0x5000 bit[7]).

I may simply be looking for the wrong thing in the wrong place, though LENC dallying with the RB and G channels separately in 5x5 blocks certainly sounds like EDOF.

It's pretty likely technically the lens compensation can be turned off, but that would require drivers changes, plus the plumbing through to the OpenMAX layers. Certainly possible, and not that hard, but difficult to squeeze in the time. Although might already be there...

In fact, almost everything people have asked for is technically possible. But some of it would require a lot of work, and a lot of that work would need to be on the GPU code side. So done by either Broadcom or someone with access to the source and required compilers. Plus a lot of time and technical know how. So expensive.

Point. Would it be easier (or even possible) to have anyone who wants more control fiddle with lens compensation and the like directly (by hooking the camera module up via I2C and flipping bits in the register) without any modifications to the driver? Can you even do that via I2C?