Subject: Re: [clue] Language re capture axis

From: Stephan Wenger <[email-masked]>
Date: Thu, 1 Mar 2012 17:01:12 +0000

Hi Christian,

No, it wouldn't (without the note, or a flag, or explicit information
about he axis of capture).

As I have shown on the whiteboard in Andover, the axis of capture of a
camera can be independent from the area of capture, if there is a digital
pan/zoom option build into the camera (as it is in most cameras nowadays).

I can live with all three options:
1) note only as originally proposed by me with modifications by Mark
(which basically disallows camera arrangements where the axis of capture
if very different from the field of capture without sender-side geometric
corrections, such as TeleSuite's old 130 degree lens with four fields of
capture)
2) A flag indicating that the axis of capture is not derivable from the
field of capture (as proposed by Roni), or
3) Independently defining area of capture and axis of capture.

Option 3 obviously would provide the most flexibility.

Is anyone here worried about wide angle lenses and a single high-res
sensor, whose output is split up into multiple fields?  If so, we may want
to go with option 3.

Stephan

On 2.29.2012 18:47 , "Christian Groves" <[email-masked]>
wrote:

>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
>
>On 1/03/2012 3:52 AM, Roni Even wrote:
>> 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
>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>>> Duckworth, Mark
>>> Sent: Wednesday, February 29, 2012 6:14 PM
>>> To: Paul Kyzivat; [email-masked]
>>> Subject: Re: [clue] Language re capture axis
>>>
>>> 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
>>>>
>>>> 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
>>
>_______________________________________________
>clue mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/clue
>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Thu, 1 Mar 2012 10:30:31 -0800

I still don't understand why the axis of capture is important.  The way I see it, the four points defining area of capture (a quadrilateral) are mapped to the four corner points of a video capture (a rectangle, typically with 16:9 aspect ratio).  So by mapping a quadrilateral to a rectangle, is this enough information for the consumer to figure out whatever it needs if it wants to perform some geometric correction?  Perhaps even without knowing the point of capture?

Example (view with fixed width font)

(the numbers I use are examples to show the point, not perfectly correct for a real world case)

Showing Area of Capture coordinates (for an area offset to the right of a camera that is pointed toward the area at an angle)

First a front view, from camera point of view:

                                       (100,200,30)

          (0,200,25)                        .

              .

              .

          (0,200,-25)                       .

                                       (100,200,-30)

Now a top view:

          (0,200,z)                    (100,200,z)

              .                             .

             .

          (0,0,0)

          Camera point of capture

It seems to me that if the area of capture is a trapezoid as shown, then the consumer will know that the interesting stuff on the right side of the image is at a smaller scale than the interesting stuff on the left side of the image.  It knows this because the larger scene height on the right and the smaller scene height on the left are mapped onto the same video height of the video capture.  So stuff on the right must be made smaller relative to stuff on the left to form the video capture.

So now if the consumer wants to correct for this, it knows it needs to expand the right side of the image relative to the left side when it renders.

Notice that the consumer does not need the point of capture and capture axis to figure this out.

I think this shows that Stephan's use case for the consumer to perform geometric correction can be met, hopefully without the need to specify in an RFC how geometric transformations and calculations are done.  That should be up to the consumer to do whatever it wants.

Am I missing anything here?

Mark

> Stephan Wenger

> Sent: Thursday, March 01, 2012 12:01 PM

> To: Christian Groves; [email-masked]

> No, it wouldn't (without the note, or a flag, or explicit information about he

> axis of capture).

> 1) note only as originally proposed by me with modifications by Mark (which

> basically disallows camera arrangements where the axis of capture if very

> different from the field of capture without sender-side geometric

> 2) A flag indicating that the axis of capture is not derivable from the field of

> capture (as proposed by Roni), or

> Is anyone here worried about wide angle lenses and a single high-res sensor,

> whose output is split up into multiple fields?  If so, we may want to go with

> option 3.

> On 2.29.2012 18:47 , "Christian Groves" <[email-masked]<mailto:[email-masked]>>

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

> >>> Of Duckworth, Mark

> >>> Personally, I'd rather just leave it out altogether because I think

> >>> it doesn't add anything that needs to be standardized.  But Stephan

> >>> thought it was important, so I was trying to find a way to say it in

> >>> an "accurate enough" way.

> >>>> From: [email-masked] [mailto:[email-masked]] On

> >>>> Behalf Of Paul Kyzivat

> >>>> source. Otherwise we run the risk that not all will correctly

> >>>> derive

> >>>>> *From:[email-masked] [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> *On

> >>>>> *To:* [email-masked]<mailto:[email-masked]>

> >>>>> [email-masked]<mailto:[email-masked]>

> >>>> [email-masked]<mailto:[email-masked]>

> >>> [email-masked]<mailto:[email-masked]>

> >> [email-masked]<mailto:[email-masked]>

> >[email-masked]<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>