Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test new -tune=ssimulacra2 #17

Open
juliobbv-p opened this issue Nov 25, 2024 · 5 comments
Open

Test new -tune=ssimulacra2 #17

juliobbv-p opened this issue Nov 25, 2024 · 5 comments

Comments

@juliobbv-p
Copy link

juliobbv-p commented Nov 25, 2024

Recently, libaom landed a new SSIMULACRA2 tune, specifically optimized for still pictures: https://aomedia-review.googlesource.com/c/aom/+/194662. It's currently available on the main branch.

The new tune consists of a set of optimized defaults (QMs, deltaq, rdmult and luma/chroma allocation tweaks, etc) that improve SSIMULACRA 2 scores, and in our preliminary testing, it also has a more favorable subjective quality profile.

It'd be nice to have SSIMULACRA 2 results (in addition to the default tune) so we can have a more complete look at how other metrics react (especially with butteraugli and DSSIM).
image =100x100

@y-guyon
Copy link
Collaborator

y-guyon commented Nov 27, 2024

Here are my findings on a dataset from https://www.compression.cc with multiple codecs at default encoding effort. Let me know if you expect significantly different results at other speeds.

Web-quality range and 4:2:0

Restricting AVIF bpp to [0.03-1.03] range and images to 2-3 megapixels to match the 10th to 90th percentiles at https://github.com/webmproject/codec-compare/wiki/Bits-per-pixel-of-Internet-images.

For the same Butteraugli score

Plot

  • AOM_TUNE_SSIMULACRA2 leads to files 13% bigger than AOM_TUNE_SSIM.

For the same DSSIM score

Plot

  • AOM_TUNE_SSIMULACRA2 leads to files 6% smaller than AOM_TUNE_SSIM.

High-quality range 70-90 and 4:4:4

Restricting to AVIF quality range 70 to 90 is arbitrary.

For the same Butteraugli score

Plot

  • AOM_TUNE_SSIMULACRA2 leads to files 17% smaller than AOM_TUNE_SSIM.

For the same DSSIM score

Plot

  • AOM_TUNE_SSIMULACRA2 leads to files 14% smaller than AOM_TUNE_SSIM.

@juliobbv-p
Copy link
Author

juliobbv-p commented Nov 27, 2024

Thanks @y-guyon for running the tests! I took a quick look, and I can already tell they're very informative.

Tune ssimulacra2's changes mainly deal with bit redistribution, so I wouldn't expect wildly different results at other speeds.

That said: I'd also recommend testing speed 3, as it enables rectangular partitions, larger transforms, and restoration filters; while still being fast enough for some production scenarios. It'd be interesting to see how the tune's tweaks interact with the larger available tooling repertoire.

Edit: I'd also suggest testing 10-bit speed 6, as the additional internal precision can make a significant difference at preventing banding, which SSIMULACRA 2 heavily penalizes. At very high quality, SSIMULACRA 2 scores can increase by a whole point or more.

@gitoss
Copy link

gitoss commented Nov 28, 2024

Here are my findings on a dataset from https://www.compression.cc with multiple codecs at default encoding effort. Let me know if you expect significantly different results at other speeds.

Here's another comment: AOMediaCodec/libavif#2412 (comment)

@y-guyon
Copy link
Collaborator

y-guyon commented Dec 3, 2024

That said: I'd also recommend testing speed 3, as it enables rectangular partitions, larger transforms, and restoration filters; while still being fast enough for some production scenarios. It'd be interesting to see how the tune's tweaks interact with the larger available tooling repertoire.

At speed 3 the gains are in the same ballpark:

Web-quality range and 4:2:0

Restricting AVIF bpp to [0.03-1.03] range and images to 2-3 megapixels to match the 10th to 90th percentiles at https://github.com/webmproject/codec-compare/wiki/Bits-per-pixel-of-Internet-images.

For the same Butteraugli score

Plot

  • AOM_TUNE_SSIMULACRA2 leads to files 14% bigger than AOM_TUNE_SSIM.

For the same DSSIM score

Plot

  • AOM_TUNE_SSIMULACRA2 leads to files 6% smaller than AOM_TUNE_SSIM.

High-quality range 70-90 and 4:4:4

Restricting to AVIF quality range 70 to 90 is arbitrary.

For the same Butteraugli score

Plot

  • AOM_TUNE_SSIMULACRA2 leads to files 15% smaller than AOM_TUNE_SSIM.

For the same DSSIM score

Plot

  • AOM_TUNE_SSIMULACRA2 leads to files 11% smaller than AOM_TUNE_SSIM.

Edit: I'd also suggest testing 10-bit speed 6, as the additional internal precision can make a significant difference at preventing banding, which SSIMULACRA 2 heavily penalizes. At very high quality, SSIMULACRA 2 scores can increase by a whole point or more.

My dataset is 8-bit. Do you have a 10-bit corpus with a permissive license to recommend?

@juliobbv-p
Copy link
Author

Thanks @y-guyon for the follow-up! It's reassuring to see the gains for SSIMULACRA 2 hold up proportionally for s3.

My dataset is 8-bit. Do you have a 10-bit corpus with a permissive license to recommend?

My apologies, I should've clarified. By "10-bit", I was thinking of using the CLIC dataset, but converted to 10-bit before encoding (e.g. by specifying -d 10 in avifenc). Enabling the AV1 HBD codepath (done by the 10-bit conversion) can greatly reduce banding and improve SSIMULACRA2 scores for images with subtle gradients.

For example, this image of a flower against a blurry background from CLIC:

8-bit 10-bit
8 bit 10 bit
  • 8-bit: size 152 KB, SSIMULACRA 2 score 83.72
  • 10-bit: size 138 KB, SSIMULACRA 2 score 85.86

The 10-bit image is 9% smaller, yet it scores 2 points higher. Both images were encoded at speed 6, with tune SSIMULACRA2.

Close visual inspection of the 8-bit image reveals subtle banding/blocking that's not present in the converted 10-bit image:

8-bit 10-bit
8 bit 10 bit

Here are the source and encoded files for reference: 8bit vs 10bit.zip

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants