Open Bug 1805278 Opened 3 years ago Updated 5 months ago

avif image is darker than it should be

Categories

(Core :: Graphics: ImageLib, defect)

Firefox 102
defect

Tracking

()

UNCONFIRMED

People

(Reporter: mozbugz, Unassigned)

References

(Blocks 2 open bugs)

Details

Attachments

(3 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Firefox/102.0

Steps to reproduce:

This may be related to: https://bugzilla.mozilla.org/show_bug.cgi?id=1788866

I opened the AVIF file, which was obtained from the HDR10 sample files, and encoded to AVIF via ffmpeg.

  1. Download HDR10 sample file from: https://drive.google.com/drive/folders/1JSfP3EGvA9aM4gYCrI09Y_CdFP10KTby
  2. Convert to avif: ffmpeg -ss 54 -i Mehanik\ HDR10\ test\ patterns/04.\ Colors/01.\ Banding_Rotating-gradients_23.976.mp4 -frames:v 1 colors.banding.avif
  3. Drag file onto FireFox.

Actual results:

The file opened, but the output was significantly darker than it should be. Rendering the video in VLC works fine.

Expected results:

Expected result should be bright colors.

If I convert the frame to pam first, and then to avif, it renders fine, that is:

  1. ffmpeg -ss 54 -i 01.\ Banding_Rotating-gradients_23.976.mp4 -frames:v 1 colors.banding.pam
  2. ffmpeg -i colors.banding.pam -frames:v 1 colors.banding.from.pam.avif
  3. open this avif.

Here is same frame rendered through an intermediary PAM file that renders as expected.

forgot to include ffmpeg information:
ffmpeg version 5.1.2 Copyright (c) 2000-2022 the FFmpeg developers
built with Apple clang version 14.0.0 (clang-1400.0.29.202)
configuration: --prefix=/opt/local --enable-swscale --enable-avfilter --enable-libmp3lame --enable-libvorbis --enable-libopus --enable-librsvg --enable-libtheora --enable-libopenjpeg --enable-libmodplug --enable-libvpx --enable-libsoxr --enable-libspeex --enable-libass --enable-libbluray --enable-libzimg --enable-libzvbi --enable-lzma --enable-gnutls --enable-fontconfig --enable-libfreetype --enable-libfribidi --enable-zlib --disable-libjack --disable-libopencore-amrnb --disable-libopencore-amrwb --disable-libxcb --disable-libxcb-shm --disable-libxcb-xfixes --disable-indev=jack --enable-opencl --disable-outdev=xv --enable-audiotoolbox --enable-videotoolbox --enable-sdl2 --disable-securetransport --mandir=/opt/local/share/man --enable-shared --enable-pthreads --cc=/usr/bin/clang --enable-libaom --enable-librav1e --enable-libsvtav1 --arch=arm64 --enable-gpl --enable-postproc --enable-libx264 --enable-libx265 --enable-libxvid --enable-libvidstab
libavutil 57. 28.100 / 57. 28.100
libavcodec 59. 37.100 / 59. 37.100
libavformat 59. 27.100 / 59. 27.100
libavdevice 59. 7.100 / 59. 7.100
libavfilter 8. 44.100 / 8. 44.100
libswscale 6. 7.100 / 6. 7.100
libswresample 4. 7.100 / 4. 7.100
libpostproc 56. 6.100 / 56. 6.100

Information from reference decoder displaying basic info, and there is some significant differences.

$ avifdec -i colors.banding.avif
Image decoded: colors.banding.avif

  • Resolution : 3840x2160
  • Bit Depth : 10
  • Format : YUV420
  • Chroma Sam. Pos: 0
  • Alpha : Absent
  • Range : Limited
  • Color Primaries: 9
  • Transfer Char. : 16
  • Matrix Coeffs. : 9
  • ICC Profile : Absent (0 bytes)
  • XMP Metadata : Absent (0 bytes)
  • EXIF Metadata : Absent (0 bytes)
  • Transformations: None
  • Progressive : Unavailable
  • 1 timescales per second, 1.00 seconds (1 timescales), 1 frame
  • Frame:
    • Decoded frame [0] [pts 0.00 (0 timescales)] [duration 1.00 (1 timescales)] [3840x2160]
      $ avifdec -i colors.banding.from.pam.avif
      Image decoded: colors.banding.from.pam.avif
  • Resolution : 3840x2160
  • Bit Depth : 12
  • Format : YUV444
  • Alpha : Absent
  • Range : Full
  • Color Primaries: 2
  • Transfer Char. : 2
  • Matrix Coeffs. : 0
  • ICC Profile : Absent (0 bytes)
  • XMP Metadata : Absent (0 bytes)
  • EXIF Metadata : Absent (0 bytes)
  • Transformations: None
  • Progressive : Unavailable
  • 1 timescales per second, 1.00 seconds (1 timescales), 1 frame
  • Frame:
    • Decoded frame [0] [pts 0.00 (0 timescales)] [duration 1.00 (1 timescales)] [3840x2160]

So there are a number of differences between the two.

Oh, I also forgot to include that this is on a 2021 14" MBP running Ventura 13.0.1.

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: ImageLib' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Graphics: ImageLib
Product: Firefox → Core

The severity field is not set for this bug.
:aosmond, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(aosmond)
Blocks: AVIF
Severity: -- → S3
Flags: needinfo?(aosmond)

Confirmed that this is still an issue on: 115.8.0esr on MacOS 14.2.1

Comment #3's parameters indicate a standard rec2100 pq (ncl) colorspace. We don't really support 2100 yet, since that's generally hdr.

Attached image g128.avif

I created a simplified testcase for this. I took a 128 grey png (just header and image data), I inserted an sRGB chunk (rendering intent Perceptual) so it was considered in sRGB.

Then I ran this command line

ffmpeg -i in.png -color_range 1 -colorspace 9 -color_primaries 9 -color_trc 16 -pix_fmt yuv420p10le g128.avif

to get an avif that replicates the testcase here. It does indeed seem to reproduce the same issue, ie it is much darker in Firefox.

Opening that testcase and using teh digital color meter app on my mac I get the following values:
Firefox 24
Safari 128
Chrome 153

If I change the pixel format to yuv420p then the same problem seems to reproduce.

It seems like we handle the matrix coeffs okay, ie the conversion from yuv to rgb seems to be okay. If I manually disable qcms then we get a lighter rendering in Firefox. So it seems something happening in qcms.

See Also: → 1793091
See Also: → 1960856
Blocks: 1961936
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: