[XviD-devel] Adaptive quantisation

[Michael Militzer]

Hi,

new lumi masking algorithm?? I didn't even know that!

.....ok, I just did some research and have to admit that I'm a bit angry
now: uManiac seems to have overwritten my luminance masking code even while
stating that the new code is "unoptimized". There are such nice things like
"#ifdefs" to add experimental new code! Why does noone ask before
overwriting code?


Nonetheless I've tested this new code and it seems total bogus:

my dogma test-clip, fixed quant 4:

25.442.304 Bytes, without lumi-masking
25.403.392 Bytes, with lumi-masking

A file reduction by 38912 Bytes, that's really not very impressive... And
no, luminance masking _cannot_ increase quality (as someone over at doom9
asked). The luminance masking code can only _increase_ quantizers for
certain blocks, which means a degradation in quality. So the current code
does nothing than reducing quality and wasting encoding time. Why has noone
tested the code (at least once) before committing?? I really don't get this,
one shouldn't overwrite code if the new one isn't proven to be better...

I've looked at the lumi masking code itself right now and the approach is
not wrong, but isn't perfect either. When I was writing my luminance masking
code, I tried this approach at first but dropped it because it causes
problems in overall dark or overall bright frames: The new code (obviously
written by ProfDrMorph) calculates the relative luminance of a block
(relative to the global luminance). If the block is much darker (or
brighter) than the global luminance, the quantizer of this block is changed.
The problem is that dark scenes (night) the global luminance will be small.
A small bright object (like the lights of a car, for example) in this dark
night scene will be much brighter than the global luminance and will
therefore heavily quantized (and therefore look ugly). But often the viewer
will spend most attention to the bright parts of a dark scene (the lights of
our moving car, which look now ugly btw.) and will then rate this scene as
"bad quality". For very bright scenes the same problems occur.

Therefore my luminance masking code also first calculates overall luminance,
but only kicks in, if we have a scene of "normal" brightness. Only in this
case, blocks which are much brighter or darker relative to the global
luminance are searched and then higher quantized. This solves the above
mentioned problems. Moreover my solution had better values for the
thresholds, saved about 8% for the above mentioned clip and noone ever
complained about ugly frames (at least not that I knew about and luminance
masking was for example activated during doom9's codec comparison, where we
weren't that bad either...).

Therefore I'll simply switch back to my "old" code. About the user
adjustable values: There are pretty much values that are important and it's
maybe no good idea to let the user adjust all of them. I'd suggest to allow
the user to adjust how "aggressive" luminance masking should work (maybe a
nice slider) and that we'll include this option in the upcoming API 3.0.

btw: thanks koepi for letting me know at all, elsewise I would have never
noticed that the code had been changed...

bye
Michael


----- Original Message -----
From: "Dirk Knop" <dknop@gwdg.de>
To: <xvid-devel@xvid.org>
Sent: Sunday, August 04, 2002 4:23 PM
Subject: [XviD-devel] Adaptive quantisation


> Hi,
>
> since the new luma masking algorithm was introduced, many people (users)
> complained that they didn't gain compressability.
>
> In adapt_quant.c we find hardcoded values:
>
>     const float DarkThres = 0.25;
>     const float DarkAmpl = 7.0;
>
>     const float BrightThres = 4.0;
>     const float BrightAmpl = 5.0;
>
>     const char LowestVal = 10;
>
>     const float GlobalBrightThres = 220.0;
>     const float GlobalDarkThres = 20.0;
>     float global_quant = 1.0;
>
> I think we could add some of those values to the xvid api so we could
> "tweak" them via the encoding application ( I have to admit that I
> didn't look deeper into the sources yet to understand all of these
> values...).
>
> Did anyone do some tests and has better values to replace these with,
> would be nice as so there wouldn't be the need for an API change.
>
> Thanks,
> Regards,
> Koepi
>
> _______________________________________________
> XviD-devel mailing list
> XviD-devel@xvid.org
> http://list.xvid.org/mailman/listinfo/xvid-devel
>