How to access camera from .net CF?

Hi there.

Could anyone point me in the right direction regarding incorporating the
camera functionality of MS based devices?

Specifically, I would like to capture photos using the XDA 2, directly from
my .net CF application on Pocket PC 2003.

Many thanks!

Salo.

r_z_aret
Sat May 08 13:38:41 CDT 2004

I just used google () to look up
camera
in microsoft.public.pocketpc.developer and got 218 hits. A quick
glance suggests several would be relevant and useful (of course, one
was my contribution, so I'm biased).

I'm pretty sure CE has neither TWAIN nor any such "universal" driver.
Some cameras come with SDKs.

My app works with whatever application comes with the camera. Not
quite as neat for the user as using an SDK. But I don't need to
program for every SDK and/or restrict user's choice of camera.

On Sat, 8 May 2004 17:16:08 +0200, "Salo" <nospamplease@nospam.com>
wrote:

>Hi there.
>
>Could anyone point me in the right direction regarding incorporating the
>camera functionality of MS based devices?
>
>Specifically, I would like to capture photos using the XDA 2, directly from
>my .net CF application on Pocket PC 2003.
>
>Many thanks!
>
>Salo.
>

-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret, eMVP
PenFact, Inc.
500 Harrison Ave., Suite 3R
Boston, MA 02118
www.penfact.com

Andy
Sun May 09 08:01:17 CDT 2004

For the XDA2 the camera API is closed, and the producers of the camera
software are reluctant to release details on how to use the camera in your
own application.

This is not a nice situation, and Microsoft could add a lot of value to
their devices by standardising an image aquisition library on the
WindowsMobile platform - many new devices have camera hardware. Unlikely to
happen considering what happened with the Radio interface layer (i.e. MS
produced an excellent API for OEMs to conform to [RIL] even to the point of
patenting it, but none of the OEMs or their software developers was
willing/able to fully implement it; so rather than prevent a whole trance of
exciting new devices reaching the market, MS just clsosed off the API and
allowed OEMs to deliver with patchy support. A lot of politics involved I'm
sure).

Salo
Sun May 09 14:15:42 CDT 2004

Any idea behind the thinking of camera / radio OEMs closing their APIs? I
mean, what do they have to loose exactly ? Exposing something like
GetPicture() is hardly going to erode their competitive advantage... and
surely not exposing it can only limit their uptake in the market?

Or is it more a case of OEMs not being able to reach consensus on features
to support....?

You'd think we wouldnt have to put up with this rubbish in this day and age!


"Andy Clapham" <news@artiDONTINCLUDETHISBITlect.co.uk> wrote in message
news:uU94wWcNEHA.3016@tk2msftngp13.phx.gbl...
> For the XDA2 the camera API is closed, and the producers of the camera
> software are reluctant to release details on how to use the camera in your
> own application.
>
> This is not a nice situation, and Microsoft could add a lot of value to
> their devices by standardising an image aquisition library on the
> WindowsMobile platform - many new devices have camera hardware. Unlikely
to
> happen considering what happened with the Radio interface layer (i.e. MS
> produced an excellent API for OEMs to conform to [RIL] even to the point
of
> patenting it, but none of the OEMs or their software developers was
> willing/able to fully implement it; so rather than prevent a whole trance
of
> exciting new devices reaching the market, MS just clsosed off the API and
> allowed OEMs to deliver with patchy support. A lot of politics involved
I'm
> sure).
>
>

Andy
Sun May 09 14:43:04 CDT 2004

> Any idea behind the thinking of camera / radio OEMs closing their APIs? I
> mean, what do they have to loose exactly ? Exposing something like
> GetPicture() is hardly going to erode their competitive advantage... and
> surely not exposing it can only limit their uptake in the market?

Absoultely, I guess they don't want the support. headaches involved. Letting
people on technical forums know how to use it, at their own risk, and
possible providing a simple peer-support forum, would be easy for them, but
they just don't seem to do it.
> Or is it more a case of OEMs not being able to reach consensus on features
> to support....?
Here we're getting into the issue of how to design a perfect API - and it's
really MSs arena. The main thing about designing a good common hardware API
is to provide a capability and extension mechanism to ease the effort
required for OEMs to comply. Rather than having a Take3dHologram() function,
you provide a GetDeviceCaps(CAMCAP_HOLO_PHOTO) and a
CallBizarreExtension(CAMEXT_HOLO_PHOTO, holostruct)..

Salo
Sun May 09 15:13:20 CDT 2004

Yeah, it seems these decisions are way more politics based than tech/sense
based. Mildly surprised MS didnt bully the OEMs into complying - they seem
to have generally have a good grip on the "make developers' lives easier and
it will work for you" idea.

What happened with the RIL situation? Have developers successfully worked
around the lack of API?

"Andy Clapham" <news@artiDONTINCLUDETHISBITlect.co.uk> wrote in message
news:e5WhR3fNEHA.1528@TK2MSFTNGP10.phx.gbl...
> > Any idea behind the thinking of camera / radio OEMs closing their APIs?
I
> > mean, what do they have to loose exactly ? Exposing something like
> > GetPicture() is hardly going to erode their competitive advantage... and
> > surely not exposing it can only limit their uptake in the market?
>
> Absoultely, I guess they don't want the support. headaches involved.
Letting
> people on technical forums know how to use it, at their own risk, and
> possible providing a simple peer-support forum, would be easy for them,
but
> they just don't seem to do it.
> > Or is it more a case of OEMs not being able to reach consensus on
features
> > to support....?
> Here we're getting into the issue of how to design a perfect API - and
it's
> really MSs arena. The main thing about designing a good common hardware
API
> is to provide a capability and extension mechanism to ease the effort
> required for OEMs to comply. Rather than having a Take3dHologram()
function,
> you provide a GetDeviceCaps(CAMCAP_HOLO_PHOTO) and a
> CallBizarreExtension(CAMEXT_HOLO_PHOTO, holostruct)..
>
>

The
Mon May 10 05:19:44 CDT 2004

It is much simpler than that. Hardware manufacturers do not give a damn
about software, or documentation. They are just overheads, which cut in to
their profits.

"Salo" <nospamplease@nospam.com> wrote in message
news:%23F5wP6gNEHA.3744@TK2MSFTNGP10.phx.gbl...
> Yeah, it seems these decisions are way more politics based than tech/sense
> based. Mildly surprised MS didnt bully the OEMs into complying - they seem
> to have generally have a good grip on the "make developers' lives easier
and
> it will work for you" idea.
>
> What happened with the RIL situation? Have developers successfully worked
> around the lack of API?
>
> "Andy Clapham" <news@artiDONTINCLUDETHISBITlect.co.uk> wrote in message
> news:e5WhR3fNEHA.1528@TK2MSFTNGP10.phx.gbl...
> > > Any idea behind the thinking of camera / radio OEMs closing their
APIs?
> I
> > > mean, what do they have to loose exactly ? Exposing something like
> > > GetPicture() is hardly going to erode their competitive advantage...
and
> > > surely not exposing it can only limit their uptake in the market?
> >
> > Absoultely, I guess they don't want the support. headaches involved.
> Letting
> > people on technical forums know how to use it, at their own risk, and
> > possible providing a simple peer-support forum, would be easy for them,
> but
> > they just don't seem to do it.
> > > Or is it more a case of OEMs not being able to reach consensus on
> features
> > > to support....?
> > Here we're getting into the issue of how to design a perfect API - and
> it's
> > really MSs arena. The main thing about designing a good common hardware
> API
> > is to provide a capability and extension mechanism to ease the effort
> > required for OEMs to comply. Rather than having a Take3dHologram()
> function,
> > you provide a GetDeviceCaps(CAMCAP_HOLO_PHOTO) and a
> > CallBizarreExtension(CAMEXT_HOLO_PHOTO, holostruct)..
> >
> >
>
>