Open Bug 1534997 Opened 5 years ago Updated 2 years ago

Firefox does not seem to apply any colour correction to WebP images

Categories

(Core :: Graphics: ImageLib, defect, P3)

66 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: jc86035, Unassigned)

Details

Attachments

(1 file)

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

Steps to reproduce:

  • I viewed https://en.wikipedia.org/wiki/Template:Bristol_and_Gloucester_Railway_Line in the most recent versions of Chromium and Firefox, as well as Firefox Developer Edition 66.0b14. The page contains a number of PNG thumbnails which have been converted from SVG files by librsvg; some of those PNG thumbnails are displayed as WebP due to the images being served in that format by the Wikimedia servers.
  • I made several screenshots using the macOS screenshot function, and also inspected the colours using the Firefox colour picker.

Actual results:

As noted in https://bugzilla.mozilla.org/show_bug.cgi?id=1533990 and https://phabricator.wikimedia.org/T180899#5015155:

  • In Firefox (both 65 and 66), there is a large amount of contrast between the colours of the WebP images and those of the PNG images. This is because the WebP images do not undergo any colour correction. The images' juxtaposition in the diagram is visually distracting and aesthetically irritating (particularly since the exact same RGB colours are frequently used in the source code of the original SVGs).
  • In Chromium, both the PNG and WebP images appear to be colour-corrected, so the difference in colour between the two image formats is less jarring and almost completely unnoticeable.

More images are attached in the comments of the phabricator.wikimedia.org ticket.

Expected results:

  • Firefox should have consistently applied colour correction to the images, or at least the images should not display as differently after conversion to WebP.
Component: Untriaged → ImageLib
Product: Firefox → Core

It should support color correction to the same extent as PNG. I'll investigate.

Flags: needinfo?(aosmond)
Priority: -- → P3

I see the PNG images do not have ICCP chunks, but they do have gAMA/cHRM chunks, which we can alternatively create a qcms profile from:

https://searchfox.org/mozilla-central/rev/aae527894a97ee3bbe0c2cfce9c67c59e8b8fcb9/image/decoders/nsPNGDecoder.cpp#486

The WebP images have nothing. By default we only color management images which are tagged with an ICC profile (or equivalent in the case of PNG), whereas Chrome color manages everything IIRC. Could you try going to about:config and setting the pref gfx.color_management.mode from 2 to 1? I expect it will display correctly. This is a default I would like to change in the next few releases, but I do need to assess the performance costs before doing so.

Flags: needinfo?(aosmond) → needinfo?(jc86035)

I can confirm that changing that setting does improve the colours and makes them almost perfectly consistent, at least for these particular images. The .svg.png and svg.png.webp versions of File:BSicon exSTR+1~RF.svg now display with the solid colours #cc8481 and #cb8380 respectively (the original colour is #d77f7e).

(I have saved both of the images to the Internet Archive in case the Wikimedia server configuration changes before this bug is fixed. The original .svg.png file should still be consistently served as a PNG, since the server currently only converts thumbnails used on more than 400 pages to WebP.)

Flags: needinfo?(jc86035)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: