Camera I/F's

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I hacked together my "IP cameras" using some web cams for which I was
able to track down some FOSS i/f implementation documentation.  This
was OK for a proof of concept.  But, I now have to settle on "production"
hardware.

There seem to be a variety of i/f's for cameras:
- RS170 (requires hardware to digitize the signal; inflexible)
- parallel (video is digized, just needs to be captured at pixel rate)
- USB (digitized but packed in proprietary transport protocols over USB)
- CSI (digitized with specialty hardware required in host)
- IP (digitized but packed in protocols over IP)

The USB option is the easiest from the host's *hardware* point of view.
But, seems to limit the devices that could be supported as camera
vendors are loathe to publish details that only *their* driver implementers
should need.

RS170 is... "passe"

Parallel requires lots of signals to/from the host/camera.

CSI seems to be primarily supported on hosts intended to address the
mobile market.

As USB is essentially "free" (hardware-wise), adding support for it as
an *alternative* interface seems prudent.

Relying on CSI seems like it will restrict my choice of processor(s)
going forward (I'd like to standardize on *a* host platform and not
have to support a variety) -- though that's where the volume lies
(think camera in cell phones).  OTOH, it may make getting components
difficult (small fish, etc.)

IP seems to have more costs than USB with little/no gain.

Anyone been down this road who can share experiences?  Probably
only looking at 10K/yr...

Re: Camera I/F's
On 08.7.2017 ?. 21:05, Don Y wrote:
Quoted text here. Click to load it

The obvious choice would be the MIPI cameras - like in every phone.
A few years ago I looked into that; I found out they (MIPI) had some
special (politburo) membership fee if you were a "small enterprise",
"small" meant if you had < $100M annual revenue IIRC...

It is getting all but impossible to be a small maker of tech gadgets,
everything is becoming accessible only for politburo members.

Dimiter

  ======================================================
  Dimiter Popoff, TGI             http://www.tgi-sci.com
  ======================================================
  http://www.flickr.com/photos/didi_tgi/






Re: Camera I/F's
Hi Dimiter,

[Still 40+C every day.  18 consecutive days with a high temperature
above 40C.  Those huge icicles sure would be nice right about now!  :> ]

On 7/8/2017 11:30 AM, Dimiter_Popoff wrote:
Quoted text here. Click to load it

Yes, MIPI being the backers of the CSI approach.  Its great appeal
is so few conductors to the camera and megapixel support!

Quoted text here. Click to load it

I'd be more worried about actually getting *parts* than "specs"
(which is what the "membership fee" provides).  There's a point
(sales volume) below which folks addressing markets with HUGE
customers simply don't want to be bothered.

Or, you worry about the part being "on allocation", etc.

Quoted text here. Click to load it

Its been that way for a long time.  *Timely* access being the issue
(you can easily buy parts that have "lost their shine").

I think a prudent course will be to start gutting existing products
just to see what other manufacturers have "decided" (by way of their
designs) is the best way forward.

Re: Camera I/F's
On 08.7.2017 ?. 23:41, Don Y wrote:
Quoted text here. Click to load it

We had 2-3 hot days (up to 38C) and then a cold wave came, now we are
below 30. Pretty good during the day but the nights get below 20C,
pretty unusual for July here. All that with the very long winter we had,
average annual temperatures will likely be way below the norm.

Quoted text here. Click to load it

I don't see how I can get to these worries. The CSI specification is
"members only".
Then this market is so huge there will always be some stock unless
you are after the latest versions. Or if you want to go into the
volumes of say Samsung but in this case you'd have allocation
issues whatever type you go for, probably worse than with mipi.

Dimiter


Re: Camera I/F's
Quoted text here. Click to load it

Our *nights* just barely fall below 30C.  Average 24 hour temperature
is often 30C+.  Rains will start (hopefully) soon to moderate these
temperatures a bit (maybe 5-7C) -- at the expense of humidity.

Quoted text here. Click to load it


Yes.  But paying for membership can be a one-time thing (to access
specs).  Or, accessed by "other means"...  :>

Quoted text here. Click to load it

It's often an issue of finding someone willing to *talk* to you
for orders that are considered "tiny".  You'd be dealing
direct with the manufacturer so wouldn't really have any leverage
with a local disti (you might be a "big customer" to a local disti
but small-fry to the manufacturer).

Dunno.  It's always a crap shoot trying to guess where the *practical*
market is headed so you don't design in the "right" device for the
application only to discover its the *wrong* device for the "product".

Re: Camera I/F's
On Sat, 08 Jul 2017 11:05:26 -0700, Don Y wrote:

Quoted text here. Click to load it

I've been looking for a 2MP 30fps solution.  For 10K units the China
guys will probably give you a deal and customize if you want to go
that way.
Alibaba as a boat load of pages of people making IP cameras based on the
HiSilicon Hi3516C chip and different image sensors.

Lot of options for the CSI route.  Cypress has a CSI->USB chip.
A PI zero for 10 bucks and a camera is also a easy way to get to USB
A PI zero and a USB->Enet will get you a IP camera.  A PI 3 and a
camera will get you a netcam but at that price you might as well just
buy a IP camera.

TI has a CSI-2 FPD-Link III Serializer which I really need but it's
still showing pre-production.  With that you could plug a CSI camera
in one end, use a twisted pair and get CSI or LVDS out the other end
with one of their deserializers.

Finally there are several articles about interfacing the CSI physical
layer to a FPGA and some open source VHDL to deal with the
link interface.  I'd really like to shove the CSI,H.264 and Ethernet
in a FPGA.  But the price of the PI Zero starts eating your lunch.  
I need something smaller but might have to live with it for now.

Price wise it seems the PI zero and a camera module is the least
expensive.  I got one of the China IP camera modules and it sucked.
Ran REAL HOT.  Severe video lag when moving the camera.
Interesting if you telnet to the unit the prompt is
"ak47 login:"

--  
Chisolm
Republic of Texas


Re: Camera I/F's
Hi Joe,

On 7/8/2017 3:06 PM, Joe Chisolm wrote:
Quoted text here. Click to load it


But, they're likely to customize a *camera*, not "my application"
(camera is just one of many "peripherals" in this device).

Quoted text here. Click to load it

That would, essentially, be the "buy a custom camera PRODUCT" -- typ
USB I/O.  I'd still talk to it as a USB peripheral (the 3516 would
be a bad match for the other needs that I have; it's deigned with
"I'm a camera" in mind)

Quoted text here. Click to load it

Yes, its easy to QUICKLY end up at the "high level interface" approach
to the "camera component".

Quoted text here. Click to load it

In my case, the twisted pair would just be a few inches long.  But, the
"camera conditioning" (SERDES) would necessitate making the "camera PCB"
larger (than just the bare sensor with *its* I/O connections).

Quoted text here. Click to load it

In my case, I want the "local processor" to actually *deal* with the
imagery, not just pull it off the camera, encode and encrypt it for
"remote handling".  And, the needs of one camera instance will be
different than others (e.g., surveilling outdoor areas is different
than recognizing faces).  So, choice of camera sensor as well as
code behind it will vary from one "camera" to the next.

Quoted text here. Click to load it

I'd like to be able to trade dollars for performance (as above).
But, don't want to have to design different "host hardware"
for each possible "video price/performance point".

It seems like USB is the "safe" bet in that I can always play
"big customer" by approaching a COTS camera supplier with a
big buy and a request for protocol details (under NDA).  Then,
just worry about a four conductor cable traveling to the
"sensor".

The downside is there is a lot of overhead in the USB stack.
So, maybe prune it down to something that KNOWS the camera
is its only peripheral?


Re: Camera I/F's
says...
Quoted text here. Click to load it

My problem is without knowing what type of data flow (what will happen  
to the viideo still or stream), rates you are requiring and for how many  
sources it is difficult to suggest anything.

If you want an I/F to take almost any resolution from multiple cameras
to then do something with, even as HDMI or LVDS then you could look at

Averlogic AL360 and AL361 devices, all relatively new and they send  
samples around the world.

See

    http://www.averlogic.com/AL362.asp

and

    http://www.averlogic.com/AL361.asp

Inthe past I have used various devices from people like Conexant when I  
was building something with my own sensors and lenses. Aptina can be  
easier to get small supplies of sensors than others.

--  
Paul Carpenter          | snipped-for-privacy@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/ PC Services
We've slightly trimmed the long signature. Click to see the full one.
Re: Camera I/F's
On 7/9/2017 3:58 AM, Paul wrote:
Quoted text here. Click to load it

*One* camera paired to *one* processor.  The demands made of the camera
can vary, though -- and the processor does other things besides just
conditioning video for delivery to a "remote".

In some cases, I might want high frame rates at the expense of detail.
In other cases, the exact opposite.  Most of the frames may get discarded
to concentrate on "areas of interest" -- based on an analysis of the
*entire* frame (at a slower rate).

I use cameras to access a variety of "field conditions" that are otherwise
hard to instrument.  Tweaking the software or optics (or even the choice
of image sensor) is easier than having to move to a different processor
(family) to meet a different application.

Quoted text here. Click to load it

<frown>  First glance looks like intended for a different market.  I'll
have to spend some more time looking at them, though.  Thanks!

Quoted text here. Click to load it

I recall an 8 camera RS170 interface that they made some years ago.
But, I think that's an obsolescent (if not already obsolete!) path
for designs going forward.

There (currently) seems to be a disconnect between the consumer
(video/surveillance) camera market and the "cell phone" camera
market.  Will this persist?  Or, will we start seeing 4MP (and higher)
as the new normal for consumer camera kit of all types?  (i.e.,
because the cell phone volumes end up driving ALL sensor production)

Re: Camera I/F's
Quoted text here. Click to load it

One thing worth pointing out is that talking to a camera in CSI or other
native format gives you essentially unprocessed RAW data.  On a smartphone
the ISP processor does (quite a lot of) image processing to turn the
pixels into an acceptable JPEG image.  This includes all of the vendor
tricks like dual cameras, HDR, white balance, etc.

If you just want JPEGs you can slap down a network connection, you might
want a chip that does all the image processing for you, which is what you
get in USB/etc land.  If you want to attach to a raw sensor then be prepared
to budget for some compute (and software) to tidy up the images for you.

Theo

Re: Camera I/F's
theom+ snipped-for-privacy@chiark.greenend.org.uk says...
Quoted text here. Click to load it

People like Connexant, Averlogic and others do chips for converting  
stills or streams into JPEG, H.264, MPEG 2 or 4..

Makes the processing requirements in the camera a LOT less

--  
Paul Carpenter          | snipped-for-privacy@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/ PC Services
We've slightly trimmed the long signature. Click to see the full one.
Re: Camera I/F's
Quoted text here. Click to load it

It depends what you want the images for.  For example, here's the cropped
RAW output of a Raspberry Pi CSI camera against the processed output:
https://www.pic-upload.de/view-30656067/2016-05-15-RAW-vs-Processed.jpg.html

To produce the image on the right you have to do various noise filtering and
colour compensation.  If this is video you have to do it on every frame.  
Less than JPEG, but not insignificant.

Theo

Re: Camera I/F's
Hi Theo,

On 7/10/2017 2:09 AM, Theo Markettos wrote:
Quoted text here. Click to load it

Yes.  But, if you are doing anything beyond just shipping that video
to a remote location, then you typically *want* access to the raw
video.  And, often don't care about color purity, etc.

E.g., if you are looking for signs of *motion* in an image, you want to
be able to apply a mask to the raw image and then look for changes in
the selected portions of the image.  If the image has been compressed,
this is harder to do in the general case.

Likewise, doing facial feature extraction/recognition, you don't really care
if the flesh-tones are way off hue (e.g., greenish) as you're really looking
for shapes, sizes and relative placements of those "features".  Again,
harder to do with a JPEG than with the raw pixels from which it was
distilled.

In each of these cases, you might conditionally (or unconditionally) *ALSO*
prepare a compressed data stream (to reduce transport/storage costs) to ship
off to be recorded or post-processed elsewhere.

Quoted text here. Click to load it


Site Timeline