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?

Re-editing the source image's actual colours to compensate, when the pixel data was correct all along and the real problem is a missing or mismatched colour profile.

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

Colours can look muddy and saturated colours get clipped, because the sRGB gamut doesn't map cleanly onto the press's CMYK gamut.

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

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.