Subject: [clue] Area of capture attribute

From: Roni Even <[email-masked]>
Date: Wed, 05 Oct 2011 08:03:11 +0200

Hi,

I read the new revision and I think that this attribute is a good starting
point to address the discussion on the spatial description. I hope that we
will be able to finalize the model in the Interim meeting.

I started a new thread after seeing the comments from Christian and Mark.

I will send more feedback on the draft in a separate email.

I think that there is some information missing that will be helpful

1.       The position of the origin of the axis  and the full range of the
area is needed probably as a capture set attribute in order to understand
the view. For example having a VC that says (0,33) does not provide enough
information to know what part of the room it covers. I do not think that
saying that there will be one configuration for example (VC1 (0,33),
VC2(33,66),VC3(66,99)) is the right way since it requires to have such
configuration and it also means that the range is (0,99) while it may also
be covering part of a (-10,110) range. The major requirement is not to use
implied information but be explicit.

2.       I think that it is important not only to have the X coordinates but
also have the Y coordinates to be able to know if there is a gap or overlap
at the relevant distance. Again the origin of the axes is crucial here.

3.       I am not sure about the example in section 7 for the active speaker
(VC3) "VC3- (the loudest panel stream), encoding group:EG1,
attributes:purpose=main;auto-switched:yes; area_of_capture={xBegin=0,
xEnd=99}". How do you know what is the area of capture you are really
getting, my understanding is that it is  implied that there are VC0,VC1 and
VC2 and you get one of them. Again, I prefer explicit information for this
case even if it means having at attribute that will specify that the switch
is between VC0, VC1 and VC2 or have it as part of the auto-switch attribute.

Regards 

Roni

  _____

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 5 Oct 2011 10:05:08 -0400

> at the relevant distance. Again the origin of the axes is crucial here.

I agree with both of these, which of course were both covered in my
original message on
this subject. Obviously, it takes 2 axes to define an area. (There are
4:3 and 16:9 capture / render
devices out there, so already just knowing the horizontal doesn't mean
you know the vertical.

> is between VC0, VC1 and VC2 or have it as part of the auto-switch attribute.

I assumed that the 0-99 range meant that it was switched and could be
anywhere within that range. I
think that that is confusing and not very informative - wouldn't it
make more sense to have a switched capture scene
be virtual, something like

VC3- (the loudest panel stream), encoding group:EG1, attributes:
purpose=main;auto-switched:yes; area_of_capture={one_of{VC0, VC1,
VC2}}

with a restriction that "one_of" lists MUST NOT be self-referential.

Regards
Marshall

>
>
> Regards
>
> Roni
>
>
>
> ________________________________
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>
>

---

From: "Brian Baldino (bbaldino)" <[email-masked]>
Date: Wed, 5 Oct 2011 10:42:47 -0700

Hey Roni,

Took my best shot inline.

-Brian

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roni Even
Sent: Tuesday, October 04, 2011 11:03 PM
To: [email-masked]
Subject: [clue] Area of capture attribute

Hi,

I read the new revision and I think that this attribute is a good
starting point to address the discussion on the spatial description. I
hope that we will be able to finalize the model in the Interim meeting.

I started a new thread after seeing the comments from Christian and
Mark.

1.       The position of the origin of the axis  and the full range of
the area is needed probably as a capture set attribute in order to
understand the view. For example having a VC that says (0,33) does not
provide enough information to know what part of the room it covers. I do
not think that saying that there will be one configuration for example
(VC1 (0,33), VC2(33,66),VC3(66,99)) is the right way since it requires
to have such configuration and it also means that the range is (0,99)
while it may also be covering part of a (-10,110) range. The major
requirement is not to use implied information but be explicit.

[BB] I think I agree that this might be useful, but, I'm not sure we've
come up with a use case that really demands it yet.  Let me see if what
I have in mind for what you described (and why the origin and full range
up front aren't needed there) makes sense:

I'm not sure what you've described (an advertiser only offering a single
video capture VC0(0,33)) would be that common (as, like you said, it
isn't very useful) but if it did, I still think the renderer could
render it sensibly.  Since there are no other captures advertised, the
renderer does not need to be careful about rendering the VC in a certain
position relative to other captures from that same device because there
are none.  In your example: if a 3 camera endpoint only advertised its
left camera as VC0(0,33) a 3 screen endpoint on the other end could
render it wherever it wanted because its main concern (making sure
cameras from a multi-camera transmitter are placed correctly relative to
one another) is no longer an issue.  Perhaps there is a scenario unlike
what I've just described where, even though only one small subset of the
entire device was advertised, it was important to render it in exactly
one place.  Do you know of an example where that may be the case?

2.       I think that it is important not only to have the X coordinates
but also have the Y coordinates to be able to know if there is a gap or
overlap at the relevant distance. Again the origin of the axes is
crucial here.

[BB] The document provides for describing the area of capture in up to 3
dimensions(x, y and z); seems like that gives the flexibility you're
looking for?  

3.       I am not sure about the example in section 7 for the active
speaker (VC3) "VC3- (the loudest panel stream), encoding group:EG1,
attributes:purpose=main;auto-switched:yes; area_of_capture={xBegin=0,
xEnd=99}". How do you know what is the area of capture you are really
getting, my understanding is that it is  implied that there are VC0,VC1
and VC2 and you get one of them. Again, I prefer explicit information
for this case even if it means having at attribute that will specify
that the switch is between VC0, VC1 and VC2 or have it as part of the
auto-switch attribute.

[BB] The idea here is that the transmitter is showing you the most
appropriate subset of that range.  You're right the receiver doesn't
know specifically what's being sent, but, why does it care?  The
receiver signed up for getting the most relevant stream in that range
and that's what the transmitter will send it.  What do you think the
receiver needs to know? 

Regards 

Roni

---

From: "Brian Baldino (bbaldino)" <[email-masked]>
Date: Wed, 5 Oct 2011 10:47:40 -0700

Hey Marshall, responded to your last point inline.

-Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marshall Eubanks
Sent: Wednesday, October 05, 2011 7:05 AM
To: Roni Even
Cc: [email-masked]
Subject: Re: [clue] Area of capture attribute

with a restriction that "one_of" lists MUST NOT be self-referential.
[BB] This seems a bit restrictive, what is the information we're really looking to get here?  What area of capture the switched stream currently contains at any given point?  What discrete areas of capture it could possibly contain?  How do we imagine this information would be used?  Would like to get a better idea of the use case.

Regards
Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 5 Oct 2011 14:44:27 -0400

On Wed, Oct 5, 2011 at 1:42 PM, Brian Baldino (bbaldino)
<[email-masked]> wrote:
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni
> Even
> [BB] I think I agree that this might be useful, but, I’m not sure we’ve come
> up with a use case that really demands it yet.  Let me see if what I have in
> mind for what you described (and why the origin and full range up front
> aren’t needed there) makes sense:
>
> I’m not sure what you’ve described (an advertiser only offering a single
> video capture VC0(0,33)) would be that common (as, like you said, it isn’t
> very useful) but if it did, I still think the renderer could render it
> sensibly.  Since there are no other captures advertised, the renderer does
> not need to be careful about rendering the VC in a certain position relative
> to other captures from that same device because there are none.  In your
> example: if a 3 camera endpoint only advertised its left camera as VC0(0,33)
> a 3 screen endpoint on the other end could render it wherever it wanted
> because its main concern (making sure cameras from a multi-camera
> transmitter are placed correctly relative to one another) is no longer an
> issue.  Perhaps there is a scenario unlike what I’ve just described where,
> even though only one small subset of the entire device was advertised, it
> was important to render it in exactly one place.  Do you know of an example
> where that may be the case?
>
> dimensions(x, y and z); seems like that gives the flexibility you’re looking
> for?
>

Ah, I missed that - it's implicit in 5.2.4. (I searched on vertical,
which is nowhere mentioned.) Obviously, this could use some wording
tweaks, which I promised to provide.

In 5.2.4, I suggest you start with

The area_of_capture attribute is used to describe the relevant area of
which a media capture is "capturing".
Area of capture is expressed as pairs of  {x, y, z} coordinates to
describe {left to right, front to back, low to high} ranges in that
order where, as with point_of_capture, only the necessary dimensions
need be expressed. In other words, it is specified that, as numbers
move from lower to higher, the location is going from: left to 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).

 In 5.2.6. it says

 Area Scale Millimeters
An optional Boolean variable indicating if the numbers used for area
of capture and point of capture are in terms of millimeters. If this
attribute is true, then the x,y,z numbers represent millimeters. If
this attribute is false, then there is no physical scale. The default
value is false.

Note that "degrees" are not mentioned anywhere in the document.
Degrees may not be a physical scale, but they are still a scale. (If
you interpret {0,33} as radians or pixels, you are unlikely to get
pleasing results.) There is another issue, as I don't know what the
equivalent to angles are for front to back.

I would change " If this attribute is false, then there is no physical
scale."  to

 " If this attribute is false, then the  scale for x and z is degrees,
and the scale for y remains mm."

If you have another default scale for y, you should specify it (I
can't imagine what it would be.)

(BTW, I believe that I suggested y being up and down and z being front
to back, precisely because most people will specify x, fewer up-down,
and fewest front back distances. If you do that, you have to switch
the definition of left and right to stage-left and stage-right to keep
a right handed system.)

In Section 3, it says.

Left: For media captures, left and right is from the point of view of
a person observing the rendered media.

This is the opposite of stage-left and stage-right, and would be
called camera-left  and camera-right in American TV.

In other words, "left" and "right" are camera-left  and camera-right
in theatrical parlance, and are the opposite of left and right for the
person being observed.

Actually, I would strongly urge the  definition and _explicit_ use of
camera-left and camera-right (or stage-left and stage-right)  in EVERY
occurrence of their use.

If we don't do that, I am willing to bet someone will mess it up.

So, if you do this, the definition becomes

Camera-Left: For media captures, camera-left and camera-right is from
the point of view of a person observing the rendered media. They are
the opposite of stage-left and stage-right, which are the left and
right of the person being observed.

Note also that front and back are not defined. They should be. Up and
down I think can go undefined.

Front. Front is the portion of the room closest to the cameras. In
going towards back you move away from the cameras.

> appropriate subset of that range.  You’re right the receiver doesn’t know
> specifically what’s being sent, but, why does it care?  The receiver signed
> up for getting the most relevant stream in that range and that’s what the
> transmitter will send it.  What do you think the receiver needs to know?
>

To scale the image appropriately. For example, if VC3 is really VC1,
that could maybe be shown
in full. If VC3 is really VC0+VC1+VC3 composited together, it should
be letter boxed.

I am also nervous about throwing away information when we don't have to.

Regards
Marshall

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 5 Oct 2011 14:15:51 -0700

I can see that degrees might be a useful scale for X and Z in addition to millimeters.  Maybe it should be tenths of a degree, and use integers (no floating point)?  So if we allow that, then we need a way to indicate the scale of area of capture and point of capture numbers which would be one of: none, millimeters, degrees.  And I think this scale indication applies to an entire capture set, not individual media captures.  Everything in a particular capture set must use the same scale.

When we introduced the area of capture concept, and using a millimeter scale, I thought that would eliminate the need for the Video Scale attribute we had before.  I now think we should bring back a separate Video Scale attribute, because the area of capture won't always be enough to tell the scale in terms of how large to render it to make it seem the appropriate size at the rendering side.  One example is an auto-switched video capture that covers 0 to 99 (area of capture), while at any one time it is only covering a third of it (video scale), so having a separate video scale attribute allows the renderer to scale it accordingly if it wants.  Now I wonder if the scale attribute really should be associated with a video stream in RTP, rather than with a video capture, because maybe it should be more dynamic than capture set advertisements.

Marshall, your definition of left and right makes good sense to me.

Mark Duckworth

> Marshall Eubanks
> Sent: Wednesday, October 05, 2011 2:44 PM
> To: Brian Baldino (bbaldino)
> Cc: [email-masked]
> starting
> > [BB] I think I agree that this might be useful, but, I'm not sure
> we've come
> > aren't needed there) makes sense:
> >
> isn't
> > issue.  Perhaps there is a scenario unlike what I've just described
> where,
> looking
> (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).
> 
> 
>  In 5.2.6. it says
> 
>  Area Scale Millimeters
> speaker
> know
> > specifically what's being sent, but, why does it care?  The receiver
> signed
> > up for getting the most relevant stream in that range and that's what
> the

---

From: Roni Even <[email-masked]>
Date: Wed, 05 Oct 2011 23:22:18 +0200

Brian,

Inline

Roni

From: Brian Baldino (bbaldino) [mailto:[email-masked]] 
Sent: Wednesday, October 05, 2011 7:43 PM
To: Roni Even; [email-masked]
Subject: RE: [clue] Area of capture attribute

Hey Roni,

-Brian

Hi,

[BB] I think I agree that this might be useful, but, I'm not sure we've come
up with a use case that really demands it yet.  Let me see if what I have in
mind for what you described (and why the origin and full range up front
aren't needed there) makes sense:

video capture VC0(0,33)) would be that common (as, like you said, it isn't
issue.  Perhaps there is a scenario unlike what I've just described where,

[Roni] I hope you followed the discussion on the list about gaps between
captures. This is a use case where you need the origin and the X,Y
coordinates. I think that also the multiview use case will need it. It will
not be needed if there is a hidden  assumption that the area describes the
range at the line where the first row of people is at. Some systems may
decide that this measure is at the back of the room.

You claim that by having all the different video captures I can learn the
range of the room and I say why learn it from all the specified captures
provide it separately. I am not sure why you are trying to optimize the
provided information.

[BB] The document provides for describing the area of capture in up to 3
dimensions(x, y and z); seems like that gives the flexibility you're looking
for?  

[Roni] My claim is that you must provide at least X and Y

[BB] The idea here is that the transmitter is showing you the most
appropriate subset of that range.  You're right the receiver doesn't know
specifically what's being sent, but, why does it care?  The receiver signed
up for getting the most relevant stream in that range and that's what the
transmitter will send it.  What do you think the receiver needs to know? 

[Roni} you want to know in order to choose between VC3, VC4, VC5 which offer
similar proposal. The  consumer will need to select the most relevant
stream, for VC3 note that for auto-switch according to 5.2.8 "In this case
the offered AC or VC varies depending on some rule"  which hints that it may
be not only loudest speaker so you do not really know what auto-switch
means. I will continue to insist on providing explicit information from the
provider to the consumer so he can make a sensible selection and to enable
extensibility. In this case it will be the providing the auto switching
algorithm.

Regards 

Roni

---

From: Stephen Botzko <[email-masked]>
Date: Thu, 6 Oct 2011 07:20:52 -0400

In order to get actual-size information with field-of-view in degrees, you
need to know the distance from the camera to the first row (which right now
is implicit in the mm scale).

This suggests a couple of mathematically equivalent alternatives:
(a) provide both MM scale and field of view in degrees.  If someone needed
the distance to the first row, it could be computed.
(b) provide MM scale and the distance to the first row.  In this
combination, field-of-view in degrees can be computed.

(b) has an advantage in that it can be extended to include multiple rows.

On Wed, Oct 5, 2011 at 5:15 PM, Duckworth, Mark
<[email-masked]>wrote:

> I can see that degrees might be a useful scale for X and Z in addition to
> millimeters.  Maybe it should be tenths of a degree, and use integers (no
> floating point)?  So if we allow that, then we need a way to indicate the
> scale of area of capture and point of capture numbers which would be one of:
> none, millimeters, degrees.  And I think this scale indication applies to an
> entire capture set, not individual media captures.  Everything in a
> particular capture set must use the same scale.
>
> When we introduced the area of capture concept, and using a millimeter
> scale, I thought that would eliminate the need for the Video Scale attribute
> we had before.  I now think we should bring back a separate Video Scale
> attribute, because the area of capture won't always be enough to tell the
> scale in terms of how large to render it to make it seem the appropriate
> size at the rendering side.  One example is an auto-switched video capture
> that covers 0 to 99 (area of capture), while at any one time it is only
> covering a third of it (video scale), so having a separate video scale
> attribute allows the renderer to scale it accordingly if it wants.  Now I
> wonder if the scale attribute really should be associated with a video
> stream in RTP, rather than with a video capture, because maybe it should be
> more dynamic than capture set advertisements.
>

---

From: Michael Hammer <[email-masked]>
Date: Thu, 6 Oct 2011 10:22:16 -0400

This discussion about the scale and distance to first row sounds a lot like
the definition of the aperature of a camera lens.  If so, lenses often have
a focal point which could be up close or distant along with a depth of
field.  Sometimes stuff in the foreground or distance or both are out of
focus.  Presumable, the cameras used for capture have already built-in in
such a range/depth determination that could be used.  Zoom lenses that might
be dynamic might also have some type of settings to exploit.

Camera/lens vendors would be useful here.

Mike

On Thu, Oct 6, 2011 at 7:20 AM, Stephen Botzko <[email-masked]>wrote:

> On Wed, Oct 5, 2011 at 5:15 PM, Duckworth, Mark <
> [email-masked]> wrote:
>

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 6 Oct 2011 10:57:25 -0400

> (b) has an advantage in that it can be extended to include multiple rows.

In a kludgy way (mm means mm, except for the second row, when it
doesn't). I prefer

(c) Provide the FOV in degrees and a scale factor (standard length).

Is there any reason why this shouldn't be (possibly) included
for every scene captured, including possibly sub-scene. (In other
words, how do you determine the distance to the second row without
information about that scale factor.)

I am also specifically interested in including podium type situations,
which are not "rows."

Regards
Marshall

>
> On Wed, Oct 5, 2011 at 5:15 PM, Duckworth, Mark <[email-masked]>
> wrote:
>>

---

From: Stephen Botzko <[email-masked]>
Date: Thu, 6 Oct 2011 11:09:32 -0400

Not sure how that is different from (a); it seems the same to me.  Maybe we
can discuss next week

Stephen Botzko

On Thu, Oct 6, 2011 at 10:57 AM, Marshall Eubanks <
[email-masked]> wrote:

> >> > > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >> > Of Roni
> >> > > Even
> >> > > configuration and it also means that the range is (0,99) while it
> may
> >> > also
> >> > > sensibly.  Since there are no other captures advertised, the
> renderer
> >> > does
> >> > > VC2 and you get one of them. Again, I prefer explicit information
> for
> >> > this

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 6 Oct 2011 11:24:08 -0400

> Not sure how that is different from (a); it seems the same to me.  Maybe we

a) provide both MM scale and field of view in degrees.

I interpreted this as something like

area_of_capture  for Camera 1 is (0, 33 degrees) OR (0, 245 mm)

I am proposing something like

FOV for Camera 1 is
area_of_capture={xBegin=0, xEnd=33}
point_of_interest=(ypoint="425" , type="Row 1")

If this is done I would suggest certain specific default "types" -
"Row {i}", "Podium {i}", etc.

If area of capture is defined in angular units, then point_of_interest
can always be in mm.

Regards
Marshall

P.S. In preparing this email I noticed that the point_of_capture
_format_ seems to be defined nowhere.
I would suggest

point_of_capture=(xpoint="15")

as a suitable format.

> Stephen Botzko
>
> On Thu, Oct 6, 2011 at 10:57 AM, Marshall Eubanks
> <[email-masked]> wrote:
>>
>> >> > > up with a use case that really demands it yet.  Let me see if what
>> >> > > I
>> >> > have in
>> >> > > case even if it means having at attribute that will specify that
>> >> > > the
>> >> > switch

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Oct 2011 12:16:29 -0400

(As individual)

Comment on one point. I've trimmed out the rest of the discussion.

On 10/5/11 1:42 PM, Brian Baldino (bbaldino) wrote:
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Roni Even
> *Sent:* Tuesday, October 04, 2011 11:03 PM
> *To:* [email-masked]
> *Subject:* [clue] Area of capture attribute
>
> Hi,
>
> 1.The position of the origin of the axis and the full range of the area
> is needed probably as a capture set attribute in order to understand the
> view. For example having a VC that says (0,33) does not provide enough
> configuration and it also means that the range is (0,99) while it may
> also be covering part of a (-10,110) range. The major requirement is not
> to use implied information but be explicit.
>
> */[BB] I think I agree that this might be useful, but, I’m not sure
> we’ve come up with a use case that really demands it yet. Let me see if
> what I have in mind for what you described (and why the origin and full
> range up front aren’t needed there) makes sense:/*
>
> */I’m not sure what you’ve described (an advertiser only offering a
> single video capture VC0(0,33)) would be that common (as, like you said,
> it isn’t very useful) but if it did, I still think the renderer could
> what I’ve just described where, even though only one small subset of the
> one place. Do you know of an example where that may be the case?/*

Suppose someone is alone in a three-screen, three-capture room. He has 
turned off the cameras other than the one showing him. Depending on 
where he is sitting, it might be (0,33), (33,66), or (66,99).

If the receiving room also has three screens, it might chose to display 
this on any of its screens - perhaps by default the center one.

Later some other people come into the first room and the other cameras 
are turned on. This could result in the receiving room having to change 
the screen on which the first person is displayed. That could be a 
little annoying. That wouldn't happen if the "proper" screen had been 
used in the first place.

	Thanks,
	Paul

---

From: "Brian Baldino (bbaldino)" <[email-masked]>
Date: Thu, 6 Oct 2011 09:53:23 -0700

Hey Roni, inline again.

From: Roni Even [mailto:[email-masked]] 
Sent: Wednesday, October 05, 2011 2:22 PM
To: Brian Baldino (bbaldino); [email-masked]
Subject: RE: [clue] Area of capture attribute

Brian,

Inline

Roni

Hey Roni,

-Brian

Hi,

 

[Roni] I hope you followed the discussion on the list about gaps between
captures. This is a use case where you need the origin and the X,Y
coordinates. I think that also the multiview use case will need it. It
will not be needed if there is a hidden  assumption that the area
describes the range at the line where the first row of people is at.
Some systems may decide that this measure is at the back of the room.

You claim that by having all the different video captures I can learn
the range of the room and I say why learn it from all the specified
captures provide it separately. I am not sure why you are trying to
optimize the provided information.

[BB] I'm not saying we can't provide the entire range of the room up
front, maybe there's a good reason for it.  I still haven't heard why
the origin is necessary though to determine the gap between captures? 

[BB] If my producer only has captures which vary in 1 dimension, why
must I provide the Y coordinate?

[Roni} you want to know in order to choose between VC3, VC4, VC5 which
offer similar proposal. The  consumer will need to select the most
relevant stream, for VC3 note that for auto-switch according to 5.2.8
"In this case the offered AC or VC varies depending on some rule"  which
hints that it may be not only loudest speaker so you do not really know
what auto-switch means. I will continue to insist on providing explicit
information from the provider to the consumer so he can make a sensible
selection and to enable extensibility. In this case it will be the
providing the auto switching algorithm.

[BB] Ok, I think we're on the same page here...I think we may need a
more solid definition of 'auto-switched' or we'll need to enable the
producer to be more explicit.

Regards 

Roni

---

From: Stephen Botzko <[email-masked]>
Date: Thu, 6 Oct 2011 15:02:19 -0400

in-line

> area_of_capture  for Camera 1 is (0, 33 degrees) OR (0, 245 mm)
[sb] For (a) I meant "AND" not "OR", which would allow the ypoint to be
computed.  That is for a 33 degree field of view, you can compute the
distance to the plane where the capture is 245 mm wide.

> point_of_interest=(ypoint="425" , type="Row 1")
[sb] I guess for scale, you are thinking that I should compute the size of
the capture at ypoint as (2*425) * arctan (0.5 * (xEnd-xBegin))?  For most
of our envisioned use cases I need to know scale and adjacency, and not
FoV.  I'd prefer to limit the trig to the rarer scenarios if possible.  I am
also envisioning bugs related to degrees/radians...

Perhaps more importantly, I think this representation assumes that all
cameras are co-located.  At least, with angular units I do not see how to
relate xBegin and xEnd of camera 1 with the xBegin and Xend of camera 2
unless I assume that the cameras are co-located.

BTW, unless I made a math mistake, 245 mm capture width at a distance of 425
mm works out to a 34 degree FoV.  If I got this wrong, let me know.

> >> On Thu, Oct 6, 2011 at 7:20 AM, Stephen Botzko <
> [email-masked]>
> >> wrote:
> >> > need to know the distance from the camera to the first row (which
> right
> >> > now
> >> >> I can see that degrees might be a useful scale for X and Z in
> addition
> >> >> to
> >> >> none, millimeters, degrees.  And I think this scale indication
> applies
> >> >> to an
> >> >> attribute allows the renderer to scale it accordingly if it wants.
>  Now
> >> >> I
> >> >> > Of
> >> >> > > point to address the discussion on the spatial description. I
> hope
> >> >> > that we
> >> >> > > 1.       The position of the origin of the axis  and the full
> range
> >> >> > of the
> >> >> > > the view. For example having a VC that says (0,33) does not
> provide
> >> >> > enough
> >> >> > > information to know what part of the room it covers. I do not
> think
> >> >> > that
> >> >> > > be covering part of a (-10,110) range. The major requirement is
> not
> >> >> > to use
> >> >> > > very useful) but if it did, I still think the renderer could
> render
> >> >> > it
> >> >> > > not need to be careful about rendering the VC in a certain
> position
> >> >> > relative
> >> >> > > to other captures from that same device because there are none.
> In
> >> >> > your
> >> >> > > example: if a 3 camera endpoint only advertised its left camera
> as
> >> >> > VC0(0,33)
> >> >> > > was important to render it in exactly one place.  Do you know of
> an
> >> >> > example
> >> >> > > also have the Y coordinates to be able to know if there is a gap
> or
> >> >> > overlap
> >> >> > > [BB] The document provides for describing the area of capture in
> up
> >> >> > to 3
> >> >> > > transmitter will send it.  What do you think the receiver needs
> to
> >> >> > know?
> >> >> > >
> >> >> >
> >> >> > I am also nervous about throwing away information when we don't
> have
> >> >> > to.
> >> >> >
> >> >> > Regards
> >> >> > Marshall
> >> >> >
> >> >> > > Regards
> >> >> > > Roni

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 6 Oct 2011 18:13:26 -0400

On Thu, Oct 6, 2011 at 3:02 PM, Stephen Botzko <[email-masked]> wrote:
> in-line
>
> On Thu, Oct 6, 2011 at 11:24 AM, Marshall Eubanks

OK, so we are really proposing the same things, and just discussing
the most parsimonious representation.

> unless I assume that the cameras are co-located.

I don't see how the stating that

area_of_capture  for Camera 1 is (0, 33 degrees) AND (0, 245 mm)

avoids these issues.

> mm works out to a 34 degree FoV.  If I got this wrong, let me know.

Well, here is another area of fuzziness - are these FOV in mm chords
or circular segments ? I _bet_ that most will interpret FOV in degrees
as circular segments and FOV in mm as chords (those being the easiest
to measure). Now,

33 deg = .57596 radians so at a distance of 425 mm this corresponds to
a circular segment of 244.8 mm
and a chord of 241.4 mm

Is it possible you were calculating using the chord versus the
circular segment ? (I was using the circular segment.)

At any rate, all of this needs to be very precisely specified, unless
you go to my idea of specifying distances.

Regards
Marshall

>> >> On Thu, Oct 6, 2011 at 7:20 AM, Stephen Botzko
>> >> > In order to get actual-size information with field-of-view in
>> >> > degrees,
>> >> > you
>> >> >> millimeters.  Maybe it should be tenths of a degree, and use
>> >> >> integers
>> >> >> (no
>> >> >> floating point)?  So if we allow that, then we need a way to
>> >> >> indicate
>> >> >> the
>> >> >> attribute, because the area of capture won't always be enough to
>> >> >> tell
>> >> >> the
>> >> >> > > VC2(33,66),VC3(66,99)) is the right way since it requires to
>> >> >> > > have
>> >> >> > such
>> >> >> > > mind for what you described (and why the origin and full range
>> >> >> > > up
>> >> >> > front
>> >> >> > > I'm not sure what you've described (an advertiser only offering
>> >> >> > > a
>> >> >> > single
>> >> >> > > video capture VC0(0,33)) would be that common (as, like you
>> >> >> > > said,
>> >> >> > > it
>> >> >> > isn't
>> >> >> > > at the relevant distance. Again the origin of the axes is
>> >> >> > > crucial
>> >> >> > here.
>> >> >> > >
>> >> >> > The area_of_capture attribute is used to describe the relevant
>> >> >> > area
>> >> >> > of
>> >> >> > > is between VC0, VC1 and VC2 or have it as part of the
>> >> >> > > auto-switch
>> >> >> > attribute.
>> >> >> > >

---

From: Stephen Botzko <[email-masked]>
Date: Thu, 6 Oct 2011 18:39:54 -0400

In-line

On Thu, Oct 6, 2011 at 6:13 PM, Marshall Eubanks <[email-masked]

> >> > Not sure how that is different from (a); it seems the same to me.
> Maybe
> >> > we
> >> > can discuss next week
> >> >
> >>

Yes, I think we are actually pretty close.

> I believe the xBegin, xEnd framework in MM would avoid them, assuming the
distance (ypoint) defined the same plane for all cameras in the scene -
which is a plausible assumption in present commercial systems.

> circular segment ? (I was using the circular segment.)
I calculated the chord (I specified the formula in the earlier post)  34 deg
works out to a chord of 245.16...

> >> >> >> scale of area of capture and point of capture numbers which would
> be
> >> >> >> one of:
> >> >> >> > > I started a new thread after seeing the comments from
> Christian
> >> >> >> > > and
> >> >> >> > Mark.
> >> >> >> > >
> >> >> >> > > a 3 screen endpoint on the other end could render it wherever
> it
> >> >> >> > wanted
> >> >> >> > > transmitter are placed correctly relative to one another) is
> no
> >> >> >> > longer an
> >> >> >> > (in the case of the 'x' dimension), front to back (in the case
> of
> >> >> >> > the
> >> >> >> > the definition of left and right to stage-left and stage-right
> to
> >> >> >> > keep
> >> >> >> > a right handed system.)
> >> >> >> >
> >> >> >> > In Section 3, it says.
> >> >> >> >
> >> >> >> > Left: For media captures, left and right is from the point of
> view
> >> >> >> > of
> >> >> >> > in theatrical parlance, and are the opposite of left and right
> for
> >> >> >> > the
> >> >> >> > person being observed.
> >> >> >> >
> >> >> >> > Actually, I would strongly urge the  definition and _explicit_
> use
> >> >> >> > of
> >> >> >> > Note also that front and back are not defined. They should be.
> Up
> >> >> >> > and
> >> >> >> > > getting, my understanding is that it is  implied that there
> are
> >> >> >> > VC0,VC1 and
> >> >> >> > > up for getting the most relevant stream in that range and
> that's
> >> >> >> > > what
> >> >> >> > the