RE: Camera properties (Re: [sysinfo] draft ready for review)

So the way that we've looked at this in BONDI is that the device status
API [1] allows a developer a point of reference to gather all the global
data they need before presenting something nice to the user. Previously
developers have only had static information such as UAProf and 3rd party
device databases to use.

So this allows for greater flexibility in devices. For example, if the
device doesn't have a camera at all then the application is
significantly different. Presence of a function is often not enough
though and in a lot of cases, it is good to have some fine-grained
information. If that isn't supported then it is easy to present as such
to the developer. I guess it is just an architecture choice but device
status is more of a very extensible registry that you can go straight to
and know that it will always be there before you start doing other
stuff.

Cheers,


David.

[1] http://bondi.omtp.org/1.1/cr/apis/devicestatus.html 

-----Original Message-----
From: Thomas Roessler [mailto:tlr@w3.org] 
Sent: 06 January 2010 11:39
To: David Rogers
Cc: Thomas Roessler; Max Froumentin; public-device-apis@w3.org
Subject: Re: Camera properties (Re: [sysinfo] draft ready for review)

Like you, I expect to see any number of weird ways in which decent
cameras and communications equipment might converge; hence I'm bringing
up the question.

I suspect the properties I listed make sense only if they're settable --
if all we're interested in is finding out about them later on, then
we'll typically find them in EXIF data anyway, and can consider that
another problem solved elsewhere.  By that argument, I'm convincing
myself that the early December thread was right, i.e., these belong in
Capture, not sysinfo.

A few more issues with the current Camera property:

- maxZoomFactor refers to hasPhysicalZoom, which isn't defined
- to each max, there should be a min ;)
- note there are cameras that support distinct aspect ratios with subtly
different pixel numbers on the sensor.  In that case, the sensorPixels
property isn't very helpful 

Regards,
--
Thomas Roessler, W3C  <tlr@w3.org>







On 6 Jan 2010, at 12:29, David Rogers wrote:

> I think the majority of devices are going to be mobile, but who's to
say that a decent camera isn't going to contain a 3G module in the
future? I think the question is really whether we want to push this back
to version 2.0 or not - at the moment, 99% of devices using this will be
your average mobile phone cameras (and we're talking multi-millions of
devices).
> 
> David.
> 
> -----Original Message-----
> From: public-device-apis-request@w3.org
[mailto:public-device-apis-request@w3.org] On Behalf Of Max Froumentin
> Sent: 06 January 2010 11:19
> To: Thomas Roessler
> Cc: public-device-apis@w3.org
> Subject: Re: Camera properties (Re: [sysinfo] draft ready for review)
> 
> On 05/01/2010 17:53, Thomas Roessler wrote:
>> The camera API looks like it's focused on a really cheap camera.  I
>> wonder whether we want to go down the route of describing things
>> like
>> 
>> - aperture - shutter - sensor dimension (both physical and pixel) -
>> ISO speed - focal length - camera orientation - flash on or off for
>> the next capture?
> 
> Fair enough. After the discussion at [1] I didn't think much more
about 
> what to put in there, and what to leave to the Capture API. The
current 
> list (supportsVideo, hasFlash, sensorPixels, maxZoomFactor) contains 
> properties which are fixed, while I think that variable attributes 
> (zoom, aperture, ISO, etc.) should go to Capture. But it's a very fine

> line, and the question is noted in an issue in the draft, awaiting 
> proposals.
> 
> [1]
http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0192.html
> 
> Max.
>

Received on Wednesday, 6 January 2010 12:09:13 UTC