It sounds like you're trying to check the colors via printscreen/screenshot or by a color picker that is in the web browser. This is not a good way to check the colors due to the way programs and computers generate colors, there are a lot of factors that come into play.

I opened the generated raster images 500px-BSicon_RACONTgq.svg.png and 500px-BSicon_RAl.svg.png in photoshop and I'm showing the colors #FFFF00 and #FF0000.

@Offnfopt Regardless, the difference in rendering is still an issue because BSicons are usually juxtaposed with each other in Wikipedia articles, so the colour change between icons uploaded before April 2017 and after March 2017 is minor but nevertheless visible. The easiest way to fix this would be to force every SVG on Commons to be re-rendered, but I'm not sure if that's possible without reuploading every single file.

No action is presently needed since I have purged all of the BSicon files myself with pywikibot, but it would be nice to have the renders automatically redone upon librsvg updates.

@Aklapper I don't know if the original issue is still relevant, since this may have been some sort of normally-invisible librsvg change that made Firefox start applying colour correction. However, starting with Firefox 65, there is still an issue with non-matching colours, which only occurs because certain files (and only at certain thumbnail sizes – 20px, 30px and 40px) are being served as WebP.

Firefox 65	Internet Archive	Firefox 60 / Tor Browser	Safari 12	wget
40px-BSicon_exSTRr.svg.png290 BDownload

I have no idea why the server is doing this for a very particular set of BSicons. It could be related to frequency of usage, since rarer images don't seem to ever be served as WebP, but there might not be a particularly strong correlation.

I drafted a Phabricator bug report but decided to file one to Mozilla's bug tracker first (after posting to Wikipedia:Village pump (technical) on enwiki), and was bluntly informed that this was an issue with the Wikimedia server.

Firefox does not convert between image formats !
The server converted the image to webp and send the webp image to Firefox for the requested URL !

I think this may warrant a different bug report but I'm still not sure if this is the same issue. The downloading issue will no longer appear in Firefox 66 but the colour mismatch issue could.

We serve WebP for some browsers and popular thumbnails as per https://phabricator.wikimedia.org/source/operations-puppet/browse/production/modules/varnish/templates/upload-frontend.inc.vcl.erb$225

Would it be possible or appropriate to turn this off for BSicons, or even all PNGs?

Alternately, would it be possible to turn this on for all BSicons? There are about 110K of them, so this may be an issue.

(Also, it could be appropriate to turn it off until after Firefox 66 is released, since there are a lot of Firefox users who are currently unable to save loaded PNGs.)

Using one of the files you've mentioned https://commons.wikimedia.org/wiki/File:BSicon_exSTR.svg

Opening the SVG, the PNG thumbnail we generate at 40px and the webp thumbnail we generate at 40px, the color of the stroke is exactly #d77f7e in all three of them (verified in GIMP). Files attached here for reference:

Displaying all 3 formats together on an HTML page, no difference in Firefox 66:

This was tested on Firefox 66/MacOS 10.14.3

@Gilles What Firefox displays is different to what GIMP displays because (as far as I understand it) Firefox applies some sort of colour correction to PNGs but not WebP images. No one is viewing the pages in GIMP.

As tested in Firefox 66.0b14:

These are screenshots from Template:Bristol and Gloucester Railway Line. I used Firefox's built-in colour picker on the row above "Lawrence Hill", and I used the built-in macOS screenshot function to make the screenshots. The difference is large enough to be visually noticeable for me.

(The middle image is actually enough to demonstrate the difference, because a PNG image is overlaid above a WebP image in the diagram.)

• In Chrome/Chromium, there is a very slight colour difference between .svg.png and .svg.png.webp thumbnails; the colours above are actually shown as #b03730 and #af3a33 respectively. However, because Firefox applies no colour correction at all to WebP files, the difference is more jarring.
• In Safari, the webp file is not recognized and Safari tries to download the file. (macOS does not seem to support WebP files natively.)
• Tor Browser (Firefox 60.5.1esr) does the same, since WebP support was added in version 65.

Below is Chrome's rendering of part of the same diagram. The difference is much subtler, and I didn't notice it at all.

Should we expect Firefox to apply colour correction to WebP files?

We should expect browsers to render identical color information identically, irrespective of the image format it's expressed in... What we get from GIMP by looking at the files directly is the reference and we're getting identical color values between the 3 formats we're serving. If there are color rendering discrepancies when displayed, it's a browser bug.

At least the mix-and-matching of WebPs and PNGs in those diagrams will go away eventually, as we are working on serving WebP variants to WebP-capable clients for all images, not just the high traffic ones. Currently blocked by this ongoing task: T211661: Automatically clean up unused thumbnails in Swift which I hope to complete this year.

Would it be appropriate to file another Firefox bug? I can't find an existing ticket for this, although maybe it's because I'm using the wrong keywords.

Certainly. You should provide the identical webp and png after having verified that they contain the same color information in GIMP, Photoshop or any tool of that nature, and a screenshot showing that they render differently side-by-side in Firefox.

Are we sure that the ICC and/or sRGB info is equal between the two thumbs as well ? Because that too could cause browser side differences of course. especially if browsers support one of those and not the other..

No ICC profile in any of these, because SVGs don't have color profiles.

I've filed a Firefox bug.

I'm glad that the issue has been acknowledged by Mozilla. Thanks for your thorough reporting work both on our end and theirs, @Jc86035