AVIF image creates some weird artefacts on text

[adityapatadia]

Please check these two images:

Oringinal: https://www.websitepolicies.com/uploads/j/i/j/a/kog3telytsh1ifkxvg4v.png

AVIF: https://websitepolicies.gumlet.io/uploads/j/i/j/a/kog3telytsh1ifkxvg4v.png?format=avif

The AVIF image has some color distortion on black texts.

[imfantuan]

Please check these two images:

Oringinal: https://www.websitepolicies.com/uploads/j/i/j/a/kog3telytsh1ifkxvg4v.png

AVIF: https://websitepolicies.gumlet.io/uploads/j/i/j/a/kog3telytsh1ifkxvg4v.png?format=avif

The AVIF image has some color distortion on black texts.

Hi, adityapatadia:

I confirm this is not "AVIF's" problem, but "Rav1e's".

Please try libaom. I have to say it's very hard to choise.

[imfantuan]

https://res.cloudinary.com/demo/image/fetch/w_1123,q_65,f_avif/https://www.websitepolicies.com/uploads/j/i/j/a/kog3telytsh1ifkxvg4v.png

I think this is a libaom's result.

[adityapatadia]

AOM is almost not-usable. It's very slow for encoding. If this is confirmed, I will raise issue for rav1e.

[silverbacknet]

This is nothing but the difference between 4:4:4 and 4:2:0. Rav1e supports 4:4:4 as well. What command line or API call did you use, @adityapatadia ? You should never make a bug report without specifying HOW you made your result, including exact command line or API call, and exact version.

[adityapatadia]

Understood. My bad creating report without details.

I use libvips call from sharp library for nodejs. Libvips version 8.10.0. Sharp version 0.26.0. Libheif version 1.8.0. Rav1e version 0.3.3. Let me know if more information is needed. I am pretty unaware about API being used by libvips.

[imfantuan]

SORRY. I made a big mistake about:

I confirm this is not "AVIF's" problem, but "Rav1e's".

---

These are some new infomations:

libheif master + rav1e 0.3.3 with ./configure --enable-local-rav1e && make

./heif-enc -q 50 -p chroma=444 -A /input_file.png -o /output_file.avif :

---

libheif master + AOM 1.0.0-8.20190810 with ./configure && make

./heif-enc -q 50 -p chroma=444 -A /input_file.png -o /output_file.avif :

---

Parameters for encoder Rav1e encoder:

  speed, default=8, [0;10]
  threads, default=4, [1;16]
  tile-rows, default=4, [0;0]
  tile-cols, default=4, [0;0]
  chroma, default=420, { 420,422,444 }
  min-q, default=0, [0;255]

Parameters for encoder AOMedia Project AV1 Encoder 1.0.0-2227-gcfd59e96a:

  realtime, default=false
  speed, default=5, [0;8]
  threads, default=4, [1;16]
  quality, default=50, [0;100]
  lossless, default=false
  chroma, default=420, { 420,422,444 }
  min-q, default=1, [1;62]
  max-q, default=63, [0;63]

Options for ./heif-enc:

  -h, --help      show help
  -q, --quality   set output quality (0-100) for lossy compression
  -L, --lossless  generate lossless output (-q has no effect)
  -t, --thumb #   generate thumbnail with maximum size # (default: off)
      --no-alpha  do not save alpha channel
      --no-thumb-alpha  do not save alpha channel in thumbnail image
  -o, --output    output filename (optional)
  -v, --verbose   enable logging output (more -v will increase logging level)
  -P, --params    show all encoder parameters
  -b #            bit-depth of generated HEIF/AVIF file when using 16-bit PNG input (default: 10 bit)
  -p              set encoder parameter (NAME=VALUE)
  -A, --avif      encode as AVIF
  --matrix_coefficients     nclx profile: color conversion matrix coefficients, default=6 (see h.273)
  --colour_primaries        nclx profile: color primaries (see h.273)
  --transfer_characteristic nclx profile: transfer characteristics (see h.273)
  --full_range_flag         nclx profile: full range flag, default: 1

[farindk]

I also first thought that this is a 4:2:0 vs 4:4:4 issue, but it seems to be a different encoding issue. The only way I could reliably remove the color ringing was by using --matrix_coefficients=0 i.e. encoding in RGB color space. That works fine with aom, rav1e, and x265.

[farindk]

Ok, I found the problem and fixed it. The color conversion did not have any routine to convert RGB24 to YCbCr 4:4:4. Hence, it decided that the best it could do is to use these steps

• RGB24 -> YCbCr 4:2:0
• YCbCr 4:2:0 -> RGB planar
• RGB planar -> YCbCr 4:4:4

I have added a direct conversion to 4:4:4 (9f4918e). You'll now get clean output even without --matrix-coefficients=0.

[adityapatadia]

Is this anyhow related to #311?

[farindk]

@adityapatadia No, not related to #311 .

[adityapatadia]

Thanks for resolving this super quick!

[adityapatadia]

@farindk it would be great if you can make point release like 1.8.1 for such bug fixes. It helps us deploy in production faster.

[farindk]

Sorry, I don't have time this week, but there will be a new release early next week.

[adityapatadia]

This issue is not resolved as of v1.9.1.

Original: https://www.websitepolicies.com/uploads/j/i/j/a/kog3telytsh1ifkxvg4v.png

AVIF: https://websitepolicies.gumlet.io/uploads/j/i/j/a/kog3telytsh1ifkxvg4v.png?v=22&format=avif