Colour management information

Various colour management stuff – see the “Colour Management” menu above for more. 


Colour (mis)management by websites

19th February 2021

Colour management – appropriate rendering of colour information – has a troubled relationship with the web, which is to say few people understand it and many websites commit heinous atrocities to colour. 

For websites, it’s very simple: don’t 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. 

If your website is concerned only with sRGB images, you can make a case for converting images to sRGB. That’s not always a good idea, and means the website won’t 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’t 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’t convert images to sRGB, they simply delete the profile!  This is like taking a temperature value and crossing off the label that says whether it’s degrees F or degrees C (or even degrees K).  When the web page is retrieved, the poor bloody browser has no clue how to render the colour in the image. 

This website uses WordPress, and I’ve discovered that WordPress and some plugins do mysterious and inconsistent things to colour profiles.  The WordPress block editor sometimes (but intriguingly not always) removes colour profiles when an image is displayed.  It does this for all block types that that incorporate images, including the legacy Classsic blocks. It doesn’t normally alter the stored image (though some plugins do), but appears use CSS classes (or the php behind them) to remove the profile and some metadata, probably if the image is resized for display.  I’ve not quite got to the bottom of this, as sometimes the profile is removed and sometimes it isn’t, and some or all of the metadata is (or isn’t) removed. 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. 

Nextgen Gallery (one of the most popular photo gallery plugin) appears to remove profiles sometimes when the image is uploaded. 

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. 

This chaotic and arbitrary treatment of colour has been around a long time.  Google 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’s 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. 

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’t have the bright, vivid colours that were the reason for buying an HDR monitor. 

The only fix I’ve found is to display images by inserting custom html blocks with <img > tags without any class (or with your own classes that don’t mess with colour).

The WordPress developer community are not alone in messing up colour.  In 2020, Firefox made a change to the browser that meant that it stopped colour-managing images and graphic elements without embedded profiles.  This is contrary to the W3C specification (which says that untagged images should be assumed to be sRGB) and made Firefox largely unusable on a wide-gamut monitor.  The discussion on the bugzilla threads for this change suggested the developers didn’t really understand the issue (which was fixed after a month or two)  . 

Thes things are what happen when people that don’t know what they’re doing start messing with colour.  And if you don’t know what you’re doing, don’t touch profiles or colour metadata, and follow the standards.