Motherboard Forums


Reply
Thread Tools Display Modes

Tablet/phone cameras

 
 
Don Y
Guest
Posts: n/a
 
      06-16-2011, 02:54 PM
Hi,

I currently have a kiosk application that I would like
to port to a wireless, *portable* implementation. So,
small tablets or (ack!) smart-phones (with the phone
functionality permanently and irreparably disabled)
seem a good choice. Phones being better suited in
terms of size (want to tuck this into a shirt-pocket
while not in use).

But, I rely extensively on barcodes to provide data to
the application (item identification, location identification,
etc.).

Since (some) cell phones currently have QR code capabilities,
I figure adding that to a camera-equipped tablet (or phone)
is a potential solution.

Before I get myself "pregnant" on a solution path, I need
to get a handle on what's "realistic" in terms of expectations.

[I don't *use* cell phones so my ignorance here requires
patience :> ]

I know (some) cameras have motion video capabilities. From
that, I can (?) deduce that the optics and electronics in
the camera are "fast enough" that images can be captured
at "several" frames per second.

- does this effectively render the "phone" useless for
other tasks (i.e., how CPU intensive is this task, how
clumsy is the interface to the camera output, etc.)?

- is this occurring at the same resolution as still pictures?
or, is the camera degraded to a lower "movie mode"?

The phones that I have played with require the camera to
be explicitly "activated" (no doubt because the typical user
doesn't want the camera on all the time -- privacy? performance?
battery life??).

- does the use of the camera (in movie mode) eat batteries?

- is there some *other* significant start-up/run cost that
is associated with the camera functionality?

- does the *camera* drive the interface or does the application?
By that, I mean, do you say, "go into movie mode" and then sit
back and wait for the camera to deliver frames at whatever rate
*it* wants? Or, do you say, "give me a frame, *now* (note that
in this latter case, you could effectively run the video at
2 FPS, 3 FPS, 12 FPS, etc. -- as appropriate to your application)

What I would *like* to do is leave the camera on continuously and
have my barcode recognizer/decoder processing images as fast as
feasible. So, instead of the user having to explicitly enable
the camera, point it at the targeted barcode label and *then*
take a "capture barcode" snapshot, the application can hunt
for suitable labels itself and use them as appropriate.

Since the recognizer can be a resource pig, you would want to
be able to control the rate at which it processes images. I.e.,
"take a picture, process it, twiddle thumbs so other parts
of the application can run, lather, rinse, repeat".

Are there any other issues that could eat my lunch that I
haven't considered?

Finally, any pointers for *hackable* camera tablets/phones?
(of course, they need to have some form of WiFi capability)

Thx,
--don
 
Reply With Quote
 
 
 
 
Boudewijn Dijkstra
Guest
Posts: n/a
 
      06-16-2011, 05:11 PM
Op Thu, 16 Jun 2011 16:54:47 +0200 schreef Don Y <(E-Mail Removed)>:
> Hi,
>
> I currently have a kiosk application that I would like
> to port to a wireless, *portable* implementation. So,
> small tablets or (ack!) smart-phones (with the phone
> functionality permanently and irreparably disabled)
> seem a good choice. Phones being better suited in
> terms of size (want to tuck this into a shirt-pocket
> while not in use).
>
> But, I rely extensively on barcodes to provide data to
> the application (item identification, location identification,
> etc.).
>
> Since (some) cell phones currently have QR code capabilities,
> I figure adding that to a camera-equipped tablet (or phone)
> is a potential solution.


Do be wary of the fact that there are two different kind of lenses used in
camera phones:
* "narrow focus": a focus light is used to determine the appropriate
position of the lens
* "wide/fixed focus": no moving parts or focus light needed

Wide focus is used in cheap forward-facing lenses (for capturing your
surroundings), fixed focus is used in cheap backward-facing lenses (for
capturing yourself).

> Before I get myself "pregnant" on a solution path, I need
> to get a handle on what's "realistic" in terms of expectations.
>
> [I don't *use* cell phones so my ignorance here requires
> patience :> ]
>
> I know (some) cameras have motion video capabilities. From
> that, I can (?) deduce that the optics and electronics in
> the camera are "fast enough" that images can be captured
> at "several" frames per second.


All phone camera's I've seen are fast enough to show captured images on
the main LCD at several frames per second. Compressing and storing the
data somewhere is a different matter.

> - does this effectively render the "phone" useless for
> other tasks (i.e., how CPU intensive is this task, how
> clumsy is the interface to the camera output, etc.)?


Without knowing the answer for any specific phone, I will go out on a limb
and say: it depends.

> - is this occurring at the same resolution as still pictures?
> or, is the camera degraded to a lower "movie mode"?


For my phone, movie mode is lower quality for a few reasons:
1. data has to be compressed on-the-fly (with a video codec!)
2. compressed data has to be stored on a slow SD card
3. in lower quality, it doesn't matter whether the focus is exactly right
4. audio is also captured, compressed and stored

> The phones that I have played with require the camera to
> be explicitly "activated" (no doubt because the typical user
> doesn't want the camera on all the time -- privacy? performance?
> battery life??).
>
> - does the use of the camera (in movie mode) eat batteries?


Taking a picture is more than just grabbing a frame of data from the CCD,
but also:
* adjusting light sensitivity of the CCD (which might take many frames)
* focussing the lens (which might take many frames)
And in the 'default' setting also:
* deciding whether to use the flash

> - is there some *other* significant start-up/run cost that
> is associated with the camera functionality?


* loading the software that controls the camera (including any "cool
effects" that might be provided in real-time, like sepia, negative,
solarise, etc.)
* charging the flash capacitor

> - does the *camera* drive the interface or does the application?
> By that, I mean, do you say, "go into movie mode" and then sit
> back and wait for the camera to deliver frames at whatever rate
> *it* wants? Or, do you say, "give me a frame, *now* (note that
> in this latter case, you could effectively run the video at
> 2 FPS, 3 FPS, 12 FPS, etc. -- as appropriate to your application)


Since at the very least, light sensitivity adjustment will need to be made
at a certain rate, frames will probably be grabbed at a fixed rate when
the camera is active. I guess it is the choice of the application to skip
as many frames as it needs to.

> What I would *like* to do is leave the camera on continuously and
> have my barcode recognizer/decoder processing images as fast as
> feasible. So, instead of the user having to explicitly enable
> the camera, point it at the targeted barcode label and *then*
> take a "capture barcode" snapshot, the application can hunt
> for suitable labels itself and use them as appropriate.


Can you say "battery life" ? What if I'm sleeping? What if the phone is
in my pocket?
Also, you may not even have complete control over that; my camera phone
has a sliding lens cap that triggers camera mode.

> Since the recognizer can be a resource pig, you would want to
> be able to control the rate at which it processes images. I.e.,
> "take a picture, process it, twiddle thumbs so other parts
> of the application can run, lather, rinse, repeat".


It would be a great advantage if the phone had an accelerometer. Then you
can grab more frames if the phone is held still while viewing a suitably
bright object.

> Are there any other issues that could eat my lunch that I
> haven't considered?
>
> Finally, any pointers for *hackable* camera tablets/phones?
> (of course, they need to have some form of WiFi capability)
>
> Thx,
> --don



--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
(Remove the obvious prefix to reply privately.)
 
Reply With Quote
 
 
 
 
linnix
Guest
Posts: n/a
 
      06-16-2011, 06:11 PM
On Jun 16, 10:11*am, "Boudewijn Dijkstra"
<(E-Mail Removed)> wrote:
> Op Thu, 16 Jun 2011 16:54:47 +0200 schreef Don Y <(E-Mail Removed)>:


My comments are mostly for Android camera phones (i.e. LG VS740).

> > Hi,

>
> > I currently have a kiosk application that I would like
> > to port to a wireless, *portable* implementation. *So,
> > small tablets or (ack!) smart-phones (with the phone
> > functionality permanently and irreparably disabled)
> > seem a good choice. *Phones being better suited in
> > terms of size (want to tuck this into a shirt-pocket
> > while not in use).

>
> > But, I rely extensively on barcodes to provide data to
> > the application (item identification, location identification,
> > etc.).


Phones cameras are more geared for 2D barcodes, but i guess old
fashion barcodes are workable.

>
> > Since (some) cell phones currently have QR code capabilities,
> > I figure adding that to a camera-equipped tablet (or phone)
> > is a potential solution.

>
> Do be wary of the fact that there are two different kind of lenses used in *
> camera phones:
> * "narrow focus": a focus light is used to determine the appropriate *
> position of the lens
> * "wide/fixed focus": no moving parts or focus light needed
>
> Wide focus is used in cheap forward-facing lenses (for capturing your *
> surroundings), fixed focus is used in cheap backward-facing lenses (for *
> capturing yourself).


My phone has only auto focused forward-facing lens.

>
> > Before I get myself "pregnant" on a solution path, I need
> > to get a handle on what's "realistic" in terms of expectations.

>
> > [I don't *use* cell phones so my ignorance here requires
> > patience *:> ]

>
> > I know (some) cameras have motion video capabilities. *From
> > that, I can (?) deduce that the optics and electronics in
> > the camera are "fast enough" that images can be captured
> > at "several" frames per second.

>


Motion video are captured and processed in SDRAM (256M in my case)
first. Single hi-res (upto 2000x1500) takes couple of seconds. The
jpeg file can be several megabytes compressed.

> All phone camera's I've seen are fast enough to show captured images on *
> the main LCD at several frames per second. *Compressing and storing the*
> data somewhere is a different matter.
>
> > - does this effectively render the "phone" useless for
> > other tasks (i.e., how CPU intensive is this task, how
> > clumsy is the interface to the camera output, etc.)?


You can always write your custom camera app: Java for Android.

>
> Without knowing the answer for any specific phone, I will go out on a limb *
> and say: it depends.
>
> > - is this occurring at the same resolution as still pictures?
> > or, is the camera degraded to a lower "movie mode"?

>
> For my phone, movie mode is lower quality for a few reasons:
> 1. data has to be compressed on-the-fly (with a video codec!)
> 2. compressed data has to be stored on a slow SD card
> 3. in lower quality, it doesn't matter whether the focus is exactly right
> 4. audio is also captured, compressed and stored
>
> > The phones that I have played with require the camera to
> > be explicitly "activated" (no doubt because the typical user
> > doesn't want the camera on all the time -- privacy? performance?
> > battery life??).

>
> > - does the use of the camera (in movie mode) eat batteries?


Yes, you have to keep charging it.

>
> Taking a picture is more than just grabbing a frame of data from the CCD,*
> but also:
> * adjusting light sensitivity of the CCD (which might take many frames)
> * focussing the lens (which might take many frames)
> And in the 'default' setting also:
> * deciding whether to use the flash
>
> > - is there some *other* significant start-up/run cost that
> > is associated with the camera functionality

>
> * loading the software that controls the camera (including any "cool *
> effects" that might be provided in real-time, like sepia, negative, *
> solarise, etc.)
> * charging the flash capacitor
>
> > - does the *camera* drive the interface or does the application?
> > By that, I mean, do you say, "go into movie mode" and then sit
> > back and wait for the camera to deliver frames at whatever rate
> > *it* wants? *Or, do you say, "give me a frame, *now* (note that
> > in this latter case, you could effectively run the video at
> > 2 FPS, 3 FPS, 12 FPS, etc. -- as appropriate to your application)

>


Build-in app only do single shot or video (fixed 15 FPS, i believed).
Of course, you can write your custom apps.

> Since at the very least, light sensitivity adjustment will need to be made *
> at a certain rate, frames will probably be grabbed at a fixed rate when *
> the camera is active. *I guess it is the choice of the application to skip *
> as many frames as it needs to.
>
> > What I would *like* to do is leave the camera on continuously and
> > have my barcode recognizer/decoder processing images as fast as
> > feasible. *So, instead of the user having to explicitly enable
> > the camera, point it at the targeted barcode label and *then*
> > take a "capture barcode" snapshot, the application can hunt
> > for suitable labels itself and use them as appropriate.

>


You will have to write your custom apps.

> Can you say "battery life" ? *What if I'm sleeping? *What if the phone is *
> in my pocket?
> Also, you may not even have complete control over that; my camera phone *
> has a sliding lens cap that triggers camera mode.
>
> > Since the recognizer can be a resource pig, you would want to
> > be able to control the rate at which it processes images. *I.e.,
> > "take a picture, process it, twiddle thumbs so other parts
> > of the application can run, lather, rinse, repeat".

>
> It would be a great advantage if the phone had an accelerometer. *Then you *
> can grab more frames if the phone is held still while viewing a suitably *
> bright object.
>
> > Are there any other issues that could eat my lunch that I
> > haven't considered?

>
> > Finally, any pointers for *hackable* camera tablets/phones?
> > (of course, they need to have some form of WiFi capability)


I would go for a rooted Android. Unfortunately, theVS740 is hard to
root.

>
> > Thx,
> > --don

>
> --
> Gemaakt met Opera's revolutionaire e-mailprogramma: *http://www.opera.com/mail/
> (Remove the obvious prefix to reply privately.)


 
Reply With Quote
 
Don Y
Guest
Posts: n/a
 
      06-16-2011, 06:25 PM
Hi Boudewijn,

On 6/16/2011 10:11 AM, Boudewijn Dijkstra wrote:
>> Since (some) cell phones currently have QR code capabilities,
>> I figure adding that to a camera-equipped tablet (or phone)
>> is a potential solution.

>
> Do be wary of the fact that there are two different kind of lenses used
> in camera phones:
> * "narrow focus": a focus light is used to determine the appropriate
> position of the lens
> * "wide/fixed focus": no moving parts or focus light needed
>
> Wide focus is used in cheap forward-facing lenses (for capturing your
> surroundings), fixed focus is used in cheap backward-facing lenses (for
> capturing yourself).


Gack! You've confused me.

OK, my understanding was that the *original* cameras in
phones (so far, we haven't talked about tablets) were on
the "back" of the phone. I.e., while viewing the screen
(the "main" screen -- since some phones have more than one),
you would be looking in the same direction that the camera
was "pointed". (so, the camera would be imaging what you see
*beyond* the phone as you look at the screen)

I guess this is what you call the "forward-facing" lens?

Some phones appear to have a little adjustment "lever" on
this lens (rotate it 90 degrees about the center of the
lens to cause ____________).

You mentioned narrow and wide/fixed. Then, went on to
describe wide and fixed. Are wide/fixed synonyms? In
which case, what about "narrow" (is this what would be
called "macro" on a digital camera?)

>> I know (some) cameras have motion video capabilities. From
>> that, I can (?) deduce that the optics and electronics in
>> the camera are "fast enough" that images can be captured
>> at "several" frames per second.

>
> All phone camera's I've seen are fast enough to show captured images on
> the main LCD at several frames per second. Compressing and storing the
> data somewhere is a different matter.


But, the display in most (?) phones seems to be lower quality
than the stated camera capabilities. Is this real-time display
deliberately discarding data? I.e., it exists solely to help
the user get an idea of what the camera is shooting? Like
a "preview" mode in a page scanner?

Does the application have to do anything to make this data
available to the display (i.e., is the application copying
data from camera to display or is there a special data path
that is enabled to make this happen "for free")

>> - does this effectively render the "phone" useless for
>> other tasks (i.e., how CPU intensive is this task, how
>> clumsy is the interface to the camera output, etc.)?

>
> Without knowing the answer for any specific phone, I will go out on a
> limb and say: it depends.


<grin>
<frown>

>> - is this occurring at the same resolution as still pictures?
>> or, is the camera degraded to a lower "movie mode"?

>
> For my phone, movie mode is lower quality for a few reasons:
> 1. data has to be compressed on-the-fly (with a video codec!)
> 2. compressed data has to be stored on a slow SD card
> 3. in lower quality, it doesn't matter whether the focus is exactly right
> 4. audio is also captured, compressed and stored


OK. None of those allow you to conclude that the phone is
incapable of *processing* data at that rate (i.e., and
discarding it)

>> The phones that I have played with require the camera to
>> be explicitly "activated" (no doubt because the typical user
>> doesn't want the camera on all the time -- privacy? performance?
>> battery life??).
>>
>> - does the use of the camera (in movie mode) eat batteries?

>
> Taking a picture is more than just grabbing a frame of data from the
> CCD, but also:
> * adjusting light sensitivity of the CCD (which might take many frames)
> * focussing the lens (which might take many frames)
> And in the 'default' setting also:
> * deciding whether to use the flash


It would be very "unfriendly" if the device had to keep taking flash
photos. So, I will assume there will be enough ambient light to
capture the images required.

Adjusting light sensitivity can be ongoing -- because the camera
is "on always". I guess this is the dimming/brightening effect
you tend to see when the camera is first "enabled".

Is the camera focused mechanically? What role does the application
software take in doing that? Does the application *know* when the
scene is "in focus" or do you rely on the user delaying "snapping"
the picture until the displayed image "looks good"?

>> - is there some *other* significant start-up/run cost that
>> is associated with the camera functionality?

>
> * loading the software that controls the camera (including any "cool
> effects" that might be provided in real-time, like sepia, negative,
> solarise, etc.)


So, the camera isn't just "turned on and off" but, rather, treated
as an application in its own right.

> * charging the flash capacitor
>
>> - does the *camera* drive the interface or does the application?
>> By that, I mean, do you say, "go into movie mode" and then sit
>> back and wait for the camera to deliver frames at whatever rate
>> *it* wants? Or, do you say, "give me a frame, *now* (note that
>> in this latter case, you could effectively run the video at
>> 2 FPS, 3 FPS, 12 FPS, etc. -- as appropriate to your application)

>
> Since at the very least, light sensitivity adjustment will need to be
> made at a certain rate, frames will probably be grabbed at a fixed rate


This suggests that the *camera* does this adjustment? Or, is it in
the "camera application"? I.e., do I have any control over it?

> when the camera is active. I guess it is the choice of the application
> to skip as many frames as it needs to.
>
>> What I would *like* to do is leave the camera on continuously and
>> have my barcode recognizer/decoder processing images as fast as
>> feasible. So, instead of the user having to explicitly enable
>> the camera, point it at the targeted barcode label and *then*
>> take a "capture barcode" snapshot, the application can hunt
>> for suitable labels itself and use them as appropriate.

>
> Can you say "battery life" ? What if I'm sleeping? What if the phone is
> in my pocket?


This will be used in an industrial setting. I.e., turned off
at the end of a shift. Possibly returned to a "charging base"
frequently during the day (if folks learn that it is prudent
to do so).

If its in your pocket, then it won't see anything (and will just
waste battery life).

Note that the application will obviously idle the "phone" (which
could be a tablet, recall) when it notices that it isn't being
actively used.

> Also, you may not even have complete control over that; my camera phone
> has a sliding lens cap that triggers camera mode.
>
>> Since the recognizer can be a resource pig, you would want to
>> be able to control the rate at which it processes images. I.e.,
>> "take a picture, process it, twiddle thumbs so other parts
>> of the application can run, lather, rinse, repeat".

>
> It would be a great advantage if the phone had an accelerometer. Then
> you can grab more frames if the phone is held still while viewing a
> suitably bright object.


Ah! That's an excellent idea! If the camera is "in motion",
then, chances are, the *image* won't be "in focus". And,
regardless, the user will not be "focussed" on a particular
barcoded object.

So, you could almost idle the camera -- just doing brightness
compensation and, possibly, some crude scene processing to
augment the accelerometer's idea of whether or not the
device is "moving".

Thanks! There's a fair bit to chew on...
 
Reply With Quote
 
Boudewijn Dijkstra
Guest
Posts: n/a
 
      06-17-2011, 08:26 AM
Op Thu, 16 Jun 2011 20:25:34 +0200 schreef Don Y <(E-Mail Removed)>:
> On 6/16/2011 10:11 AM, Boudewijn Dijkstra wrote:
>>> Since (some) cell phones currently have QR code capabilities,
>>> I figure adding that to a camera-equipped tablet (or phone)
>>> is a potential solution.

>>
>> Do be wary of the fact that there are two different kind of lenses used
>> in camera phones:
>> * "narrow focus": a focus light is used to determine the appropriate
>> position of the lens
>> * "wide/fixed focus": no moving parts or focus light needed
>>
>> Wide focus is used in cheap forward-facing lenses (for capturing your
>> surroundings), fixed focus is used in cheap backward-facing lenses (for
>> capturing yourself).

>
> Gack! You've confused me.


You expectorate a hairball when confused?

> OK, my understanding was that the *original* cameras in
> phones (so far, we haven't talked about tablets) were on
> the "back" of the phone. I.e., while viewing the screen
> (the "main" screen -- since some phones have more than one),
> you would be looking in the same direction that the camera
> was "pointed". (so, the camera would be imaging what you see
> *beyond* the phone as you look at the screen)
>
> I guess this is what you call the "forward-facing" lens?


Yes.

> Some phones appear to have a little adjustment "lever" on
> this lens (rotate it 90 degrees about the center of the
> lens to cause ____________).


Hmm, I didn't even think about hand-operated lenses.

> You mentioned narrow and wide/fixed. Then, went on to
> describe wide and fixed. Are wide/fixed synonyms? In
> which case, what about "narrow" (is this what would be
> called "macro" on a digital camera?)


No, wide and fixed are not synonyms. Wide focus means the image is sharp
over a wide range (like in a disposable camera), fixed focus means the
image is only sharp at a fixed distance. Analogously, narrow focus means
the image is sharp only in a narrow (but not fixed) distance range. IIRC
"macro" is for short distances only, and involves dynamic mechanical zoom
(which most phone cameras don't provide).

But, I was just trying to illustrate that some lenses need time (and
energy) to focus on the object of interest.

>>> I know (some) cameras have motion video capabilities. From
>>> that, I can (?) deduce that the optics and electronics in
>>> the camera are "fast enough" that images can be captured
>>> at "several" frames per second.

>>
>> All phone camera's I've seen are fast enough to show captured images on
>> the main LCD at several frames per second. Compressing and storing the
>> data somewhere is a different matter.

>
> But, the display in most (?) phones seems to be lower quality
> than the stated camera capabilities. Is this real-time display
> deliberately discarding data?


It has no choice but to create a scaled version of the image. What's
wrong with that?

> I.e., it exists solely to help
> the user get an idea of what the camera is shooting? Like
> a "preview" mode in a page scanner?


Yes.

> Does the application have to do anything to make this data
> available to the display (i.e., is the application copying
> data from camera to display or is there a special data path
> that is enabled to make this happen "for free")


Dunno.

>> Taking a picture is more than just grabbing a frame of data from the
>> CCD, but also:
>> * adjusting light sensitivity of the CCD (which might take many frames)
>> * focussing the lens (which might take many frames)
>> And in the 'default' setting also:
>> * deciding whether to use the flash

>
> It would be very "unfriendly" if the device had to keep taking flash
> photos. So, I will assume there will be enough ambient light to
> capture the images required.
>
> Adjusting light sensitivity can be ongoing -- because the camera
> is "on always". I guess this is the dimming/brightening effect
> you tend to see when the camera is first "enabled".


Yes.

> Is the camera focused mechanically?


Depends on the lens type, as mentioned above.

> What role does the application
> software take in doing that? Does the application *know* when the
> scene is "in focus" or do you rely on the user delaying "snapping"
> the picture until the displayed image "looks good"?


My phone camera has a "dual action" button like in regular cameras. Press
it softly and it will try to focus (which may fail), press it all the way
to capture the image. If you press it all the way directly, it will first
try to focus. The user is notified when the camera thinks that the image
is focused. But, it will only know after trying to focus. So it is an
interactive process.

>>> - is there some *other* significant start-up/run cost that
>>> is associated with the camera functionality?

>>
>> * loading the software that controls the camera (including any "cool
>> effects" that might be provided in real-time, like sepia, negative,
>> solarise, etc.)

>
> So, the camera isn't just "turned on and off" but, rather, treated
> as an application in its own right.


Yes. In order to conserve resources, I presume.

>>> - does the *camera* drive the interface or does the application?
>>> By that, I mean, do you say, "go into movie mode" and then sit
>>> back and wait for the camera to deliver frames at whatever rate
>>> *it* wants? Or, do you say, "give me a frame, *now* (note that
>>> in this latter case, you could effectively run the video at
>>> 2 FPS, 3 FPS, 12 FPS, etc. -- as appropriate to your application)

>>
>> Since at the very least, light sensitivity adjustment will need to be
>> made at a certain rate, frames will probably be grabbed at a fixed rate

>
> This suggests that the *camera* does this adjustment? Or, is it in
> the "camera application"? I.e., do I have any control over it?


Dunno. But why would you want to mess with it?



--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
(Remove the obvious prefix to reply.)
 
Reply With Quote
 
larwe
Guest
Posts: n/a
 
      06-17-2011, 01:42 PM
On Jun 16, 10:54*am, Don Y <(E-Mail Removed)> wrote:

> I know (some) cameras have motion video capabilities. *From
> that, I can (?) deduce that the optics and electronics in
> the camera are "fast enough" that images can be captured
> at "several" frames per second.


This is highly variable. To run off a few possibilities - some phones/
tablets have the camera on an internal USB interface. Some have the
image sensor connected directly to a dedicated port on the SoC (this
would almost always be the case for cameras). To acquire images, you
have to power up the sensor, enable a DMA channel (for the dedicated
camera port type solution), maybe instruct the GPU to set up an
overlay window to perform YUV->RGB conversion. Exposure and white
balance are typically adjusted on the fly by host-side software but
this is certainly not universally true, especially for the USB
solutions. The frame rate will typically be some divisor of 60Hz, for
some resolution which might be anything from 160x120 up to full HD
resolution depending on the camera. Some cameras, especially higher
resolution cameras, have mechanical autofocus.

Notice how I'm using words like "variable" "typical" etc. These
systems can range from a single-core 400MHz ARM9 to a dual-core 1.2GHz
Cortex with a separate DSP and/or other coprocessor(s), so there is
absolutely no one size fits all answer.

These sensors also typically require fairly long exposure times, so
simply waving the camera about won't acquire a good image - you need
to select a subject and hold the sensor still while acquiring the
image. Usually, the live-view mode is significantly lower resolution
than the sensor's actual max resolution.

> - does the use of the camera (in movie mode) eat batteries?


Sure, because you have powered up the sensor, moved the CPU core into
a higher power mode, possibly activated a separate DSP core to handle
MPEG compression, possibly powered up additional segments of the GPU
(if any) to handle the overlay window, increased RAM bandwidth usage,
forced the screen to remain on with 100% duty cycle, ... ... ...

> - does the *camera* drive the interface or does the application?


And for this you should start by looking at the APIs offered by the OS
in the device you intend to use, because life's too short for hacking
below the OS level in this case - especially if you want to insulate
yourself against supply chain changes.

 
Reply With Quote
 
Don Y
Guest
Posts: n/a
 
      06-17-2011, 06:03 PM
On 6/16/2011 11:11 AM, linnix wrote:
> On Jun 16, 10:11 am, "Boudewijn Dijkstra"
> <(E-Mail Removed)> wrote:
>> Op Thu, 16 Jun 2011 16:54:47 +0200 schreef Don Y<(E-Mail Removed)>:

>
> My comments are mostly for Android camera phones (i.e. LG VS740).
>
>>> Hi,

>>
>>> I currently have a kiosk application that I would like
>>> to port to a wireless, *portable* implementation. So,
>>> small tablets or (ack!) smart-phones (with the phone
>>> functionality permanently and irreparably disabled)
>>> seem a good choice. Phones being better suited in
>>> terms of size (want to tuck this into a shirt-pocket
>>> while not in use).

>>
>>> But, I rely extensively on barcodes to provide data to
>>> the application (item identification, location identification,
>>> etc.).

>
> Phones cameras are more geared for 2D barcodes, but i guess old
> fashion barcodes are workable.


Yes -- hence my mention of QR (below). It's conceivable that
you could decode linear ("classic") barcodes but they would
probably need to be printed at exaggerated scales to get the
proper discrimination between wide/narrow bars/spaces.

>>> Before I get myself "pregnant" on a solution path, I need
>>> to get a handle on what's "realistic" in terms of expectations.

>>
>>> [I don't *use* cell phones so my ignorance here requires
>>> patience :> ]

>>
>>> I know (some) cameras have motion video capabilities. From
>>> that, I can (?) deduce that the optics and electronics in
>>> the camera are "fast enough" that images can be captured
>>> at "several" frames per second.

>
> Motion video are captured and processed in SDRAM (256M in my case)


So, if there is enough horsepower (or, clever enough recognizer),
the image could be examined -- and discarded -- relatively quickly
(i.e., no need to compress and/or store it)

> first. Single hi-res (upto 2000x1500) takes couple of seconds. The
> jpeg file can be several megabytes compressed.


>>> - does the use of the camera (in movie mode) eat batteries?

>
> Yes, you have to keep charging it.


Every 3 minutes? 2 hours? etc.? You have to "keep charging" a
cell phone *regardless*... the point is how much of an impact
it makes on battery life, relatively speaking. (e.g., does
phone w/ radio off, camera on consume as much/more/less than
phone w/ radio on, camera off, etc.?

>> Since at the very least, light sensitivity adjustment will need to be made
>> at a certain rate, frames will probably be grabbed at a fixed rate when
>> the camera is active. I guess it is the choice of the application to skip
>> as many frames as it needs to.
>>
>>> What I would *like* to do is leave the camera on continuously and
>>> have my barcode recognizer/decoder processing images as fast as
>>> feasible. So, instead of the user having to explicitly enable
>>> the camera, point it at the targeted barcode label and *then*
>>> take a "capture barcode" snapshot, the application can hunt
>>> for suitable labels itself and use them as appropriate.

>
> You will have to write your custom apps.


Yes, I plan on writing most everything "from scratch" as I suspect
it will be *more* work to try to coerce a device made for one
type of use into a very different type of usage (see comments
re: software reuse thread :> )

>>> Are there any other issues that could eat my lunch that I
>>> haven't considered?

>>
>>> Finally, any pointers for *hackable* camera tablets/phones?
>>> (of course, they need to have some form of WiFi capability)

>
> I would go for a rooted Android. Unfortunately, theVS740 is hard to
> root.


Thanks, I'll look and see what's around with my basic needs
(incl tablets).
 
Reply With Quote
 
Don Y
Guest
Posts: n/a
 
      06-17-2011, 06:08 PM
Hi Boudewijn,

On 6/17/2011 1:26 AM, Boudewijn Dijkstra wrote:

[attributions elided]

>> You mentioned narrow and wide/fixed. Then, went on to
>> describe wide and fixed. Are wide/fixed synonyms? In
>> which case, what about "narrow" (is this what would be
>> called "macro" on a digital camera?)

>
> No, wide and fixed are not synonyms. Wide focus means the image is sharp
> over a wide range (like in a disposable camera), fixed focus means the
> image is only sharp at a fixed distance. Analogously, narrow focus means
> the image is sharp only in a narrow (but not fixed) distance range. IIRC
> "macro" is for short distances only, and involves dynamic mechanical
> zoom (which most phone cameras don't provide).


Ah, OK. "depth of field".

> But, I was just trying to illustrate that some lenses need time (and
> energy) to focus on the object of interest.
>
>>>> I know (some) cameras have motion video capabilities. From
>>>> that, I can (?) deduce that the optics and electronics in
>>>> the camera are "fast enough" that images can be captured
>>>> at "several" frames per second.
>>>
>>> All phone camera's I've seen are fast enough to show captured images on
>>> the main LCD at several frames per second. Compressing and storing the
>>> data somewhere is a different matter.

>>
>> But, the display in most (?) phones seems to be lower quality
>> than the stated camera capabilities. Is this real-time display
>> deliberately discarding data?

>
> It has no choice but to create a scaled version of the image. What's
> wrong with that?


I'm not claiming there is anything *wrong* with it! :> Rather,
I am wondering how much of a "fortunate circumstance" this is for
the phone implementor? I.e., knowing he only has to *display*
~1/4 of the data that he's taking in?

>> What role does the application
>> software take in doing that? Does the application *know* when the
>> scene is "in focus" or do you rely on the user delaying "snapping"
>> the picture until the displayed image "looks good"?

>
> My phone camera has a "dual action" button like in regular cameras.
> Press it softly and it will try to focus (which may fail), press it all
> the way to capture the image. If you press it all the way directly, it
> will first try to focus. The user is notified when the camera thinks
> that the image is focused. But, it will only know after trying to focus.
> So it is an interactive process.


But, there is nothing that prevents a piece of code from making
that decision (albeit possibly "less well")?

>>>> - does the *camera* drive the interface or does the application?
>>>> By that, I mean, do you say, "go into movie mode" and then sit
>>>> back and wait for the camera to deliver frames at whatever rate
>>>> *it* wants? Or, do you say, "give me a frame, *now* (note that
>>>> in this latter case, you could effectively run the video at
>>>> 2 FPS, 3 FPS, 12 FPS, etc. -- as appropriate to your application)
>>>
>>> Since at the very least, light sensitivity adjustment will need to be
>>> made at a certain rate, frames will probably be grabbed at a fixed rate

>>
>> This suggests that the *camera* does this adjustment? Or, is it in
>> the "camera application"? I.e., do I have any control over it?

>
> Dunno. But why would you want to mess with it?


Just rying to understand what's involved, what's "canned", what's
likely to be "proprietary", what's clonable, etc.
 
Reply With Quote
 
Don Y
Guest
Posts: n/a
 
      06-17-2011, 06:17 PM
Hi Lewin,

On 6/17/2011 6:42 AM, larwe wrote:
> On Jun 16, 10:54 am, Don Y<(E-Mail Removed)> wrote:
>
>> I know (some) cameras have motion video capabilities. From
>> that, I can (?) deduce that the optics and electronics in
>> the camera are "fast enough" that images can be captured
>> at "several" frames per second.

>
> This is highly variable. To run off a few possibilities - some phones/
> tablets have the camera on an internal USB interface. Some have the
> image sensor connected directly to a dedicated port on the SoC (this
> would almost always be the case for cameras). To acquire images, you
> have to power up the sensor, enable a DMA channel (for the dedicated
> camera port type solution), maybe instruct the GPU to set up an
> overlay window to perform YUV->RGB conversion. Exposure and white
> balance are typically adjusted on the fly by host-side software but
> this is certainly not universally true, especially for the USB


But these aren't (as) important when processing monochromatic
video (e.g., barcode symbols).

> solutions. The frame rate will typically be some divisor of 60Hz, for
> some resolution which might be anything from 160x120 up to full HD
> resolution depending on the camera. Some cameras, especially higher
> resolution cameras, have mechanical autofocus.
>
> Notice how I'm using words like "variable" "typical" etc. These
> systems can range from a single-core 400MHz ARM9 to a dual-core 1.2GHz
> Cortex with a separate DSP and/or other coprocessor(s), so there is
> absolutely no one size fits all answer.


Understood.

> These sensors also typically require fairly long exposure times, so


So, "motion video" is, of necessity, pretty poor quality?

Is the issue related to luminance, too (instead of just chrominance)?

> simply waving the camera about won't acquire a good image - you need
> to select a subject and hold the sensor still while acquiring the
> image. Usually, the live-view mode is significantly lower resolution
> than the sensor's actual max resolution.
>
>> - does the use of the camera (in movie mode) eat batteries?

>
> Sure, because you have powered up the sensor, moved the CPU core into
> a higher power mode, possibly activated a separate DSP core to handle
> MPEG compression, possibly powered up additional segments of the GPU
> (if any) to handle the overlay window, increased RAM bandwidth usage,
> forced the screen to remain on with 100% duty cycle, ... ... ...


As expected. But, many of these things I can live without or
have to deal with already. E.g., I don't have to worry about
compression because I'm not saving images. How the video is
displayed is entirely up to me (if it is displayed at all!).
CPU will already tend to be running at a higher duty cycle
(imagine being *on* the phone all the time it is powered up).
Etc.

>> - does the *camera* drive the interface or does the application?

>
> And for this you should start by looking at the APIs offered by the OS
> in the device you intend to use, because life's too short for hacking
> below the OS level in this case - especially if you want to insulate
> yourself against supply chain changes.


Supply chain won't be a problem in the quantities we're looking
at. In the short term (prototyping), I suspect trying to
fit some "middleware" above the OS to make it behave the way
the application would *want* it to behave would be more work
than gutting the device completely -- especially as it will
need to be done *eventually*. Annoying to have a successful
prototype and then have to "start over" to come up with a
*real* product -- about which the prototype will have taught you
very little! :-/
 
Reply With Quote
 
linnix
Guest
Posts: n/a
 
      06-17-2011, 06:23 PM
On Jun 17, 11:03*am, Don Y <(E-Mail Removed)> wrote:
> On 6/16/2011 11:11 AM, linnix wrote:
>
>
>
>
>
>
>
>
>
> > On Jun 16, 10:11 am, "Boudewijn Dijkstra"
> > <(E-Mail Removed)> *wrote:
> >> Op Thu, 16 Jun 2011 16:54:47 +0200 schreef Don Y<(E-Mail Removed)>:

>
> > My comments are mostly for Android camera phones (i.e. LG VS740).

>
> >>> Hi,

>
> >>> I currently have a kiosk application that I would like
> >>> to port to a wireless, *portable* implementation. *So,
> >>> small tablets or (ack!) smart-phones (with the phone
> >>> functionality permanently and irreparably disabled)
> >>> seem a good choice. *Phones being better suited in
> >>> terms of size (want to tuck this into a shirt-pocket
> >>> while not in use).

>
> >>> But, I rely extensively on barcodes to provide data to
> >>> the application (item identification, location identification,
> >>> etc.).

>
> > Phones cameras are more geared for 2D barcodes, but i guess old
> > fashion barcodes are workable.

>
> Yes -- hence my mention of QR (below). *It's conceivable that
> you could decode linear ("classic") barcodes but they would
> probably need to be printed at exaggerated scales to get the
> proper discrimination between wide/narrow bars/spaces.
>
> >>> Before I get myself "pregnant" on a solution path, I need
> >>> to get a handle on what's "realistic" in terms of expectations.

>
> >>> [I don't *use* cell phones so my ignorance here requires
> >>> patience *:> *]

>
> >>> I know (some) cameras have motion video capabilities. *From
> >>> that, I can (?) deduce that the optics and electronics in
> >>> the camera are "fast enough" that images can be captured
> >>> at "several" frames per second.

>
> > Motion video are captured and processed in SDRAM (256M in my case)

>
> So, if there is enough horsepower (or, clever enough recognizer),
> the image could be examined -- and discarded -- relatively quickly
> (i.e., no need to compress and/or store it)
>
> > first. *Single hi-res (upto 2000x1500) takes couple of seconds. *The
> > jpeg file can be several megabytes compressed.
> >>> - does the use of the camera (in movie mode) eat batteries?

>
> > Yes, you have to keep charging it.

>
> Every 3 minutes? *2 hours? etc.? *You have to "keep charging" a
> cell phone *regardless*... *the point is how much of an impact
> it makes on battery life, relatively speaking. *(e.g., does
> phone w/ radio off, camera on consume as much/more/less than
> phone w/ radio on, camera off, etc.?
>


I took 10 pictures and the battery drop from 66% to 65%. So, i guess
you can take 1000 pictures on a full charge.

larwe: USB sensors are impractical beyond VGA. Need lots of memory
and bandwidth on chip to do so. The 3M pixel sensor of VS740 has
parallel data bus into the system DSP. Pictures are first captured in
SDRAM, then write to SD card. However, in Linux, you can probably
memory map the SDRAM for processing, but you need rooted Android. The
camera software library is available in C++ (unsupported), but wrapper
in Java (supported) available.
 
Reply With Quote
 
 
 
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
FS:Brand New Plasma Tv,Apple Ipods,Xbox 360,Digital Cameras @ Cheap Price maurice2gi Motherboards 0 07-25-2006 10:15 AM
Do Photosmart Cameras Charge Thru USB Kim Johnson HP 1 12-29-2003 07:25 PM
FS Digital Cameras Mike HP 0 10-16-2003 07:36 PM
HP DIGITAL CAMERAS AND SUPPORT SUCK Ben Haas HP 1 08-30-2003 02:05 AM
hp scanjet not in the "Scanners and Cameras" LuisFelix HP 0 07-01-2003 10:34 AM


All times are GMT. The time now is 04:33 AM.


Welcome!
Welcome to Motherboard Point
 

Advertisment