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
[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