[M4IF Technotes] Sprite brightness change?

[Kris Huber]

Dear Yoshinori,
How about disallowing the value 0 for no_of_sprite_warping_points when
sprite_enable='GMC'?  In that case GMC prediction for the macroblock is
identical to the prediction done by the 'not_coded' bit without GMC.  Or do
I miss a subtle difference?
The semantics of no_of_sprite_warping_points in the text of clause 6.3.3
would change from
"
... the value of 4 is disallowed ...
"
to
"
... the values of 0 and 4 are disallowed ...
"
Thanks in advance for clarification,
Kris
-----Original Message-----
From: Yoshinori Suzuki [mailto:yosinori   crl.hitachi.co.jp]
Sent: Wednesday, March 06, 2024 6:49 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 Technotes] Sprite brightness change?
Dear Kris,
Thank your for the reply and the support on my editorial comment.
I also think that the brightness change could be a useful tool on the 
general GMC approach in principle. However, I selected to remove the 
brightness change tool from the GMC specification from the viewpoint of 
compulational complexity, since the AS or ACE profile does not support 
even the static sprite. 
Best regards,
Yoshinori Suzuki
Hitachi, Ltd.
Kris Huber wrote:
> 
> 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.
> _______________________________________________
> Technotes mailing list
> Technotes   lists.m4if.org
> http://lists.m4if.org/mailman/listinfo/technotes