{"id":289,"date":"2021-03-01T22:18:58","date_gmt":"2021-03-01T22:18:58","guid":{"rendered":"http:\/\/simongarrett.uk\/simon\/?page_id=289"},"modified":"2023-05-12T10:09:54","modified_gmt":"2023-05-12T09:09:54","slug":"colour-mismanagement-on-the-web","status":"publish","type":"page","link":"https:\/\/simongarrett.uk\/simon\/colour-management-information\/colour-mismanagement-on-the-web\/","title":{"rendered":"Colour (mis)management on the web"},"content":{"rendered":"\n

Updated: 12th May 2023<\/em><\/p>\n

Colour management \u2013 appropriate rendering of colour information \u2013 has a troubled relationship with the web, which is to say few people understand it and many websites commit heinous atrocities to colour.<\/p>\n

For website designers, it\u2019s very simple: don\u2019t mess with colour information. Leave that colour profile alone and walk away. The website should store graphic elements with any embedded colour profiles or colour-related metadata. When the page is requested from the website it should then supply the graphic element with any embedded profile and colour-related metadata unaltered. Any rendering from one colour space to another should normally be a matter for the browser, not the website.<\/p>\n

If your website is concerned only with sRGB images, you can make a case for\u00a0converting<\/em> images to sRGB. That\u2019s not always a good idea, and means the website may not be future-proof, but it may make sense if you are targetting a general web audience, who probably have roughly sRGB gamut monitors. Whatever you do, don\u2019t simply remove the profile or colour-related metadata, and if you convert to another colour space, make sure the correct profile for the new colour space is embedded. Unfortunately many web content management systems (CMS) are a bit clueless about colour, and don\u2019t convert images to sRGB, they simply delete the profile! This is like taking a temperature value and then removing the label that says whether it\u2019s degrees F or degrees C (or even degrees K). When the web page is retrieved, if images have no colour profiles then the poor bloody browser has no clue how to render the colour in the image, and has to guess.\u00a0<\/p>\n

WordPress<\/h3>\n

This website uses WordPress, and I\u2019ve discovered that WordPress and some plugins do mysterious and inconsistent things to colour profiles. When an image is uploaded to the site, typically it is put in the “Media Library”.\u00a0 In addition to the original image (with any profile and colour-related metadata intact), WordPress typically creates lower resolution versions with the profile and most medadata stripped out.\u00a0 The W3C standard says that images without embedded profiles or colour metadata should be in sRGB colour space, but WordPress doesn’t bother to convert or even check the colour space before discarding any relevant information.\u00a0<\/p>\n

When an image is displayed, what happens depends on whether the original image is displayed or one of the reduced resolution versions.\u00a0 Code created by the WordPress block editor may choose one of the lower resolution versions, which may then be displayed incorrectly.\u00a0 This is unpredictable.\u00a0 It does this for all block types I’ve checked that that incorporate images, including the legacy Classsic blocks. To make matters worse, different browsers make different assumptions if profile and\/or metadata is missing. Intriguingly, even different Chrome-based browsers differ in how they render WordPress-delivered images.\u00a0 Nextgen Gallery and other gallery plugins may take different action.\u00a0<\/p>\n

The result of all this is that images in colour spaces other than sRGB may be displayed incorrectly, depending on the exact circumstances in which the image is displayed (including the size of the displayed image), which plugins are used to upload or display the images, and depending on assumptions made by the browser for missing profile or metadata.\u00a0<\/p>\n

This chaotic and arbitrary treatment of colour has been around a long time. Googling about colour errors on WordPress returns many, many hits where people report inaccurate colour on WordPress sites, and the only answer appears to be to upload only sRGB images. It\u2019s a disaster if you want to use other colour spaces. The WordPress developer community is presumably blissfully unaware of the problems they create, as most of the web is unconcerned with colour accuracy and most monitors are roughly sRGB.<\/p>\n

This issue will come back to bite WordPress, as increasingly monitors will not be sRGB, but will be wider gamut spaces like UHD Rec 2020, and people will start wondering why colours are all wrong. They may also start wondering why they can\u2019t have the bright, vivid colours that were the reason for buying an HDR monitor.<\/p>\n

The only fix I\u2019ve found is to display images by inserting custom html blocks with <img > tags that explicitly reference the original uploaded image, rather than one of the reduced resolution versions (which is what WordPress editor blocks tend to do).<\/p>\n

The moral for website developers: if you don\u2019t understand colour management, then don\u2019t touch profiles or colour metadata.\u00a0 Whatever profiles or colour-related metadate are in an image file when it’s uploaded, leave them there.\u00a0 And follow the standards.\u00a0<\/p>\n

Microsoft browsers and image viewers<\/h3>\n

Internet Explorer and Edge (up until the new Chromium-based version launched in 2020) had colour management built in, but deliberatly crippled it.\u00a0 They ignore the monitor profile and convert the image to sRGB.\u00a0 This guarantees wrong colours except for monitors with an accurate sRGB colour space, and I\u2019ve yet to hear any rational explanation for this behaviour.\u00a0<\/p>\n

The Windows 7 \u201cWindows Photo Viewer\u201d correctly colour-manages.\u00a0 But the newer Windows 10 Photos app behaves the same way as IE and the old Edge.\u00a0 Why?<\/p>\n

Firefox<\/h3>\n

The Firefox developer community don\u2019t get it quite right either.\u00a0 The W3C (World Wide Web Consortium), who write the web standards, do understand colour, and and specify that if an image or graphic element does not contain an embedded profile it should be rendered as sRGB.\u00a0 The Firefox developers (probably through ignorance and failure to read the W3C specs) decided that by default Firefox won\u2019t colour-manage elements without a profile.\u00a0 The means that if an element has no profile, it will be displayed in the right colour only if by coincidence the monitor has\u00a0exactly<\/em>\u00a0the same colour space as the image.\u00a0<\/p>\n

There is an option to make Firefox obey the W3C standard, by setting option \u201cgfx.color_management.mode<\/strong>\u201d to 1 (from its default of 2).\u00a0 However in 2020, Firefox made a change to the browser that stopped even this option working.\u00a0 This was apparently not a bug, but a misunderstanding of colour management.\u00a0 This made Firefox largely unusable on a wide-gamut monitor. The discussion on the bugzilla threads for this change suggested the developers didn\u2019t really understand the issue (which was fixed after a month or two following a lot of grumbling from users that did understand the issue).\u00a0\u00a0<\/p>\n

Firefox also has a setting “gfx.color_management.native_srgb<\/strong>“, and if set true this forces Firefox to behave like the colour-dumb Microsoft software like IE and the Photos App; that is, it ignores the monitor profile and renders the image to sRGB, virtually guaranteeing false colour if you have a wide-gamut monitor.\u00a0 Fortunately, that setting defaults to false, although in Firefox 113 (May 2023) for some bizarre reason they changed the default to true.\u00a0 Apparently this is a bug, due to be fixed in release 115, which I hope means setting the default in this rather pointless setting back to false.\u00a0 However, even the existence of this setting indicates to me a poor understanding of colour management by Firefox developers.\u00a0 Whatever the problem, forcing any<\/em> software to ignore the monitor profile and render to sRGB is not the solution!<\/p>\n","protected":false},"excerpt":{"rendered":"

Updated: 12th May 2023 Colour management \u2013 appropriate rendering of colour information \u2013 has a troubled relationship with the web, which is to say few people understand it and many websites commit heinous atrocities to colour. For website designers, it\u2019s very simple: don\u2019t mess with colour information. Leave that colour profile alone and walk away. […]<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":32,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"ngg_post_thumbnail":0,"footnotes":""},"class_list":["post-289","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/simongarrett.uk\/simon\/wp-json\/wp\/v2\/pages\/289","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/simongarrett.uk\/simon\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/simongarrett.uk\/simon\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/simongarrett.uk\/simon\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/simongarrett.uk\/simon\/wp-json\/wp\/v2\/comments?post=289"}],"version-history":[{"count":15,"href":"https:\/\/simongarrett.uk\/simon\/wp-json\/wp\/v2\/pages\/289\/revisions"}],"predecessor-version":[{"id":523,"href":"https:\/\/simongarrett.uk\/simon\/wp-json\/wp\/v2\/pages\/289\/revisions\/523"}],"up":[{"embeddable":true,"href":"https:\/\/simongarrett.uk\/simon\/wp-json\/wp\/v2\/pages\/32"}],"wp:attachment":[{"href":"https:\/\/simongarrett.uk\/simon\/wp-json\/wp\/v2\/media?parent=289"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}