PicaJet

Reference Glossary

Colour profile mismatch

A discrepancy between the colour profile embedded in a file and the profile the viewing or output system expects, causing colours to render inaccurately even though the underlying pixel data is unchanged.

Why it matters in a DAM

DAM systems distribute the same asset to web CMSs, print vendors, and video platforms that don't share a common colour-management pipeline, so a file tagged Adobe RGB and opened in a non-colour-managed sRGB context can look flat and desaturated despite nothing being wrong with the actual pixels. This is a frequent source of 'why does the logo look different on the website versus the printed brochure' tickets, and the correct fix is checking the embedded profile against the destination, not re-editing colours that were never actually incorrect.

A worked example

Adobe RGB file, no embedded profile, opened in sRGB browser Colours look flat and desaturated
sRGB web asset sent directly to a CMYK press Colours can look muddy, saturated colours get clipped
File with correct embedded profile, colour-managed app Colours render as intended

Common mistake

'Correcting' colours that look wrong in one specific context (like a browser) by re-editing the source image, when the actual problem is a missing or mismatched colour profile — the pixel data was correct all along, it just wasn't rendered with the right profile.

A colour profile mismatch happens when the profile embedded in a file doesn’t match, or isn’t recognized by, the system displaying or printing it. The pixel values in the file don’t change — what changes is how those values get interpreted. An image built in the wider Adobe RGB gamut, opened without its profile in an application that assumes sRGB, gets its colours reinterpreted through the narrower space and comes out visibly duller than intended.

This is a particularly common failure point in DAM workflows because a single master asset is routinely pushed to destinations with very different colour assumptions — a colour-managed design app, a non-colour-managed browser, and a CMYK print workflow can all render the identical file differently. The diagnostic tell is that the pixel data itself is fine; the fix is making sure the correct profile is embedded and preserved through every export and delivery step, not adjusting the image’s actual colours to compensate for one context’s misreading of it.

Frequently asked

What is a colour profile mismatch?

A discrepancy between the colour profile embedded in a file and the profile the viewing or output system expects, causing colours to render inaccurately even though the underlying pixel data is unchanged.

Does the pixel data actually change in a colour profile mismatch?

No. What changes is how those values get interpreted; an Adobe RGB image opened without its profile in an sRGB-assuming app gets reinterpreted through the narrower space and looks duller than intended.

Why is this a common source of DAM support tickets?

A single master asset is routinely pushed to destinations with different colour assumptions, such as a colour-managed design app, a non-colour-managed browser, and a CMYK print workflow, so "why does the logo look different on the website versus the brochure" comes up often.

What's the mistake teams make when colours look wrong in a browser?

The common mistake is re-editing the file's actual pixel values to match what's visible on screen, rather than diagnosing the real cause: a missing or wrong ICC profile on the file, or mismatched colour-management settings in the browser or monitor. Manually adjusting pixels to compensate for a display issue permanently alters the source, so the image then looks wrong on any correctly calibrated, colour-managed system that reads it afterward.

What happens when an sRGB web asset is sent directly to a CMYK press?

An sRGB web asset carries the narrower gamut used for screens, while a CMYK press works within the smaller, differently shaped gamut achievable with cyan, magenta, yellow and black ink on paper. Sending the file straight to press without converting the profile leaves out-of-gamut colours, especially bright saturated hues, clipped to the nearest reproducible shade, producing dull, muddy, or shifted results; the fix is an explicit sRGB-to-CMYK profile conversion before printing, not a direct handoff of the original file.

What's the correct fix for a colour profile mismatch?

The fix is converting the file into the target colour space via its ICC profile — for example Adobe RGB to sRGB before web delivery — using a mathematical transformation that recalculates pixel values while preserving the actual colour, not manually editing or guessing at hues to compensate for a bad on-screen preview. The converted file keeps its correct embedded profile through every export and delivery step, so colours stay accurate on any properly calibrated device.