• Please use real names.

    Greetings to all who have registered to OPF and those guests taking a look around. Please use real names. Registrations with fictitious names will not be processed. REAL NAMES ONLY will be processed

    Firstname Lastname

    Register

    We are a courteous and supportive community. No need to hide behind an alia. If you have a genuine need for privacy/secrecy then let me know!
  • Welcome to the new site. Here's a thread about the update where you can post your feedback, ask questions or spot those nasty bugs!

Display calibration and profiling

Doug Kerr

Well-known member
When we seek to "prefect" the way in which our display system present the colors of an image file, we typically use software packages that, operating with a colorimeter "head", perform in sequence two quite different processes, calibration and profiling. These two are often confused.

[By the way, the details that follow pertain to Windows, and only through XP that I can be sure of.]

• In performing calibration, the software determines the response of the display system (driver plus monitor) and, by formulating a new suite of entries for the "lookup tables" (LUT) in the display adapter, seeks to give the display system a response matching a standard color space (often sRGB). In general, it is not possible to perfectly attain this (more on this shortly).

• In performing profiling, the software determines the response of the display system (driver plus monitor) with the freshly-determined "calibration" in place. It then describes that response in an icc profile file.

Profile-aware image editing or handling applications then can refer to this icc profile and properly transform the color representations in an image file into representations that, fed to this particular display system, will cause it to generate the colors described in the file.

One objective of the calibration stage of the process is that the calibrated display will do the best attainable job of correctly presenting the colors in an image file fed to the display by an application that does not make use of the icc profile (a "non-profile aware" application).

The LUT tables in the display adapter, one for each "channel", R, G, and B, describe transfer functions between the channel value sent to the display system and the channel signal sent to the monitor. We cannot, merely by changing the entries in these tables, overcome all the imperfections in display behavior. Most notably, we cannot that way compensate for the primaries of the display not having the chromaticities assumed by the standard color space.

Thus the importance of the icc profile in "perfecting" the display process.

Different software packages may use different strategies for deciding, if it can't "perfect" the display by calibration, which "imperfect" situation should it put into effect.

Note that the icc profile for a display only works properly if the LUT settings in the display driver are those chosen and implanted by the calibration-profiling software just before it developed the profile.

Are the lookup table settings held in non-volatile memory in the display adapter? Not usually. In fact, when the system is (re) started, those tables are filled with standard "factory" values from RAM in the adapter.

How then does the calibration established by our software package stay in effect? A little program (an "LUT loader"), usually installed by the profiling-calibration software, each time the system is (re)started, automatically runs and loads into the LUT that suite of entries. Where does it get those?

Normally, these LUT settings are stored in a "caboose" of the icc profile file, called the vcgt tag, from “video card gamma table” (“gamma table” referring to the LUTs). This is not part of the profile proper, but the icc standard for profile files recognizes that this caboose may exist.

Which icc profile file does the "LUT loader" get the entries from? One that it was told to use during the calibration-profiling process. (That is held in the Registry.)

Not the one we told some profile-aware application to use? Nope. Not the one we told Windows was the preferred profile for our display? Nope.

What in fact does it do when we tell Windows that a certain icc profile is the one we want use for our display? Does is make the operating system, itself, apply the profile when colors are sent to the display? Nope. That only happens in a profile-aware image application, before the colors are sent to the OS.

What is does is, when a profile-aware image application starts up, it asks Windows, "has the owner 'nominated' a profile for use with the display system here?" Windows reports, "yes, this one". The application then starts by putting that profile into effect, which remains in force unless and until the user tells the application to use another profile.

What if we have used more than one calibration-profiling software package? Then there might me more than one LUT loader in operation, and the LUT will end up with the settings from the caboose of the icc profile file used by which ever one runs last during the startup.

What happens if the icc profile we tell a profile-aware application was made by one calibrating-profiling package, but the one whose caboose is used by the LUT loader to populate the LUT at startup was made by another package? Might that mean that we don't get the intended color performance? Could be.

Best regards,

Doug
 

Doug Kerr

Well-known member
Hi, Andrew,

I’d say a critical reason to calibrate (and what you would calibrate for, the targets) is to produce a screen to print match.

Well, my thought is that to attain this we need to profile, or preferably calibrate and then profile, for the display chain, and profile for the printer.

Maybe by "calibrate" you mean "profile" or (where applicable) "calibrate and profile".

Best regards,

Doug
 

Andrew Rodney

New member
In the chain of events, calibration takes place first, then the profile reflects those conditions. Calibration is placing a device into a desired (optimal?) state. Profiling describes that state.

Not all devices need to be calibrated. A display is unstable, and its behavior should be calibrated to reflect a condition that produces a match to a print if your goal is WYSIWYG and described in the link above. Some devices are very stable, they don’t necessarily need calibration. An Epson printer is an example. Its behavior isn’t ideal IMHO (its not all that linear in ink delivery). But it can profiled and since its quite stable, the canned profiles Epson provides do a pretty good job.
 

Doug Kerr

Well-known member
Hi, Andrew,

In the chain of events, calibration takes place first, then the profile reflects those conditions. Calibration is placing a device into a desired (optimal?) state. Profiling describes that state.
Yes.

Not all devices need to be calibrated. A display is unstable, and its behavior should be calibrated to reflect a condition that produces a match to a print if your goal is WYSIWYG and described in the link above.
But calibration alone will not (necessarily) attain that. Profiling (and of course the use of that profile) is (usually) needed to complete the desired situation.

Some devices are very stable, they don’t necessarily need calibration. An Epson printer is an example. Its behavior isn’t ideal IMHO (its not all that linear in ink delivery). But it can profiled and since its quite stable, the canned profiles Epson provides do a pretty good job.
Yes.

Best regards,

Doug
 
Top