Open BlueSwordM opened 2 years ago
@wantehchang If you have the time, perhaps you could look into it and give some insights for your team. The butteraugli RD tune is top notch, and having it work on all bit depths would be awesome.
On another note, I discovered maybe why it didn't work properly in my patch: bad translation of YCbCr to RGB values, although there could always be something else causing the bugs.
It's working 'fine' (ish) in my build, with just what's available in gitlab/jpeg-xl / aom / libavif.
But the 8bpp restriction is still in (And it's in aom so I think asking here has no effect). It only works with bt709/bt601 matrix coefficients. It says so now if you try to use something else.
The problem I'm having is that bt709 seems to give an error about unable to get butteraugli distances, but bt601 works OK.
If I compare some encodes on how close I can get with to a certain butteraugli_main test command line, the scores are really close with JpegXL (in pixel-peeping-quality mode though, not '3 feet away looking'), ssimulacra2 and the filesizes are competitive. Also pixel-peeping myself to see what is different between the files I kinda rate them similar. (So I'm not just looking at metrics).
Unfortunately, jpeg-xl has removed the API in v0.9.0: https://github.com/libjxl/libjxl/commit/a96301672a1b27a387c8f4906801b30ff64868a4 (https://github.com/libjxl/libjxl/pull/2576).
Yeah so you need to use an older version, because the only thing this integration picks up was the Butteraugli stuff.
And as mentioned in the libjxl ticket, that project is supposed to be a sort of reference 'standard' implementation, and including butteraugli in it means everybody would be forced to include a butteraugli implementation if you wanted to be a libjxl alternative. The plan is (was?) to move the metrics stuff to a separate library. Which makes more sense, that projects like this can just use the metrics library to get scores instead of having to include the encoder library for a completely different image format, just for some metrics.
I don't know honestly if they ever got around to that. For the jxl team, it's low priority.
And to be honest, with the 8 bit limitation and the results I ended up not really bothering anymore for recent builds I use for my personal use.
On Tue, 16 Jan 2024 at 14:30, rathann @.***> wrote:
Unfortunately, jpeg-xl has removed the API in v0.9.0: libjxl/libjxl@ a963016 https://github.com/libjxl/libjxl/commit/a96301672a1b27a387c8f4906801b30ff64868a4 (libjxl/libjxl#2576 https://github.com/libjxl/libjxl/pull/2576).
— Reply to this email directly, view it on GitHub https://github.com/AOMediaCodec/libavif/issues/899#issuecomment-1893746893, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALMD2DXFP7WGINFKGTAGSC3YOZ6HZAVCNFSM5R3PFMYKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBZGM3TINRYHEZQ . You are receiving this because you commented.Message ID: @.***>
Currently, the butteraugli(from libjxl) RD tune is available in aomenc, but only for 8-bit inputs/outputs which is honestly a shame, since it currently is the best RD tune when it comes to raw low-high quality and fidelity.
It would be therefore be very nice if it worked consistently with 10b/12b outputs since this RD tune is extremely strong overall psycho-visually speaking, and is has a good quality/compute time cost overall.
Sadly, progress towards that seems to have stopped entirely in the related aomedia Gerrit issue, which is why I'm asking here: https://bugs.chromium.org/p/aomedia/issues/detail?id=3129
If it would be possible to make it work for HBD inputs, it would not only be great for AVIF in general, but also be beneficial for video/animation AVIF/AV1.