Subject: [clue] Language re capture axis

From: Stephan Wenger <[email-masked]>
Date: Wed, 15 Feb 2012 16:03:49 +0000

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

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 29 Feb 2012 07:10:33 -0800

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."

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.

"

Stephan

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 29 Feb 2012 15:26:23 +0000

You analysis of the math appears to be correct.  Your proposal is Ok with me.
Stephan

From: "Duckworth, Mark" <[email-masked]<mailto:[email-masked]>>
Date: Wed, 29 Feb 2012 07:10:33 -0800
To: Stephan Wenger <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Language re capture axis

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.“

Mark

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Stephan Wenger
Sent: Wednesday, February 15, 2012 11:04 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [clue] Language re capture axis

Hi,

"

Stephan

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Feb 2012 10:55:45 -0500

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).
>
> “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.
>
> 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

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 29 Feb 2012 08:14:05 -0800

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.

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
> 
> > 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
> > 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
> >
> > directional audio capture-anything that is not omnidirectional) is
> > 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.
> >
> > Note that, for the purpose of receiver-side geometric correction, it

---

From: "Roni Even" <[email-masked]>
Date: Wed, 29 Feb 2012 18:52:16 +0200

Hi,
My view is that we should either point out that the axis of capture is not
specified or add a value for it. My preference is that since in most cases
the area of capture and point of capture will provide the axis of capture we
can add a flag that will say whether the axis of capture can be calculated
based on the information or not.
Roni 

> Duckworth, Mark
> Sent: Wednesday, February 29, 2012 6:14 PM
> To: Paul Kyzivat; [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.
> 
> 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."
> >
> 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: Christian Groves <[email-masked]>
Date: Thu, 01 Mar 2012 13:47:50 +1100

Hello Roni,

I'm not sure I follow. Why would the provider add a flag to say whether 
the axis of capture can be calculated? Wouldn't the consumer know this 
from the information delivered to it?

Regards, Christian