Thread Subject: "Internet" cameras

I use the Image Aqu toolbox with standard webcams now.
Looking into buying a wireless camera to replace it but it
seems like these work a little differently. They have an
IP address on a local wireless network and you use your
webbrowser to view their images. They do not
have "driver software".

Can I use the image aquistion toolbox with these products?

Here is an example, but I am not married to this model.
http://www.dlink.com/products/?sec=0&pid=365

Joel wrote:
> I use the Image Aqu toolbox with standard webcams now.
> Looking into buying a wireless camera to replace it but it
> seems like these work a little differently. They have an
> IP address on a local wireless network and you use your
> webbrowser to view their images. They do not
> have "driver software".
>
> Can I use the image aquistion toolbox with these products?
>
> Here is an example, but I am not married to this model.
> http://www.dlink.com/products/?sec=0&pid=365

Hi Joel,

Currently we do not support these types of cameras because they are only
usable through a web browser.

Mark

In article <46C5A649.2000705@mathworks.com>,
Mark Jones <mark.jones@mathworks.com> wrote:
>Joel wrote:
>> I use the Image Aqu toolbox with standard webcams now.
>> Looking into buying a wireless camera to replace it but it
>> seems like these work a little differently. They have an
>> IP address on a local wireless network and you use your
>> webbrowser to view their images.

>Currently we do not support these types of cameras because they are only
>usable through a web browser.

Perhaps urlread() could be used?
--
  There are some ideas so wrong that only a very intelligent person
  could believe in them. -- George Orwell

roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote in
message <fa4qh4$hli$1@canopus.cc.umanitoba.ca>...
> In article <46C5A649.2000705@mathworks.com>,
> Mark Jones <mark.jones@mathworks.com> wrote:
> >Joel wrote:
> >> I use the Image Aqu toolbox with standard webcams now.
> >> Looking into buying a wireless camera to replace it but it
> >> seems like these work a little differently. They have an
> >> IP address on a local wireless network and you use your
> >> webbrowser to view their images.
>
> >Currently we do not support these types of cameras
because they are only
> >usable through a web browser.
>
> Perhaps urlread() could be used?

I'm working on this right now. If your web cam is not
password protected, this should be easy. For example, I
have a TrendNet IP-100W camera that doesn't require a
password. I can load its video into Matlab with the single
command:

img = imread ('http://192.168.0.100/image.jpg') ;

The camera server stores the current frame in a file called
"image.jpg". Your camera might be different. Just connect
to it from a browesr and then view the page source - it
should be in there.

My problem is getting Matlab to do the WWW authentication
properly. The TrendNet cameras use Basic authentication. I
can easily do the Base 64 encode of the user name and the
password. Unfortunately, for me this ends with an "=" sign.
 For some reason, Matlab insists on writing this out on the
wire as "%3D" (ie. the 3 separate bytes 25 33 44) instead of
the single byte 3D (which is hex for "="). The camera then
gives me a password error.

Here's my code:

opt{1} = {'Authentication: Basic'}
opt{2} = {base64encode ('username:password')}
urlread ('http://192.168.0.101', 'POST', opt)

This is in R6 v.13 on a PC with XP if that matters.

I'm stuck. How can I get urlread to write "=" out as one
byte, 3D? Any help would be appreciated. Thanks!

I took a quick look at URLREAD. In R2007a, line 85 looks
like this:

  value = char(java.net.URLEncoder.encode(params{i+1}))

I think this is where your "=" is becoming "%3D". This is
because these values are being passed as part of a form
submit, and not a header.

I think these threads will get you pointed in the right
direction:

http://www.mathworks.com/matlabcentral/newsreader/view_thread/81924
http://www.mathworks.com/matlabcentral/newsreader/view_thread/85012
http://www.mathworks.com/matlabcentral/newsreader/view_thread/52859

"Matthew Simoneau" <matthew@mathworks.com> wrote in message
<fai2os$5pa$1@fred.mathworks.com>...
> I took a quick look at URLREAD. In R2007a, line 85 looks
> like this:
>
> value = char(java.net.URLEncoder.encode(params{i+1}))
>
> I think this is where your "=" is becoming "%3D". This is
> because these values are being passed as part of a form
> submit, and not a header.

Thanks very much, Matthew! We're halfway there. Your
analysis of the byte problem was correct. I modified
urlread by adding a urlConnection.setRequestProperty line
after the urlConnection = url.openConnection;. Now the
username:password combination gets written out properly and
it looks like the camera server accepts that.

Unfortunately, I still can't read my image. What's odd is
that, looking at the byte stream using Ethereal, it seems
like the camera is actually sending the requested image (I
see a TCP packet on the wire containing the string "Content
type: image/jpg", followed by lots of imagy-looking bytes)

But from this: imread ('http://192.168.0.103/image.jpg')
I get this:
??? Error using ==> imread
Unable to determine the file format.

If I say: urlread ('http://192.168.0.103/image.jpg')

I get

ans = yØÿâ

The imread does work just fine with a different camera (same
model) that doesn't require authentication.

I'm guessing that urlread isn't picking up the camera server
reply properly. Or maybe there's some funniness in imread??
 I'm going to work on this some more. In the meantime, if
anyone else has any ideas, I'd love to hear them. Thanks
for the help so far!

OK, duh. I guess it helps to read the documentation. Right
at the start of urlread, it plainly says "If the server
returns binary data, the string will contain garbage." And
my camera is indeed returning my image, image.jpg, as binary
data.

So I guess my question now simply boils down to: how do I
read binary data from a server?

Success! Turns out that urlread won't read binary data but
urlwrite will, and in fact imread calls urlwrite. So I just
applied the above authentication mod to urlwrite instead of
urlread. I can now read frames from my password-protected
Trendnet web cam. Code:

cam103 = imreadauth ('http://192.168.0.103/image.jpg') ;

"imreadauth" simply calls my modified version of urlwrite.

Note that a lot of other popular web cams (eg. D-Link) use
the same protocols, so this solution should work for them too.

In retrospect, I found the taxonomy of urlread/urlwrite
confusing. You've got urlread which reads urls as you might
expect. But urlwrite does not write urls - it just also
reads them and then saves them to a file. I submit that all
of this would be clearer and simpler if there was only one
function, urlread, with an optional file argument to save
the data to a file. Either that or let urlread work with
binary data the same way that urlwrite does. Right now, the
two functions seem to be slightly at odds with one another.