Subject: [clue] New Ticket #9 (was Re: Language re capture axis

From: Mary Barnes <[email-masked]>
Date: Fri, 9 Mar 2012 16:07:51 -0600

Please note that I've opened a ticket to track this issue:
http://trac.tools.ietf.org/wg/clue/trac/ticket/9

If folks could please keep the ticket #9 in the Subject when discussing
this topic, that would be very helpful.

Thanks,
Mary.
- as CLUE WG co-chair

On Tue, Mar 6, 2012 at 6:34 PM, Stephan Wenger <[email-masked]> wrote:

> 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
> >
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>