Re: [capture] A couple of editorial comments

comment /question inline, thanks for helping out here.

regards, Frederick

Frederick Hirsch
Nokia



On Nov 27, 2012, at 5:08 PM, ext Tobie Langel wrote:

> On 11/27/12 9:49 PM, "Frederick.Hirsch@nokia.com"
> <Frederick.Hirsch@nokia.com> wrote:
> 
>> On Nov 27, 2012, at 3:28 PM, ext Tobie Langel wrote:
>> 
>>> Thanks for your answers, Frederick.
>>> 
>>> On 11/27/12 8:21 PM, "Frederick.Hirsch@nokia.com"
>>> <Frederick.Hirsch@nokia.com> wrote:
>>> 
>>>> On Nov 21, 2012, at 7:38 AM, ext Tobie Langel wrote:
>>>> 
>>>>> 
>>>>> - The wording in the abstract seems to imply HTML Media Capture is
>>>>> only
>>>>> useful to immediately upload captured content. It might be worth
>>>>> mentioning it gives the document access to the capture content through
>>>>> the
>>>>> File API which allows client-side manipulation and storing (in
>>>>> IndexedDB).
>>>> 
>>>> The primary purpose is to upload immediately captured content. Why not
>>>> use the FileAPI directly otherwise?
>>> 
>>> How can the FileAPI launch capture control types?
>> 
>> it cannot as far as I know, but it can upload files that are in an
>> appropriate format or location, isn't that so?
> 
> No, you need XHR for this. But thatıs an orthogonal issue, really.
> 
>>> 
>>> The use case is to take a picture, then manipulate and store it locally.
>> 
>> Let's see, wouldn't this use case be three steps for a web application:
>> 
>> 1. take a picture - HTML Media Capture
>> 2. Manipulate - e.g. web application uses Web Intents to invoke
>> manipulation program, local or remote
>> 3. Store locally - web application uses another API (IndexedDB API?) to
>> store
>> 
>> Thus for the first step, capture, the focus of HTML MediaCapture, there
>> is no support for local or remote manipulation (other than what is
>> integrated into the device UI itself, though this UI could provide
>> various features)
> 
> Agreed.
> 
>> My understanding is that capture and upload are integrated without the
>> ability for an explicit distinct local manipulation step.
> 
> That's incorrect, there is such as step: When the capture control returns
> control to application code, the result of the capture is available as a
> File object from the input element's `files` property.

let me see if I understand...

the 'application code' is the web application that is integrated with the form HTML code (e.g. javascript on a page that has the form markup)

I think what you are saying is what I said - that the application can perform additional manipulation per step #2

The detailed difference you point out is that the upload does not happen until the files object is used by the application javascript to actually process the file object provided as a result of 'html media capture', e.g. the handle for the file is provided and the app can choose to upload it or not.  Conceivably there could be a device API that took the handle and allowed local manipulation for example, but I suspect a common case would be to upload and process server side.

Did I get this right? 

If so,  the spec introduction language should probably have some minor clarification and I could do that.

> 
>> I.e. when I select the camera via the UA in response to an HTML Media
>> Capture element the picture is taken by the user (using camera controls
>> as appropriate) with immediate upload.
> 
> No, upload is an extra step away, and needs the form that contains the
> input element to be submitted.
> 
>> Thus no step to run an additional local program for red-eye removal for
>> example (if this is what you meant by manipulation)
> 
> Yes I meant some form of client-side manipulation, like applying filters
> using canvas, for example.
> 
>> maybe we  need clarity on this in the document and it is possible I could
>> be confused.
>> 
>>> 
>>>> That said, we should not make changes which lose the primary purpose
>>>> though we could clarify that file upload is also possible
>>>> 
>>>>> 
>>>>> - I am not sure I fully understand the sentence "These form extensions
>>>>> enable the upload of still images, video, and audio directly from a
>>>>> device
>>>>> capture mechanism but capture the default offered by the device,
>>>>> providing
>>>>> limited control over what is captured."
>>>> 
>>>> What is not clear? It says that using forms one can upload material
>>>> captured by device mechanisms but cannot have fine grained control like
>>>> handling tracks etc.
>>> 
>>> It is unclear to me whether the limited control refers to that of the
>>> end
>>> user or the author. I'm also not sure what "the default offered by the
>>> device" means in that context. (Not trolling, I really don't understand.
>>> :-/ )
>> 
>> what I mean specifically to give one example, is that with HTML Media
>> Capture you are stuck with the integrated camera and microphone for video
>> capture for example - what you get is a recorded video with the
>> 'default' integrated audio and video stream. This is very limited control
>> (and in fact Doug asked why not offer more detailed control).
>> 
>> This is one thing that distinguishes the supported use cases for HTML
>> Media Capture versus getUserMedia, which could allow a more advanced user
>> use case, where i decide to have a higher quality microphone on a stand
>> closer to the subject and then combine that audio stream with the image
>> stream to achieve a capture.
>> 
>> Thus there is limited control over what is captured, both for the user
>> and the web page author as neither can use HTML Media capture to achieve
>> the external microphone capture use case (unless again the local camera
>> app includes  it)
> 
> Agreed with regard to the developer control. Regarding user control, this
> is implementation specific. A device targeted at musicians could very well
> allow the user to pick between different kinds of microphones (both
> internal and external) through the capture control.
> 
> On Android devices, where capture control can be implemented through an
> Android Intent, the user can choose whatever application he prefers to
> handle the capture and different application offer a different degree of
> control (and could potentially include things such as: picking a camera,
> applying filters, cropping the picture, storing it in the local gallery,
> etc., etc.).
> 
> --tobie
>

Received on Tuesday, 27 November 2012 22:34:47 UTC