Bug 1634741 was recently resolved, so I now have the ability to test the correctness of Firefox's color management of AV1 images.

A few important preliminary notes:

All of the following must be in place to recreate the conditions I'm testing under.

• AVIF decoding must be enabled (via image.avif.enabled=true or by default)
• Color management of all images must be enabled (gfx.color_management.mode=1)
• An appropriate color profile must be set (via gfx.color_management.display_profile - note that on some platforms Firefox may be able to detect the profile automatically, but this does not work for me on Linux with colord)
• You must not be using Firefox on a platform where it "solves" the color management problem by converting all input color spaces to sRGB. My understanding is that this is currently only done for macOS. (I'm relying on a report from a user that this is the case as I do not have an Apple device with a wide gamut screen to test, please correct me if this is wrong.)

After the color management bug was resolved, I did indeed see an enormous improvement. Colors were no longer incorrect and ludicrously over-saturated. But it's still not quite right (on my platform, under my testing conditions). The images are faded, as if the wrong gamma was being used or a full range image was being decoded as limited range (I've checked, however, and my images are limited range).

I have a pretty easy test case that should repro the issue: Image 1 Image 2

My AVIF images were encoded with aomenc from the official aom toolset, and placed in an AVIF container with MP4Box (from gpac). The resulting files pass this AVIF validator tool.

These images should look exactly the same, and in fact they do look the same in Chrome and my offline image viewer (eog - the Gnome image viewer). But in Firefox the AVIF image is slightly washed out / decontrasted.

I have attached a screenshot showing what I see. (The screenshot is of my interactive image codec comparison tool, which allows comparing AVIF to other image encoders.) This screenshot was captured, tagged with my monitor's color profile, and then converted to and tagged with ProPhoto. This should allow anyone with a color managed image viewer to see approximately what I see when I compare these two images.

A quick but important additional note: I regenerated the AVIF file using avifenc (from the libavif toolset), and the resulting file does not show this problem. So this is something limited to files generated in the particular way I have generated.

However, I believe this is still likely to be a Firefox bug (or at least a Firefox incompatibility with the way other image decoders handle certain AVIF images), since other viewers give the expected output for these files and since they pass the AVIF validator I mention above. If there is something wrong with my files I'd be grateful to have that pointed out (as well as have this case added to the discussion of how Firefox should handle quirky AVIF images).

For the record, here is the way I generated the problematic files. This is how many guides on the web recommended creating AVIF files for a very long time, since the tooling around them was less than adequate.

aomenc --i444 --passes=2 --end-usage=q --cq-level=15 --ivf -o file.ivf input.y4m
MP4Box -add-image file.ivf:primary -ab avif -ab miaf -new file.avif

Quick addition. Since I unexpectedly discovered a workaround (detailed in the last post), I updated the images on my comparison site, so the links in my OP are now out of date. Sorry for any confusion resulting from that.

I'm attaching the original, broken file created using aomenc.

The updated, now working file (created with avifenc) is here.

The expected appearance of the file, as rendered to a PNG, is here.

Some more experimentation revealed something I had previously missed. The handling of colors in AVIF files is still imperfect, even after switching to the avifenc files. It's not really noticeable in the picture I was using as an example earlier, but check out the following two:

AVIF file
PNG decoded from AVIF file

On my (WCG) screen, the AVIF image is subtly more saturated in Firefox, especially in the sky, than the reference PNG. The files are (as expected) indistinguishable from one another when I view them in eog.

So there are potentially two issues here:

1. Firefox's handling of certain AVIF files (potentially broken ones?) is different / buggy compared to other viewers.

2. When color management is enabled in Firefox, the colors aren't quite perfect in AVIF files. They seem close on my screen, but there is definitely still a noticeable difference in how Firefox is managing an AVIF file and a PNG decode of the same file. Obviously, there shouldn't be.

(In reply to adam.m.fontenot from comment #0)

• Color management of all images must be enabled (gfx.color_management.mode=1)

The default of 2 (Tagged Images Only) behaves identically for AVIF. It only behaves differently if set to off (0). This setting isn't referenced anywhere else in the pipeline as far as I can tell.

• You must not be using Firefox on a platform where it "solves" the color management problem by converting all input color spaces to sRGB. My understanding is that this is currently only done for macOS. (I'm relying on a report from a user that this is the case as I do not have an Apple device with a wide gamut screen to test, please correct me if this is wrong.)

I'm pretty certain this is the approach for all platforms. We convert to sRGB with via the qcms library internally and the firefox graphics pipeline uses sRGB, but the conversion to display space may differ according to the OS. jrmuizel may know better, so I think he should weigh in here.

(In reply to adam.m.fontenot from comment #3)

Some more experimentation revealed something I had previously missed. The handling of colors in AVIF files is still imperfect, even after switching to the avifenc files. It's not really noticeable in the picture I was using as an example earlier, but check out the following two:

AVIF file
PNG decoded from AVIF file

These look pixel identical to me in my setup; see attached comparison using the comparison mode of the Vantage viewer, written by the author of libavif.

So there are potentially two issues here:

1. Firefox's handling of certain AVIF files (potentially broken ones?) is different / buggy compared to other viewers.

I don't think White_Dune_-_Mui_Ne.avif is buggy. It was written with libavif and looks very standard to me.

2. When color management is enabled in Firefox, the colors aren't quite perfect in AVIF files. They seem close on my screen, but there is definitely still a noticeable difference in how Firefox is managing an AVIF file and a PNG decode of the same file. Obviously, there shouldn't be.

This may be the case when using a custom display profile, but it doesn't seem likely to be AVIF-specific in that case. Unless the implementation of CICP values was wrong. But this image is using 1/13/6, which is by far the most common and would affect nearly all AVIF if it were off, regardless of display profile.

I'll investigate some more and discuss with the other folks who know the back half of the color pipeline better.

Triaging

Thanks for the quick response!

converting all input color spaces to sRGB

I'm pretty certain this is the approach for all platforms.

Definitely not the case for me here on Linux. This would be quite upsetting to me if true, since it would mean that Firefox cannot properly display wide gamut (e.g. P3, AdobeRGB) images. There's an easy way to test this. If I open this website, it has a nice comparison with color bars between a ProPhotoRGB tagged image, and an sRGB image. If Firefox were converting to sRGB internally on my platform, the ProPhotoRGB image would look exactly the same as the sRGB one. Instead, the colors are retina-searingly intense!

Check out this ProPhoto tagged screenshot of the webpage that I made. Bottom is Chrome (which does convert the images to sRGB), top is Firefox, which is clearly not doing that.

These look pixel identical to me in my setup

Firefox is the only viewer I've tried in which they look different. I haven't been able to further narrow down the cause.

Since this report has had several tangents, let me restate the problems I'm seeing. (I'm also rehosting the files that are not already uploaded to Bugzilla in case I change the files in my project in the future.)

1. This AVIF file does not decode correctly for me. It is faded out, compared to a correctly decoded file. In the screenshot here, it is shown on the left half of the image while the correctly decoded version (a PNG) is on the right. I do not see this issue on a fresh profile with no ICC profile set, but I do see it when I set the profile and restart.

2. This AVIF file looks different to me (in Firefox) than a PNG copy of the same file which I created with avifdec. The AVIF file looks slightly more saturated and perhaps slightly less purple than the PNG version. In this screenshot you can see what they look like to me. AVIF on the left, PNG on the right.

One possibility that I have definitely eliminated is that Firefox isn't performing color management on the AVIF image at all. If I tag the PNG image with my monitor's color space (rather than the sRGB default), it is vastly more saturated than the AVIF. So that's not what's happening here.

I solved problem 2, I think!

If I leave the PNG file untagged, it looks different from the AVIF (as previously described). However, if I tag it with a standard sRGB ICC profile, it looks exactly the same (in Firefox) as the AVIF!

What this suggest to me is that there are small inaccuracies involved in the color management process in Firefox, such that a file with no profile gets treated slightly differently than a file with an sRGB profile. It seems likely to me that the AVIF color management process recently committed is unconditionally performing a conversion from the file's color space to some other color space (possibly sRGB, but maybe not). What this color management process ought to do is treat the (untagged) AVIF exactly like Firefox treats untagged JPEG and PNG files.

1. This AVIF file does not decode correctly for me. It is faded out, compared to a correctly decoded file. In the screenshot here, it is shown on the left half of the image while the correctly decoded version (a PNG) is on the right. I do not see this issue on a fresh profile with no ICC profile set, but I do see it when I set the profile and restart.

This file contains no color management information:

$ avifdec -i not_working_avif_file_firefox.avif 
Image decoded: /tmp/not_working_avif_file_firefox.avif
 * Resolution     : 1436x730
 * Bit Depth      : 8
 * Format         : YUV444
 * Alpha          : Absent
 * Range          : Limited
 * Color Primaries: 2
 * Transfer Char. : 2
 * Matrix Coeffs. : 2
 * ICC Profile    : Absent (0 bytes)
 * XMP Metadata   : Absent (0 bytes)
 * EXIF Metadata  : Absent (0 bytes)
 * Transformations:
    * pasp (Aspect Ratio)  : 1/1
 * 1 timescales per second, 1.00 seconds (1 timescales), 1 frame
 * Frames:
   * Decoded frame [0] [pts 0.00 (0 timescales)] [duration 1.00 (1 timescales)]

Note Color Primaries: 2, Transfer Char. : 2 and Matrix Coeffs. : 2 as well as ICC Profile : Absent (0 bytes). The CICP value 2 means "unspecified" and there's no ICC profile to specify primaries either. So unless it happened to exactly match the values that the AVIF standard specifies to use for unspecified inputs, it will indeed look wrong. Even if the CP/TC/MC are correct, if the input is expecting full range values, the fact the AV1 OBU here indicates limited would lead to an incorrect appearance. I'm currently looking into a discrepancy between what avifdec is reporting here and what I'm seeing from the decoder libraries themselves (both aom and dav1d) when decoding this file, but I'm pretty sure it's just that avifdec reports on only container-level color information in the -i output. Internally, I can see this is being rendered as "full" range in Firefox and since the CP/TC/MC values are all unspecified, it gets the fallback values of 1/13/6.

Let's ignore this file and stick to ones generated by a known good AVIF writer like avifenc.

2. This AVIF file looks different to me (in Firefox) than a PNG copy of the same file which I created with avifdec. The AVIF file looks slightly more saturated and perhaps slightly less purple than the PNG version. In this screenshot you can see what they look like to me. AVIF on the left, PNG on the right.

Was the PNG you attach here the output of the AVIF (converted to PNG via avifdec) or is that a typo which should read avifenc and the PNG is the input for the AVIF?

If the PNG is the input, then it looks exactly as I would expect and the attached Vantage comparison of the two shows just that: most pixels match perfectly and the greatest difference is 1.

If the PNG is the output, how was the AVIF created?

If I leave the PNG file untagged, it looks different from the AVIF (as previously described). However, if I tag it with a standard sRGB ICC profile, it looks exactly the same (in Firefox) as the AVIF!

Let's be clear on the repro here. There are 2 input PNGs ("tagged" and "untagged") and 2 corresponding output AVIF. Can you provide all 4 so I can verify?

What this suggest to me is that there are small inaccuracies involved in the color management process in Firefox, such that a file with no profile gets treated slightly differently than a file with an sRGB profile.

Well, AVIF isn't as simple as "tagged" or not. There are 3 sources of color management information:

1. Container-level NCLX (CICP values for color primaries, transfer characteristics and matrix coefficients + a full/limited range indicator)
2. Container-level ICC profile
3. AV1 bitstream-level NCLX values

The recently fixed bug 1729071 notwithstanding, it's possible to have all 3 present in a file. The NCLX values from the container override the ones in the AV1 bitstream, and the ICC profile overrides the CICP values for CP and TC, though the writer should probably make those values 2 (unspecified) when adding an ICC profile to reduce ambiguity.

More detail on the whole situation here https://github.com/AOMediaCodec/libavif/wiki/CICP

What this color management process ought to do is treat the (untagged) AVIF exactly like Firefox treats untagged JPEG and PNG files.

I encourage you to read the long and complicated history of how color management works in AVIF, but by and large, the default values used when specific information is absent are the same as JPEG (CP=BT.709, TC=sRGB, MC=BT.601), and that's exactly what Firefox does.

Note that for the sake of this discussion, saying a CP/TC value of 1/16 and a "standard sRGB" embedded profile are identical depends on the specific implementation of the CICP values in the CMS. I happened to implement CICP values in qcms, so I know there's really no such thing as a "standard sRGB" ICC profile. For instance, the primary values are well understood mathematically, but different profiles calculate them to different levels of precision. Also, the white point D65 can vary according to how its calculated (6500K or 6504K?) and the transfer function is an even bigger source of differences since it can be implemented either as a ICC parametric function (para) (again, different levels of precision are possible) or as a sampled value (curv) (again, how many samples?).

So, if we're down to talking about very small differences between the way "a file with no profile" versus a file with "an sRGB profile" is rendered, that's likely unavoidable because not all sRGB profiles are the same, and only some will result in identical results to the CICP implementation of 1/16.

If I leave the PNG file untagged, it looks different from the AVIF (as previously described). However, if I tag it with a standard sRGB ICC profile, it looks exactly the same (in Firefox) as the AVIF!

Ok after consulting with jrmuizel, I've learned that PNG and JPEG that lack any color management info aren't color managed at all, so results will be platform-specific. I think that explains the behavior here. The exception is macOS, where we always convert to sRGB and the OS handles conversion to the display profile. You were right about the platform difference there, so I learned something! My apologies for the mistaken info in comment 4.

It appears our behavior with untagged PNG/JPEG is for historical performance reasons (this comment supports that as well), meaning it's not AVIF that's the issue here, and probably the best fix will be to render untagged older formats as sRGB (or rather, 1/13/6/full). I'll make sure there's a bug filed for that (or that one of the existing ones is receiving appropriate attention) and link it back here before closing this one, but as it stands I don't see anything wrong with the AVIF-specific color management.

Bug 553599 is the one for changing the handling of untagged PNG/JPEGs.

However, after even more looking at this, I've realized there is a bug in the following case:

1. No color management at the AVIF container layer indicating the color range (that is, no colr boxes or only colr boxes with ICC profile data, not NCLX)
2. No color management at the AV1 bitstream level (see § 5.5.2. Color config syntax)
3. Input is limited range

I made an error interpreting the color_description_present_flag in the AV1 OBU. I thought if if was false, there was no information present about the CP/TC/MC nor the color_range, and in the absence of that defaulted to full range (like JPEG). However, even when the color_description_present_flag is false and there are no CICP values, there is still a valid color range value, which I was ignoring.

Since the libaom decoder has a different interface, this bug isn't present there. A quick test of changing the image.avif.use-dav1d pref to false, should allow you to see if that changes things for you.

I'll keep this bug open to fix that. Thanks very much for the report! It would've definitely taken longer to discover this otherwise.

A quick test of changing the image.avif.use-dav1d pref to false, should allow you to see if that changes things for you.

YES!! This fixes not_working_avif_file_firefox.avif for me!! Problem 1 solved!

It seemingly does not fix my other issue, however, so let me restate why I still believe that it's a problem (not just tiny ICC profile differences):

Ok after consulting with jrmuizel, I've learned that PNG and JPEG that lack any color management info aren't color managed at all, so results will be platform-specific. I think that explains the behavior here.

That's only 95% right, so let me be specific about what happens. If you have gfx.color_management.mode=2 (the default), untagged PNG and JPEG are not color managed. That's why I mentioned in my initial report that I have gfx.color_management.mode=1. When you enable this, Firefox will treat untagged images as sRGB. But (and this is the crucial thing) the way in which Firefox handles these untagged images still seems to be slightly different to the way that Firefox handles untagged AVIF. Specifically, what I see is that Firefox's handling of untagged AVIF is extremely similar to how it handles an sRGB tagged PNG.

What this suggests to me is that either Firefox is performing an additional conversion for AVIF (which can be triggered for the PNG by the addition of an ICC file), or that Firefox treats "sRGB" as meaning different things for AVIF files and untagged PNG files. I'm sorry to harp on this issue, but I really do think something here may need to be fixed. If you feel confident that the issue must be on the PNG end, I can move my comments over to the other issue.

So, if we're down to talking about very small differences between the way "a file with no profile" versus a file with "an sRGB profile" is rendered, that's likely unavoidable because not all sRGB profiles are the same

What you say is true, but the differences at issue here actually worked the other way around. There is a difference, on my system, between the way an untagged AVIF file (created with avifenc) and an untagged PNG file (created with avifdec from the AVIF file) are shown in Firefox. The interesting thing about ICC files was simply that if I tag the output PNG file with a relatively standard sRGB profile, the difference goes away. Something about the behavior of the PNG file changes when it is tagged, in such a way as to seemingly match an untagged AVIF file. My assumption is that an untagged AVIF file and an untagged PNG file decoded from that AVIF file should have exactly the same colors in Firefox.

Let me do the repro again from scratch, giving you access to the whole pipeline: https://cloudflare-ipfs.com/ipfs/QmfJgsCwtWk3nAYaRuNbwEdAf8m6XD8xTDz1brqwrEPotr

1. Input image (1.png)
2. AVIF image (2.avif) created with avifenc 1.png 2.avif
3. PNG image (3.png) created with avifdec 2.avif 3.png
4. PNG image (4.png) created with convert 3.png -set profile /usr/share/color/icc/colord/sRGB.icc 4.png

Note: convert is an imagemagick command. Here we are simply setting a profile to an untagged image, not performing a conversion.

My belief is that 2.avif should look exactly the same in Firefox as 3.png, because decoding the file is a lossless process, and that 4.png should look very similar to 3.png (but not exactly the same, due to differences between ICC profiles).

On the contrary, I see that 2.avif and 3.png have subtle differences (which may only be possible to see on systems where Firefox does real color management, not macOS!), and that 4.png and 2.avif are visually identical! This is extremely surprising, and suggests a bug somewhere in how Firefox is handling the color management of untagged images. (1.png and 3.png are also visually identical, suggesting that the issue is not with the encoder but with the rendering.)

Use the dav1d value for color_range even when color_description_present is false

I'll look at this further after I get this known bug with the range sorted. In the meantime, can you include sRGB.icc in that shared directory?

(In reply to Jon Bauman [:jbauman:] from comment #15)

I'll look at this further after I get this known bug with the range sorted. In the meantime, can you include sRGB.icc in that shared directory?

Unfortunately, IPFS hashes are immutable. I wish I could either edit my comments on this site, or upload multiple files at once, but that's seemingly not possible. Instead, I'm uploading the sRGB here. I'll also upload a new folder with all five files in case that is more useful: https://cloudflare-ipfs.com/ipfs/QmVNG8TKpTzGJVAJib37ZnKLi3Hiw4L64pC64P4ZhN2smM

Just to make certain that we're not miscommunicating, let me underscore the fact that the apparent bug is visible to me before you bring the question of ICC profiles into it at all. I only include that last step in my pipeline because the fact that tagging a PNG with an sRGB profile seemingly fixes the problem of differing rendering (between untagged PNG and AVIF files) is suggestive of where the problem might lie.

So, this is interesting.

I've discovered that the bug does not occur unless gfx.color_management.enablev4 is true. This is extremely exciting because it sounds insane; as far as I know this is only supposed to enable support for embedded v4 ICC profiles, but this problem shows up on images with no embedded profiles at all. Furthermore, even my display profile is a v2 profile, because that's all DisplayCal supports.

Something else too: I don't see the issue with every display profile I set, only with a number of them. Specifically, I've only seen it with certain DisplayCal profiles. Something about the v4 toggle is activating a feature of these display profiles (even though they're version 2), and that feature behaves differently between untagged AVIF and PNG images. Notably, the DisplayCal profiles I've tried all have lookup tables.

Also, even better, I have successfully reproduced the bug on Windows. It requires the following (same as Linux):

gfx.color_management.display_profile=/path/to/your/display/profile
gfx.color_management.enablev4=true
gfx.color_management.mode=1

Better still, I have found DisplayCal created profiles freely available on the web that show the issue. Here is one you can download to confirm my findings.

So on any Firefox install on Windows / Linux, with a fresh profile, set those three settings above (using the profile I linked), restart the browser, open the four test images I linked, and you will see the behavior I'm talking about. Notably, even though the profile I'm linking is not mine, you should see exactly the same effect: images 2 and 3 look different, images 2 and 4 look the same. Something about the color management pipeline for AVIF has got to differ from that used by PNG.

If you think this issue would be better dealt with as part of some color management component, I'm happy to file another bug (though I'd appreciate your help with the AVIF aspect of this). Just let me know.

I can also confirm that, as you said, decoding of AVIF files does not respect the gfx.color_management.mode. I fully agree with you that Bug 553599 should be fixed and the mode should be switched to 1 by default - you're doing the right thing here - but at the same time that's a 12 year old bug. Perhaps in the interest of consistency you should check the value of that setting to determine what to do for AVIF.

FWIW, v4 enables support for lookup tables in profiles.

(In reply to adam.m.fontenot from comment #13)

the way in which Firefox handles these untagged images still seems to be slightly different to the way that Firefox handles untagged AVIF. Specifically, what I see is that Firefox's handling of untagged AVIF is extremely similar to how it handles an sRGB tagged PNG.

What this suggests to me is that either Firefox is performing an additional conversion for AVIF (which can be triggered for the PNG by the addition of an ICC file), or that Firefox treats "sRGB" as meaning different things for AVIF files and untagged PNG files. I'm sorry to harp on this issue, but I really do think something here may need to be fixed. If you feel confident that the issue must be on the PNG end, I can move my comments over to the other issue.

The PNG code was written long before my time, so I'll need to investigate the implementation more, but I can speak to how AVIF works since I'm responsible for nearly all the AVIF-specific code.

The terms "tagged" and "untagged" are kind of unclear in this context, so let's be explicit. For the case of AVIF, color management info comes in 2 layers:

1. The AVIF container (based on ISO BMFF aka MP4) ColourInformation (colr) boxes
2. The AV1 bitstream

The colr boxes can either contain NCLX (CICP values for CP/TC/MC + full_range_flag) or an ICC profile or both (now that bug 1729071 is fixed). The reason for having both is that an ICC profile doesn't provide any way to signal the MC (matrix coefficients) used to convert from YCbCr -> RGB*. So if you want a custom ICC profile in an AVIF, typically it ends up with 1 colr box for the ICC profile and 1 colr box for the NCLX values, but typically with CP/TC set to 2 (unspecified).

The AV1 bitstream has no mechanism for storing ICC profiles (that I know of), but it can store something very similar to NCLX values. The only real difference I can detect is that the CP/TC/MC may be omitted if the color_description_present_flag in the color_config section of the sequence_header_obu, but the color_range is always defined. (See AV1 bitstream spec)

Given all this, it's fairly complex how it all gets applied in all cases, but for the one AVIF in question here (2.avif), things are simple. There's 1 colr box, NCLX-style, so that has 100% of the information we need:

colour_primaries: 1,
transfer_characteristics: 13,
matrix_coefficients: 6,
full_range_flag: true

That is by far the most common situation for AVIF since the vast majority of them on the web today were dynamically generated from existing JPEGs. I'm fairly confident that if the handling there were wrong, I'd have heard about it by now. Almost certainly, if there's an error, it's in my CICP implementation in QCMS, but at least for CP=1 (BT.709) and TC=13 (sRGB), that seems pretty unlikely, since those merely return well-defined constants in the case of CP=1:

ColourPrimaries::Bt709 => {
    green = qcms_chromaticity { x: 0.300, y: 0.600 };
    blue = qcms_chromaticity { x: 0.150, y: 0.060 };
    red = qcms_chromaticity { x: 0.640, y: 0.330 };
}

or the exact same call as what Profile::new_sRGB uses (since NUM_TRC_TABLE_ENTRIES is defined as 1024)

TransferCharacteristics::Srgb => {
    curveType::Curve(build_sRGB_gamma_table(NUM_TRC_TABLE_ENTRIES))
}

So, I find it exceedingly unlikely there's a major error with the way a 1/13/6/full AVIF is handled in Firefox. Furthermore, checking against Chrome with a digital color meter, the results are essentially perfect. I observe at most a difference of 1, while most pixels are identical.

There is a difference, on my system, between the way an untagged AVIF file (created with avifenc) and an untagged PNG file (created with avifdec from the AVIF file) are shown in Firefox.

I'll keep looking at your updated info, but are you seeing a visual differences between how Firefox and Chrome are rendering 2.avif? If not, I think the issue should be discussed elsewhere and this bug can be closed after the limited/full fix lands.

I'm still working to reproduce the difference you're seeing between 3.png and 4.png.

* This isn't relevant if the AVIF happens to store RGB pixel data, but nearly all of them use YCbCr (including all these images), so we can ignore that

(In reply to Adam Fontenot from comment #17)

I can also confirm that, as you said, decoding of AVIF files does not respect the gfx.color_management.mode. I fully agree with you that Bug 553599 should be fixed and the mode should be switched to 1 by default - you're doing the right thing here - but at the same time that's a 12 year old bug. Perhaps in the interest of consistency you should check the value of that setting to determine what to do for AVIF.

I would disagree. It's not that AVIF doesn't respect gfx.color_management.mode so much as there's really no such thing as an "untagged" AVIF. In all cases, the color management is fully specified. Even if there is no signalling via colr boxes, and all the CP/TC/MC values are absent from the AV1 bitstream, the range is always there and the specification requires a specific interpretation (in this case 1/13/6), which is functionally the same as having an ICC profile present for the primaries and transfer characteristics.

(In reply to Adam Fontenot from comment #17)

So, this is interesting.

The weird behaviour you're seeing is caused by bug 1731888

Updating bug name to be accurate to the AVIF-specific issue discovered here and removing the keep-open flag since this issue will be resolved by https://phabricator.services.mozilla.com/D108076

https://hg.mozilla.org/mozilla-central/rev/2d4b49f482c1

Is that patch needed to ship AVIF in 93 or can it ride the trains? Thanks

Comment on attachment 9242167 [details]
Bug 1731404 - Color management of AVIF images is sometimes performed incorrectly. r=jrmuizel

Beta/Release Uplift Approval Request

• User impact if declined: An AVIF with no color management information containing limited-range pixel data will be incorrectly rendered as full-range and look wrong. No known writers generate files like this, so the impact should be very rare, but we don't have the exact telemetry needed to know for sure
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The change is very small, just accessing the range field which I mistakenly believed wouldn't be valid in the absence of other color management information
• String changes made/needed:

Comment on attachment 9242167 [details]
Bug 1731404 - Color management of AVIF images is sometimes performed incorrectly. r=jrmuizel

Approved for 93 beta 9, last beta before RC, thanks.

https://hg.mozilla.org/releases/mozilla-beta/rev/dafc32b38653