Subject: [clue] CLUE Coordinate system proposal

From: "Brian Baldino (bbaldino)" <[email-masked]>
Date: Fri, 11 Nov 2011 09:24:09 -0800

Attached is the doc describing the coordinate system proposal which will
be presented next week; wanted to send it out now to give everyone a
chance to read it over.

-Brian

---

From: Roni even <[email-masked]>
Date: Fri, 11 Nov 2011 18:34:33 +0000

Hi Brian,

I think that in order to agree we need first to agree on what are the co-ordinates used for.

I am not sure why a one capture device TP system will not send co-ordinates if they can be used to scale to real size and maybe if real co-ordinates (mm) are used can also provide relative scaling when composing a mixed video.

As for the origin, again, what is the use here. I am also wondering if you supply X co-ordinates with no other information where in the room are they relating to.  I think I am OK with the concept as long as it will be clear that when you provide only x co-ordinates they describe the line of the people in front of the camera (Probably a straight line between the two extreme people).

Regards

Roni

________________________________
From: [email-masked] [[email-masked]] on behalf of Brian Baldino (bbaldino) [[email-masked]]
Sent: Friday, November 11, 2011 19:24
To: [email-masked]
Subject: [clue] CLUE Coordinate system proposal

Attached is the doc describing the coordinate system proposal which will be presented next week; wanted to send it out now to give everyone a chance to read it over.

-Brian

---

From: "Brian Baldino (bbaldino)" <[email-masked]>
Date: Fri, 11 Nov 2011 10:59:56 -0800

Hey Roni, inline.

From: Roni even [mailto:[email-masked]] 
Sent: Friday, November 11, 2011 10:35 AM
To: Brian Baldino (bbaldino); [email-masked]
Subject: RE: CLUE Coordinate system proposal

Hi Brian,

I think that in order to agree we need first to agree on what are the
co-ordinates used for.

I am not sure why a one capture device TP system will not send
co-ordinates if they can be used to scale to real size and maybe if real
co-ordinates (mm) are used can also provide relative scaling when
composing a mixed video.

[BB] I don't believe it's safe to assume that all devices will even be
able to know their geometry, so I don't think it's fair to require that
they send coordinates expressed in real-world dimensions.

As for the origin, again, what is the use here. I am also wondering if
you supply X co-ordinates with no other information where in the room
are they relating to.  I think I am OK with the concept as long as it
will be clear that when you provide only x co-ordinates they describe
the line of the people in front of the camera (Probably a straight line
between the two extreme people).

[BB] Not sure I follow all of this, but, the proposal does not allow for
expressing only a subset of dimensions when expressing the coordinates
(some of the diagrams leave a dimension out for purposes of
simplification, this is called out in the text).  In an actual CLUE
exchange each point would be expressed in all 3 dimensions (with the
caveat that a 'NaN'-type value could be used, per some of Stephan's
concerns).  I also don't think there's anything in there that ties the X
plane explicitly to something like a row of participants-I'm not sure
that's an assumption we'd want to build in. 

Regards

Roni

From: [email-masked] [[email-masked]] on behalf of Brian
Baldino (bbaldino) [[email-masked]]
Sent: Friday, November 11, 2011 19:24
To: [email-masked]
Subject: [clue] CLUE Coordinate system proposal

-Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Nov 2011 14:45:48 -0500

Brian,

Do you intend to publish this as a draft once we get past the blackout?

This seems to be largely replicated in the framework slides for the 
meeting. I assume the intent is to discuss based on the slides.

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Sat, 12 Nov 2011 17:45:02 +0200

Hi Brian,

This proposal do not address the issue of knowing what is the gap between
the capture views at the row where people sit which we discussed in the
interim meeting unless the X is at the row of participants or it is clear
where it is so that it can be calculated. If the origin is not known and the
X axis position is not know it does not provide the information.

I think that it will not work when you have a system that can do both the
regular view and multiview since if you do not know where the X axis is in
relation to the row of participant the information will not be enough to
know which part of the row you see in the multiview if the regular view will
each show two participants.

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Baldino (bbaldino)
Sent: Friday, November 11, 2011 9:00 PM
To: Roni even; [email-masked]
Subject: Re: [clue] CLUE Coordinate system proposal

Hey Roni, inline.

Hi Brian,

I am not sure why a one capture device TP system will not send co-ordinates
if they can be used to scale to real size and maybe if real co-ordinates
(mm) are used can also provide relative scaling when composing a mixed
video.

[BB] I don't believe it's safe to assume that all devices will even be able
to know their geometry, so I don't think it's fair to require that they send
coordinates expressed in real-world dimensions.

As for the origin, again, what is the use here. I am also wondering if you
supply X co-ordinates with no other information where in the room are they
relating to.  I think I am OK with the concept as long as it will be clear
that when you provide only x co-ordinates they describe the line of the
people in front of the camera (Probably a straight line between the two
extreme people).

[BB] Not sure I follow all of this, but, the proposal does not allow for
expressing only a subset of dimensions when expressing the coordinates (some
of the diagrams leave a dimension out for purposes of simplification, this
is called out in the text).  In an actual CLUE exchange each point would be
expressed in all 3 dimensions (with the caveat that a 'NaN'-type value could
be used, per some of Stephan's concerns).  I also don't think there's
anything in there that ties the X plane explicitly to something like a row
of participants-I'm not sure that's an assumption we'd want to build in. 

Regards

Roni

  _____  

Attached is the doc describing the coordinate system proposal which will be
presented next week; wanted to send it out now to give everyone a chance to
read it over.

-Brian

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Sun, 13 Nov 2011 05:12:24 -0800

I think Brian is traveling, so I'll answer.

This material is potentially for the framework document, not a separate
draft. It represents the authors' proposal for how to handle spatial
relations. It fleshes out the point and area that are already descried
in the document. Whatever the WG decides will get put into the framework
document. Is that not also how you see it? Had you other thoughts?

The slides and this note are the same. As Brian mentioned, we thought it
would be a good idea to make the material available to people for them
to think about prior to hearing about it in the slides that are going to
be presented during the framework discussion in CLUE.

Thanks,
Allyn

> -----Original Message-----
> Paul Kyzivat
> Sent: Friday, November 11, 2011 11:46 AM
> To: [email-masked]
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 13 Nov 2011 10:32:38 -0500

> be presented during the framework discussion in CLUE.

OK - it wasn't clear what the intent was.
If its just a preview of the slides, and the intent is to fold it into 
the framework then fine.

	Thanks,
	Paul

---

From: Michael Hammer <[email-masked]>
Date: Mon, 14 Nov 2011 10:28:58 -0500

Comment from the peanut gallery:

1. This is a very good start to clearly explaining the frame of reference.

2. If a rectangular system is always used, the upper left and lower right
(or vice versa) points would be sufficient to define the view

Mike

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 14 Nov 2011 13:56:19 -0500

> (or vice versa) points would be sufficient to define the view

Note that if the cameras are tilted, then either the field of view
isn't rectangular, or
it has a tilt (i.e., you have to know the z* of those points).

Regards
Marshall

* A minor point, but can we please use either x,y,z for left-right,
back-front, up-down,
or abandon that terminology entirely ? How about A, D, V (for

A - along screen
D - depth into audience
V - vertical

If we use a completely different nomenclature, then no one will be
confused by z not being vertical, etc.

---

From: Michael Hammer <[email-masked]>
Date: Mon, 14 Nov 2011 15:27:42 -0500

I was still assuming the z component was used, thus tilt detectable (delta
z values)

No problem with using alternate variable names that are more intuitive.

Mike

---

From: Christian Groves <[email-masked]>
Date: Tue, 15 Nov 2011 09:31:34 +1100

I'd prefer to use x,y,z for left-right, back-front, up-down. Do long as 
its used consistently I think its more intuitive than coming up with yet 
another naming convention.

Christian

On 15/11/2011 7:27 AM, Michael Hammer wrote:
> I was still assuming the z component was used, thus tilt detectable 
> (delta z values)
>
> On Mon, Nov 14, 2011 at 1:56 PM, Marshall Eubanks 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     On Mon, Nov 14, 2011 at 10:28 AM, Michael Hammer <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > On Sun, Nov 13, 2011 at 8:12 AM, Allyn Romanow (allyn)
>     <[email-masked] <mailto:[email-masked]>>
>     > wrote:
>     >>
>     >> > From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     Behalf
>     >> Of
>     >> > Paul Kyzivat
>     >> > To: [email-masked] <mailto:[email-masked]>
>     >> > > Attached is the doc describing the coordinate system
>     proposal which
>     >> > will
>     >> > [email-masked] <mailto:[email-masked]>
>     >> [email-masked] <mailto:[email-masked]>
>     > [email-masked] <mailto:[email-masked]>

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 14 Nov 2011 18:04:58 -0500

On Mon, Nov 14, 2011 at 5:31 PM, Christian Groves
<[email-masked]> wrote:
> I'd prefer to use x,y,z for left-right, back-front, up-down.

I prefer too as well. I think it matches general use. I made my
proposal purely in case some people felt
strongly that we need to do something non-standard.

 Do long as its
> used consistently I think its more intuitive than coming up with yet another
> naming convention.
>

Agree

Marshall

>>    > Comment from the peanut gallery:
>>    > 1. This is a very good start to clearly explaining the frame of
>>    reference.
>>    > 2. If a rectangular system is always used, the upper left and
>>    lower right
>>    > (or vice versa) points would be sufficient to define the view
>>    > Mike
>>
>>    >
>>    > On Sun, Nov 13, 2011 at 8:12 AM, Allyn Romanow (allyn)
>>    > wrote:
>>    >>
>>    >> I think Brian is traveling, so I'll answer.
>>    >>
>>    >> This material is potentially for the framework document, not a
>>    separate
>>    >> draft. It represents the authors' proposal for how to handle
>>    spatial
>>    >> relations. It fleshes out the point and area that are already
>>    descried
>>    >> in the document. Whatever the WG decides will get put into the
>>    framework
>>    >> document. Is that not also how you see it? Had you other thoughts?
>>    >>
>>    >> The slides and this note are the same. As Brian mentioned, we
>>    thought it
>>    >> would be a good idea to make the material available to people
>>    for them
>>    >> to think about prior to hearing about it in the slides that are
>>    going to
>>    >> be presented during the framework discussion in CLUE.
>>    >>
>>    >> Thanks,
>>    >> Allyn
>>    >>
>>    >> > -----Original Message-----
>>    >> > From: [email-masked] <mailto:[email-masked]>
>>    >> Of
>>    >> > Paul Kyzivat
>>    >> > Sent: Friday, November 11, 2011 11:46 AM
>>    >> > To: [email-masked] <mailto:[email-masked]>
>>    >> > Subject: Re: [clue] CLUE Coordinate system proposal
>>    >> >
>>    >> > Brian,
>>    >> >
>>    >> > Do you intend to publish this as a draft once we get past the
>>    >> blackout?
>>    >> >
>>    >> > This seems to be largely replicated in the framework slides
>>    for the
>>    >> > meeting. I assume the intent is to discuss based on the slides.
>>    >> >
>>    >> >       Thanks,
>>    >> >       Paul
>>    >> >
>>    >> > On 11/11/11 12:24 PM, Brian Baldino (bbaldino) wrote:
>>    >> > > Attached is the doc describing the coordinate system
>>    proposal which
>>    >> > will
>>    >> > > be presented next week; wanted to send it out now to give
>>    everyone a
>>    >> > > chance to read it over.
>>    >> > >
>>    >> > > -Brian
>>    >> >
>>    >> > _______________________________________________
>>    >> > clue mailing list
>>    >> > [email-masked] <mailto:[email-masked]>
>>    >> > https://www.ietf.org/mailman/listinfo/clue
>>    >> _______________________________________________
>>    >> clue mailing list
>>    >> [email-masked] <mailto:[email-masked]>
>>    >> https://www.ietf.org/mailman/listinfo/clue
>>    >
>>    >
>>    > _______________________________________________
>>    > clue mailing list
>>    > [email-masked] <mailto:[email-masked]>
>>    > https://www.ietf.org/mailman/listinfo/clue
>>    >
>>    >
>>
>>
>>
>>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 14 Nov 2011 15:49:03 -0800

> I'd prefer to use x,y,z for left-right, back-front, up-down.
That's fine with me too.

As for using 2 points or 4 points or some other way of describing the area, it does get a bit tricky if you want to be really exact about it.  Using only two points would mean we have to make some other limitations about the orientation of the rectangular area (and confine it to a rectangle).  I thought we probably don't want to impose those limitations.  I was thinking we use 4 points in the same plane to define a quadrilateral.  I think it would work out fine if implementers used these 4 points to define rectangles perpendicular to the floor even if it isn't exactly correct for the angle of the camera.  But I'm open to other ideas.

Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marshall Eubanks
Sent: Tuesday, November 15, 2011 7:05 AM
To: Christian Groves
Cc: [email-masked]
Subject: Re: [clue] CLUE Coordinate system proposal

> I'd prefer to use x,y,z for left-right, back-front, up-down.

I prefer too as well. I think it matches general use. I made my proposal purely in case some people felt strongly that we need to do something non-standard.

 Do long as its
> used consistently I think its more intuitive than coming up with yet 

Agree

Marshall

---

From: Stephen Botzko <[email-masked]>
Date: Tue, 15 Nov 2011 08:38:09 +0800

I agree that x,y,z is best.

 Two points for rectangles only works if the point of capture is also
signaled (otherwise you can not determine the plane).  Since signaling
point of capture is optional, I prefer to send all four points. (it also
somewhat simplifies the computation needed in the receiver).

Stephen Botzko

On Tue, Nov 15, 2011 at 7:49 AM, Duckworth, Mark <[email-masked]

> As for using 2 points or 4 points or some other way of describing the
> area, it does get a bit tricky if you want to be really exact about it.
>  Using only two points would mean we have to make some other limitations
> about the orientation of the rectangular area (and confine it to a
> rectangle).  I thought we probably don't want to impose those limitations.
>  I was thinking we use 4 points in the same plane to define a
> quadrilateral.  I think it would work out fine if implementers used these 4
> points to define rectangles perpendicular to the floor even if it isn't
> exactly correct for the angle of the camera.  But I'm open to other ideas.
>
> Mark
>
> Marshall Eubanks
> I prefer too as well. I think it matches general use. I made my proposal
> purely in case some people felt strongly that we need to do something
> non-standard.
>
>  Do long as its

---

From: Paul Coverdale <[email-masked]>
Date: Tue, 15 Nov 2011 08:43:21 +0800

For the camera direction, wouldn't it be more logical to define it in
azimuth-elevation (in  degrees)? 

.Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephen Botzko
Sent: Tuesday, November 15, 2011 8:38 AM
To: Duckworth, Mark
Cc: [email-masked]
Subject: Re: [clue] CLUE Coordinate system proposal

 Two points for rectangles only works if the point of capture is also
signaled (otherwise you can not determine the plane).  Since signaling point
of capture is optional, I prefer to send all four points. (it also somewhat
simplifies the computation needed in the receiver).

Stephen Botzko

That's fine with me too.

As for using 2 points or 4 points or some other way of describing the area,
it does get a bit tricky if you want to be really exact about it.  Using
only two points would mean we have to make some other limitations about the
orientation of the rectangular area (and confine it to a rectangle).  I
thought we probably don't want to impose those limitations.  I was thinking
we use 4 points in the same plane to define a quadrilateral.  I think it
would work out fine if implementers used these 4 points to define rectangles
perpendicular to the floor even if it isn't exactly correct for the angle of
the camera.  But I'm open to other ideas.

Mark

-----Original Message-----

 Do long as its

Agree

Marshall

---

From: Stephen Botzko <[email-masked]>
Date: Tue, 15 Nov 2011 08:52:08 +0800

I would rather not mix cartesian and polar coordinates.

For multiple cameras, using degrees only works if you use the camera
location as the origin of the polar coordinate system for that camera.
Having multiple origins in the coordinate system seems needlessly complex.

Steve B.

On Tue, Nov 15, 2011 at 8:43 AM, Paul Coverdale <[email-masked]>wrote:

> For the camera direction, wouldn’t it be more logical to define it in
> azimuth-elevation (in  degrees)? ****
>
> ** **
>
> …Paul****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Stephen Botzko
> *Sent:* Tuesday, November 15, 2011 8:38 AM
> *To:* Duckworth, Mark
>
> *Cc:* [email-masked]
> *Subject:* Re: [clue] CLUE Coordinate system proposal****
>
> ** **
>
> ****
> On Tue, Nov 15, 2011 at 7:49 AM, Duckworth, Mark <
> [email-masked]> wrote:****
>
> > I'd prefer to use x,y,z for left-right, back-front, up-down.****
>
> That's fine with me too.
>
> Mark****
> https://www.ietf.org/mailman/listinfo/clue****
>
> ** **
>

---

From: Michael Hammer <[email-masked]>
Date: Mon, 14 Nov 2011 20:07:03 -0500

You would still need to explain somewhere how x, y, and z map to:

H-orizontal
V-ertical
D-epth

Mike

On Mon, Nov 14, 2011 at 5:31 PM, Christian Groves <
[email-masked]> wrote:

>> [email-masked] <mailto:marshall.eubanks@**gmail.com<[email-masked]>>>
>> wrote:
>>
>>    [mailto:[email-masked] <mailto:[email-masked]>**] On
>>    Behalf
>>    >> Of
>>    >> > Paul Kyzivat
>>    >> > ______________________________**_________________
>>    >> > clue mailing list
>>    >> > https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>    >> ______________________________**_________________
>>    >> clue mailing list
>>    >> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>    >
>>    >
>>    > ______________________________**_________________
>>    > clue mailing list
>>    > https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>    >
>>    >
>>
>>
>>
>>
>> ______________________________**_________________
>> clue mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>
> ______________________________**_________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Nov 2011 20:12:36 -0500

> another naming convention.

I have now seen two mappings of xyz to real world in the docs:
x:left-right, y:back-front, z:up-down
x:left-right, y:up-down, z:back-front

Can people agree which it is?

When using 4 points to define the plane-of-interest, there is the 
potential that the four points are not coplanar.
Of course from a normative perspective we can just say "don't do that", 
but implementers will need to do something if it happens.

	Thanks,
	Paul

---

From: Stephen Botzko <[email-masked]>
Date: Tue, 15 Nov 2011 09:16:23 +0800

The framework draft already does that in section 5.3.4.

Stephen Botzko

---

From: Stephen Botzko <[email-masked]>
Date: Tue, 15 Nov 2011 09:24:35 +0800

(a) 5.3.4 in the framework states

However, it is specified that as numbers
   move from lower to higher, the location is going from: camera-left to
   camera-right (in the case of the 'x' dimension), front to back (in
   the case of the 'y' dimension or low to high (in the case of the 'z'
   dimension).

This would be x:left-right, y:back-front, z:up-down

Of course from a normative perspective we can just say "don't do
that", but implementers will need to do something if it happens.

I agree we should normatively say "don't do that".

Since we have no normative text on how receivers use any of this data
for rendering, perhaps we do not need to say what implementers need to
do in the non-coplanar case

Stephen Botzko

On Tue, Nov 15, 2011 at 9:12 AM, Paul Kyzivat <[email-masked]> wrote:

>>> On Mon, Nov 14, 2011 at 10:28 AM, Michael Hammer < [email-masked]
>>> ______________________________ _________________
>>> clue mailing list
>>> [email-masked]

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 14 Nov 2011 20:32:35 -0500

> This would be x:left-right, y:back-front, z:up-down

And this is what I would support.

Marshall

>>>>
> When using 4 points to define the plane-of-interest, there is the potential
> that the four points are not coplanar.
>
> Of course from a normative perspective we can just say "don't do that", but
> implementers will need to do something if it happens.
>>>>
>
> Since we have no normative text on how receivers use any of this data for
> rendering, perhaps we do not need to say what implementers need to do in the
> non-coplanar case
>
> Stephen Botzko
>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 14 Nov 2011 20:39:53 -0500

Huh.

While I see why you might like that, and of course we can make it work, it does seem much more natural to treat X/Y the way the capture and presentation devices do, and treat Z as back/front.

Brian

---

From: Stephen Botzko <[email-masked]>
Date: Tue, 15 Nov 2011 09:47:30 +0800

We could argue that tradeoff forever.

 Z as vertical is the "classic" cartesian system (
http://en.wikipedia.org/wiki/Cartesian_coordinate_system#Cartesian_coordinates_in_three_dimensions),
which I think is a significant advantage.  Though if this is the only point
of controversy, then we have made significant progress.

Stephen Botzko

On Tue, Nov 15, 2011 at 9:39 AM, Brian Rosen <[email-masked]> wrote:

> Huh.
>
> While I see why you might like that, and of course we can make it work, it
> does seem much more natural to treat X/Y the way the capture and
> presentation devices do, and treat Z as back/front.
>
> Brian
>
> but
> for

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 14 Nov 2011 20:50:09 -0500

> While I see why you might like that, and of course we can make it work, it does seem much more natural to treat X/Y the way the capture and presentation devices do, and treat Z as back/front.

Which is why I suggested ADV. Z is classically vertical. If there is
another community for which is not, then (IMHO) we should use ADV.

Marshall

---

From: Paul Coverdale <[email-masked]>
Date: Tue, 15 Nov 2011 09:50:59 +0800

My thinking for using polar coordinates for the camera is that, from a
practical point of view, how do we figure out the Cartesian coordinates for
the 4 points that define the area of capture? 

.Paul

From: Stephen Botzko [mailto:[email-masked]] 
Sent: Tuesday, November 15, 2011 8:52 AM
To: Paul Coverdale
Cc: Duckworth, Mark; [email-masked]
Subject: Re: [clue] CLUE Coordinate system proposal

Steve B.

On Tue, Nov 15, 2011 at 8:43 AM, Paul Coverdale <[email-masked]>
wrote:

.Paul

Cc: [email-masked]

Stephen Botzko

That's fine with me too.

Mark

-----Original Message-----

 Do long as its

Agree

Marshall

---

From: Stephen Botzko <[email-masked]>
Date: Tue, 15 Nov 2011 10:40:03 +0800

I see no issue with figuring out the Cartesian coordinates on the sender
side.

I see lots of issues dealing with polar coordinates in receivers, in
particular it is very hard to compute whether two captures are adjacent or
not - which is the single most important piece of information.

Stephen Botzko

On Tue, Nov 15, 2011 at 9:50 AM, Paul Coverdale <[email-masked]>wrote:

> the 4 points that define the area of capture? ****
>
> ** **
>
> …Paul****
>
> ** **
>
> *From:* Stephen Botzko [mailto:[email-masked]]
> *Sent:* Tuesday, November 15, 2011 8:52 AM
> *To:* Paul Coverdale
> *Cc:* Duckworth, Mark; [email-masked]
>
> Steve B.****
> wrote:****
> *To:* Duckworth, Mark****
>
>
> *Cc:* [email-masked]
> Stephen Botzko****

---

From: John Leslie <[email-masked]>
Date: Mon, 14 Nov 2011 21:46:52 -0500

Brian Rosen <[email-masked]> wrote:
> 
> While I see why you might like that, and of course we can make it
> work, it does seem much more natural to treat X/Y the way the
> capture and presentation devices do, and treat Z as back/front.

   I'm going to disagree with Brian here.

   Z as back/front _is_ normal when processing video; but that's not
what we're trying to define here -- we're trying to relate the camera
to the room (whether the actual room or some virtual room).

   Thus, _room_ coordinates are to be preferred to _video_ coordinates.

   (YMMV, I suppose...)

--
John Leslie <[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Nov 2011 21:48:33 -0500

> The framework draft already does that in section 5.3.4.

Yes, but the framework slides from yesterday have a "Directionality" 
slide that has z being front to back.

I don't much care, as long as everybody has the same definition.

	Thanks,
	Paul

> Stephen Botzko
>
> On Tue, Nov 15, 2011 at 9:07 AM, Michael Hammer <[email-masked]
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         I'd prefer to use x,y,z for left-right, back-front, up-down. Do
>         long as its used consistently I think its more intuitive than
>         coming up with yet another naming convention.
>
>         Christian
>
>             I was still assuming the z component was used, thus tilt
>             detectable (delta z values)
>
>             <[email-masked]
>             <mailto:[email-masked]>
>             <mailto:[email-masked]
>             <mailto:[email-masked]>>> wrote:
>
>                 On Mon, Nov 14, 2011 at 10:28 AM, Michael Hammer
>             <[email-masked] <mailto:[email-masked]>
>             <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>              > 1. This is a very good start to clearly explaining the
>             frame of
>                 reference.
>             <[email-masked] <mailto:[email-masked]>
>             <mailto:[email-masked] <mailto:[email-masked]>>>
>              > wrote:
>              >>
>              >> This material is potentially for the framework document,
>             not a
>                 separate
>              >> relations. It fleshes out the point and area that are
>             already
>                 descried
>              >> in the document. Whatever the WG decides will get put
>             into the
>                 framework
>              >> The slides and this note are the same. As Brian
>             mentioned, we
>                 thought it
>              >> would be a good idea to make the material available to
>             people
>                 for them
>              >> to think about prior to hearing about it in the slides
>             that are
>                 going to
>              >> > From: [email-masked]
>             <mailto:[email-masked]> <mailto:[email-masked]
>             <mailto:[email-masked]>>
>                 [mailto:[email-masked]
>             <mailto:[email-masked]> <mailto:[email-masked]
>             <mailto:[email-masked]>>__] On
>                 Behalf
>              >> Of
>              >> > Paul Kyzivat
>             <mailto:[email-masked] <mailto:[email-masked]>>
>              >> > Do you intend to publish this as a draft once we get
>             past the
>              >> blackout?
>              >> >
>              >> > This seems to be largely replicated in the framework
>             slides
>                 for the
>              >> > > be presented next week; wanted to send it out now to
>             give
>                 everyone a
>              >> > > chance to read it over.
>              >> > >
>              >> > > -Brian
>              >> >
>              >> > _________________________________________________
>              >> > clue mailing list
>             <mailto:[email-masked] <mailto:[email-masked]>>
>              >> > https://www.ietf.org/mailman/__listinfo/clue
>             <https://www.ietf.org/mailman/listinfo/clue>
>              >> _________________________________________________
>              >> clue mailing list
>             <mailto:[email-masked] <mailto:[email-masked]>>
>              >> https://www.ietf.org/mailman/__listinfo/clue
>             <https://www.ietf.org/mailman/listinfo/clue>
>              >
>              >
>              > _________________________________________________
>              > clue mailing list
>             <mailto:[email-masked] <mailto:[email-masked]>>
>              > https://www.ietf.org/mailman/__listinfo/clue
>             <https://www.ietf.org/mailman/listinfo/clue>
>              >
>              >
>
>
>
>
>             _________________________________________________
>             clue mailing list
>             https://www.ietf.org/mailman/__listinfo/clue
>             <https://www.ietf.org/mailman/listinfo/clue>
>
>         _________________________________________________
>         clue mailing list
>         https://www.ietf.org/mailman/__listinfo/clue
>         <https://www.ietf.org/mailman/listinfo/clue>
>
>
>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 14 Nov 2011 21:50:26 -0500

Okay, I see the point.

Brian

---

From: Christian Groves <[email-masked]>
Date: Wed, 16 Nov 2011 09:05:24 +1100

Hello Brian and Roni,

On the single capture system my understand is that it would be 
"optional" to send the capture co-ordinates. Is this correct? or? It 
seems that Roni assumes from the document that "need not" means "shall 
not" and Brian seems to assume Roni wants to say "shall send".

The proposal doesn't mention "area of scene" which is in the current 
framework document. Is the inference that this would be removed?

Regards, Christian

On 13/11/2011 2:45 AM, Roni Even wrote:
>
> Hi Brian,
>
> This proposal do not address the issue of knowing what is the gap 
> between the capture views at the row where people sit which we 
> discussed in the interim meeting unless the X is at the row of 
> participants or it is clear where it is so that it can be calculated. 
> If the origin is not known and the X axis position is not know it does 
> not provide the information.
>
> I think that it will not work when you have a system that can do both 
> the regular view and multiview since if you do not know where the X 
> axis is in relation to the row of participant the information will not 
> be enough to know which part of the row you see in the multiview if 
> the regular view will each show two participants.
>
> Roni
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Brian Baldino (bbaldino)
> *Sent:* Friday, November 11, 2011 9:00 PM
> *To:* Roni even; [email-masked]
> *Subject:* Re: [clue] CLUE Coordinate system proposal
>
> Hey Roni, inline.
>
> *From:*Roni even [mailto:[email-masked]]
> *Sent:* Friday, November 11, 2011 10:35 AM
> *To:* Brian Baldino (bbaldino); [email-masked]
> *Subject:* RE: CLUE Coordinate system proposal
>
> Hi Brian,
>
> co-ordinates if they can be used to scale to real size and maybe if 
> real co-ordinates (mm) are used can also provide relative scaling when 
> composing a mixed video.
>
> */[BB] I don’t believe it’s safe to assume that all devices will even 
> be able to know their geometry, so I don’t think it’s fair to require 
> that they send coordinates expressed in real-world dimensions./*
>
> the line of the people in front of the camera (Probably a straight 
> line between the two extreme people).
>
> */[BB] Not sure I follow all of this, but, the proposal does not allow 
> for expressing only a subset of dimensions when expressing the 
> coordinates (some of the diagrams leave a dimension out for purposes 
> of simplification, this is called out in the text). In an actual CLUE 
> caveat that a ‘NaN’-type value could be used, per some of Stephan’s 
> concerns). I also don’t think there’s anything in there that ties the 
> X plane explicitly to something like a row of participants—I’m not 
> sure that’s an assumption we’d want to build in. /*
>
> Regards
>
> Roni
>
> ------------------------------------------------------------------------
>
> *From:[email-masked] [[email-masked]] on behalf of 
> Brian Baldino (bbaldino) [[email-masked]]
> *Sent:* Friday, November 11, 2011 19:24
> *To:* [email-masked]
> *Subject:* [clue] CLUE Coordinate system proposal
>
> Attached is the doc describing the coordinate system proposal which 
> will be presented next week; wanted to send it out now to give 
> everyone a chance to read it over.
>
> -Brian
>
>
>

---

From: "Brian Baldino (bbaldino)" <[email-masked]>
Date: Tue, 15 Nov 2011 15:17:44 -0800

Hey Christian,
The slides/doc refer to the coordinates being optional, so a single
capture device need not provide coordinates but could if it so wished
(e.g. if it wanted to give the other side a sense of its real-world
dimensions). 

I did not mean to suggest that the area of scene was removed by not
mentioning it in the slides; the slides were more intended to explain
the workings of the coordinate system, not so much where the information
would be placed.

-Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Christian Groves
Sent: Tuesday, November 15, 2011 2:05 PM
To: [email-masked]
Subject: Re: [clue] CLUE Coordinate system proposal

Hello Brian and Roni,

Regards, Christian

> composing a mixed video.
>
> */[BB] I don't believe it's safe to assume that all devices will even 
> be able to know their geometry, so I don't think it's fair to require 

> concerns). I also don't think there's anything in there that ties the 
> X plane explicitly to something like a row of participants-I'm not 
> sure that's an assumption we'd want to build in. /*
>
> Regards
>
> Roni
>
>

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 15 Nov 2011 22:01:42 -0500

Here are two ideas on coordinates.

First : Our coordinates are obviously {Width, Height, Depth}, which we
can shorten to {x,y,z}. I think that that is much more mnemonic.

Second : That there be a variable, let's call it Coordinate_Type, with
the following possible values

Coordinate_Type = "Known" - values are in mm, as either measured or
built into the system.

Coordinate_Type = "Unknown" - values are quoted as in mm, but that is
purely nominal and the scale is unknown. For example, a mobile device
might report

Width = "500" mm, but that is just a nominal value, the actual depth
might be something different.

That would, BTW, allow consumers to adjust scale, maybe even on the
fly (by, say, detecting faces and scaling the image accordingly).

In this case, e.g., two captures with Width={0,250} and
Width={250,500} would imply captures that abut each other, and another
with Width={0,500} would completely encompass the first two in the
horizontal. You just wouldn't know the actual scale.

And, finally,

Coordinate_Type = "NoScale" - No scale is implied. All that is meant
that a coordinate of N+X is further {to the left, deeper into the
audience, higher}
than a coordinate of N, for X > 0.

NoScale should imply reflexivity, however, so that  two captures with
Width={0,250} and Width={251,252} would still imply captures that abut
each other, and another with Width={0,251} would completely encompass
the first two in the horizontal. The difference is that it would not
be proper to say anything  about the relative size of the two
captures, except that they do not abut each other. (This might easily
arise in a MCU setting, where two inputs use radically different
Virtual coordinate assignments.)

I believe that these 3 cases capture all of the use cases I have heard
in our various meetings. Did I miss any ?

Note that Coordinate_Type = "Known" can be treated as Coordinate_Type
= "Unknown", and Coordinate_Type = "Unknown" can be
treated as Coordinate_Type = "NoScale", so that composite images
should take the lowest coordinate type of any image in the composite.

Regards
Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 15 Nov 2011 22:19:47 -0500

> each other, and another with Width={0,251} would completely encompass

typo

s/251/252/

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Nov 2011 17:01:51 +0800

Clarification please:

On 11/16/11 11:19 AM, Marshall Eubanks wrote:

>> than a coordinate of N, for X>  0.
>>

Are these *real* numbers? Or integers? If integers, are they open or 
closed intervals?

In one example {0,250} is adjacent to {250,500}

in the other, {0,250} is adjacent to {252,252}.

You can't have it both ways. Since they can be mm, I presume these are 
real numbers, and so the latter set is is not really adjacent.

(And {252,252} seems like an uninteresting capture.)

	Thanks,
	Paul

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 16 Nov 2011 04:22:03 -0500

On Wed, Nov 16, 2011 at 4:01 AM, Paul Kyzivat <[email-masked]> wrote:
> Are these *real* numbers? Or integers? If integers, are they open or closed
> intervals?
>

That is a good question. I believe that integers are generally
assumed, and that one reason why
mm rather than m are used is to allow for integer variables.

> You can't have it both ways. Since they can be mm, I presume these are real
> numbers, and so the latter set is is not really adjacent.
>

Sorry,

{0,250} and {250,252} was what was meant. The point was that

- with virtual coordinates there is no real difference that can be
derived _in scale_ between {0,250} and {250,252}.
They are arbitrary choices EXCEPT that

- {0,250} and {250,252} implies adjacency while
  {0,250} and {251,252} does not

and, of course,  {0,250} is to the left of {250,252}

Regards
Marshall

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Nov 2011 17:29:29 +0800

On 11/16/11 5:22 PM, Marshall Eubanks wrote:
> On Wed, Nov 16, 2011 at 4:01 AM, Paul Kyzivat<[email-masked]>  wrote:
>> Clarification please:
>>

So then these are really [0,250), [250, 252) to have adjacency without 
overlap?

	Thanks,
	Paul

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 16 Nov 2011 05:20:42 -0500

On Wed, Nov 16, 2011 at 4:29 AM, Paul Kyzivat <[email-masked]> wrote:
>>> closed
>>> real

That is how I would interpret virtual coordinates.

{M,N}, {N, P}   M < N < P implies adjacency, while

{M,N}, {P, Q}   M < N < P < Q implies no adjacency

while both imply ordering. (By adjacency I mean being contiguous).

My assumption here is that virtual coordinates are likely to be of the form

{1}, {2}, {3} to imply left, middle, right screens.

Regards
Marshall

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Nov 2011 05:48:13 +0800

On 11/16/11 6:20 PM, Marshall Eubanks wrote:
> On Wed, Nov 16, 2011 at 4:29 AM, Paul Kyzivat<[email-masked]>  wrote:
> {M,N}, {N, P}   M<  N<  P implies adjacency, while
>
> {M,N}, {P, Q}   M<  N<  P<  Q implies no adjacency
>

OK. So these are just readings off a metric tape measure, to a 
resolution of mm. And for virtual ones they are readings off a tape 
measure with unknown resolution.

	Thanks,
	Paul

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 16 Nov 2011 17:10:47 -0500

On Wed, Nov 16, 2011 at 4:48 PM, Paul Kyzivat <[email-masked]> wrote:
> OK. So these are just readings off a metric tape measure, to a resolution of
> mm. And for virtual ones they are readings off a tape measure with unknown
> resolution.

Yes. I believe this captures the discussion that we have been having,
in person and on this list.

Marshall

---

From: Christian Groves <[email-masked]>
Date: Thu, 17 Nov 2011 10:43:35 +1100

"And for virtual ones they are readings off a tape measure with unknown 
resolution."

Just to clarify is it really "unknown and possibly changing resolution"? 
For me a tape measure implies a constant scale even if you don't know 
what it is. Maybe an elastic tape measure? :-)

Regards, Christian

On 17/11/2011 9:10 AM, Marshall Eubanks wrote:
> On Wed, Nov 16, 2011 at 4:48 PM, Paul Kyzivat<[email-masked]>  wrote:

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Nov 2011 08:54:33 +0800

> what it is. Maybe an elastic tape measure? :-)

I think that each capture set has one tape measure of unknown but fixed 
scale.

	Thanks,
	Paul

>>> resolution of

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 16 Nov 2011 19:56:07 -0500

On Wed, Nov 16, 2011 at 6:43 PM, Christian Groves
<[email-masked]> wrote:
> Just to clarify is it really "unknown and possibly changing resolution"? For
> me a tape measure implies a constant scale even if you don't know what it
> is. Maybe an elastic tape measure? :-)
>

Yes, I would agree.

"There is no metric information in virtual NoScale coordinates."

For example, a MCU could easily change their meaning when compositing images.

Regards
Marshall