Re: [MMUSIC] New Version Notification for draft-abhishek-mmusic-superimposition-grouping-00.txt(Internet mail)

[Paul Kyzivat <[e-mail]>]

Rohit,

On 1/19/21 2:57 AM, rabhishek(RohitAbhishek) wrote:
> Hi Paul,
> 
> Thanks again for your feedback.
> 
> My comments below
> 
> On 1/18/21, 7:32 AM, "Paul Kyzivat" <[e-mail]> wrote:
> 
>      On 1/17/21 5:29 PM, rabhishek(RohitAbhishek) wrote:
> 
>      > Hi Paul, Christer,
> 
>      >
> 
>      > My understanding is the transparent attribute is same as alpha 
> compositing which would control the linear interpolation between the 
> foreground and the background pixels. Here’s an example wrt figure 1 in 
> the draft.
> 
>      First, I'm concerned with you starting your reply with "my 
> understanding
> 
>      is ...". This is your draft! The goal is to ensure that all readers 
> come
> 
>      to the same understanding. There should be no vagueness.
> 
> *Rohit: I will make sure to phrase it correctly moving forward **😃***
> 
>      Another thing: Section 5 says:
> 
>              transparency-attribute =
> 
>                           "a=transparency:" transparency-tag
> 
>              transparency-tag =tranparency-value *("," 
> tranparency-value) CRLF
> 
>              transparency-value= alpha
> 
>          Alpha describes the transparency for the foreground media 
> stream.  It
> 
>          is identified by its transparency-tag values in the transparency-
> 
>          attribute.  It could be an integer with values between 0 and 100.
> 
>          This is an informative value.  Details of interpretion to be left
> 
>          open to the renderer, expect that a value of 0 means foreground 
> media
> 
>          is opaque and value of 100 means that it is transparent.
> 
>       From an ABNF perspective "alpha" is undefined. The text says it 
> *could
> 
>      be" an integer between 0 and 100, but "details of interpretation are
> 
>      open to the renderer". That negates the value of creating a standard.
> 
>      The whole point of a standard is to ensure that interoperating parties
> 
>      handle things the same way.
> 
> *Rohit: The value can be between 0-1/0-10/0-100 with lowest value 
> indicating opaque and highest value indicates that it is transparent. 
>   Do you mean I should be specific with the values or will changing the 
> text to " expect that lowest value means foreground media is opaque and 
> highest value means that it is transparent" be acceptable?*

You have to imagine that the offerer and the answerer know nothing about 
each other. So the offerer needs to understand: is the value to be from 
0-1, 0-10, or 0-100? And is it an integer or a real.

So you need to decide this and put it in the spec. And define the syntax 
and associated normative text to make this clear.

And yes, also the significance of lower and higher values.

>      > X= Background Image
> 
>      > A, B, C= foreground image (Media C partially over B)
> 
>      > Transparency(to be applied each pixel) =alpha(A), beta (B), gamma (C)
> 
>      > Background media which shows through A= (1-alpha)X
> 
>      > Background media which shows through B and C = (1-beta)( 1-gamma)X
> 
>      > Overall composed image= gamma.C+ (1-gamma)[beta.B+ (1- beta.B)X]
> 
>      I don't know much about this technology, so perhaps this would be well
> 
>      known to implementers. But it shouldn't just be assumed. If this is 
> then
> 
>      intended mechanism then it should be specified in the document, either
> 
>      directly or by reference to some public document.
> 
> **
> 
> *Rohit: Will include the reference in the update*

That will help.

>      Finally, ISTM that you don't need to treat the background document 
> as a
> 
>      special case. The grouping mechanism can be used to identify all the
> 
>      media streams participating in this superposition mechanism, including
> 
>      the one you are considering to be the background.
> 
>      IIUC the scheme you describe defines the result of superposition based
> 
>      on the transparency values of the individual streams, so that no other
> 
>      ordering mechanism is needed. (Do I have that right?) If so, isn't the
> 
>      background just the media stream with tranparency = 100?
> 
> *Rohit: The ordering mechanism will be needed. Suppose we have a 
> background X with transparency=100, and a superimposed media A with 
> transparency=50. A over X would mean that X would visible partially 
> through A, however X over A would mean that A wouldn't show through X.*

If the ordering is needed, then you need to specify how it is 
determined. IMO it is permissible to use the order of values in the 
a=group: line to specify this ordering. (RFC5888 doesn't ascribe any 
semantics to this ordering of values, but neither does it forbid 
assigning meaning for particular grouping semantics.) I am not certain 
if Christer agrees with me on this point. The alternative is to use a 
new attribute in the grouped media descriptions for this purpose.)

And then you really need to specify the algorithm by which the layering 
plus the transparency is applied to the media streams to yield the 
composed media stream.

	Thanks,
	Paul