Calibrate and Profile the Display Used to Review a Treatment

A treatment usually gets its color adjusted for a reason nobody wrote down. A warm page of reference images and type samples reads as muddy on the designer's screen, so the palette gets nudged cooler to compensate. The nudge is now in the file. It will outlive the monitor that caused it.

The screen you review on is the one variable in that story you can actually measure. The client's laptop, the colorist's suite, the proof on the printer's table, the phone someone holds up in a meeting — you can describe those, but you can't inspect them. Your own display sits in front of you with a cable, a menu, and usually a supported way to ask what it's doing.

So the job is to establish a measured local condition, write it down, and then judge the treatment inside it. Not to make other screens agree with yours, which isn't on offer, but to stop an unmeasured display from quietly dictating edits to a file it will never travel with.

Two words do most of the work here, and they're often used as though they were one. Calibration pushes a display toward declared targets. Characterization, or profiling, measures what the display actually does and writes that down. One changes the device or the signal going into it. The other describes the result. Most software performs both in a single pass behind a single button, which is exactly why it's worth keeping them apart in your head.

Define the review condition before you choose targets

Before an instrument comes out of its box, answer four questions and put the answers somewhere you'll find them again.

Which display. Not "my monitor." A name, a connector, a position on the desk. If two screens are attached, the profile you build belongs to one of them, and systems are not always careful about sorting them out when cables move or hardware changes. Deciding to fix the colors without first knowing which panel you're about to characterize is how people carefully profile the wrong screen.

What the work actually is. You're reviewing a treatment on screen: reference images, a palette, type and layout, in an application, for a conversation with a client or an internal team. That is not contract proofing for print, not broadcast grading, and not product color approval. The distinction sets how tight the targets need to be and, more consequentially, what you're allowed to claim afterward. Treatment review needs a stable, known, repeatable condition. It does not need a certificate.

The room. Light falling on the screen changes what you see even when the display hasn't changed at all. Note the window, the blinds, the lamps, and whether you can sit roughly square to the panel — off-axis, many displays shift color more than a small calibration error would. Write the condition down in enough detail to recreate it, because "I looked at it in the morning and again after dinner" is not a comparison. It's two different rooms.

The current state. Record everything you're about to change. The display's own menu mode and brightness number. The name of the profile currently assigned to it. Any night-shift or blue-light feature, any automatic brightness, dynamic contrast, or content-adaptive mode that changes the panel's behavior depending on what's on screen. Photograph the menu if that's faster than transcribing it. The point isn't ceremony. Some calibrations make a panel worse for a particular job — banded in shadows, dimmer than you want under office light — and you want a road back that doesn't depend on memory.

Now targets. A target is an agreement, not a fact about color. It usually has three parts: what white should measure, how bright the display should sit (luminance, in candelas per square meter — the same quantity people call nits), and how it distributes tones (a tone response, usually written as a gamma value or as the sRGB curve, which is close to 2.2 but not identical to it near black).

Every tool offers defaults for those three, and the defaults disagree with each other. Brightness is the one that most obviously depends on your situation — a very bright display can look impressive and can also push you toward a contrast decision you'd reverse in a dimmer room. Pick targets that fit the review you actually do, write down why you chose them, and keep them consistent across sessions so later comparisons mean something. Choosing a white point because a preset carries that number and choosing it because your references and your colleagues' screens live in that neighborhood are different decisions, and only the second one survives being questioned.

One thing this task is not: it isn't choosing the commercial's palette. A treatment reference can be legitimately warm. It can be green, dim, or oversaturated on purpose. After a display has been measured and adjusted, a warm reference still looks warm, and that's the correct outcome. A newly calibrated screen is a standing invitation to rebalance artwork that was never unbalanced. Measurement tells you what the page is doing under a stated condition. It doesn't tell you whether you like it.

Confirm the measurement chain is actually supported

Calibration isn't a property of an instrument or of a display. It's a relationship among three things — the instrument, the software driving it, and the specific display — and sometimes a fourth: an instrument correction that accounts for how your display's light differs from the light the instrument was built around.

Supported is the word to hold onto. A combination that worked well on one panel may read a different panel inaccurately, and a software release that supports your display today may not support it after the panel, the operating system, or the connection changes. So before you write installation steps — for yourself, for a colleague, for a studio wiki — check current documentation from the makers for the exact combination in front of you: instrument model, software version, operating system, display model. Not a forum post from three years ago, not the version someone recommended in a thread. Current documentation, for your combination.

The reason correction exists is worth understanding. Many instruments infer color from a small set of filtered sensors, and what those sensors report depends partly on the spectral character of the light reaching them. Panels differ there: different backlights, different coatings, wide-gamut versus standard. Where a maker publishes a correction for your instrument and display type, treat it as part of the supported setup rather than an optional refinement. Where nothing is published for your combination, that's a real limitation, and it belongs in your record instead of in a footnote you'll forget.

The DisplayCAL project's documentation — on the page headed version 3.8.9.3 and dated 14 December 2019 — keeps the measuring-and-adjusting step separate from characterizing a display with a profile, and it warns that a closed-loop check can reproduce an instrument's own error. That separation and that warning are durable ideas about how display measurement works. The page describes a historical release, so it's a conceptual reference rather than an installation recommendation; whether any given version installs on and supports your hardware is a question for current material from the project and the hardware makers, and it deserves its own check rather than an assumption.

Identify the display unambiguously while you're at it. Many systems will flash a number on each screen on request. Write down which port the panel is on. And decide once, in a two-display setup, which one is the review display, then treat every other screen on the desk as untrusted for judging color — because it is.

Adjust and characterize without confusing the two jobs

In a typical supported workflow, the software shows a sequence of patches and reads them, adjusts the display toward your targets — sometimes by asking you to change the display's own controls, sometimes by writing a correction curve the operating system loads for that display — and then measures a broader set of patches to build a profile. Several steps adjust. One step describes. Keeping track of which is which is the discipline.

The adjustment changes the condition. The profile describes the condition. Everything after that — every judgment about the treatment, every comparison against a printed reference, every note you send a colorist — is only as trustworthy as your memory of the state it was made in. Turn the brightness knob next week and the profile is describing a display that no longer exists.

A practical detail follows from this. On most consumer displays and many prosumer ones, a good share of the adjustment happens in the graphics system rather than inside the panel. That correction curve is a piece of state living in your computer: it can be dropped by a driver update, and it doesn't follow the display to another machine. Re-cable or swap computers and you may end up with the profile present and the adjustment absent, or the reverse. Record both, and check, with your eyes, that the display still looks the way the record says it should.

Some panels, laptop screens especially, expose almost no controls of their own. That pushes more of the work into the correction curve and makes recording that curve more important, not less.

Now the record. Here's the shape of one. Every entry below is invented to show the fields and how a target that was only partly met gets written down instead of hidden; nothing in it was measured for this article.

Two files are involved in this workflow, and they have different jobs. The profile you just built describes a display. The profile embedded in a treatment page describes the meaning of the numbers in that page. Choosing the monitor's profile in an "assign profile" command, or letting it ride along in an export, tells every other machine that your page's colors were meant to be interpreted through your particular panel's individual quirks. Even an accurate display profile is the wrong profile for a document. It's a description of a device, being asked to do the job of describing a file.

If the treatment genuinely has a color problem — an image with no embedded profile, a profile that doesn't match what's inside it, a page that carries a different intent than the reference beside it — that's a separate investigation with its own evidence. The one move to rule out is recoloring the page so your screen agrees. You'd be writing your display's unknown error into a file that travels without it.

Check where the profile sits in the viewing route

A calibrated display with a profile that nothing uses is a very well-documented decoration. Three things have to line up: the intended display has the profile assigned, the application you're reviewing in honors it, and you're looking at the right window.

The first is partly a naming problem. Two screens on a desk, two profiles, and a system that may or may not be clear about which is which. Use the identify function, confirm that EXT-27 is the panel you think it is, and confirm the profile is assigned to it. Moving the window to the other display invalidates your measured condition silently, which is what makes it dangerous — nothing about the image announces that it's now being described by the wrong file.

The second is a behavior question, and here, remembering lore is worse than checking. Applications differ in whether they manage color at all, whether they use the display profile, whether a proofing toggle is changing the preview, and how they treat an untagged image. Thumbnails, quick previews, and a browser's built-in viewer may take a different path than the application itself, so what you see in a preview isn't automatically what the app would show you.

So name your system and your application by version, find out what those versions do, and write down what you found rather than what an older article said about an earlier release. Operating system color management has changed over the years, and only the version in front of you counts.

A cheap diagnostic: make a page containing a few patches of known values, open it in the application you'll use for the treatment, and see whether it renders the way the numbers suggest. If it doesn't, you've found a route problem — an application setting, a profile assigned to the wrong display, a proofing toggle left on. That page is a diagnostic, not a fix. Then open a representative page of the actual treatment under the recorded condition.

Two more things worth noting in the record. If the display offers a wide-gamut or HDR mode, write down which mode was active, and treat any other mode as unmeasured — some of those modes sit outside the ordinary profile path rather than being described by it. And if the page still looks wrong once the route is confirmed, resist correcting the page. Note what you saw and keep the possibilities separate: the file, the route, or the condition. Diagnosis that gets painted into the artwork is very hard to unpaint later.

Read verification as a bounded measurement

The verification run is where a calibration turns into a record. The software measures the display again — a set of patches, sometimes the same one, sometimes a larger grid — and compares what it reads against your declared targets and the profile it built. The output is a short report: an average difference and a worst case, usually as ΔE values, alongside the date, the instrument, the software, and the settings.

Keep that report. Read it correctly. It's a measurement of a display chain under a stated condition, not a verdict about color in general.

The trap is the closed loop. The same instrument that helped build the profile usually performs the check afterward. A systematic error in that instrument — the kind that comes from how it responds to a particular panel's light — shows up in the profile and in the check in the same direction, so a reassuring number can be partly the instrument agreeing with itself. This is why the DisplayCAL documentation's warning about repeated instrument error matters beyond that page: consistency within one chain is not proof of absolute accuracy. In the invented record above, an average of 1.1 and a worst case of 2.4 would mean the display behaves close to what the profile claims. They would not mean the display is objectively right, and they certainly wouldn't mean another screen somewhere shows the same thing.

If you want something closer to an independent check, that means a different instrument — ideally a different type or from a different maker — reading the same display. If you only have one, say so where the record lives. A documented limitation is worth more than an implied guarantee.

What the number does buy you is real, though, and it's the reason to bother. It tells you the profile matches the display closely enough that a color-managed application can convert into it without obvious error. It gives you a baseline: measure again in a few months, and a shift in the values is drift you can see rather than drift you discover mid-argument about a file. Panels age, backlights change, and a dated record is how you catch it.

And then the boundaries, stated plainly because they're the part that gets overpromised. A verified display does not make other viewers' screens match. It isn't a print match. It doesn't certify product color, and it isn't evidence that the treatment is right — only that you judged it under a condition you can name. What it removes is the silent case: the unmeasured monitor steering file edits that nobody can trace back to it. That's a smaller claim than "calibrated," and a more useful one.

Keep the record short enough that you'll actually reopen it. The display, the targets, the numbers, the residual, the date, the way back. Months from now, when someone asks why the page looks the way it does, the answer you want isn't that it looked fine on your screen — it's a date, a condition, and a note about which parts of the file you changed on purpose.

Frequently asked questions

What is the difference between calibration and characterization or profiling?

Calibration pushes a display toward declared targets. Characterization, or profiling, measures what the display actually does and writes that down. One changes the device or signal going into it; the other describes the result. Software often performs both, but keeping the jobs separate matters.

What should be recorded before calibration begins?

Record the specific display, the room and viewing position, and the current state: menu mode, brightness number, assigned profile, and any night-shift, auto-brightness, dynamic contrast or content-adaptive mode. Photograph the menu if that is faster. Some calibrations can make a panel worse for a particular job, so you need a road back that does not depend on memory.

What does the verification report actually tell you?

It measures a display chain under a stated condition and compares results with declared targets and the profile. An average and worst-case difference show the display behaves close to what the profile claims. It is not proof of absolute accuracy: the same instrument often performs the check, so a reassuring number can be partly the instrument agreeing with itself. It also does not make other screens match or certify product color.

Why is assigning a display profile to a treatment document a mistake?

A display profile describes a device. A treatment document's embedded profile describes the meaning of the numbers in that file. Assigning the monitor's profile or letting it ride along in an export tells other machines to interpret the page through your panel's individual quirks. If the treatment has a real color problem, that is a separate investigation; do not recolor the page so your screen agrees.

What has to line up in the viewing route?

The intended display must have the profile assigned, the application you review in must honor it, and you must be looking at the right window. Moving the window to another display invalidates the measured condition silently. Application color behavior varies by version, so check the versions in front of you rather than relying on older lore. Wide-gamut or HDR modes should be recorded and other modes treated as unmeasured.

Further reading

• Match Commercial Test Shots Before Judging the Color Look — Before judging a proposed color look on your measured display, use this to separate unintended exposure and white-balance differences from deliberate scene changes.