Subject: Re: [clue] Language re capture axis

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Mar 2012 16:53:17 -0500

On 2/29/12 11:14 AM, Duckworth, Mark wrote:
> Paul and Stephan,
>
> Personally, I'd rather just leave it out altogether because I think it doesn't add anything that needs to be standardized.  But Stephan thought it was important, so I was trying to find a way to say it in an "accurate enough" way.

If there is no widespread interest in having this, and those who have 
asked about it are happy without, then I'm fine with leaving it out.

If it is to be mentioned, with the idea that the recipient might use it 
for something, then I think it should be made clear how it can be 
determined.

	Thanks,
	Paul

> Mark
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> Paul Kyzivat
>> Sent: Wednesday, February 29, 2012 10:56 AM
>> To: [email-masked]
>> Subject: Re: [clue] Language re capture axis
>>
>> On 2/29/12 10:10 AM, Duckworth, Mark wrote:
>>> Hi Stephan,
>>>
>>> I agree in principle with your suggestion, but I think your suggested
>>> text is not mathematically accurate. I think the axis of capture
>>> doesn't go to the center of the area of capture. For example, if the
>>> camera is pointed at the area of capture at an angle, the center point
>>> of the area would not line up with the center point of the camera's
>>> field of view (which defines the axis).
>>>
>>> So rather than try to get into the mathematical details, how about this:
>>>
>>> "Note that, for the purpose of receiver-side geometric correction, it
>>> can be assumed that the axis of capture of directional capture devices
>>> (cameras, directional microphones etc.) can be calculated from the
>>> coordinates of the point of capture and area of capture."
>>
>> IMO this is dangerously vague. Presumably there is a real axis of capture.
>> Hopefully there is a well defined algorithm for deriving the axis from the
>> available data, so that the recipient will determine the actual axis. If so, then
>> it should be specified or referenced from some source. Otherwise we run
>> the risk that not all will correctly derive the axis.
>>
>> 	Thanks,
>> 	Paul
>>
>>> Mark
>>>
>>> *From:[email-masked] [mailto:[email-masked]] *On Behalf
>>> Of *Stephan Wenger
>>> *Sent:* Wednesday, February 15, 2012 11:04 AM
>>> *To:* [email-masked]
>>> *Subject:* [clue] Language re capture axis
>>>
>>> Hi,
>>>
>>> The issue I mentioned in the meeting is that nowhere in the framework
>>> (as far as I recall) the axis of capture of a video capture (or
>>> directional audio capture-anything that is not omnidirectional) is
>>> undefined. Without that axis being defined, receiver-side geometric
>>> correction is not possible.
>>>
>>> The issue could be solved in two ways: include attributes, per
>>> capture, indicating angle of capture in 3D space (relative to
>>> what???), or by making the bold assumption that the coordinates
>>> defining area of capture plus capture point define the axis of
>>> capture. I suggest the latter as it is easy to implement and (I believe)
>> practical.
>>>
>>> The language could be something like:
>>>
>>> "
>>>
>>> Note that, for the purpose of receiver-side geometric correction, it
>>> can be assumed that the axis of capture of directional capture devices
>>> (cameras, directional microphones etc.) is the line from the capture
>>> point to the center of the plane of capture.
>>>
>>> "
>>>
>>> Stephan
>>>
>>>
>>>
>>> _______________________________________________
>>> clue mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/clue
>>
>> _______________________________________________
>> clue mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/clue
>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 5 Mar 2012 10:29:24 -0800

As editor, it seems I should leave this out of the next version.  Okay?

Otherwise, I would appreciate having interested parties propose new text to discuss on the mailing list, considering Paul's desire to have more specific text than what we have previously discussed.

Thanks,
Mark

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, March 01, 2012 4:53 PM
> To: Duckworth, Mark
> Cc: [email-masked]
> > Personally, I'd rather just leave it out altogether because I think it doesn't
> add anything that needs to be standardized.  But Stephan thought it was
> important, so I was trying to find a way to say it in an "accurate enough" way.
> 
> If there is no widespread interest in having this, and those who have asked
> about it are happy without, then I'm fine with leaving it out.
> 
> If it is to be mentioned, with the idea that the recipient might use it for
> something, then I think it should be made clear how it can be determined.
> 
> 	Thanks,
> 	Paul
> 
> > Mark
> >
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> >> Of Paul Kyzivat
> >>> I agree in principle with your suggestion, but I think your
> >>> suggested text is not mathematically accurate. I think the axis of
> >>> capture doesn't go to the center of the area of capture. For
> >>> example, if the camera is pointed at the area of capture at an
> >>> angle, the center point of the area would not line up with the
> >>> center point of the camera's field of view (which defines the axis).
> >>>
> >>> "Note that, for the purpose of receiver-side geometric correction,
> >>> it can be assumed that the axis of capture of directional capture
> >>> devices (cameras, directional microphones etc.) can be calculated
> >>> from the coordinates of the point of capture and area of capture."
> >>
> >> Hopefully there is a well defined algorithm for deriving the axis
> >> from the available data, so that the recipient will determine the
> >> actual axis. If so, then it should be specified or referenced from
> >> some source. Otherwise we run the risk that not all will correctly derive
> the axis.
> >>
> >> 	Thanks,
> >> 	Paul
> >>
> >>> Mark
> >>>
> >>> *From:[email-masked] [mailto:[email-masked]] *On
> >>> Behalf Of *Stephan Wenger
> >>> The issue I mentioned in the meeting is that nowhere in the
> >>> framework (as far as I recall) the axis of capture of a video
> >>> capture (or directional audio capture-anything that is not
> >>> omnidirectional) is undefined. Without that axis being defined,
> >>> receiver-side geometric correction is not possible.
> >>>
> >>> can be assumed that the axis of capture of directional capture
> >>> devices (cameras, directional microphones etc.) is the line from the
> >>> capture point to the center of the plane of capture.
> >>>
> >>> "
> >>>
> >>> Stephan
> >>>
> >>>
> >>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Mar 2012 17:51:57 -0500

> As editor, it seems I should leave this out of the next version.  Okay?

I'm ok with leaving any mention of it out, assuming those who were 
concerned about it (Stephan) are ok with that.

	Paul

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 7 Mar 2012 00:34:36 +0000

With the understanding that "out of this version" means "out of this
interation of the I-D", I'm fine.  I still want this in the published RFC.
 Same goes for (de)composition info.
I will propose text as soon as I find the cycles (not before the Paris I-D
deadline).

Stephan

On 3.6.2012 14:51 , "Paul Kyzivat" <[email-masked]> wrote:

>> Otherwise, I would appreciate having interested parties propose new
>>text to discuss on the mailing list, considering Paul's desire to have
>>more specific text than what we have previously discussed.
>>
>> Thanks,
>> Mark
>>
>>>asked