Subject: [clue] Capture Attribute Discussion: 4.6.4. Telepresence

From: Christian Groves <[email-masked]>
Date: Thu, 13 Dec 2012 14:37:42 +1100

Hello,

The telepresence attribute is described in draft-groves-clue-capture-attr:

"4.6.4.  Telepresence

    In certain use cases scenarios it is important to maintain a feeling
    of "Telepresence" associated with captures when they are played at
    the remote end.  For example: in medical use cases it is important to
    maintain the colour of images.  It is important to note that CLUE is
    used to describe multi-stream conferences.  These may or may not be
    "telepresence" conferences.  Alternatively it could be assumed that
    all captures possess this attribute and the only captures not subject
    to processing to create "telepresence" this are those marked with
    "presentation".  We did discuss the aspect of how an endpoint
    determines if a capture relates to a computer generated image or a
    real environment.  An endpoint may apply different images processing
    depending on a source, i.e. it may or not apply image processing to
    adjust lighting levels for a telepresence experience.

    This parameter indicates that "telepresence" should be associated
    with the capture.  E.g. real world environmental conditions are
    associated with this capture.  Lighting, spatial and timing
    information are important aspects of the telepresence session. The
    remote should apply the appropriate capture processing to maintain
    integrity of this information.  For example: the colour related
    information associated with the original capture is important and
    should be replicated when displayed/played."

Does any one have concerns about adding this to the framework?

Regards, Christian

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 13 Dec 2012 18:04:03 +0100

This one seems so unspecific in its definition that I have no idea whether it is useful. 

There is nothing here that guarantees two devices will either set this or not set this when an identical set of conditions and usages exist at the two devices. 

In other words, there is too much hand waving involved in deciding whether it should be sent, and whether I can trust it if I receive it, to be useful.

I'd also question whether this is the right name for this concept, as I suspect many people have a view of telepresence that is wider than this, and will assume that definition rather than the one provided (unspecific though it is), with even more problems for interoperability.

As a suggestion, is it not possible to list a set of capabilities, and assign a precedence value to them, e.g. colour - apply a weighting of 90% in deciding the best capture.

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Christian Groves
> Sent: 13 December 2012 03:38
> To: [email-masked]
> Subject: [clue] Capture Attribute Discussion: 4.6.4. Telepresence
> 
> Hello,
> 
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Dec 2012 14:01:10 -0500

I agree with Keith, that there is *something* here but it needs 
significant refinement to make it tangible, and make it possible for an 
independent party to verify whether an implementation has conformed to 
it. (Or perhaps, how close the implementation comes to meeting it.)

For instance:
- are captures rendered at the indicated size?
- are multiple captures rendered in the appropriate spatial relationship 
to one another?

And this attribute suggests that some captures are more deserving of 
faithful rendering than others.

Obviously putting things in separate scenes is already an indication 
that rendering them in a particular spatial relationship to one another 
isn't important.

I don't really understand about color. I agree that it color faithful 
rendition might be more important for some captures than others. But I 
don't understand what the receiver would do differently if it knows 
this. Would it choose "better" monitors for the captures that need 
faithful color? Wouldn't that conflict with getting spatial 
relationships correct?

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Fri, 14 Dec 2012 10:14:34 +1100

Hello Keith and Paul,

I agree the way its defined is pretty loose. That's because I'm not sure 
exactly what form this should take. My feeling is also there's something 
there but it will need thrashing out.

I guess the initial trigger for this was the question "is CLUE only used 
for telepresence systems?". My assumption is that no it could be used by 
any system with multiple streams. The next question is that if an 
endpoint knew it was interacting with an endpoint seeking/offering a 
telepresence experience whether it would do anything different? We've 
defined a number of information element that are explicitly signalled 
between endpoints. However are there implicit assumptions that 
telepresence endpoints make today based on whether they connect to a 
telepresence endpoint or whether to simpler video conferencing equipment?

Q5/16 has done some work (H.TPS-AV) on defining parameters associated 
with telepresence systems. Much of it references the CLUE work however 
there are others that aren't signalled. It might be relevant for 
discussions.
http://wftp3.itu.int/av-arch/avc-site/2009-2012/1209_Bri/TD-39.zip

Please see my comments below.

Regards, Christian

On 14/12/2012 6:01 AM, Paul Kyzivat wrote:
> significant refinement to make it tangible, and make it possible for 
> an independent party to verify whether an implementation has conformed 
> to it. (Or perhaps, how close the implementation comes to meeting it.)
[CNG] I agree.
> - are multiple captures rendered in the appropriate spatial 
> relationship to one another?
[CNG] Yes these are the sort of assumptions I was thinking of.
> that rendering them in a particular spatial relationship to one 
> another isn't important.
>
[CNG] I was thinking more about what image processing it would do for 
colour balancing rather than choosing better monitors. Sect 7.3.1 of 
H.TPS-AV has some discussion of lighting for telepresence systems.
>> There is nothing here that guarantees two devices will either set 
>> this or not set this when an identical set of conditions and usages 
>> exist at the two devices.
>>
>> In other words, there is too much hand waving involved in deciding 
>> whether it should be sent, and whether I can trust it if I receive 
>> it, to be useful.
>>
>> I'd also question whether this is the right name for this concept, as 
>> I suspect many people have a view of telepresence that is wider than 
>> this, and will assume that definition rather than the one provided 
>> (unspecific though it is), with even more problems for interoperability.
>>
>> As a suggestion, is it not possible to list a set of capabilities, 
>> and assign a precedence value to them, e.g. colour - apply a 
>> weighting of 90% in deciding the best capture.
>>
>> Regards
>>
>> Keith
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Dec 2012 18:40:21 -0500

Christian,

While I am sympathetic to this, it seems like it could be controversial 
and a lot of work to get defined in a sufficient way. And I don't think 
it is *necessary* to do this to satisfy our current goals.

So I would prefer to see you take this one off the table *for now*.
If you want to come back later with a more fully fleshed out proposal 
then we can consider it.

We have a lot of other things that we must get done that we should focus 
on for now.

	Thanks,
	Paul