| |
In article <001501c6d613$4aece680$060ba8c0@dickdesktop>, Dick Swan
<dickswan@sbcglobal.net> writes
>
> Anyone know if user applications (Java?) running on a camera phone have
> access to a recent frame buffer from the on-board camera?
There are quite a number of different software platforms, versions and
variants for 'feature phones' and 'smart' phones. For Java a lot of
APIs are optional, to varying degrees and have different versions.
These may even change with firmware version.
Most application environment have APIs to take pictures, (usually as
JPEG or PNG). Also to take short videos.
For a phone with Java you want to find out if it supports MIDP, (Mobile
Information Device profile), and what version. And if it is MIDP 2.0 or
later whether it supports the Media API or Mobile Media API, (MMAPI) or
on some older phones a manufacturer specific API for the camera.
The Java capabilities of the Sony Ericsson Z530I, that Anders mentioned,
are described here:
http://developer.sonyericsson.com/site/global/products/phonegallery/z530/p_z530.jsp
Whilst it does list the phone as supporting MMAPI I would suggest a
device with a larger screen would be more comfortable to program.
The Sony Ericsson developer home page is here:
http://developer.sonyericsson.com/site/global/home/p_home.jsp
- Tony
--
The NXT Step blog discusses the Lego Mindstorms NXT:
http://thenxtstep.blogspot.com/
|
|
| |
Topic was formerly named "Gnah I'm afraid I've discovered a new bug".
I've put a more relevant subject on it. This is in response to a reply
from Tony Naggs.
This is a good answer but not to the question I wanted answered. The
currently available cameras (CMUCAM, AVRCAM) for hobby robots are
"smart" cameras.
The robot tells the camera what color(s) to look for and the camera
analyses the video image (say 10 frames per second or higher) to report
back to the robot the bounding rectangles of color blobs that matched
the defined colors. The value of this approach is that it minimizes CPU
overhead and I/O bandwidth on the NXT -- it's simply exchanging 10 to 20
bytes every 100 msec vs a constant video stream.
So my question is multi-part.
It would be nice to use an existing camera phone for this application
instead of buying a CMUCAM/AVRCAM ($100 - $200 each). So my question was
really related to this specific application.
1. Can a user's JAVE program running in the camera phone gain
access to a video frame buffer and do the blob recognition? The
application needs access to a "raw" video image and not a JPEG or
other compressed file.
2. Is there enough CPU horsepower in the camera phone for this
application? An AVRCAM is a 20Mhz 8-bit AVR with 384 bytes
of RAM so I figured a camera phone should have enough cycles.
3. Can the JAVA gain fast enough access to process 10 frames per
second?
4. Does the JAVA gain access to the video frame in RAM in real
time?
5. Can you find an easy want to message (BT?) between the camera
phone and the NXT?
|
|
| |
In article <003701c6d6bc$fe18c630$060ba8c0@dickdesktop>, Dick Swan
<dickswan@sbcglobal.net> writes
>
> Topic was formerly named "Gnah I'm afraid I've discovered a new bug".
> I've put a more relevant subject on it. This is in response to a reply
> from Tony Naggs.
>
> This is a good answer
Okay.
> but not to the question I wanted answered.
I was lacking context, and I think you are looking for a simple answer
that is not yet available.
> The
> currently available cameras (CMUCAM, AVRCAM) for hobby robots are
> "smart" cameras.
>
> The robot tells the camera what color(s) to look for and the camera
> analyses the video image (say 10 frames per second or higher) to report
> back to the robot the bounding rectangles of color blobs that matched
> the defined colors.
Interesting, I have not met any of this before.
> The value of this approach is that it minimizes CPU
> overhead and I/O bandwidth on the NXT -- it's simply exchanging 10 to 20
> bytes every 100 msec vs a constant video stream.
>
> So my question is multi-part.
I shall try to work my way through it.
> It would be nice to use an existing camera phone for this application
> instead of buying a CMUCAM/AVRCAM ($100 - $200 each). So my question was
> really related to this specific application.
>
> 1. Can a user's JAVE program running in the camera phone gain
> access to a video frame buffer and do the blob recognition? The
> application needs access to a "raw" video image and not a JPEG or
> other compressed file.
From a very quick web survey I think that most camera phones with Java
will support picture capture. (Given that the phone is less than 2
years old and comes from a well known brand; Nokia, Motorola, Sony
Ericsson, ...)
> 2. Is there enough CPU horsepower in the camera phone for this
> application? An AVRCAM is a 20Mhz 8-bit AVR with 384 bytes
> of RAM so I figured a camera phone should have enough cycles.
Camera phones often have an ARMv4 core, possibly running up to +/-200
MHz. (Or even +/-400 MHz for the MHz hungry Windows platforms.)
There should at least be plenty of power. :-)
> 3. Can the JAVA gain fast enough access to process 10 frames per
> second?
This needs an experiment, and comparison of different devices.
(I am doubtful that many camera phones will have this performance.)
> 4. Does the JAVA gain access to the video frame in RAM in real
> time?
I have not yet used Java on a phone, (soon I hope!), the apparent
capability is to active the camera with the view on screen. Then when
the program wishes it asks for a 'snapshot'. I am not clear whether
these can be taken sufficiently often for your purpose.
The snapshot will be in a standard format, PNG or JPEG seem most
popular. Though often quite small, e.g. 160 x 120 pixels.
Supported formats are different on each device, and may reflect the
underlying camera hardware as much as the manufacturer's preferences.
The applications targeted by these functions seem to be simple camera
apps. These an interesting, brief introductory article here:
http://developers.sun.com/techtopics/mobility/midp/articles/picture/
> 5. Can you find an easy want to message (BT?) between the camera
> phone and the NXT?
If the phone allows applications to use the camera most likely then can
use the Bluetooth too. It looks to be fairly easy to write a library
that opens a Bluetooth connection to a NXT as a serial port, and to then
exchange the message in the NXT Hardware Developer Kit. (It is on my
'to do' list.)
A native application on something like a recent Nokia 'series 60' phone
will probably do better. However these phones are much more expensive
than a basic camera phone, unless your carrier/service operator has big
subsidies.
Cheers,
Tony
--
The NXT Step blog discusses the Lego Mindstorms NXT:
http://thenxtstep.blogspot.com/
|
|
|
