Subject: Re: [clue] <capturePoint> should be optional

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Apr 2014 11:15:58 -0400

On 3/31/14 8:52 PM, Christian Groves wrote:
> Hello
>
> In some respects I agree with John. The discussions around the use of
> spatial information for audio captures just seemed to die out without
> any real conclusion. As John has alluded to the use of the spatial
> attributes for audio is problematic. We don't seem to have any text in
> the framework discussing this or forbidding the use of the spatial
> information for audio.

Certainly there is nothing forbidding the use of the existing spatial 
information for audio. But neither is there any guidance in how it 
could/should be used. John has repeatedly made the point that the 
existing info doesn't work for audio. But we have never actually *done* 
anything about that.

I have been of the assumption that people had in mind some way they 
would use the existing spatial info for audio. But without some clarity 
about how that is to be done I suspect that there could be major 
interoperability problems.

> With regards to the video related spatial information I didn't realize
> that there was deep seated confusion over the use of the attributes.

The lack of apparent confusion doesn't mean there is consistent 
understanding. :-)

>  From a previous email:
>
> where the "to be rendered" information are represented by means of the
> <capturedArea> within the <spatialInformation> tag associated to the MCCs.
>
>     <captureArea> has always bothered me, because it is a two-dimensional
> quantity, while we interact in three-dimensional space. I suppose I should
> have objected to including it at all in <spatialInformation>; but until
> now I thought we understood it to be defining space in a plane within
> our three-dimensional interaction space (and therefore a three-dimensional
> space from <capturePoint> to the <captureArea>).
>
> I thought of the <captureArea> being a quadrilateral on a plane in 3D
> space, i.e. a 2D area. The <capturePoint> and <lineOfCapturePoint> were
> points in this 3D space giving the relationship between the capture
> device and the <captureArea>. This was in order to allow the Renderer to
> perform what ever geometric corrections it needed to do in order to
> provide an optimal rendering of the image on a screen i.e. quadrilateral
> on a plane.

*My* understanding is that the capture area and the point of capture 
define a "capture volume" as a sort of pyramid, with the capture area 
being in focus.

In the case of captures by cameras, the content captured may occur 
anywhere in that volume. It clearly doesn't all come from the 2d capture 
area. But in most cases we would imagine that it will be displayed in a 
comparable 2d area.

But clearly this model doesn't work well for audio.

ISTM that, as for video, the goal here must be to provide the 
information needed for the consumer to:
- decide which audio captures to configure;
- decide how to render those on the equipment available to the receiver.

> In the case where the image has been through a device that performs the
> geometric corrections etc. (e.g. an MCU) the resultant image still
> represents an quadrilateral on a plane (albeit with Y=0). In terms of
> the <capturePoint> and <lineOfCapturePoint> there would be "virtual"
> values for these as a result of any transformations applied to the
> image. I guess the assumption is that is would be meaningless to send
> these as no further transformation requiring these points would be
> required.

The extreme here is for synthetic captures, such as presentations. They 
may truly not have a point of capture, and the volume of capture is 
truly just the 2d area of capture.

	Thanks,
	Paul

> Regards, Christian
>
>
> On 29/03/2014 4:42 AM, John Leslie wrote:
>> Duckworth, Mark <[email-masked]> wrote:
>>> The group spent a lot of time discussing and finalizing the spatial
>>> information as currently defined.
>>     Indeed!
>>
>>> It has been very stable for a long time now.
>>     Umm, Seems more "dormant" to me...
>>
>>> I'd rather not re-open that discussion now, unless there is strong
>>> consensus in the group to do so.
>>     Hmm...
>>
>>> My view is that both types of usages described below are real spatial
>>> information, but only one is directly derived from physical space.
>>     An interesting view...
>>
>>     ISTM that one describes physical space (three-dimensional) and the
>> other describes a mathematical concept, instantiated on a visual
>> display. Mixing them is inherently confusing.
>>
>>     (Arguments that the mathematical concept is a "space" do not move
>> me -- everything in math is sometimes described as a "space".)
>>
>>     I seriously fear that we've only scratched the surface of the
>> confusion we've uncovered.
>>
>>     I do understand that bikeshedding can prevent progress until it's
>> too late to consider the important issues. But keeping physical space
>> distinct from mathematical "space" strikes me as an important issue.
>>
>>> They are distinguished by the "scale" attribute of <captureScene>.
>>     I doubt this. I remember only "millimeters", "unknown", and
>> "noscale".
>> I can imagine folks using "noscale" for three-dimensional space.
>>
>>     Also, I find "scale" a rather strange way to disambiguate physical
>> from mathematical space...
>>
>> --
>> John Leslie <[email-masked]>
>>
>> _______________________________________________
>> clue mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/clue
>>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>