[M4IF Technotes] Chroma components in inter4v mode

[Chandra Sekhar Reddy G]

hi,
not really completely connected to ME/MC/4MV or MPEG-4,
but shows how much is the (less) importance of chroma over luma.
just download this JPEG-2000 related publication.
http://jj2000.epfl.ch/jj_publications/papers/011.pdf
see the slides 30-39.
i am sorry, but this document size is of 11MB (eleven MB).
chandra
----- Original Message -----
From: "Christoph Lampert" <chl   math.uni-bonn.de>
To: <technotes   lists.m4if.org>
Sent: Monday, June 24, 2023 4:11 PM
Subject: RE: [M4IF Technotes] Chroma components in inter4v mode
> > +> Why was it chosen like that? It sound like that's exactly the wrong
> > +> position, because that might be wrong for _all_ of the four blocks.
> > +> Also, it makes motion search much more difficult.
> >
> > Most people don't use chroma at all in the motion search.
> > (Although they would get better quality if they did, given
> > sufficient processing power.)
>
> Of course, but in 16x16 mode, a good match for lumi is most
> likely also a good match for 8x8 chroma.
> In 4MV mode, this is simply not true, unless all 8x8 vectors
> are very close together. One "better" lumi 8x8 vector changes
> two 8x8 chroma vectors, maybe to the worse.
>
> Unfortunately, the value of chroma depends on all 4 lumi
> vectors, so it's not possible to search those four independently
> if chroma is to be considered :-(
>
> > +> If would have been logical to either add a fifth vector, or
> > +> 2 bits to
> > +> signalize which of the blocks' vector to use, or something similar.
> >
> > That might not be worth the extra bits it would cost to send the
> > vector or indication.  And it would take extra processing power to
> > determine the values to put in those extra bits.
>
> Are there any published results on chroma+4MV search? Or even
> only 4MV search? Any papers? It seems everybody agrees on
> "chroma is not important" without anyone really checking.
>
> > Chroma doesn't usually consume very many bits overall
> > relative to luma and isn't as visually important as
> > luma, so often it is treated as not being very important
> > in a codec design.  Chroma tends to take about 10-20% of
> > the total bit rate, so even if you could cut that in half
> > with some better processing method you wouldn't save that
> > much in the overall bit rate.
>
> So the answer is: "It was chosen that way, because it does
> not matter very much". Okay, that's an answer.
> How's the situation in H26.L?
>
> Christoph
>
> --
> Christoph H. Lampert chl   math.uni-bonn.de | Diese Signature wurde maschi-
> Beringstr. 6, Raum 14 Tel. (0228) 73-2948 | nell erstellt und bedarf
> Sprechstunden: keine, aber meistens da    | keiner Unterschrift. AZ 27B-6
>
> _______________________________________________
> Technotes mailing list
> Technotes   lists.m4if.org
> http://lists.m4if.org/mailman/listinfo/technotes