Re: Proposal for Still Image Capture

On 08/21/2012 05:03 PM, Mandyam, Giridhar wrote:
> Hi Harald,
> Thanks for the feedback.  As the proposal currently stands, the returned ArrayBuffer would contain PNG data (similar to the snapshot example in Section 6 of the current getUserMedia spec).
Actually that example in getUserMedia shows getting the data by putting 
the stream into a <video> tag and snapshotting that by drawing the video 
onto a canvas, which is kind of indirect, but firmly leaves the question 
of format support to the canvas element - where PNG is a default value, 
not the only supported one, according to 
http://www.w3.org/TR/html5/the-canvas-element.html#a-serialization-of-the-image-as-a-file

That's what made me ask.

>
>
> If the group would like to see alternate image formats returned, a possibility is to add a feature key that specifies image format, e.g. 'picture_format'.  This would allow the returned array to contain encoded image data (e.g. JPEG).
>
> I admit that I have left some gaps in the proposal I sent out, as I wanted to see what camera settings that the group would be interested in before suggesting for detailed settings values.
>
> -Giri
>
> -----Original Message-----
> From: Harald Alvestrand [mailto:harald@alvestrand.no]
> Sent: Tuesday, August 21, 2012 7:46 AM
> To: public-media-capture@w3.org
> Subject: Re: Proposal for Still Image Capture
>
> Thanks for the proposal!
>
> One question - there may be an obvious answer, but I don't see it: The proposal says this:
>
> "captureImage() will return a binary ArrayBuffer to the success callback function."
>
> What's the format of the data contained in the binary ArrayBuffer, and how is the application supposed to know it?
>
>
> On 08/21/2012 02:46 AM, Mandyam, Giridhar wrote:
>> Hello All,
>> Since the Recording API is on the agenda for the upcoming telco, I'd like to put forward for the group the enclosed proposal for still image capture.  The "Simple image capture API" is still listed on the Wiki under Open Items.
>>
>> Please note the following:
>> 1. This proposal has commonalities to the Camera API proposed on Qualcomm's developer website:  https://developer.qualcomm.com/docs/html5/api/camera.html.
>> 2.  The "Feature Keys" listed in the enclosed doc are not defined in the doc itself.  Please refer to the above website for a further breakdown of the proposed individual values for the keys and if applicable the returned values if a feature key is set.
>> I look forward to feedback.
>>
>> -Giri Mandyam, Qualcomm Innovation Center
>>
>>
>>
>> -----Original Message-----
>> From: Stefan Hakansson LK [mailto:stefan.lk.hakansson@ericsson.com]
>> Sent: Friday, August 17, 2012 5:58 AM
>> To: public-media-capture@w3.org
>> Subject: Proposed agenda items
>>
>> Hi all,
>>
>> based on input received the chairs propose the following agenda items for the upcoming Media Capture Teleconf (Aug 23rd 5pm-6:30pm CEST):
>>
>> 1. Welcome, scribe
>> 2. Approve minutes of previous meeting
>> 3. Milestones, schedule
>>       - Quick route to a trimmed down v1, or longer time and more features?
>>       - What can we trim?
>> 4. Scenarios/requirement document
>> 5. Constraints modification API proposal from Travis - adopt, reject or "consider later"
>>       - is this OK for a "change resolution" API, or do we need more?
>> 6. Recording API
>>      - detailed requirements (are they captured well in scenarios/reqs doc?)
>>      - whether to include in V1
>>      - Travis' proposal:
>> http://lists.w3.org/Archives/Public/public-media-capture/2011Dec/0043.html
>> 7. Rich's proposal for advanced video track control http://lists.w3.org/Archives/Public/public-media-capture/2012Aug/0032.html
>>
>>
>> This is a first draft, as always feedback is most welcome!
>>
>> Stefan for the chairs
>