Subject: [clue] Ticket #9 - axis of capture description

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 21 May 2012 15:14:14 -0700

Hi Stephan,
Do you want to discuss your proposal for describing the "capture axis" at the upcoming interim meeting, as part of a framework discussion?  Do you have any more details yet?

Mark

> -----Original Message-----
> From: Stephan Wenger [mailto:[email-masked]]
> Sent: Tuesday, March 06, 2012 7:35 PM
> To: Paul Kyzivat; Duckworth, Mark
> Cc: [email-masked]
> Subject: Re: [clue] Language re capture axis
> 
> 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:
> 
> >On 3/5/12 1:29 PM, Duckworth, Mark wrote:
> >> 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
> >
> >> 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
> >>
> >>> -----Original Message-----
> >>> From: Paul Kyzivat [mailto:[email-masked]]
> >>> Sent: Thursday, March 01, 2012 4:53 PM
> >>> To: Duckworth, Mark
> >>> Cc: [email-masked]
> >>> Subject: Re: [clue] Language re capture axis
> >>>
> >>> 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
> >>>>
> >>
> >>
> >
> >_______________________________________________
> >clue mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/clue
> >
>

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 21 May 2012 22:47:44 +0000

Uh.  Yes and No to your questions.  I will have a text proposal ready by
the interim, or shortly before.  And perhaps also a slide deck.  Good?
Stephan

On 5.21.2012 15:14 , "Duckworth, Mark" <[email-masked]> wrote:

>Hi Stephan,
>Do you want to discuss your proposal for describing the "capture axis" at
>the upcoming interim meeting, as part of a framework discussion?  Do you
>have any more details yet?
>
>Mark
>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 22 May 2012 04:09:28 -0700

Hi Stephan, that's good, thanks.
Mark

> Sent: Monday, May 21, 2012 6:48 PM
> To: Duckworth, Mark; [email-masked]
> Subject: Re: Ticket #9 - axis of capture description
> 
> Uh.  Yes and No to your questions.  I will have a text proposal ready by the
> interim, or shortly before.  And perhaps also a slide deck.  Good?
> Stephan
> 
> 
> >Do you want to discuss your proposal for describing the "capture axis"
> >at the upcoming interim meeting, as part of a framework discussion?  Do
> >you have any more details yet?
> >
> >Mark
> >
> >> I will propose text as soon as I find the cycles (not before the
> >>Paris I-D  deadline).
> >>
> >> Stephan
> >>
> >>
> >> >> 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
> >> >>
> >> >>>> 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.
> >> >>>
> >> >>>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
> >> >>>>
> >> >>>>>> 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).
> >> >>>>>>
> >> >>>>> 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
> >> >>>>>> omnidirectional) is undefined. Without that axis being
> >> >>>>>> defined, receiver-side geometric correction is not possible.
> >> >>>>>>
> >> >>>>>> 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.
> >> >>>>>>
> >> >>>>>> Note that, for the purpose of receiver-side geometric
> >> >>>>>> etc.) is the line from the capture point to the center of the plane
> of capture.
> >> >>>>>>
> >> >>>>>> "
> >> >>>>>>
> >> >>>>>> Stephan
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>