[M4IF Technotes] Sprite brightness change?

[Rob Koenen]

Think you need to carry this over to the MPEG Video reflector.
Rob
> -----Original Message-----
> From: Yoshinori Suzuki [mailto:yosinori   crl.hitachi.co.jp]
> Sent: Wednesday, March 06, 2024 17:49
> 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
> _______________________________________________
> Technotes mailing list
> Technotes   lists.m4if.org
> http://lists.m4if.org/mailman/listinfo/technotes
>