jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 25924
Joined: Sat Jul 30, 2011 7:41 pm

Re: Camera Interface Specs

Sun Feb 17, 2013 1:35 pm

Hardware_man wrote:JamisH,

As I have said, I would convert HDMI (or maybe DVI or even analog component) to CSI-2 in an add on hardware board. I was under the impression that the problem was getting through the ISP. Do I understand correctly, the ISP is the Input Signal Processor and this is where a camera CCD is tuned? The ISP was not designed with the expectation of a video source that is already tuned so there is no existing “default” tuning that is essentially a “straight pass through”?

So you would have to manually “tune” the ISP for already tuned video, you can’t just “call default tuning”. If I have this right, creating a “default tuning” would be as much work as tuning for any specific CCD and this is the “driver” that you are talking about?

Is this about right?

Hardware_man
Yes, we would bypass the ISP in this case - there are camera sensors that have inbuilt ISP's which use a similar path. Still need to write the driver for the CSI, and mod the OpenMAX frame work to allow the driver to drive input resolution rather than the usual way round. That's where the effort lies.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“My wife said to me `...you’re not even listening`.
I thought, that’s an odd way to start a conversation.."

towolf
Posts: 421
Joined: Fri Jan 18, 2013 2:11 pm

Re: Camera Interface Specs

Sun Feb 17, 2013 5:42 pm

Will it be possible to capture at, say, 1 frame per minute and pipe that directly to the H264 encoder?

That would be seriously cool. Or are the frame rates fixed like in webcams?

ghans
Posts: 7882
Joined: Mon Dec 12, 2011 8:30 pm
Location: Germany

Re: Camera Interface Specs

Sun Feb 17, 2013 5:44 pm

The encoder is capable of [email protected] AFAIK.


ghans
• Don't like the board ? Missing features ? Change to the prosilver theme ! You can find it in your settings.
• Don't like to search the forum BEFORE posting 'cos it's useless ? Try googling : yoursearchtermshere site:raspberrypi.org

towolf
Posts: 421
Joined: Fri Jan 18, 2013 2:11 pm

Re: Camera Interface Specs

Sun Feb 17, 2013 5:51 pm

What does that mean? It only outputs files at 30 fps? Because the fps in the output is not much more than a number in a header. I’m wondering if I can do very slow timelapses, over a year for example.

ghans
Posts: 7882
Joined: Mon Dec 12, 2011 8:30 pm
Location: Germany

Re: Camera Interface Specs

Sun Feb 17, 2013 6:01 pm

Are you referring to the camera module ?
I was thinking we were still OT :D


ghans
• Don't like the board ? Missing features ? Change to the prosilver theme ! You can find it in your settings.
• Don't like to search the forum BEFORE posting 'cos it's useless ? Try googling : yoursearchtermshere site:raspberrypi.org

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 25924
Joined: Sat Jul 30, 2011 7:41 pm

Re: Camera Interface Specs

Sun Feb 17, 2013 6:56 pm

towolf wrote:Will it be possible to capture at, say, 1 frame per minute and pipe that directly to the H264 encoder?

That would be seriously cool. Or are the frame rates fixed like in webcams?
I seem to remember asking this of the codec team a while ago. I think the minimum was 1 fps. But that may be a problem with how we pass the fps value about rather than a codec requirement.

I would be inclined for serious time lapsing to do timed stills capture (at video resolution, or you could go to 2K or 4K!), and then post process to create a video file.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“My wife said to me `...you’re not even listening`.
I thought, that’s an odd way to start a conversation.."

towolf
Posts: 421
Joined: Fri Jan 18, 2013 2:11 pm

Re: Camera Interface Specs

Sun Feb 17, 2013 8:17 pm

Ah, I think I’m in the wrong thread, sorry.

The advantage is that you’d get a ready made highly compressed movie that exploits the redundancies between frames.

At 15 MBit/s you could fit a whole year onto a 32GB SD card.

I reckon the encoder could discard frames (modulo 60)?

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 25924
Joined: Sat Jul 30, 2011 7:41 pm

Re: Camera Interface Specs

Sun Feb 17, 2013 8:40 pm

towolf wrote:Ah, I think I’m in the wrong thread, sorry.

The advantage is that you’d get a ready made highly compressed movie that exploits the redundancies between frames.

At 15 MBit/s you could fit a whole year onto a 32GB SD card.

I reckon the encoder could discard frames (modulo 60)?
Well, a lot of the compression advantage comes from frames being similar (either before or after the current frame), and the further they are apart in time the less likely they are to be similar. So time lapse with say a minute between frames wont compress as well as normal video, unless the subject is really moving slowly. I'd still be inclined to post process from high quality jpeg captures.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“My wife said to me `...you’re not even listening`.
I thought, that’s an odd way to start a conversation.."

B1234
Posts: 14
Joined: Mon Mar 05, 2012 11:40 am

Re: Camera Interface Specs

Mon Feb 18, 2013 12:05 pm

geek01 wrote:I believe you are vastly underestimating the market for a digital video-in solution, even without HDCP.
I dont think people underestimate potential markets, its just that the Raspberry Pi is a "small low cost computer for education".

As soon as you start adding more things to it, particularly when its all being produced by a non-profit organisation with a lot of volunteers etc, you suddenly start pushing the price up.

Its a bit like asking for Ferrari performance from a Nissan Micra, it could be done, but it wont be cheap nor something you can just stick on.

Hardware_man
Posts: 94
Joined: Tue Dec 04, 2012 6:28 pm
Contact: Website

Re: Camera Interface Specs

Mon Feb 18, 2013 6:35 pm

From Broadcom’s point of view, selling chips is selling chips. In this thread, I am talking about an add on board for the “universal” video in function, not redoing the Pi board to add this function. So the added cost would only be for people who want to buy the additional “universal” video in option. Just like you have the option to by just the Pi board, or also buy the camera now (or soon).

So let’s say somebody writes some KVM code, and figures he can buy Pi boards and add on input boards in quantity, throw it into a box with some connectors and sell a KVM cheaper and make money. This doesn’t hurt the Foundation, this helps the Foundation.

The more Pi boards that the Foundation sells, the more Broadcom will devote resources, like firmware writers to the Foundation. And that generates code that everybody can use. So even if somebody is making a profit with the Pi board instead of using it for educational purposes, it helps all of us.

Hardware_man

B1234
Posts: 14
Joined: Mon Mar 05, 2012 11:40 am

Re: Camera Interface Specs

Tue Feb 19, 2013 10:18 am

Oh I agree completely, add-ons and increased market for the Pi can only be good things, if nothing else they will push the cost of each board down, making them even cheaper.

I think the "problem" starts when you want to add things that require extensive work from the Foundation and/or Broadcom or that arent necessarily suitable for the Pis design, eg requires access to i/o lines that arent exposed.

Without knowing what was required, in both time and parts, it would be impossible to estimate the cost for some things, and "expressing interest" isnt the same as "committing to buy", but then, as was suggested before, maybe the Foundation should do a Kickstarter, that way they combine both expressing and committing.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 25924
Joined: Sat Jul 30, 2011 7:41 pm

Re: Camera Interface Specs

Tue Feb 19, 2013 10:46 am

B1234 wrote:Oh I agree completely, add-ons and increased market for the Pi can only be good things, if nothing else they will push the cost of each board down, making them even cheaper.

I think the "problem" starts when you want to add things that require extensive work from the Foundation and/or Broadcom or that arent necessarily suitable for the Pis design, eg requires access to i/o lines that arent exposed.

Without knowing what was required, in both time and parts, it would be impossible to estimate the cost for some things, and "expressing interest" isnt the same as "committing to buy", but then, as was suggested before, maybe the Foundation should do a Kickstarter, that way they combine both expressing and committing.
TBH, it's not really a question of money (although you would need it!), but of finding engineers who are available to do the job. It's not a quick thing, and taking engineers off other projects that make a lot more money won't be top of Broadcom list of things that keep shareholders happy.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“My wife said to me `...you’re not even listening`.
I thought, that’s an odd way to start a conversation.."

Hardware_man
Posts: 94
Joined: Tue Dec 04, 2012 6:28 pm
Contact: Website

Re: Camera Interface Specs

Wed Feb 20, 2013 4:10 pm

B1234,

The more I think about it, the Pi actually is the “Ferrari”, not the “Nissan Micra”. Broadcom got a design win for a Samsung smart phone. That is huge when you consider, Samsung chose the Broadcom GPU over their own GPU.

All that I can speculate is that Broadcom must have an excellent H.264 and MPEG2 implementation. Traditionally, better performance cost more money (as in the car analogy). But to some degree, the economics of I.C.s is different. The better implementation gets more sales thus has larger volumes thus doesn’t cost more. Maybe even cost less!

Wish I had a video input!

Hardware_man

GauVeldt
Posts: 24
Joined: Thu Mar 14, 2013 4:46 pm
Contact: Website

Re: Camera Interface Specs

Thu Mar 14, 2013 6:13 pm

jamesh wrote:I think all the connector specs are public (maybe not camera?), but the camera interface connects directly to the GPU either using CCP2 or CSI-2. Your camera would require a new driver on the GPU, and they are usually pretty complicated. Since yours has a zoom lens you also need a more than usually complicated lens driver and appropriate tuning. I doubt we already have a driver since we have never worked on a a system with a zoom lens. It's a big job I'm afraid, and wouldn't be possible for anyone outside the Foundation or Broadcom to do it. Therefore that would be something you would need to contract the Foundation or Broadcom to do for you. Might be worth it depending on your use case.

Sorry, that's probably not what you wanted to hear.
I can't help but to think the proprietary interface controller (GPU) may indeed be the bottleneck here for general video(camera) input on RPi. It's such a small population within the community that want advanced video features unfortunately thus probably not enough to stomp out the USB bugs showstopping most other (USB) alternatives (it is very much hit-and-miss game with USB cameras on RPi).

A more complicated solution might be to thin out the work needing to be done in the GPU by limiting the GPU role to strictly data transfer and storage (which could probably get buried in a blob and the API to do that may even already exist to the bazaar in the current camera drivers for the Foundation camera) and have the GPIO do all other camera control tuning parameters. My thinking here is that if the proprietary GPU path is simply because it can keep up with the data stream when the ARM and GPIO can't then move all other camera controller parameters to GPIO. A camera in this configuration would require a CSI2 and GPIO connection but would only send the final image data over CSI2/GPU link with the cathedral's NDA'd (ie: Broadcom) GPU-based driver simply performing a store-and-save operation (optionally with compression if his API can be accessed by the bazaar). Could all other parameters be done over GPIO to totally bypass the proprietary GPU path (the GPIO specs are freely available to the bazaar)? Assume for this argument a camera whose tuning parameters and other specifications are already available. Basically I'm taking the approach that the GPU path has proprietary bottlenecks so it's made to handle only the traffic (realtime image data) that can't be transferred to RPi's RAM any other way and move all other traffic onto the unencumbered GPIO pathway with whatever hardware needed (4K SRAM to hold the 2000 odd tuning settings assuimg 16-bit words, 8K SRAM if 32-bit words needed, 16K SRAM for 64-bit doubles, shift register to select SRAM address, r/W mode, clock strobe, buffers, etc.) and protocol to select, store and retrieve parameters. This would be more costly but might be the only way to do general purpose video/image input in a bazaar-friendly manner.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 25924
Joined: Sat Jul 30, 2011 7:41 pm

Re: Camera Interface Specs

Thu Mar 14, 2013 10:22 pm

Remember that the GPU does a lot more than just 'move the data around'. It has a real time Image processing pipeline so all the tuning is applied to the incoming data. Also note that the CSI is just for the data side, there is also an I2C interface on the camera control purposes (Is that what you were proposing for the GPIO?). It difficult to see how any of the processing done on the GPU could be moved to the CPU without losing a lot of the performance.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“My wife said to me `...you’re not even listening`.
I thought, that’s an odd way to start a conversation.."

GauVeldt
Posts: 24
Joined: Thu Mar 14, 2013 4:46 pm
Contact: Website

Re: Camera Interface Specs

Fri Mar 15, 2013 2:55 am

jamesh wrote:Remember that the GPU does a lot more than just 'move the data around'. It has a real time Image processing pipeline so all the tuning is applied to the incoming data. Also note that the CSI is just for the data side, there is also an I2C interface on the camera control purposes (Is that what you were proposing for the GPIO?). It difficult to see how any of the processing done on the GPU could be moved to the CPU without losing a lot of the performance.
Yes I'm suggesting splitting the pipeline to avoid all the proprietary landmines of trying to do these things in the GPU Kingdom and offending King Broadcom. It would be a performance hit no doubt but alas I see no other way to have a general bazaar-accessible camera interface other than to erect a major detour of GPU Kingdom. So yes I'm proprosing moving any image processing and camera tuning controls away from the GPU and leaving the GPU only to transfer the data to memory over the proprietary-jailed CSI2 pathway and only using [GPU-hosted texture/image processing pathways] (think: fragment shaders) that have bazaar-accessible interfaces. Any other processing would have to be done via GPIO/ARM pathway to allow the bazaar access to collaborate on its development. Any camera tuning that can be done over GPIO takes complexity out of the sealed Foundation/Broadcom proprietary driver and makes life less miserable for everyone involved since it lets more people get involved in this project (which is an educational win for RPi's educational mandates).

Edit: For example OP's zoom function could be done over the GPIO interface so that GPU blobs would not even need to know zooming capability exists thus not increasing its complexity for any specific camera feature.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 25924
Joined: Sat Jul 30, 2011 7:41 pm

Re: Camera Interface Specs

Fri Mar 15, 2013 8:34 am

GauVeldt wrote:
jamesh wrote:Remember that the GPU does a lot more than just 'move the data around'. It has a real time Image processing pipeline so all the tuning is applied to the incoming data. Also note that the CSI is just for the data side, there is also an I2C interface on the camera control purposes (Is that what you were proposing for the GPIO?). It difficult to see how any of the processing done on the GPU could be moved to the CPU without losing a lot of the performance.
Yes I'm suggesting splitting the pipeline to avoid all the proprietary landmines of trying to do these things in the GPU Kingdom and offending King Broadcom. It would be a performance hit no doubt but alas I see no other way to have a general bazaar-accessible camera interface other than to erect a major detour of GPU Kingdom. So yes I'm proprosing moving any image processing and camera tuning controls away from the GPU and leaving the GPU only to transfer the data to memory over the proprietary-jailed CSI2 pathway and only using [GPU-hosted texture/image processing pathways] (think: fragment shaders) that have bazaar-accessible interfaces. Any other processing would have to be done via GPIO/ARM pathway to allow the bazaar access to collaborate on its development. Any camera tuning that can be done over GPIO takes complexity out of the sealed Foundation/Broadcom proprietary driver and makes life less miserable for everyone involved since it lets more people get involved in this project (which is an educational win for RPi's educational mandates).

Edit: For example OP's zoom function could be done over the GPIO interface so that GPU blobs would not even need to know zooming capability exists thus not increasing its complexity for any specific camera feature.
I don't think its possible, but if it were, I think you would be lucky to get more than 1fps in video mode, and captures would take an age (like, many 10's of seconds, compared with 1s or so now). And you seem to misunderstand the tuning aspect. This is the set of parameters (and there are a lot of them) that set up the various HW blocks in the ISP to take the raw bayer image and convert it to a decent quality image. That's not something you do over GPIO, they are GPU accessible registers. Nothing to do with communication with the camera. It's all downstream.

But you have reminded me I need to implement zooming in the camera app.

What is this 'bazaar' you keep referring to?
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“My wife said to me `...you’re not even listening`.
I thought, that’s an odd way to start a conversation.."

GauVeldt
Posts: 24
Joined: Thu Mar 14, 2013 4:46 pm
Contact: Website

Re: Camera Interface Specs

Fri Mar 15, 2013 10:16 am

jamesh wrote:What is this 'bazaar' you keep referring to?
I've seen it mentioned in the forums elsewhere so I thought you understood the metaphor of the bazaar versus the cathedral. It's a way to abstract the open-vs-closed development models without raising unnecessary attention to specifics that may become troll food (which I've seen in these very forums in various places).

The bazaar is the people at large. The development model of linux. Those who support the education models of places like uopeople.org and RPi. Those who support freedom of information, speech, association and press. The RPi is a step in the right direction to bring education and freedom back to the people of the bazaar.

The cathedral is the privileged 1% who would like to see the bazaar disappear completely. They'll even pretend to support them to get tax write-offs while maintaining enough of a leash not to lose any of their power.

GauVeldt
Posts: 24
Joined: Thu Mar 14, 2013 4:46 pm
Contact: Website

Re: Camera Interface Specs

Fri Mar 15, 2013 10:21 am

jamesh wrote:This is the set of parameters (and there are a lot of them) that set up the various HW blocks in the ISP to take the raw bayer image and convert it to a decent quality image.
You might be right. To me ISP normally means Internet Service Provider. I reckoned that it might be the hardware on the camera interpreting the lens image on the charged couple arrays into the raw data sent to transfer to the CSI2 interface.

Is the ISP something on the camera board or something within the GPU?

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 25924
Joined: Sat Jul 30, 2011 7:41 pm

Re: Camera Interface Specs

Fri Mar 15, 2013 1:16 pm

GauVeldt wrote:
jamesh wrote:This is the set of parameters (and there are a lot of them) that set up the various HW blocks in the ISP to take the raw bayer image and convert it to a decent quality image.
You might be right. To me ISP normally means Internet Service Provider. I reckoned that it might be the hardware on the camera interpreting the lens image on the charged couple arrays into the raw data sent to transfer to the CSI2 interface.

Is the ISP something on the camera board or something within the GPU?
ref: You may be right should you 'you are right' - I work for Broadcom specialising in the camera area.

Image System Pipeline is one definition (there are others). It's the path the image takes from being captures by the sensor to being fully processed and decent. On the GPU there are >20 stages to the ISP. The CSI-2 port where the camera attaches is just the first stage. That produces a raw bayer image, which is bebayered, black level corrected, lens shading corrected, denoised, sharpened, colour balanced, runs through the gain control, the white balance control. And that's just a subset of the processing...all done on the GPU at 30fps for 1080p.

Note that some camera sensors have all the processing built in - in fact the one being used does, but we don't actually use the internal ISP in this case, we use the one on the GPU, and just take bayer data from the camera.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“My wife said to me `...you’re not even listening`.
I thought, that’s an odd way to start a conversation.."

Hardware_man
Posts: 94
Joined: Tue Dec 04, 2012 6:28 pm
Contact: Website

Re: Camera Interface Specs

Fri Mar 15, 2013 3:08 pm

I really don’t want to get into a political discussion of the 1% vs the 99%. And I’m not going to quit my job as an engineer to become a Wall Street Occupier. I like running water and central heat too much ;.)

What I do want is a real time H.264 encoder. Actually, as I have searched for a real time H.264 encoder, I have discovered that most of the companies who manufacture hardware H.264 encoders / decoders have a similar business model as Broadcom. T.I. is the one exception that I have found. Maxim also makes a GPU with H.264 encoder. Both T.I. and Maxim make all GPU documentation public. T.I. will sell single piece quantities through Digi-Key, Maxim is 100 piece minimum. But they both require a very expensive development board to get started (if you want to start with proven hardware).

The Pi would be an excellent development board if the GPU documentation were public. What I want is a way to get high bandwidth video into the H.264 encoder input. And the only way to do that is from the CSI-2 connector and through the ISP. JamesH tells me there is no simple “ISP bypass” function if your video is already tuned. So Broadcom would need to create a “flat tuned” ISP driver and JamesH tells me that is as much work as tuning the ISP for a specific CCD. And even with “tuned” video, the ISP still has to do some “house keeping”, Big endian vs little endian, that kind of stuff. That’s why I suggested an add on HDMI to CSI-2 board, or even analog component to CSI-2 and a companion ISP driver to create a video input for the “bizarre”.

The Broadcom chip is designed to interface directly to a CCD, not to a “general purpose” video signal. If lots of people had replied to this thread all requesting some kind of video input for the bizarre, then the Foundation would make it a priority, but they haven’t. So don’t blame the “1%”, blame the bizarre.

Hardware_man

bernd71
Posts: 5
Joined: Fri Nov 09, 2012 10:13 am

Re: Camera Interface Specs

Fri Mar 15, 2013 4:30 pm

Hardware_man wrote:So don’t blame the “1%”, blame the bizarre.
Hardware_man
Because they aren’t interested in such an interface?

Ravenous
Posts: 1956
Joined: Fri Feb 24, 2012 1:01 pm
Location: UK

Re: Camera Interface Specs

Fri Mar 15, 2013 5:03 pm

Correct, because it's not the foundation's core aims to do this. As he's been told approximately a thousand times. So he'll have to pay and get what he's after elsewhere, at the moment. It's funny watching though.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 25924
Joined: Sat Jul 30, 2011 7:41 pm

Re: Camera Interface Specs

Fri Mar 15, 2013 8:40 pm

Hardware_man wrote:I really don’t want to get into a political discussion of the 1% vs the 99%. And I’m not going to quit my job as an engineer to become a Wall Street Occupier. I like running water and central heat too much ;.)

What I do want is a real time H.264 encoder. Actually, as I have searched for a real time H.264 encoder, I have discovered that most of the companies who manufacture hardware H.264 encoders / decoders have a similar business model as Broadcom. T.I. is the one exception that I have found. Maxim also makes a GPU with H.264 encoder. Both T.I. and Maxim make all GPU documentation public. T.I. will sell single piece quantities through Digi-Key, Maxim is 100 piece minimum. But they both require a very expensive development board to get started (if you want to start with proven hardware).

The Pi would be an excellent development board if the GPU documentation were public. What I want is a way to get high bandwidth video into the H.264 encoder input. And the only way to do that is from the CSI-2 connector and through the ISP. JamesH tells me there is no simple “ISP bypass” function if your video is already tuned. So Broadcom would need to create a “flat tuned” ISP driver and JamesH tells me that is as much work as tuning the ISP for a specific CCD. And even with “tuned” video, the ISP still has to do some “house keeping”, Big endian vs little endian, that kind of stuff. That’s why I suggested an add on HDMI to CSI-2 board, or even analog component to CSI-2 and a companion ISP driver to create a video input for the “bizarre”.

The Broadcom chip is designed to interface directly to a CCD, not to a “general purpose” video signal. If lots of people had replied to this thread all requesting some kind of video input for the bizarre, then the Foundation would make it a priority, but they haven’t. So don’t blame the “1%”, blame the bizarre.

Hardware_man
Actually that's not quite what I said, there is an ISP bypass, which is used for camera that have built in ISP's, and we have a basic driver for it (which would need modification as they do depend on the specific hardware). For HDMI in there is also work required in the framework, as in this case its the HDMI driving the system, rather than the system driving the camera, so that's more work, and the main problem is finding someone to do it. Not saying it won't get done though, just that's there a lot of work to do, and no-one to do it.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“My wife said to me `...you’re not even listening`.
I thought, that’s an odd way to start a conversation.."

GauVeldt
Posts: 24
Joined: Thu Mar 14, 2013 4:46 pm
Contact: Website

Re: Camera Interface Specs

Sat Mar 16, 2013 1:33 am

bernd71 wrote:
Hardware_man wrote:So don’t blame the “1%”, blame the bizarre.
Hardware_man
I'd say the discussion already got political despite my attempts not to.

Return to “Camera board”