[M4IF Technotes] RE: [M4IF Interop] Sprite brightness change?

[Kris Huber]

Dear Yoshinori Suzuki,
Thanks for this important clarification that affects Advanced Simple and
Advance Coding Efficiency profiles.  I support your proposed modification of
text, unless all implementors of existing AS and ACE profile have in fact
included sprite brightness change.  But given the ambiguities, I suspect
they have not.
It seems that even for the static sprite, the brightness change
functionality has not been fully implemented in the reference software
decoder or encoder.  It is fully documented in the text of the standard,
although with the inadequacy of not encoding the case of unchanged
brightness except in the VOL header.
I think brightness change could be a useful coding tool in the GMC case, but
have no supporting research to back up that intuition.  The sorts of
camcorder sequences I shoot always use fade-in and fade-out, and I would
expect some bandwidth savings for content interspersed frequently with that
effect.  As I recall, one reason that the global motion compensation tool
was attractive was it's lower memory and computational complexity than
sprite-base coding, which would allow its use in real-time devices such as
camcorders and mobile video decoders.  In principle, brightness change is
much like quarter-pel MC.  Just as quarter-pel refines the reference VOP in
the spatial dimensions, brightness change refines it in the luminance
dimension.
Best regards,
Kris
-----Original Message-----
From: Yoshinori Suzuki [mailto:yosinori   crl.hitachi.co.jp]
Sent: Tuesday, March 05, 2024 6:51 PM
To: Kris Huber
Cc: 'technotes   lists.m4if.org'; 'interop   lists.m4if.org';
'tchiang   cc.nctu.edu.tw'; 'kldi   computer.org'; 'garysull   microsoft.com'
Subject: Re: [M4IF Interop] Sprite brightness change?
Dear Dr. Huber,
Thank you for the comments on brightness changes.
I have a comment on the GMC specification.
Kris Huber wrote:
> 
> Hello all,
> 
> Are there any test bitstreams exercising brightness change for the low
> latency sprite or GMC case?  I've noticed some ambiguity in MPEG-4 visual
> about how it is done, especially relative to how I think it should be
done.
> 
> Information about specs related to MPEG-4 visual in which
> sprite_brightness_change is required to be 0 would also be appreciated
> (ISMA?, existing implementations?).
> 
> I'll make a report of this MPEG-4 problem to individuals who may have
> opportunity to address it soon within the MPEG organization.  Please reply
> in the next day or two, and there is a chance that your view can be
> incorporated into the next MPEG visual problem report.

I am an original proposer of the GMC to MPEG.
First, I would like to make it known to you that 
"the GMC does NOT support the brightness change tool".
The sprite_brightness_change is the tool for sprite warping, 
not for the GMC prediction. 
However, that is not indicated the document clearly as you pointed out.
So, I think that we should add the following sentence to the 
semantics of sprite_brightness_change for clarification:
sprite_brightness_change: This is a one-bit flag which when set to '1' 
indicates a change in brightness during sprite warping, alternatively,
a value of '0' means no change in brightness.
Note that this vaule shall be '0' when sprite_enable == 'GMC'.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Any comments?
Best regards,
Yoshinori Suzuki
Hitachi, Ltd.