diff options
Diffstat (limited to 'doc/Scenarios.html')
| -rw-r--r-- | doc/Scenarios.html | 5779 |
1 files changed, 2925 insertions, 2854 deletions
diff --git a/doc/Scenarios.html b/doc/Scenarios.html index 8cd45c9..c8bb154 100644 --- a/doc/Scenarios.html +++ b/doc/Scenarios.html @@ -1,134 +1,134 @@ -<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
- <head>
- <title>Argyll Usage Scenarios</title>
- <meta http-equiv="content-type" content="text/html;
- charset=windows-1252">
- </head>
- <body>
- <h2><u>Typical usage Scenarios and Examples</u></h2>
- Choose a task from the list below. For more details on alternative
- options, follow the links to the individual tools being used.<br>
- <br>
- Note that by default it is assumed that ICC profile have the file
- extension <span style="font-weight: bold;">.icm</span>, but that on
- Apple OS X and Unix/Linux platforms, the <span style="font-weight:
- bold;">.icc</span> extension is expected and should be used.<br>
- <h4><a href="#PM1">Profiling Displays</a></h4>
- <h4> <a href="#PM1a">Checking you can access your
- display<br>
- </a></h4>
- <h4> <a href="#PM1b">Adjusting and Calibrating a
- displays</a></h4>
- <h4> <a href="#PM1c">Adjusting, calibrating and
- profiling in one step<br>
- </a><span style="font-weight: bold;"></span><span
- style="font-weight: bold;"></span><span style="text-decoration:
- underline;"></span></h4>
- <h4> <a href="#PM2">Creating display test values</a></h4>
- <h4> <a href="#PM3">Taking readings from a
- display</a></h4>
- <h4> <a href="#PM4">Creating a display profile</a></h4>
- <h4> <span style="text-decoration: underline;"></span><a
- href="#PM5">Installing a display profile</a></h4>
- <h4> <span style="text-decoration: underline;"></span><a
- href="#PM6">Expert tips when measuring displays</a></h4>
- <h4> <span style="text-decoration: underline;"></span><a
- href="#PM7">Calibrating and profiling a display that doesn't
- have VideoLUT access.</a></h4>
- <h4><br>
- <a href="#PS1">Profiling Scanners and other input devices such as
- cameras<br>
- </a></h4>
- <h4> <a href="#PS2">Types of test charts</a></h4>
- <h4> <a href="#PS3">Taking readings from a
- scanner</a></h4>
- <h4> <a href="#PS4">Creating a scanner profile</a></h4>
- <h4><br>
- <a href="#PP1">Profiling Printers</a></h4>
- <h4> <a href="#PP2">Creating a print profile
- test chart</a></h4>
- <h4> <a href="Scenarios.html#PP2b">Printing a
- print profile test chart</a></h4>
- <h4> <a href="#PP3">Reading a print test chart
- using an instrument</a></h4>
- <h4> <a href="#PP4">Reading a print test chart
- using a scanner</a></h4>
- <h4> </h4>
- <h4> <a href="#PP5">Creating a printer profile<br>
- </a></h4>
- <h4> <a href="#PP6">Choosing a black generation
- curve</a></h4>
- <br>
- <h4><a href="Scenarios.html#PC1">Calibrating Printers</a></h4>
- <h4> <a href="Scenarios.html#PC2">Calibrated
- print workflows</a></h4>
- <h4> <a href="Scenarios.html#PC3">Creating a
- print calibration test chart</a></h4>
- <h4> </h4>
- <h4> <a href="Scenarios.html#PC4">Creating a
- printer calibration<br>
- </a></h4>
- <h4> <a href="Scenarios.html#PC5">Using a printer
- calibration</a></h4>
- <h4> <a href="#PC6">How profile ink limits are
- handled when calibration is being used<br>
- </a></h4>
- <h4> <a href="#LP1">Linking Profiles</a></h4>
- <p> <b><a href="#LP2">Image dependent gamut
- mapping using device links</a></b><br>
- </p>
- <p> <b><a href="#LP2">Soft Proofing Link</a></b><br>
- </p>
- <h4> <a href="#TR1">Transforming colorspaces of raster files</a></h4>
- <h4></h4>
- <h4> <a href="#TV1">Creating Video Calibration 3DLuts</a></h4>
- <h4><a href="Scenarios.html#TV2">Verifying Video Calibration 3DLuts</a></h4>
- <br>
- <hr style="width: 100%; height: 2px;"><br>
- <h3><a name="PM1"></a>Profiling Displays</h3>
- Argyll supports adjusting, calibrating and profiling of displays
- using one of a number of instruments - see <a
- href="instruments.html">instruments</a> for a current list.
- Adjustment and calibration are prior steps to profiling, in which
- the display is adjusted using it's screen controls, and then
- per channel lookup tables are created to make it meet a well behaved
- response of the desired type. The process following that of
- creating a display profile is then similar to that of all other
- output devices :- first a set of device colorspace test values needs
- to be created to exercise the display, then these values need to be
- displayed, while taking measurements of the resulting colors using
- the instrument. Finally, the device value/measured color values need
- to be converted into an ICC profile.<br>
- <br>
- <h3><a name="PM1a"></a>Checking you can access your display<br>
- </h3>
- You might first want to check that you are accessing and can
- calibrate your display. You can do this using the <a
- href="dispwin.html">dispwin</a><span style="font-weight: bold;"></span>
- tool<span style="font-weight: bold;">.</span> If you just run <span
- style="font-weight: bold;">dispwin</span> it will create a test
- window and run through a series of test colors before checking that
- the VideoLUT can be accessed by the display. If you invoke the usage
- for <span style="font-weight: bold;">dispwin</span> (by giving it
- an unrecognized option, e.g. <span style="font-weight: bold;">-?</span>)
- then it will show a list of available displays next to the <span
- style="font-weight: bold;"><span style="font-weight: bold;">-d</span></span>
- flag. Make sure that you are accessing the display you intend to
- calibrate and profile, and that the VideoLUT is effective (the <span
- style="font-weight: bold;">-r</span> flag can be used to just run
- the VideoLUT test). You can also try clearing the VideoLUTs using
- the <span style="font-weight: bold;">-c</span> flag, and loading a
- deliberately strange looking calibration <span style="font-weight:
- bold;">strange.cal</span> that is provided in the Argyll <span
- style="font-weight: bold;">ref</span> directory.<br>
- <br>
- Note that calibrating and/or profiling <span style="font-weight:
- bold;">remote</span> displays is possible using X11 or a web
- browser (see <span style="font-weight: bold;">-d</span> option of
- dispcal and dispread), or by using some external program to send
- test colors to a display (see <span style="font-weight: bold;">-C</span>
- and <span style="font-weight: bold;">-M</span> options of dispcal
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> +<html> + <head> + <title>Argyll Usage Scenarios</title> + <meta http-equiv="content-type" content="text/html; + charset=windows-1252"> + </head> + <body> + <h2><u>Typical usage Scenarios and Examples</u></h2> + Choose a task from the list below. For more details on alternative + options, follow the links to the individual tools being used.<br> + <br> + Note that by default it is assumed that ICC profile have the file + extension <span style="font-weight: bold;">.icm</span>, but that on + Apple OS X and Unix/Linux platforms, the <span style="font-weight: + bold;">.icc</span> extension is expected and should be used.<br> + <h4><a href="#PM1">Profiling Displays</a></h4> + <h4> <a href="#PM1a">Checking you can access your + display<br> + </a></h4> + <h4> <a href="#PM1b">Adjusting and Calibrating a + displays</a></h4> + <h4> <a href="#PM1c">Adjusting, calibrating and + profiling in one step<br> + </a><span style="font-weight: bold;"></span><span + style="font-weight: bold;"></span><span style="text-decoration: + underline;"></span></h4> + <h4> <a href="#PM2">Creating display test values</a></h4> + <h4> <a href="#PM3">Taking readings from a + display</a></h4> + <h4> <a href="#PM4">Creating a display profile</a></h4> + <h4> <span style="text-decoration: underline;"></span><a + href="#PM5">Installing a display profile</a></h4> + <h4> <span style="text-decoration: underline;"></span><a + href="#PM6">Expert tips when measuring displays</a></h4> + <h4> <span style="text-decoration: underline;"></span><a + href="#PM7">Calibrating and profiling a display that doesn't + have VideoLUT access.</a></h4> + <h4><br> + <a href="#PS1">Profiling Scanners and other input devices such as + cameras<br> + </a></h4> + <h4> <a href="#PS2">Types of test charts</a></h4> + <h4> <a href="#PS3">Taking readings from a + scanner</a></h4> + <h4> <a href="#PS4">Creating a scanner profile</a></h4> + <h4><br> + <a href="#PP1">Profiling Printers</a></h4> + <h4> <a href="#PP2">Creating a print profile + test chart</a></h4> + <h4> <a href="Scenarios.html#PP2b">Printing a + print profile test chart</a></h4> + <h4> <a href="#PP3">Reading a print test chart + using an instrument</a></h4> + <h4> <a href="#PP4">Reading a print test chart + using a scanner</a></h4> + <h4> </h4> + <h4> <a href="#PP5">Creating a printer profile<br> + </a></h4> + <h4> <a href="#PP6">Choosing a black generation + curve</a></h4> + <br> + <h4><a href="Scenarios.html#PC1">Calibrating Printers</a></h4> + <h4> <a href="Scenarios.html#PC2">Calibrated + print workflows</a></h4> + <h4> <a href="Scenarios.html#PC3">Creating a + print calibration test chart</a></h4> + <h4> </h4> + <h4> <a href="Scenarios.html#PC4">Creating a + printer calibration<br> + </a></h4> + <h4> <a href="Scenarios.html#PC5">Using a printer + calibration</a></h4> + <h4> <a href="#PC6">How profile ink limits are + handled when calibration is being used<br> + </a></h4> + <h4> <a href="#LP1">Linking Profiles</a></h4> + <p> <b><a href="#LP2">Image dependent gamut + mapping using device links</a></b><br> + </p> + <p> <b><a href="#LP2">Soft Proofing Link</a></b><br> + </p> + <h4> <a href="#TR1">Transforming colorspaces of raster files</a></h4> + <h4></h4> + <h4> <a href="#TV1">Creating Video Calibration 3DLuts</a></h4> + <h4><a href="Scenarios.html#TV2">Verifying Video Calibration 3DLuts</a></h4> + <br> + <hr style="width: 100%; height: 2px;"><br> + <h3><a name="PM1"></a>Profiling Displays</h3> + Argyll supports adjusting, calibrating and profiling of displays + using one of a number of instruments - see <a + href="instruments.html">instruments</a> for a current list. + Adjustment and calibration are prior steps to profiling, in which + the display is adjusted using it's screen controls, and then + per channel lookup tables are created to make it meet a well behaved + response of the desired type. The process following that of + creating a display profile is then similar to that of all other + output devices :- first a set of device colorspace test values needs + to be created to exercise the display, then these values need to be + displayed, while taking measurements of the resulting colors using + the instrument. Finally, the device value/measured color values need + to be converted into an ICC profile.<br> + <br> + <h3><a name="PM1a"></a>Checking you can access your display<br> + </h3> + You might first want to check that you are accessing and can + calibrate your display. You can do this using the <a + href="dispwin.html">dispwin</a><span style="font-weight: bold;"></span> + tool<span style="font-weight: bold;">.</span> If you just run <span + style="font-weight: bold;">dispwin</span> it will create a test + window and run through a series of test colors before checking that + the VideoLUT can be accessed by the display. If you invoke the usage + for <span style="font-weight: bold;">dispwin</span> (by giving it + an unrecognized option, e.g. <span style="font-weight: bold;">-?</span>) + then it will show a list of available displays next to the <span + style="font-weight: bold;"><span style="font-weight: bold;">-d</span></span> + flag. Make sure that you are accessing the display you intend to + calibrate and profile, and that the VideoLUT is effective (the <span + style="font-weight: bold;">-r</span> flag can be used to just run + the VideoLUT test). You can also try clearing the VideoLUTs using + the <span style="font-weight: bold;">-c</span> flag, and loading a + deliberately strange looking calibration <span style="font-weight: + bold;">strange.cal</span> that is provided in the Argyll <span + style="font-weight: bold;">ref</span> directory.<br> + <br> + Note that calibrating and/or profiling <span style="font-weight: + bold;">remote</span> displays is possible using X11 or a web + browser (see <span style="font-weight: bold;">-d</span> option of + dispcal and dispread), or by using some external program to send + test colors to a display (see <span style="font-weight: bold;">-C</span> + and <span style="font-weight: bold;">-M</span> options of dispcal and dispread), but you may want to refer to <a href="#PM7">Calibrating @@ -181,27 +181,29 @@ -
- and profiling a display that doesn't have VideoLUT access</a>.<br>
- <br>
- <h3><a name="PM1b"></a>Adjusting and Calibrating Displays</h3>
- Please read <a href="calvschar.html">What's the difference between
- Calibration and Characterization ?</a> if you are unclear as to
- the difference .<br>
- <br>
- The first step is to decide what the target should be for adjustment
- and calibration. This boils down to three things: The desired
- brightness, the desired white point, and the desired response curve.
- The native brightness and white points of a display may be different
- to the desired characteristics for some purposes. For instance, for
- graphic arts use, it might be desirable to run with a warmer white
- point of about 5000 degrees Kelvin, rather than the default display
- white point of 6500 to 9000 Kelvin. Some LCD displays are too bright
- to compare to printed material under available lighting, so it might
- be desirable to reduce the maximum brightness.<br>
- <br>
- You can run <a href="dispcal.html#r">dispcal -r</a> to check on how
- your display is currently set up. (you may have to run this as <span
+ + + + and profiling a display that doesn't have VideoLUT access</a>.<br> + <br> + <h3><a name="PM1b"></a>Adjusting and Calibrating Displays</h3> + Please read <a href="calvschar.html">What's the difference between + Calibration and Characterization ?</a> if you are unclear as to + the difference .<br> + <br> + The first step is to decide what the target should be for adjustment + and calibration. This boils down to three things: The desired + brightness, the desired white point, and the desired response curve. + The native brightness and white points of a display may be different + to the desired characteristics for some purposes. For instance, for + graphic arts use, it might be desirable to run with a warmer white + point of about 5000 degrees Kelvin, rather than the default display + white point of 6500 to 9000 Kelvin. Some LCD displays are too bright + to compare to printed material under available lighting, so it might + be desirable to reduce the maximum brightness.<br> + <br> + You can run <a href="dispcal.html#r">dispcal -r</a> to check on how + your display is currently set up. (you may have to run this as <span style="text-decoration: underline; color: rgb(204, 51, 204);">dispcal -yl @@ -260,332 +262,334 @@ -
- -r</span> for an LCD display, or <span style="text-decoration:
- underline; color: rgb(204, 51, 204);">dispcal -yc -r</span> for a
- CRT display with most of the colorimeter instruments. If so, this
- will apply to all of the following examples.)<br>
- <br>
- Once this is done, <a href="dispcal.html">dispcal</a> can be run to
- guide you through the display adjustments, and then calibrate it. By
- default, the brightness and white point will be kept the same as the
- devices natural brightness and white point. The default response
- curve is a gamma of 2.4, except for Apple OS X systems prior to 10.6
- where a gamma of 1.8 is the default. 2.4 is close to that of
- many monitors, and close to that of the sRGB colorspace. <br>
- <br>
- A typical calibration that leaves the brightness and white point
- alone, might be:<br>
- <br>
- <a href="dispcal.html">dispcal</a> -v TargetA<br>
- <br>
- which will result in a "TargetA.cal" calibration file, that can then
- be used during the profiling stage.<br>
- <br>
- If the absolutely native response of the display is desired during
- profiling, then calibration should be skipped, and the linear.cal
- file from the "ref" directory used instead as the argument to the -k
- flag of <span style="font-weight: bold;">dispread</span>.<br>
- <br>
- <b>Dispcal</b> will display a test window in the middle of the
- screen, and issue a series of instructions about placing the
- instrument on the display. You may need to make sure that the
- display cursor is not in the test window, and it may also be
- necessary to disable any screensaver and powersavers before starting
- the process, although both <span style="font-weight: bold;">dispcal</span>
- and <span style="font-weight: bold;">dispread</span> will attempt
- to do this for you. It's also highly desirable on CRT's, to clear
- your screen of any white or bright background images or windows
- (running your shell window with white text on a black background
- helps a lot here.), or at least keep any bright areas away from the
- test window, and be careful not to change anything on the display
- while the readings are taken. Lots of bright images or windows can
- affect the ability to measure the black point accurately, and
- changing images on the display can cause inconsistency in the
- readings, and leading to poor results.<span
- style="font-weight: bold;"></span> LCD displays seem to be less
- influenced by what else is on the screen.<br>
- <br>
- If <span style="font-weight: bold;">dispcal</span> is run without
- arguments, it will provide a usage screen. The <span
- style="font-weight: bold;">-c</span> parameter allows selecting a
- communication port for an instrument, or selecting the instrument
- you want to use, and the <a href="dispcal.html#d"><span
- style="font-weight: bold;">-d</span></a> option allows selecting
- a target display on a multi-display system. On some multi-monitor
- systems, it may not be possible to independently calibrate and
- profile each display if they appear as one single screen to the
- operating system, or if it is not possible to set separate video
- lookup tables for each display. You can change the position and size
- of the test window using the <a href="dispcal.html#P"><span
- style="font-weight: bold;">-P</span></a> parameter. You can
- determine how best to arrange the test window, as well as whether
- each display has separate video lookup capability, by experimenting
- with the <a href="dispwin.html">dispwin</a> tool. <br>
- <br>
- For a more detailed discussion on interactively adjusting the
- display controls using <span style="font-weight: bold;">dispcal</span>,
- see <a href="dispcal.html#Adjustment">dispcal-adjustment</a>. Once
- you have adjusted and calibrated your display, you can move on to
- the next step.<br>
- <br>
- When you have calibrated and profiled your display, you can keep it
- calibrated using the <a href="dispcal.html#u">dispcal -u</a>
- option.<br>
- <br>
- <h4><a name="PM1c"></a>Adjusting, calibrating and profiling in one
- step.</h4>
- If a simple matrix/shaper display profile is all that is desired, <span
- style="font-weight: bold;">dispcal</span> can be used to do this,
- permitting display adjustment, calibration and profiling all in one
- operation. This is done by using the <span style="font-weight:
- bold;"><span style="font-weight: bold;">dispcal </span>-o</span>
- flag:<br>
- <br>
- <a href="dispcal.html">dispcal</a> <a href="dispcal.html#v">-v</a>
- <a href="dispcal.html#o">-o</a> <a href="dispcal.html#p1">TargetA</a><br>
- <br>
- This will create both a TargetA.cal file, but also a TargetA.icm
- file. See <a href="dispcal.html#o">-o</a> and <a
- href="dispcal.html#O">-O</a> for other variations.<br>
- <br>
- For more flexibility in creating a display profile, the separate
- steps of creating characterization test values using <span
- style="font-weight: bold;">targen</span>, reading them from the
- display using <span style="font-weight: bold;">dispread</span>, and
- then creating a profile using <span style="font-weight: bold;">colprof</span>
- are used. The following steps illustrate this:<br>
- <h4><a name="PM2"></a>Profiling in several steps: Creating display
- test values</h4>
- If the <span style="font-weight: bold;">dispcal</span> has not been
- used to create a display profile at the same time as adjustment and
- calibration, then it can be used to create a suitable set of
- calibration curves as the first step, or the calibration step can be
- omitted, and the display cansimply be profiled.<br>
- <br>
- The first step in profiling any output device, is to create a set of
- device colorspace test values. The important parameters needed are:
- <br>
- <ul>
- <li>What colorspace does the device use ?</li>
- <li>How many test patches do I want to use ?</li>
- <li>What information do I already have about how the device
- behaves ?</li>
- </ul>
- For a display device, the colorspace will be RGB. The number
- of test patches will depend somewhat on what quality profile you
- want to make, what type of profile you want to make, and how long
- you are prepared to wait when testing the display.<br>
- At a minimum, a few hundred values are needed. A matrix/shaper type
- of profile can get by with fewer test values, while a LUT based
- profile will give better results if more test values are used. A
- typical number might be 200-600 or so values, while 1000-2000 is not
- an unreasonable number for a high quality characterization of a
- display.<br>
- <br>
- To assist the choice of test patch values, it can help to have a
- rough idea of how the device behaves. This could be in the form of
- an ICC profile of a similar device, or a lower quality, or previous
- profile for that particular device. If one were going to make a very
- high quality LUT based profile, then it might be worthwhile to make
- up a smaller, preliminary shaper/matrix profile using a few hundred
- test points, before embarking on testing the device with several
- thousand.<br>
- <br>
- Lets say that we ultimately want to make a profile for the device
- "DisplayA", the simplest approach is to make a set of test values
- that is independent of the characteristics of the particular device:<br>
- <br>
- <a href="targen.html">targen</a> <a href="targen.html#v">-v</a>
- <a href="targen.html#d">-d3</a> <a href="targen.html#f">-f500</a>
- <a href="targen.html#p1">DisplayA</a><br>
- <br>
- If there is a preliminary or previous profile called "OldDisplay"
- available, and we want to try creating a "pre-conditioned" set of
- test values that will more efficiently sample the device response,
- then the following would achieve this:<br>
- <u><br>
- </u><a href="targen.html"> targen</a> <a href="targen.html#v">-v</a>
- <a href="targen.html#d">-d3</a> <a href="targen.html#f">-f500</a>
- <a href="targen.html#c">-cOldDisplay.icm</a> <a
- href="targen.html#p1">DisplayA</a><br>
- <br>
- The output of <b>targen</b> will be the file DisplayA.ti1,
- containing the device space test values, as well as expected CIE
- values used for chart recognition purposes.<br>
- <br>
- <h4><a name="PM3"></a>Profiling in several steps: Taking readings
- from a display</h4>
- First it is necessary to connect your measurement instrument to your
- computer, and check which communication port it is connected to. In
- the following example, it is assumed that the instrument is
- connected to the default port 1, which is either the first USB
- instrument found, or serial port found. Invoking dispread so as to
- display the usage information (by using a flag -? or --) will list
- the identified serial and USB ports, and their labels.<br>
- <br>
- <a href="dispread.html">dispread</a> <a href="dispread.html#v">-v</a>
- <a href="dispread.html#p1">DisplayA</a><br>
- <br>
- If we created a calibration for the display using <a
- href="dispcal.html">dispcal</a>, then we will want to use this
- when we take the display readings (e.g. TargetA.cal from the
- calibration example)..<br>
- <br>
- <a href="dispread.html">dispread</a> <a href="dispread.html#v">-v</a>
- <a href="dispread.html#k">-k TargetA.cal</a> <a
- href="dispread.html#p1">DisplayA</a><br>
- <br>
- <b>dispread</b> will display a test window in the middle of the
- screen, and issue a series of instructions about placing the
- instrument on the display. You may need to make sure that the
- display cursor is not in the test window, and it may also be
- necessary to disable any screensaver before starting the process.
- Exactly the same facilities are provided to select alternate
- displays using the <span style="font-weight: bold;">-d</span>
- parameter, and an alternate location and size for the test window
- using the <span style="font-weight: bold;">-P</span> parameter as
- with <span style="font-weight: bold;">dispcal</span>.<br>
- <h4><a name="PM4"></a>Profiling in several steps: Creating a display
- profile</h4>
- There are two basic choices of profile type for a display, a
- shaper/matrix profile, or a LUT based profile. They have different
- tradeoffs. A shaper/matrix profile will work well on a well behaved
- display, that is one that behaves in an additive color manner, will
- give very smooth looking results, and needs fewer test points to
- create. A LUT based profile on the other hand, will model any
- display behaviour more accurately, and can accommodate gamut mapping
- and different intent tables. Often it can show some unevenness and
- contouring in the results though.<br>
- <br>
- To create a matrix/shaper profile, the following suffices:<br>
- <br>
- <a href="colprof.html">colprof</a> <a href="colprof.html#v">-v</a>
- <a href="colprof.html#E">-D"Display A"</a> <a href="colprof.html#q">-qm</a>
- <a href="colprof.html#a">-as</a> <a href="colprof.html#p1">DisplayA</a><br>
- <br>
- For a LUT based profile, where gamut mapping is desired, then a
- source profile will need to be provided to define the source gamut.
- For instance, if the display profile was likely to be linked to a
- CMYK printing source profile, say "swop.icm" or "fogra39l.icm", then
- the following would suffice:<br>
- <br>
- <a href="colprof.html">colprof</a> <a href="colprof.html#v">-v</a>
- <a href="colprof.html#E">-D"Display A"</a> <a href="colprof.html#q">-qm</a>
- <a href="colprof.html#S">-S</a><a href="colprof.html#S">
- fogra39l.icm</a> <a href="colprof.html#c">-cpp</a> <a
- href="colprof.html#d">-dmt</a> <a href="colprof.html#p1">DisplayA</a><br>
- <br>
- Make sure you check the delta E report at the end of the profile
- creation, to see if the sample data and profile is behaving
- reasonably.<br>
- If a calibration file was used with <a href="dispread.html">dispread</a>,
- then it will be converted to a vcgt tag in the profile, so that the
- operating system or other system color tools load the lookup curves
- into the display hardware, when the profile is used.<br>
- <h4><a name="PM5"></a>Installing a display profile</h4>
- <a href="dispwin.html">dispwin</a> provides a convenient way of
- installing a profile as the default system profile for the chosen
- display:<br>
- <br>
- <a href="dispwin.html">dispwin</a> <a href="dispwin.html#I">-I</a>
- <a href="dispwin.html#p1">DisplayA.icm</a><br>
- <br>
- This also sets the display to the calibration contained in the
- profile. If you want to try out a calibration before installing the
- profile, using dispwin without the <span style="font-weight: bold;">-I</span>
- option will load a calibration (ICC profile or .cal file) into the
- current display.<br>
- <br>
- Some systems will automatically set the display to the calibration
- contained in the installed profile (ie. OS X), while on other
- systems (ie. MSWindows and Linux/X11) it is necessary to use some
- tool to do this. On MSWindows XP you could install the
- optional <span style="font-weight: bold;">Microsoft Color Control Panel Applet for Windows XP</span>
- available for download from Microsoft to do this, but <span
- style="font-weight: bold;">NOTE</span> however that it seems to
- have a <span style="font-weight: bold;">bug</span>, in that it
- sometimes associates the profiles with the <span
- style="font-weight: bold;">wrong monitor</span> entry. Other
- display calibration tools will often install a similar tool, so
- beware of there being multiple, competing programs. [ Commonly these
- will be in your Start->Programs->Startup folder. ]<br>
- On Microsoft Vista, you need to use dispwin -L or some other tool to
- load the installed profiles calibration at startup.<br>
- <br>
- To use dispwin to load the installed profiles calibration to the
- display, use<br>
- <br>
- <a href="dispwin.html">dispwin</a> <a href="dispwin.html#L">-L</a><br>
- <br>
- As per usual, you can select the appropriate display using the <a
- href="dispwin.html#d">-d</a> flag.<br>
- <br>
- This can be automated on MSWindows and X11/Linux by adding this
- command to an appropriate startup script.<br>
- More system specific details, including how to create such startup
- scripts are <a href="dispprofloc.html">here</a>. <br>
- <br>
- If you are using Microsoft <span style="font-weight: bold;">Vista</span>,
- there is a known <span style="font-weight: bold;">bug</span> in
- Vista that resets the calibration every time a fade-in effect is
- executed, which happens if you lock and unlock the computer, resume
- from sleep or hibernate, or User Access Control is activated. Using
- <a href="dispwin.html">dispwin</a> <a href="dispwin.html#L">-L</a>
- may not restore the calibration, because Vista filters out setting
- (what it thinks) is a calibration that is already loaded. Use <a
- href="dispwin.html">dispwin</a> <a href="dispwin.html#c">-c</a> <a
- href="dispwin.html#L">-L</a><span style="font-family: monospace;"></span>
- as a workaround, as this will first clear the calibration, then
- re-load the current calibration.<br>
- <br>
- On X11/Linux systems, you could try adding <a href="dispwin.html">dispwin</a>
- <a href="dispwin.html#L">-L</a> to your <span style="font-weight:
- bold;">~/.config/autostart</span> file, so that your window
- manager automatically sets calibration when it starts. If you are
- running XRandR 1.2, you might consider running the experimental <a
- href="dispwin.html#D">dispwin -E</a> in the background, as in its
- "daemon" mode it will update the profile and calibration in response
- to any changes in the the connected display.<br>
- <br>
- <h4><a name="PM6"></a>Expert tips when measuring displays:<br>
- </h4>
- Sometimes it can be difficult to get good quality, consistent and
- visually relevant readings from displays, due to various practical
- considerations with regard to instruments and the displays
- themselves. Argyll's tools have some extra options that may assist
- in overcoming these problems.<br>
- <br>
- If you are using an Eye-One Pro or ColorMunki spectrometer, then you
- may wish to use the <a href="dispcal.html#H">high resolution
- spectral mode</a> (<span style="font-weight: bold;">-H</span>).
- This may be better at capturing the often narrow wavelength peaks
- that are typical of display primary colors.<br>
- <br>
- All instruments depend on silicon sensors, and such sensors generate
- a temperature dependant level of noise ("dark noise") that is
- factored out of the measurements by a dark or black instrument
- calibration. The spectrometers in particular need this calibration
- before commencing each set of measurements. Often an instrument will
- warm up as it sits on a display, and this warming up can cause the
- dark noise to increase, leading to inaccuracies in dark patch
- measurements. The longer the measurement takes, the worse this
- problem is likely to be. One way of addressing this is to
- "acclimatise" the instrument before commencing measurements by
- placing it on the screen in a powered up state, and leaving it for
- some time. (Some people leave it for up to an hour to acclimatise.).
- Another approach is to try and <a href="dispcal.html#I">compensate
- for dark calibration changes</a> (<span style="font-weight: bold;">-Ib</span>)
- by doing on the fly calibrations during the measurements, based on
- the assumption that the black level of the display itself won't
- change significantly. <br>
- <br>
- Some displays take a long time to settle down and stabilise. The is
- often the case with LCD (Liquid Crystal) displays that use
- fluorescent back lights, and these sorts of displays can change in
- brightness significantly with changes in temperature. One way of
- addressing this is to make sure that the display is given adequate
- time to warm up before measurements. Another approach is to try and
+ + + + -r</span> for an LCD display, or <span style="text-decoration: + underline; color: rgb(204, 51, 204);">dispcal -yc -r</span> for a + CRT display with most of the colorimeter instruments. If so, this + will apply to all of the following examples.)<br> + <br> + Once this is done, <a href="dispcal.html">dispcal</a> can be run to + guide you through the display adjustments, and then calibrate it. By + default, the brightness and white point will be kept the same as the + devices natural brightness and white point. The default response + curve is a gamma of 2.4, except for Apple OS X systems prior to 10.6 + where a gamma of 1.8 is the default. 2.4 is close to that of + many monitors, and close to that of the sRGB colorspace. <br> + <br> + A typical calibration that leaves the brightness and white point + alone, might be:<br> + <br> + <a href="dispcal.html">dispcal</a> -v TargetA<br> + <br> + which will result in a "TargetA.cal" calibration file, that can then + be used during the profiling stage.<br> + <br> + If the absolutely native response of the display is desired during + profiling, then calibration should be skipped, and the linear.cal + file from the "ref" directory used instead as the argument to the -k + flag of <span style="font-weight: bold;">dispread</span>.<br> + <br> + <b>Dispcal</b> will display a test window in the middle of the + screen, and issue a series of instructions about placing the + instrument on the display. You may need to make sure that the + display cursor is not in the test window, and it may also be + necessary to disable any screensaver and powersavers before starting + the process, although both <span style="font-weight: bold;">dispcal</span> + and <span style="font-weight: bold;">dispread</span> will attempt + to do this for you. It's also highly desirable on CRT's, to clear + your screen of any white or bright background images or windows + (running your shell window with white text on a black background + helps a lot here.), or at least keep any bright areas away from the + test window, and be careful not to change anything on the display + while the readings are taken. Lots of bright images or windows can + affect the ability to measure the black point accurately, and + changing images on the display can cause inconsistency in the + readings, and leading to poor results.<span + style="font-weight: bold;"></span> LCD displays seem to be less + influenced by what else is on the screen.<br> + <br> + If <span style="font-weight: bold;">dispcal</span> is run without + arguments, it will provide a usage screen. The <span + style="font-weight: bold;">-c</span> parameter allows selecting a + communication port for an instrument, or selecting the instrument + you want to use, and the <a href="dispcal.html#d"><span + style="font-weight: bold;">-d</span></a> option allows selecting + a target display on a multi-display system. On some multi-monitor + systems, it may not be possible to independently calibrate and + profile each display if they appear as one single screen to the + operating system, or if it is not possible to set separate video + lookup tables for each display. You can change the position and size + of the test window using the <a href="dispcal.html#P"><span + style="font-weight: bold;">-P</span></a> parameter. You can + determine how best to arrange the test window, as well as whether + each display has separate video lookup capability, by experimenting + with the <a href="dispwin.html">dispwin</a> tool. <br> + <br> + For a more detailed discussion on interactively adjusting the + display controls using <span style="font-weight: bold;">dispcal</span>, + see <a href="dispcal.html#Adjustment">dispcal-adjustment</a>. Once + you have adjusted and calibrated your display, you can move on to + the next step.<br> + <br> + When you have calibrated and profiled your display, you can keep it + calibrated using the <a href="dispcal.html#u">dispcal -u</a> + option.<br> + <br> + <h4><a name="PM1c"></a>Adjusting, calibrating and profiling in one + step.</h4> + If a simple matrix/shaper display profile is all that is desired, <span + style="font-weight: bold;">dispcal</span> can be used to do this, + permitting display adjustment, calibration and profiling all in one + operation. This is done by using the <span style="font-weight: + bold;"><span style="font-weight: bold;">dispcal </span>-o</span> + flag:<br> + <br> + <a href="dispcal.html">dispcal</a> <a href="dispcal.html#v">-v</a> + <a href="dispcal.html#o">-o</a> <a href="dispcal.html#p1">TargetA</a><br> + <br> + This will create both a TargetA.cal file, but also a TargetA.icm + file. See <a href="dispcal.html#o">-o</a> and <a + href="dispcal.html#O">-O</a> for other variations.<br> + <br> + For more flexibility in creating a display profile, the separate + steps of creating characterization test values using <span + style="font-weight: bold;">targen</span>, reading them from the + display using <span style="font-weight: bold;">dispread</span>, and + then creating a profile using <span style="font-weight: bold;">colprof</span> + are used. The following steps illustrate this:<br> + <h4><a name="PM2"></a>Profiling in several steps: Creating display + test values</h4> + If the <span style="font-weight: bold;">dispcal</span> has not been + used to create a display profile at the same time as adjustment and + calibration, then it can be used to create a suitable set of + calibration curves as the first step, or the calibration step can be + omitted, and the display cansimply be profiled.<br> + <br> + The first step in profiling any output device, is to create a set of + device colorspace test values. The important parameters needed are: + <br> + <ul> + <li>What colorspace does the device use ?</li> + <li>How many test patches do I want to use ?</li> + <li>What information do I already have about how the device + behaves ?</li> + </ul> + For a display device, the colorspace will be RGB. The number + of test patches will depend somewhat on what quality profile you + want to make, what type of profile you want to make, and how long + you are prepared to wait when testing the display.<br> + At a minimum, a few hundred values are needed. A matrix/shaper type + of profile can get by with fewer test values, while a LUT based + profile will give better results if more test values are used. A + typical number might be 200-600 or so values, while 1000-2000 is not + an unreasonable number for a high quality characterization of a + display.<br> + <br> + To assist the choice of test patch values, it can help to have a + rough idea of how the device behaves. This could be in the form of + an ICC profile of a similar device, or a lower quality, or previous + profile for that particular device. If one were going to make a very + high quality LUT based profile, then it might be worthwhile to make + up a smaller, preliminary shaper/matrix profile using a few hundred + test points, before embarking on testing the device with several + thousand.<br> + <br> + Lets say that we ultimately want to make a profile for the device + "DisplayA", the simplest approach is to make a set of test values + that is independent of the characteristics of the particular device:<br> + <br> + <a href="targen.html">targen</a> <a href="targen.html#v">-v</a> + <a href="targen.html#d">-d3</a> <a href="targen.html#f">-f500</a> + <a href="targen.html#p1">DisplayA</a><br> + <br> + If there is a preliminary or previous profile called "OldDisplay" + available, and we want to try creating a "pre-conditioned" set of + test values that will more efficiently sample the device response, + then the following would achieve this:<br> + <u><br> + </u><a href="targen.html"> targen</a> <a href="targen.html#v">-v</a> + <a href="targen.html#d">-d3</a> <a href="targen.html#f">-f500</a> + <a href="targen.html#c">-cOldDisplay.icm</a> <a + href="targen.html#p1">DisplayA</a><br> + <br> + The output of <b>targen</b> will be the file DisplayA.ti1, + containing the device space test values, as well as expected CIE + values used for chart recognition purposes.<br> + <br> + <h4><a name="PM3"></a>Profiling in several steps: Taking readings + from a display</h4> + First it is necessary to connect your measurement instrument to your + computer, and check which communication port it is connected to. In + the following example, it is assumed that the instrument is + connected to the default port 1, which is either the first USB + instrument found, or serial port found. Invoking dispread so as to + display the usage information (by using a flag -? or --) will list + the identified serial and USB ports, and their labels.<br> + <br> + <a href="dispread.html">dispread</a> <a href="dispread.html#v">-v</a> + <a href="dispread.html#p1">DisplayA</a><br> + <br> + If we created a calibration for the display using <a + href="dispcal.html">dispcal</a>, then we will want to use this + when we take the display readings (e.g. TargetA.cal from the + calibration example)..<br> + <br> + <a href="dispread.html">dispread</a> <a href="dispread.html#v">-v</a> + <a href="dispread.html#k">-k TargetA.cal</a> <a + href="dispread.html#p1">DisplayA</a><br> + <br> + <b>dispread</b> will display a test window in the middle of the + screen, and issue a series of instructions about placing the + instrument on the display. You may need to make sure that the + display cursor is not in the test window, and it may also be + necessary to disable any screensaver before starting the process. + Exactly the same facilities are provided to select alternate + displays using the <span style="font-weight: bold;">-d</span> + parameter, and an alternate location and size for the test window + using the <span style="font-weight: bold;">-P</span> parameter as + with <span style="font-weight: bold;">dispcal</span>.<br> + <h4><a name="PM4"></a>Profiling in several steps: Creating a display + profile</h4> + There are two basic choices of profile type for a display, a + shaper/matrix profile, or a LUT based profile. They have different + tradeoffs. A shaper/matrix profile will work well on a well behaved + display, that is one that behaves in an additive color manner, will + give very smooth looking results, and needs fewer test points to + create. A LUT based profile on the other hand, will model any + display behaviour more accurately, and can accommodate gamut mapping + and different intent tables. Often it can show some unevenness and + contouring in the results though.<br> + <br> + To create a matrix/shaper profile, the following suffices:<br> + <br> + <a href="colprof.html">colprof</a> <a href="colprof.html#v">-v</a> + <a href="colprof.html#E">-D"Display A"</a> <a href="colprof.html#q">-qm</a> + <a href="colprof.html#a">-as</a> <a href="colprof.html#p1">DisplayA</a><br> + <br> + For a LUT based profile, where gamut mapping is desired, then a + source profile will need to be provided to define the source gamut. + For instance, if the display profile was likely to be linked to a + CMYK printing source profile, say "swop.icm" or "fogra39l.icm", then + the following would suffice:<br> + <br> + <a href="colprof.html">colprof</a> <a href="colprof.html#v">-v</a> + <a href="colprof.html#E">-D"Display A"</a> <a href="colprof.html#q">-qm</a> + <a href="colprof.html#S">-S</a><a href="colprof.html#S"> + fogra39l.icm</a> <a href="colprof.html#c">-cpp</a> <a + href="colprof.html#d">-dmt</a> <a href="colprof.html#p1">DisplayA</a><br> + <br> + Make sure you check the delta E report at the end of the profile + creation, to see if the sample data and profile is behaving + reasonably.<br> + If a calibration file was used with <a href="dispread.html">dispread</a>, + then it will be converted to a vcgt tag in the profile, so that the + operating system or other system color tools load the lookup curves + into the display hardware, when the profile is used.<br> + <h4><a name="PM5"></a>Installing a display profile</h4> + <a href="dispwin.html">dispwin</a> provides a convenient way of + installing a profile as the default system profile for the chosen + display:<br> + <br> + <a href="dispwin.html">dispwin</a> <a href="dispwin.html#I">-I</a> + <a href="dispwin.html#p1">DisplayA.icm</a><br> + <br> + This also sets the display to the calibration contained in the + profile. If you want to try out a calibration before installing the + profile, using dispwin without the <span style="font-weight: bold;">-I</span> + option will load a calibration (ICC profile or .cal file) into the + current display.<br> + <br> + Some systems will automatically set the display to the calibration + contained in the installed profile (ie. OS X), while on other + systems (ie. MSWindows and Linux/X11) it is necessary to use some + tool to do this. On MSWindows XP you could install the + optional <span style="font-weight: bold;">Microsoft Color Control Panel Applet for Windows XP</span> + available for download from Microsoft to do this, but <span + style="font-weight: bold;">NOTE</span> however that it seems to + have a <span style="font-weight: bold;">bug</span>, in that it + sometimes associates the profiles with the <span + style="font-weight: bold;">wrong monitor</span> entry. Other + display calibration tools will often install a similar tool, so + beware of there being multiple, competing programs. [ Commonly these + will be in your Start->Programs->Startup folder. ]<br> + On Microsoft Vista, you need to use dispwin -L or some other tool to + load the installed profiles calibration at startup.<br> + <br> + To use dispwin to load the installed profiles calibration to the + display, use<br> + <br> + <a href="dispwin.html">dispwin</a> <a href="dispwin.html#L">-L</a><br> + <br> + As per usual, you can select the appropriate display using the <a + href="dispwin.html#d">-d</a> flag.<br> + <br> + This can be automated on MSWindows and X11/Linux by adding this + command to an appropriate startup script.<br> + More system specific details, including how to create such startup + scripts are <a href="dispprofloc.html">here</a>. <br> + <br> + If you are using Microsoft <span style="font-weight: bold;">Vista</span>, + there is a known <span style="font-weight: bold;">bug</span> in + Vista that resets the calibration every time a fade-in effect is + executed, which happens if you lock and unlock the computer, resume + from sleep or hibernate, or User Access Control is activated. Using + <a href="dispwin.html">dispwin</a> <a href="dispwin.html#L">-L</a> + may not restore the calibration, because Vista filters out setting + (what it thinks) is a calibration that is already loaded. Use <a + href="dispwin.html">dispwin</a> <a href="dispwin.html#c">-c</a> <a + href="dispwin.html#L">-L</a><span style="font-family: monospace;"></span> + as a workaround, as this will first clear the calibration, then + re-load the current calibration.<br> + <br> + On X11/Linux systems, you could try adding <a href="dispwin.html">dispwin</a> + <a href="dispwin.html#L">-L</a> to your <span style="font-weight: + bold;">~/.config/autostart</span> file, so that your window + manager automatically sets calibration when it starts. If you are + running XRandR 1.2, you might consider running the experimental <a + href="dispwin.html#D">dispwin -E</a> in the background, as in its + "daemon" mode it will update the profile and calibration in response + to any changes in the the connected display.<br> + <br> + <h4><a name="PM6"></a>Expert tips when measuring displays:<br> + </h4> + Sometimes it can be difficult to get good quality, consistent and + visually relevant readings from displays, due to various practical + considerations with regard to instruments and the displays + themselves. Argyll's tools have some extra options that may assist + in overcoming these problems.<br> + <br> + If you are using an Eye-One Pro or ColorMunki spectrometer, then you + may wish to use the <a href="dispcal.html#H">high resolution + spectral mode</a> (<span style="font-weight: bold;">-H</span>). + This may be better at capturing the often narrow wavelength peaks + that are typical of display primary colors.<br> + <br> + All instruments depend on silicon sensors, and such sensors generate + a temperature dependant level of noise ("dark noise") that is + factored out of the measurements by a dark or black instrument + calibration. The spectrometers in particular need this calibration + before commencing each set of measurements. Often an instrument will + warm up as it sits on a display, and this warming up can cause the + dark noise to increase, leading to inaccuracies in dark patch + measurements. The longer the measurement takes, the worse this + problem is likely to be. One way of addressing this is to + "acclimatise" the instrument before commencing measurements by + placing it on the screen in a powered up state, and leaving it for + some time. (Some people leave it for up to an hour to acclimatise.). + Another approach is to try and <a href="dispcal.html#I">compensate + for dark calibration changes</a> (<span style="font-weight: bold;">-Ib</span>) + by doing on the fly calibrations during the measurements, based on + the assumption that the black level of the display itself won't + change significantly. <br> + <br> + Some displays take a long time to settle down and stabilise. The is + often the case with LCD (Liquid Crystal) displays that use + fluorescent back lights, and these sorts of displays can change in + brightness significantly with changes in temperature. One way of + addressing this is to make sure that the display is given adequate + time to warm up before measurements. Another approach is to try and <a href="dispcal.html#I">compensate for display white level</a> @@ -643,21 +647,23 @@ -
- (<span style="font-weight: bold;">-Iw</span>) changes by doing on
- the fly calibrations during the measurements. Instrument black level
- drift and display white level drift can be combined (<span
- style="font-weight: bold;">-Ibw</span>).<br>
- <br>
- Colorimeter instruments make use of physical color filters that
- approximate the standard observer spectral sensitivity curves.
- Because these filters are not perfectly accurate, the manufacturer
- calibrates the instrument for typical displays, which is why you
- have to make a selection between CRT (Cathode Ray Tube) and LCD
- (Liquid Crystal Display) modes. If you are measuring a display that
- has primary colorants that differ significantly from those typical
- displays, (ie. you have a Wide Gamut Display), then you may
- get disappointing results with a Colorimeter. One way of addressing
+ + + + (<span style="font-weight: bold;">-Iw</span>) changes by doing on + the fly calibrations during the measurements. Instrument black level + drift and display white level drift can be combined (<span + style="font-weight: bold;">-Ibw</span>).<br> + <br> + Colorimeter instruments make use of physical color filters that + approximate the standard observer spectral sensitivity curves. + Because these filters are not perfectly accurate, the manufacturer + calibrates the instrument for typical displays, which is why you + have to make a selection between CRT (Cathode Ray Tube) and LCD + (Liquid Crystal Display) modes. If you are measuring a display that + has primary colorants that differ significantly from those typical + displays, (ie. you have a Wide Gamut Display), then you may + get disappointing results with a Colorimeter. One way of addressing this problem is to use a <a href="File_Formats.html#.ccmx">Colorimeter @@ -714,118 +720,120 @@ -
- Correction Matrix</a>. These are specific to a particular
- Colorimeter and Display make and model combination, although a
- matrix for a different but similar type of display may give better
- results than none at all. A list of contributed <span
- style="font-weight: bold;">ccmx</span> files is <a
- href="ccmxs.html">here</a>.<br>
- <br>
- <h4><a name="PM7"></a>Calibrating and profiling a display that
- doesn't have VideoLUT access.</h4>
- <p>In some situation there is no access to a displays VideoLUT
- hardware, and this hardware is what is usually used to implement
- display calibration. This could be because the display is being
- accessed via a web server, or because the driver or windowing
- system doesn't support VideoLUT access.<br>
- </p>
- <p>There are two basic options in this situation:<br>
- </p>
- <p> 1) Don't attempt to calibrate, just profile the display.<br>
- 2) Calibrate, but incorporate the calibration in some other
- way in the workflow.<br>
- </p>
- <p>The first case requires nothing special - just skip calibration
- (see the previous section <a href="#PM7">Profiling in several
- steps: Creating display test values</a>).</p>
- <p> In the second case, there are three choices:<br>
- </p>
- <p> 2a) Use dispcal to create a calibration and a quick profile
- that incorporates the calibration into the profile.<br>
- 2b) Use dispcal to create the calibration, then dispread and
- colprof to create a profile, and then incorporate the calibration
- into the profile using applycal.<br>
- 2c) Use dispcal to create the calibration, then dispread and
- colprof to create a profile, and then apply the calibration after
- the profile in a cctiff workflow.<br>
- </p>
- <p>The first case requires nothing special, use dispcal in a normal
- fashioned with the <span style="font-weight: bold;">-o</span>
- option to generate a quick profile.The profile created will <span
- style="text-decoration: underline;">not</span> contain a 'vcgt'
- tag, but instead will have the calibration curves incorporated
- into the profile itself. If calibration parameters are chosen that
- change the displays white point or brightness, then this will
- result in a slightly unusual profile that has a white point that
- does not correspond with device R=G=B=1.0. Some systems may not
- cope properly with this type of profile, and a general shift in
- white point through such a profile can create an odd looking
- display if it is applied to images but not to other elements on
- the display say as GUI decoration elements or other application
- windows.<br>
- </p>
- <p>In the second case, the calibration file created using dispcal
- should be provided to dispread using the <span
- style="font-weight: bold;">-K</span> flag:<br>
- </p>
- <p><a href="dispread.html">dispread</a> <a href="dispread.html#v">-v</a>
- <a href="dispread.html#K">-K TargetA.cal</a> <a
- href="dispread.html#p1">DisplayA</a></p>
- <p><span style="font-weight: bold;"></span>Create the profile as
- usual using colprof. but note that colprof will ignore the
- calibration, and that no 'vcgt' tag will be added to the profile.<br>
- You can then use <a href="applycal.html">applycal </a>to combine
- the calibration into the profile. Note that the resulting profile
- will be slightly unusual, since the profile is not made completely
- consistent with the effects of the calibration, and the device
- R=G=B=1.0 probably not longer corresponds with the PCS white or
- the white point.<br>
- </p>
- In the third case, the same procedure as above is used to create a
- profile, but the calibration is applied in a raster transformation
- workflow explicitly, e.g.:<br>
- <br>
- <a href="cctiff.html">cctiff</a> <a
- href="cctiff.html#p1">SourceProfile.icm</a> <a
- href="cctiff.html#p1">DisplayA.icm</a> <a href="cctiff.html#p2">DisplayA.cal</a>
- <a href="cctiff.html#p3">infile.tif</a> <a href="cctiff.html#p4">outfile.tif</a><br>
- or<br>
- <a href="cctiff.html">cctiff</a> <a
- href="cctiff.html#p1">SourceProfile.icm</a> <a
- href="cctiff.html#p1">DisplayA.icm</a> <a href="cctiff.html#p2">DisplayA.cal</a>
- <a href="cctiff.html#p3">infile.jpg</a> <a href="cctiff.html#p4">outfile.jpg</a><br>
- <span style="font-weight: bold;"></span><br>
- <hr size="2" width="100%">
- <h3><a name="PS1"></a>Profiling Scanners and other input devices
- such as cameras<br>
- </h3>
- Because a scanner or camera is an input device, it is necessary to
- go about profiling it in quite a different way to an output device.
- To profile it, a test chart is needed to exercise the input device
- response, to which the CIE values for each test patch is known.
- Generally standard reflection or transparency test charts are used
- for this purpose.<br>
- <h4><a name="PS2"></a>Types of test charts</h4>
- The most common and popular test chart for scanner profiling is the
- IT8.7/2 chart. This is a standard format chart generally reproduced
- on photographic film, containing about 264 test patches.<br>
- An accessible and affordable source of such targets is Wolf Faust a
- <a href="http://www.targets.coloraid.de/">www.coloraid.de</a>.<br>
- Another source is LaserSoft <a
- href="http://www.silverfast.com/show/it8/en.html">www.silverfast.com.</a><br>
- The Kodak Q-60 Color Input Target is also a typical example:<br>
- <br>
- <img src="Q60.jpg" alt="Kodak Q60 chart image" height="141"
- width="200"> <br>
- <br>
- A very simple chart that is widely available is the Macbeth
- ColorChecker chart, although it contains only 24 patches and
- therefore is probably not ideal for creating profiles:<br>
- <img alt="ColorChecker 24 patch" src="colorchecker.jpg"
- style="width: 112px; height: 78px;"><br>
- <br>
- Other popular charts are the X-Rite/GretagMacbeth ColorChecker DC
+ + + + Correction Matrix</a>. These are specific to a particular + Colorimeter and Display make and model combination, although a + matrix for a different but similar type of display may give better + results than none at all. A list of contributed <span + style="font-weight: bold;">ccmx</span> files is <a + href="ccmxs.html">here</a>.<br> + <br> + <h4><a name="PM7"></a>Calibrating and profiling a display that + doesn't have VideoLUT access.</h4> + <p>In some situation there is no access to a displays VideoLUT + hardware, and this hardware is what is usually used to implement + display calibration. This could be because the display is being + accessed via a web server, or because the driver or windowing + system doesn't support VideoLUT access.<br> + </p> + <p>There are two basic options in this situation:<br> + </p> + <p> 1) Don't attempt to calibrate, just profile the display.<br> + 2) Calibrate, but incorporate the calibration in some other + way in the workflow.<br> + </p> + <p>The first case requires nothing special - just skip calibration + (see the previous section <a href="#PM7">Profiling in several + steps: Creating display test values</a>).</p> + <p> In the second case, there are three choices:<br> + </p> + <p> 2a) Use dispcal to create a calibration and a quick profile + that incorporates the calibration into the profile.<br> + 2b) Use dispcal to create the calibration, then dispread and + colprof to create a profile, and then incorporate the calibration + into the profile using applycal.<br> + 2c) Use dispcal to create the calibration, then dispread and + colprof to create a profile, and then apply the calibration after + the profile in a cctiff workflow.<br> + </p> + <p>The first case requires nothing special, use dispcal in a normal + fashioned with the <span style="font-weight: bold;">-o</span> + option to generate a quick profile.The profile created will <span + style="text-decoration: underline;">not</span> contain a 'vcgt' + tag, but instead will have the calibration curves incorporated + into the profile itself. If calibration parameters are chosen that + change the displays white point or brightness, then this will + result in a slightly unusual profile that has a white point that + does not correspond with device R=G=B=1.0. Some systems may not + cope properly with this type of profile, and a general shift in + white point through such a profile can create an odd looking + display if it is applied to images but not to other elements on + the display say as GUI decoration elements or other application + windows.<br> + </p> + <p>In the second case, the calibration file created using dispcal + should be provided to dispread using the <span + style="font-weight: bold;">-K</span> flag:<br> + </p> + <p><a href="dispread.html">dispread</a> <a href="dispread.html#v">-v</a> + <a href="dispread.html#K">-K TargetA.cal</a> <a + href="dispread.html#p1">DisplayA</a></p> + <p><span style="font-weight: bold;"></span>Create the profile as + usual using colprof. but note that colprof will ignore the + calibration, and that no 'vcgt' tag will be added to the profile.<br> + You can then use <a href="applycal.html">applycal </a>to combine + the calibration into the profile. Note that the resulting profile + will be slightly unusual, since the profile is not made completely + consistent with the effects of the calibration, and the device + R=G=B=1.0 probably not longer corresponds with the PCS white or + the white point.<br> + </p> + In the third case, the same procedure as above is used to create a + profile, but the calibration is applied in a raster transformation + workflow explicitly, e.g.:<br> + <br> + <a href="cctiff.html">cctiff</a> <a + href="cctiff.html#p1">SourceProfile.icm</a> <a + href="cctiff.html#p1">DisplayA.icm</a> <a href="cctiff.html#p2">DisplayA.cal</a> + <a href="cctiff.html#p3">infile.tif</a> <a href="cctiff.html#p4">outfile.tif</a><br> + or<br> + <a href="cctiff.html">cctiff</a> <a + href="cctiff.html#p1">SourceProfile.icm</a> <a + href="cctiff.html#p1">DisplayA.icm</a> <a href="cctiff.html#p2">DisplayA.cal</a> + <a href="cctiff.html#p3">infile.jpg</a> <a href="cctiff.html#p4">outfile.jpg</a><br> + <span style="font-weight: bold;"></span><br> + <hr size="2" width="100%"> + <h3><a name="PS1"></a>Profiling Scanners and other input devices + such as cameras<br> + </h3> + Because a scanner or camera is an input device, it is necessary to + go about profiling it in quite a different way to an output device. + To profile it, a test chart is needed to exercise the input device + response, to which the CIE values for each test patch is known. + Generally standard reflection or transparency test charts are used + for this purpose.<br> + <h4><a name="PS2"></a>Types of test charts</h4> + The most common and popular test chart for scanner profiling is the + IT8.7/2 chart. This is a standard format chart generally reproduced + on photographic film, containing about 264 test patches.<br> + An accessible and affordable source of such targets is Wolf Faust a + <a href="http://www.targets.coloraid.de/">www.coloraid.de</a>.<br> + Another source is LaserSoft <a + href="http://www.silverfast.com/show/it8/en.html">www.silverfast.com.</a><br> + The Kodak Q-60 Color Input Target is also a typical example:<br> + <br> + <img src="Q60.jpg" alt="Kodak Q60 chart image" width="200" + height="141"> <br> + <br> + A very simple chart that is widely available is the Macbeth + ColorChecker chart, although it contains only 24 patches and + therefore is probably not ideal for creating profiles:<br> + <img alt="ColorChecker 24 patch" src="colorchecker.jpg" + style="width: 112px; height: 78px;"><br> + <br> + Other popular charts are the X-Rite/GretagMacbeth ColorChecker DC and <a href="http://www.xrite.com/product_overview.aspx?ID=938">ColorChecker @@ -883,18 +891,20 @@ -
- SG</a> charts:<br>
- <br>
- <img src="DC.jpg" alt="GretagMacbeth ColorChecker DC chart"
- height="122" width="200"> <img alt="ColorChecker SG" src="SG.jpg"
- style="width: 174px; height: 122px;"><br>
- <br>
- The GretagMacbeth Eye-One Pro Scan Target 1.4 can also be used:<br>
- <br>
- <img alt="Eye-One Scan Target 1.4" src="i1scan14.jpg" style="border:
- 2px solid ; width: 200px; height: 140px;"><br>
- <br>
+ + + + SG</a> charts:<br> + <br> + <img src="DC.jpg" alt="GretagMacbeth ColorChecker DC chart" + width="200" height="122"> <img alt="ColorChecker SG" src="SG.jpg" + style="width: 174px; height: 122px;"><br> + <br> + The GretagMacbeth Eye-One Pro Scan Target 1.4 can also be used:<br> + <br> + <img alt="Eye-One Scan Target 1.4" src="i1scan14.jpg" style="border: + 2px solid ; width: 200px; height: 140px;"><br> + <br> Also supported is the <a href="http://www.hutchcolor.com/hct.htm">HutchColor @@ -952,23 +962,25 @@ -
- HCT</a> :<br>
- <br>
- <img alt="HutchColor HCT" src="HCT.jpg" style="width: 182px; height:
- 140px;"><br>
- <br>
- <br>
- and <a href="http://www.cmp-color.fr/DT3.html">Christophe
- Métairie's Digital TargeT 003</a> and <a
- href="http://www.cmp-color.fr/digital%20target.html">Christophe
- Métairie's Digital Target - 4</a> :<br>
- <br>
- <img alt="CMP_DT_003" src="CMP_DT_003.jpg" style="width: 186px;
- height: 141px;"> <img style="width: 203px; height: 140px;"
- alt="CMP_Digital_Target-4" src="CMP_Digital_Target-4.jpg"
- height="140" width="203"><br>
- <br>
+ + + + HCT</a> :<br> + <br> + <img alt="HutchColor HCT" src="HCT.jpg" style="width: 182px; height: + 140px;"><br> + <br> + <br> + and <a href="http://www.cmp-color.fr/DT3.html">Christophe + Métairie's Digital TargeT 003</a> and <a + href="http://www.cmp-color.fr/digital%20target.html">Christophe + Métairie's Digital Target - 4</a> :<br> + <br> + <img alt="CMP_DT_003" src="CMP_DT_003.jpg" style="width: 186px; + height: 141px;"> <img style="width: 203px; height: 140px;" + alt="CMP_Digital_Target-4" src="CMP_Digital_Target-4.jpg" + width="203" height="140"><br> + <br> and the <a href="http://www.silverfast.com/show/dc-targets/en.html">LaserSoft @@ -1026,20 +1038,28 @@ -
- Imaging DCPro Target</a>:<br>
- <br>
- <img style="width: 153px; height: 122px;" alt="LaserSoft DCPro
- Target" src="LSDC.jpg"><br>
- <br>
- The Datacolor <a
- href="http://spyder.datacolor.com/product-cb-spydercheckr.php">SpyderCheckr</a>:<br>
- <br>
- <img style=" width: 146px; height: 109px;" alt="Datacolor
- SpyderCheckr" src="SpyderChecker.jpg"><br>
- <br>
- One of the QPcard's:<br>
- <a
+ + + + Imaging DCPro Target</a>:<br> + <br> + <img style="width: 153px; height: 122px;" alt="LaserSoft DCPro + Target" src="LSDC.jpg"><br> + <br> + The Datacolor <a + href="http://spyder.datacolor.com/product-cb-spydercheckr.php">SpyderCheckr</a>:<br> + <br> + <img style=" width: 146px; height: 109px;" alt="Datacolor + SpyderCheckr" src="SpyderChecker.jpg"><br> + <br> + The Datacolor <a + href="http://spyder.datacolor.com/portfolio-view/spydercheckr-24/">SpyderCheckr24</a>:<br> + <br> + <img alt="SpyderCheckr24" src="SpyderChecker24.jpg" width="82" + height="122"><br> + <br> + One of the QPcard's:<br> + <a href="http://www.qpcard.com/en_b2c/color-reference-cards/qpcard201.html">QPcard @@ -1091,8 +1111,10 @@ -
- 201</a>: <a
+ + + + 201</a>: <a href="http://www.qpcard.com/en_b2c/color-reference-cards/instant-camera-raw-profiling-with-qpcard-202.html">QPcard @@ -1144,87 +1166,89 @@ href="http://www.qpcard.com/en_b2c/color-reference-cards/instant-camera-raw-prof -
- 202</a>:<br>
- <br>
- <img style=" width: 41px; height: 141px;" alt="QPCard201"
- src="QPcard201.jpg">
- <img
- style=" width: 97px; height: 141px;" alt="QPcard202"
- src="QPcard202.jpg"><br>
- <br>
- <h4><a name="PS3"></a>Taking readings from a scanner or camera<br>
- </h4>
- The test chart you are using needs to be placed on the scanner, and
- the scanner needs to be configured to a suitable state, and restored
- to that same state when used subsequently with the resulting
- profile. For a camera, the chart needs to be lit in a controlled and
- even manner using the light source that will be used for subsequent
- photographs, and should be shot so as to minimise any geometric
- distortion, although the <a href="scanin.html#p">scanin -p</a> flag
- may be used to compensate for some degree of distortion. As with any
- color profiling task, it is important to setup a known and
- repeatable image processing flow, to ensure that the resulting
- profile will be usable.<br>
- <br>
- The chart should be captured and saved to a TIFF format file. I will
- assume the resulting file is called scanner.tif. The raster file
- need only be roughly cropped so as to contain the test chart
- (including the charts edges).<br>
- <br>
- The second step is to extract the RGB values from the scanner.tif
- file, and match then to the reference CIE values. To locate the
- patch values in the scan, the <b>scanin</b> tool needs to be given
- a template <a href="File_Formats.html#.cht">.cht</a> file that
- describes the features of the chart, and how the test patches are
- labeled. Also needed is a file containing the CIE values for each of
- the patches in the chart, which is typically supplied with the
- chart, available from the manufacturers web site, or has been
- measured using a spectrometer.<br>
- <br>
- <div style="margin-left: 40px;">For an IT8.7/2 chart, this is the <span
- style="font-weight: bold;">ref/</span><b>it8.cht</b> file
- supplied with Argyll, and the manufacturer will will supply
- an individual or batch average file along with the chart
- containing this information, or downloadable from their web site.
- For instance, Kodak Q60 target reference files are <a
- href="ftp://ftp.kodak.com/gastds/Q60DATA/">here</a>.<br>
- NOTE that the reference file for the IT8.7/2 chart supplied with <span
- style="font-weight: bold;">Monaco EZcolor</span> can be
- obtained by unzipping the .mrf file. (You may have to make a copy
- of the file with a .zip extension to do this.)<br>
- <br>
- For the ColorChecker 24 patch chart, the <span
- style="font-weight: bold;">ref/ColorChecker.cht</span> file
- should be used, and there is also a <span style="font-weight:
- bold;">ref/ColorChecker.cie</span> file provided that is based
- on the manufacturers reference values for the chart. You can also
- create your own reference file using an instrument and chartread,
- making use of the chart reference file <span style="font-weight:
- bold;">ref/ColorChecker.ti2</span>:<br>
- <a href="chartread.html">chartread</a> -n
- ColorChecker.ti2<br>
- Note that due to the small number of patches, a profile created
- from such a chart is not likely to be very detailed.<br>
- <br>
- For the ColorChecker DC chart, the <span style="font-weight:
- bold;">ref/ColorCheckerDC.cht</span> file should be used, and
- there will be a ColorCheckerDC reference file supplied by
- X-Rite/GretagMacbeth with the chart.<br>
- <br>
- The ColorChecker SG is relatively expensive, but is preferred by
- many people because (like the ColorChecker and ColorCheckerDC) its
- colors are composed of multiple different pigments, giving it
- reflective spectra that are more representative of the real world,
- unlike many other charts that are created out of combination of 3
- or 4 colorants.<br>
- A limited CIE reference file is available from X-Rite <a
-href="http://www.xrite.com/documents/apps/public/digital_colorchecker_sg_l_a_b.txt">here</a>,
- but it is not in the usual CGATS format. To convert it to a CIE
- reference file useful for <span style="font-weight: bold;">scanin</span>,
- you will need to edit the X-Rite file using a <span
- style="text-decoration: underline;">plain text</span> editor,
- first deleting everything before the line starting with "A1" and
+ + + + 202</a>:<br> + <br> + <img style=" width: 41px; height: 141px;" alt="QPCard201" + src="QPcard201.jpg"> + <img + style=" width: 97px; height: 141px;" alt="QPcard202" + src="QPcard202.jpg"><br> + <br> + <h4><a name="PS3"></a>Taking readings from a scanner or camera<br> + </h4> + The test chart you are using needs to be placed on the scanner, and + the scanner needs to be configured to a suitable state, and restored + to that same state when used subsequently with the resulting + profile. For a camera, the chart needs to be lit in a controlled and + even manner using the light source that will be used for subsequent + photographs, and should be shot so as to minimise any geometric + distortion, although the <a href="scanin.html#p">scanin -p</a> flag + may be used to compensate for some degree of distortion. As with any + color profiling task, it is important to setup a known and + repeatable image processing flow, to ensure that the resulting + profile will be usable.<br> + <br> + The chart should be captured and saved to a TIFF format file. I will + assume the resulting file is called scanner.tif. The raster file + need only be roughly cropped so as to contain the test chart + (including the charts edges).<br> + <br> + The second step is to extract the RGB values from the scanner.tif + file, and match then to the reference CIE values. To locate the + patch values in the scan, the <b>scanin</b> tool needs to be given + a template <a href="File_Formats.html#.cht">.cht</a> file that + describes the features of the chart, and how the test patches are + labeled. Also needed is a file containing the CIE values for each of + the patches in the chart, which is typically supplied with the + chart, available from the manufacturers web site, or has been + measured using a spectrometer.<br> + <br> + <div style="margin-left: 40px;">For an IT8.7/2 chart, this is the <span + style="font-weight: bold;">ref/</span><b>it8.cht</b> file + supplied with Argyll, and the manufacturer will will supply + an individual or batch average file along with the chart + containing this information, or downloadable from their web site. + For instance, Kodak Q60 target reference files are <a + href="ftp://ftp.kodak.com/gastds/Q60DATA/">here</a>.<br> + NOTE that the reference file for the IT8.7/2 chart supplied with <span + style="font-weight: bold;">Monaco EZcolor</span> can be + obtained by unzipping the .mrf file. (You may have to make a copy + of the file with a .zip extension to do this.)<br> + <br> + For the ColorChecker 24 patch chart, the <span + style="font-weight: bold;">ref/ColorChecker.cht</span> file + should be used, and there is also a <span style="font-weight: + bold;">ref/ColorChecker.cie</span> file provided that is based + on the manufacturers reference values for the chart. You can also + create your own reference file using an instrument and chartread, + making use of the chart reference file <span style="font-weight: + bold;">ref/ColorChecker.ti2</span>:<br> + <a href="chartread.html">chartread</a> -n + ColorChecker.ti2<br> + Note that due to the small number of patches, a profile created + from such a chart is not likely to be very detailed.<br> + <br> + For the ColorChecker DC chart, the <span style="font-weight: + bold;">ref/ColorCheckerDC.cht</span> file should be used, and + there will be a ColorCheckerDC reference file supplied by + X-Rite/GretagMacbeth with the chart.<br> + <br> + The ColorChecker SG is relatively expensive, but is preferred by + many people because (like the ColorChecker and ColorCheckerDC) its + colors are composed of multiple different pigments, giving it + reflective spectra that are more representative of the real world, + unlike many other charts that are created out of combination of 3 + or 4 colorants.<br> + A limited CIE reference file is available from X-Rite <a +href="http://www.xrite.com/documents/apps/public/digital_colorchecker_sg_l_a_b.txt">here</a>, + but it is not in the usual CGATS format. To convert it to a CIE + reference file useful for <span style="font-weight: bold;">scanin</span>, + you will need to edit the X-Rite file using a <span + style="text-decoration: underline;">plain text</span> editor, + first deleting everything before the line starting with "A1" and everything after "N10", then prepending <a href="SG_header.txt">this @@ -1281,83 +1305,95 @@ href="http://www.xrite.com/documents/apps/public/digital_colorchecker_sg_l_a_b.t -
- header</a>, and appending <a href="SG_footer.txt">this footer</a>,
- making sure there are no blank lines inserted in the process.
- There are reports that X-Rite have experimented with different ink
- formulations for certain patches, so the above reference may not
- be as accurate as desired, and it is preferable to measure your
- own chart using a spectrometer, if you have the capability.<br>
- If you do happen to have access to a more comprehensive instrument
- measurement of the ColorChecker SG, or you have measured it
- yourself using a color instrument,<br>
- then you <span style="text-decoration: underline;">may</span>
- need to convert the reference information from spectral <span
- style="font-weight: bold;">ColorCheckerSG.txt</span> file to CIE
- value <span style="font-weight: bold;">ColorCheckerSG.cie</span>
- reference file, follow the following steps:<br>
- <a href="txt2ti3.html">txt2ti3</a>
- ColorCheckerSG.txt ColorCheckerSG<br>
- <a href="spec2cie.html">spec2cie</a>
- ColorCheckerSG.ti3 ColorCheckerSG.cie<br>
- <br>
- For the Eye-One Pro Scan Target 1.4 chart, the <span
- style="font-weight: bold;"><span style="font-weight: bold;">ref/</span>i1_RGB_Scan_1.4.cht</span>
- file should be used, and as there is no reference file
- accompanying this chart, the chart needs to be read with an
- instrument (usually the Eye-One Pro). This can be done using
- chartread, making use of the chart reference file <span
- style="font-weight: bold;">ref/i1_RGB_Scan_1.4.ti2</span>:<br>
- <a href="chartread.html">chartread</a> -n
- i1_RGB_Scan_1.4<br>
- and then rename the resulting <span style="font-weight: bold;">i1_RGB_Scan_1.4.ti3</span>
- file to <span style="font-weight: bold;">i1_RGB_Scan_1.4.cie</span><br>
- <span style="font-weight: bold;"></span><br>
- For the HutchColor HCT chart, the <span style="font-weight:
- bold;"><span style="font-weight: bold;">ref/</span>Hutchcolor.cht</span>
- file should be used, and the reference <span style="font-weight:
- bold;">.txt</span> file downloaded from the HutchColor website.<br>
- <br>
- For the Christophe Métairie's Digital TargeT 003 chart with 285
- patches, the <span style="font-weight: bold;"><span
- style="font-weight: bold;">ref/</span>CMP_DT_003.cht</span>
- file should be used, and the cie reference <span
- style="font-weight: bold;"></span>files come with the chart.<br>
- <br>
- For the Christophe Métairie's Digital Target-4 chart with 570
- patches, the <span style="font-weight: bold;">ref/CMP_Digital_Target-4.cht</span>
- file should be used, and the cie reference <span
- style="font-weight: bold;"></span>files come with the chart.<br>
- <br>
- For the LaserSoft DCPro chart, the <span style="font-weight:
- bold;">ref/LaserSoftDCPro.cht</span> file should be used, and
- reference <span style="font-weight: bold;">.txt</span> file
- downloaded from the <a
- href="http://www.silverfast.com/it8calibration/">Silverfast
- website</a>.<br>
- <br>
- For the Datacolor SpyderCheckr, the <span style="font-weight:
- bold;">ref/SpyderChecker.cht</span> file should be used, and a
- reference <span style="font-weight: bold;">ref/SpyderChecker.cie
- </span>file made from measuring a sample chart is also available.
- Alternately you could create your own reference file by
- transcribing the <a
- href="http://spyder.datacolor.com/images/photo_checkr_colordatainfo.jpg">values</a>
- on the Datacolor website. <br>
- <br>
- For the QPCard 201, the <span style="font-weight: bold;">ref/QPcard_201.cht</span>
- file should be used, and a reference <span style="font-weight:
- bold;">ref/QPcard_201.cie</span> file made from measuring a
- sample chart is also available. <br>
- <br>
- For the QPCard 202, the <span style="font-weight: bold;">ref/QPcard_202.cht</span>
- file should be used, and a reference <span style="font-weight:
- bold;">ref/QPcard_202.cie</span> file made from measuring a
- sample chart is also available. <br>
- </div>
- <br>
- For any other type of chart, a chart recognition template file will
- need to be created (this is beyond the scope of the current
+ + + + header</a>, and appending <a href="SG_footer.txt">this footer</a>, + making sure there are no blank lines inserted in the process. + There are reports that X-Rite have experimented with different ink + formulations for certain patches, so the above reference may not + be as accurate as desired, and it is preferable to measure your + own chart using a spectrometer, if you have the capability.<br> + If you do happen to have access to a more comprehensive instrument + measurement of the ColorChecker SG, or you have measured it + yourself using a color instrument,<br> + then you <span style="text-decoration: underline;">may</span> + need to convert the reference information from spectral <span + style="font-weight: bold;">ColorCheckerSG.txt</span> file to CIE + value <span style="font-weight: bold;">ColorCheckerSG.cie</span> + reference file, follow the following steps:<br> + <a href="txt2ti3.html">txt2ti3</a> + ColorCheckerSG.txt ColorCheckerSG<br> + <a href="spec2cie.html">spec2cie</a> + ColorCheckerSG.ti3 ColorCheckerSG.cie<br> + <br> + For the Eye-One Pro Scan Target 1.4 chart, the <span + style="font-weight: bold;"><span style="font-weight: bold;">ref/</span>i1_RGB_Scan_1.4.cht</span> + file should be used, and as there is no reference file + accompanying this chart, the chart needs to be read with an + instrument (usually the Eye-One Pro). This can be done using + chartread, making use of the chart reference file <span + style="font-weight: bold;">ref/i1_RGB_Scan_1.4.ti2</span>:<br> + <a href="chartread.html">chartread</a> -n + i1_RGB_Scan_1.4<br> + and then rename the resulting <span style="font-weight: bold;">i1_RGB_Scan_1.4.ti3</span> + file to <span style="font-weight: bold;">i1_RGB_Scan_1.4.cie</span><br> + <span style="font-weight: bold;"></span><br> + For the HutchColor HCT chart, the <span style="font-weight: + bold;"><span style="font-weight: bold;">ref/</span>Hutchcolor.cht</span> + file should be used, and the reference <span style="font-weight: + bold;">.txt</span> file downloaded from the HutchColor website.<br> + <br> + For the Christophe Métairie's Digital TargeT 003 chart with 285 + patches, the <span style="font-weight: bold;"><span + style="font-weight: bold;">ref/</span>CMP_DT_003.cht</span> + file should be used, and the cie reference <span + style="font-weight: bold;"></span>files come with the chart.<br> + <br> + For the Christophe Métairie's Digital Target-4 chart with 570 + patches, the <span style="font-weight: bold;">ref/CMP_Digital_Target-4.cht</span> + file should be used, and the cie reference <span + style="font-weight: bold;"></span>files come with the chart.<br> + <br> + For the LaserSoft DCPro chart, the <span style="font-weight: + bold;">ref/LaserSoftDCPro.cht</span> file should be used, and + reference <span style="font-weight: bold;">.txt</span> file + downloaded from the <a + href="http://www.silverfast.com/it8calibration/">Silverfast + website</a>.<br> + <br> + For the Datacolor SpyderCheckr, the <span style="font-weight: + bold;">ref/SpyderChecker.cht</span> file should be used, and a + reference <span style="font-weight: bold;">ref/SpyderChecker.cie + </span>file made from measuring a sample chart is also available. + Alternately you could create your own reference file by + transcribing the <a + href="http://spyder.datacolor.com/images/photo_checkr_colordatainfo.jpg">values</a> + on the Datacolor website. <br> + <br> + For the Datacolor SpyderCheckr, the <span style="font-weight: + bold;">ref/SpyderChecker24.cht</span> file should be used, and a + reference <span style="font-weight: bold;">ref/SpyderChecker24.cie + + </span>file made from measuring a sample chart is also available. + Alternately you could create your own reference file by + transcribing the <a + href="http://spyder.datacolor.com/images/photo_checkr_colordatainfo.jpg">values</a> + on the Datacolor website. <br> + <br> + For the QPCard 201, the <span style="font-weight: bold;">ref/QPcard_201.cht</span> + file should be used, and a reference <span style="font-weight: + bold;">ref/QPcard_201.cie</span> file made from measuring a + sample chart is also available. <br> + <br> + For the QPCard 202, the <span style="font-weight: bold;">ref/QPcard_202.cht</span> + file should be used, and a reference <span style="font-weight: + bold;">ref/QPcard_202.cie</span> file made from measuring a + sample chart is also available. <br> + </div> + <br> + For any other type of chart, a chart recognition template file will + need to be created (this is beyond the scope of the current documentation, although see the <a href="cht_format.html">.cht_format @@ -1414,403 +1450,405 @@ href="http://www.xrite.com/documents/apps/public/digital_colorchecker_sg_l_a_b.t -
- documentation</a>).<br>
- <br>
- To create the scanner .ti3 file, run the <b>scanin</b> tool as
- follows (assuming an IT8 chart is being used):<br>
- <br>
- <a href="scanin.html"> scanin</a> -v scanner.tif It8.cht It8ref.txt<br>
- <br>
- "It8ref.txt" or "It8ref.cie" is assumed to be the name of the CIE
- reference file supplied by the chart manufacturer. The resulting
- file will be named "<b>scanner.ti3</b>".<br>
- <br>
- <span style="font-weight: bold;">scanin</span> will process 16 bit
- per component .tiff files, which (if the scanner is capable of
- creating such files), may improve the quality of the profile.
- <br>
- <br>
- If you have any doubts about the correctness of the chart
- recognition, or the subsequent profile's delta E report is unusual,
- then use the scanin diagnostic flags <a href="scanin.html#d">-dipn</a>
- and examine the <span style="font-weight: bold;">diag.tif</span>
- diagnostic file, to make sure that the patches are identified and
- aligned correctly. If you have problems getting good automatic
- alignment, then consider doing a manual alignment by locating the
- fiducial marks on your scan, and feeding them into scanin <a
- href="scanin.html#F">-F</a> parameters. The fiducial marks should
- be listed in a clockwise direction starting at the top left.<br>
- <h4><a name="PS4"></a>Creating a scanner or camera input profile</h4>
- Similar to a display profile, an input profile can be either a
- shaper/matrix or LUT based profile. Well behaved input devices will
- probably give the best results with a shaper/matrix profile, and
- this may also be the best choice if your test chart has a small or
- unevenly distributed set of test patchs (ie. the IT8.7.2). If a
- shaper/matrix profile is a poor fit, consider using a LUT type
- profile.<br>
- <br>
- When creating a LUT type profile, there is the choice of XYZ or
- L*a*b* PCS (Device independent, Profile Connection Space). Often for
- input devices, it is better to choose the XYZ PCS, as this may be a
- better fit given that input devices are usually close to being
- linearly additive in behaviour.<br>
- <br>
- If the purpose of the input profile is to use it as a substitute for
- a colorimeter, then the <b>-u</b> flag should be used to avoid
- clipping values above the white point. Unless the shaper/matrix type
- profile is a very good fit, it is probably advisable to use a LUT
- type profile in this situation.<br>
- <br>
- To create a matrix/shaper profile, the following suffices:<br>
- <br>
- <a href="colprof.html">colprof</a> <a href="colprof.html#v">-v</a>
- <a href="colprof.html#E">-D"Scanner</a> <a href="colprof.html#E">A"</a>
- <a href="colprof.html#q">-qm</a> <a href="colprof.html#a">-as</a> <a
- href="colprof.html#p1">scanner</a><br>
- <br>
- For an XYZ PCS LUT based profile then the following would be used:<br>
- <br>
- <a href="colprof.html">colprof</a> <a href="colprof.html#v">-v</a>
- <a href="colprof.html#E">-D"Scanner A"</a> <a href="colprof.html#q">-qm</a>
- <a href="colprof.html#a">-ax</a> <a href="colprof.html#p1">scanner</a><br>
- <br>
- For the purposes of a poor mans colorimeter, the following would
- generally be used:<br>
- <br>
- <a href="colprof.html">colprof</a> <a href="colprof.html#v">-v</a>
- <a href="colprof.html#E">-D"Scanner A"</a> <a href="colprof.html#q">-qm</a>
- <a href="colprof.html#a">-ax</a> <a href="colprof.html#u">-u</a> <a
- href="colprof.html#p1">scanner</a><br>
- <br>
- Make sure you check the delta E report at the end of the profile
- creation, to see if the sample data and profile is behaving
- reasonably. Depending on the type of device, and the consistency of
- the readings, average errors of 5 or less, and maximum errors of 15
- or less would normally be expected. If errors are grossly higher
- than this, then this is an indication that something is seriously
- wrong with the device measurement, or profile creation.<br>
- <br>
- If profiling a <span style="font-weight: bold;">camera</span> in <span
- style="font-weight: bold;">RAW</span> mode, then there may be some
- advantage in creating a pure matrix only profile, in which it is
- assumed that the camera response is completely linear. This may
- reduce extrapolation artefacts. If setting the white point will be
- done in some application, then it may also be an advantage to use
- the <span style="font-weight: bold;">-u</span> flag and avoid
- setting the white point to that of the profile chart:<br>
- <br>
- <a href="colprof.html">colprof</a> <a href="colprof.html#v">-v</a>
- <a href="colprof.html#E">-D"Camera"</a> <a href="colprof.html#q">-qm</a>
- <a href="colprof.html#a">-am</a> <a href="colprof.html#u">-u</a> <a
- href="colprof.html#p1">scanner</a><br>
- <br>
- <br>
- <hr size="2" width="100%">
- <h3><a name="PP1"></a>Profiling Printers<br>
- </h3>
- The overall process is to create a set of device measurement target
- values, print them out, measure them, and then create an ICC profile
- from the measurements. If the printer is an RGB based printer, then
- the process is only slightly more complicated than profiling a
- display. If the printer is CMYK based, then some additional
- parameters are required to set the total ink limit (TAC) and
- black generation curve.<br>
- <h4><a name="PP2"></a>Creating a print profile test chart</h4>
- The first step in profiling any output device, is to create a set of
- device colorspace test values. The important parameters needed are:<br>
- <ul>
- <li>What colorspace does the device use ?</li>
- <li>How many test patches do I want to use/what paper size do I
- want to use ?</li>
- <li>What instrument am I going to use to read the patches ?<br>
- </li>
- <li>If it is a CMYK device, what is the total ink limit ?<br>
- </li>
- <li>What information do I already have about how the device
- behaves ?</li>
- </ul>
- Most printers running through simple drivers will appear as if they
- are RGB devices. In fact there is no such thing as a real RGB
- printer, since printers use white media and the colorant must
- subtract from the light reflected on it to create color, but the
- printer itself turns the incoming RGB into the native print
- colorspace, so for this reason we will tell targen to use the "Print
- RGB" colorspace, so that it knows that it's really a subtractive
- media. Other drivers will drive a printer more directly, and will
- expect a CMYK profile. [Currently Argyll is not capable of creating
- an ICC profile for devices with more colorants than CMYK. When this
- capability is introduced, it will by creating an additional
- separation profile which then allows the printer to be treated as a
- CMY or CMYK printer.] One way of telling what sort of profile is
- expected for your device is to examine an existing profile for that
- device using <a href="http://www.argyllcms.com/doc/iccdump.html">iccdump</a>.<br>
- <br>
- The number of test patches will depend somewhat on what quality
- profile you want to make, how well behaved the printer is, as well
- as the effort needed to read the number of test values. Generally it
- is convenient to fill a certain paper size with the maximum number
- of test values that will fit.<br>
- <br>
- At a minimum, for an "RGB" device, a few hundred values are needed
- (400-1000). For high quality CMYK profiles, 1000-3000 is not an
- unreasonable number of patches.<br>
- <br>
- To assist the determination of test patch values, it can help to
- have a rough idea of how the device behaves, so that the device test
- point locations can be pre-conditioned. This could be in the form of
- an ICC profile of a similar device, or a lower quality, or previous
- profile for that particular device. If one were going to make a very
- high quality Lut based profile, then it might be worthwhile to make
- up a smaller, preliminary shaper/matrix profile using a few hundred
- test points, before embarking on testing the device with several
- thousand.<br>
- <br>
- The documentation for the <a
- href="http://www.argyllcms.com/doc/targen.html">targen</a> tool
- lists a <a href="http://www.argyllcms.com/doc/targen.html#Table">table</a>
- of paper sizes and number of patches for typical situations.<br>
- <br>
- For a CMYK device, a total ink limit usually needs to be specified.
- Sometimes a device will have a maximum total ink limit set by its
- manufacturer or operator, and some CMYK systems (such as chemical
- proofing systems) don't have any limit. Typical printing devices
- such as Xerographic printers, inkjet printers and printing presses
- will have a limit. The exact procedure for determining an ink limit
- is outside the scope of this document, but one way of going about
- this might be to generate some small (say a few hundred patches)
- with targen & pritntarg with different total ink limits, and
- printing them out, making the ink limit as large as possible without
- striking problems that are caused by too much ink.<br>
- <br>
- Generally one wants to use the maximum possible amount of ink to
- maximize the gamut available on the device. For most CMYK devices,
- an ink limit between 200 and 400 is usual, but and ink limit of 250%
- or over is generally desirable for reasonably dense blacks and dark
- saturated colors. And ink limit of less than 200% will begin to
- compromise the fully saturated gamut, as secondary colors (ie
- combinations of any two primary colorants) will not be able to reach
- full strength.<br>
- <br>
- Once an ink limit is used in printing the characterization test
- chart for a device, it becomes a critical parameter in knowing what
- the characterized gamut of the device is. If after printing the test
- chart, a greater ink limit were to be used, the the software would
- effectively be extrapolating the device behaviour at total ink
- levels beyond that used in the test chart, leading to inaccuracies.<br>
- <br>
- Generally in Argyll, the ink limit is established when creating the
- test chart values, and then carried through the profile making
- process automatically. Once the profile has been made however, the
- ink limit is no longer recorded, and you, the user, will have to
- keep track of it if the ICC profile is used in any program than
- needs to know the usable gamut of the device.<br>
- <br>
- <br>
- Lets consider two devices in our examples, "PrinterA" which is an
- "RGB" device, and "PrinterB" which is CMYK, and has a target ink
- limit of 250%. <br>
- <br>
- The simplest approach is to make a set of test values that is
- independent of the characteristics of the particular device:<br>
- <br>
- <a href="targen.html">targen</a> <a href="targen.html#v">-v</a>
- <a href="targen.html#d">-d2</a> <a href="targen.html#f">-f1053</a>
- <a href="targen.html#p1">PrinterA</a><br>
- <br>
- <a href="targen.html">targen</a> <a href="targen.html#v">-v</a>
- <a href="targen.html#d">-d4</a> <a href="targen.html#l">-l260</a>
- <a href="targen.html#f">-f1053</a> <a href="targen.html#p1">PrinterB</a><br>
- <br>
- The number of patches chosen here happens to be right for an A4
- paper size being read using a Spectroscan instrument. See the <a
- href="targen.html#Table">table</a> in the <a
- href="targen.html">targen</a> documentation for some other
- suggested numbers.<br>
- <br>
- If there is a preliminary or previous profile called "OldPrinterA"
- available, and we want to try creating a "pre-conditioned" set of
- test values that will more efficiently sample the device response,
- then the following would achieve this:<u><br>
- </u><br>
- <a href="targen.html">targen</a> <a href="targen.html#v">-v</a>
- <a href="targen.html#d">-d2</a> <a href="targen.html#f">-f1053</a>
- <a href="targen.html#c">-c OldPrinterA</a> <a
- href="targen.html#p1">PrinterA</a><br>
- <br>
- <a href="targen.html">targen</a> <a href="targen.html#v">-v</a>
- <a href="targen.html#d">-d4</a> <a href="targen.html#l">-l260</a>
- <a href="targen.html#f">-f1053</a> <a href="targen.html#c">-c
- OldPrinterB</a> <a href="targen.html#p1">PrinterB</a><br>
- <a href="targen.html#p1"></a><br>
- <br>
- The output of <b>targen</b> will be the file PrinterA.ti1 and
- PrinterB.ti1 respectively, containing the device space test values,
- as well as expected CIE values used for chart recognition purposes.<br>
- <br>
- <h4><a name="PP2b"></a>Printing a print profile test chart<br>
- <br>
- </h4>
- The next step is turn the test values in to a PostScript or TIFF
- raster test file that can printed on the device. The basic
- information that needs to be supplied is the type of instrument that
- will be used to read the patches, as well as the paper size it is to
- be formatted for.<br>
- <br>
- For an X-Rite DTP41, the following would be typical:<br>
- <br>
- <a href="printtarg.html">printtarg</a> <a href="printtarg.html#v">-v</a>
- <a href="printtarg.html#i">-i41</a> <a href="printtarg.html#p">-pA4</a>
- <a href="printtarg.html#p1">PrinterA</a><br>
- <br>
- For a Gretag Eye-One Pro, the following would be typical:<br>
- <br>
- <a href="printtarg.html">printtarg</a> <a href="printtarg.html#v">-v</a>
- <a href="printtarg.html#i">-ii1</a> <a href="printtarg.html#p">-pA4</a>
- <a href="printtarg.html#p1">PrinterA</a><br>
- <br>
- For using with a scanner as a colorimeter, the Gretag Spectroscan
- layout is suitable, but the <a href="printtarg.html#s">-s</a> flag
- should be used so as to generate a layout suitable for scan
- recognition, as well as generating the scan recognition template
- files. (You probably want to use less patches with <span
- style="font-weight: bold;">targen</span>, when using the <span
- style="font-weight: bold;">printtarg -s</span> flag, e.g. 1026
- patches for an A4R page, etc.) The following would be typical:<br>
- <br>
- <a href="printtarg.html">printtarg</a> <a href="printtarg.html#v">-v</a>
- <a href="printtarg.html#s">-s</a> <a href="printtarg.html#i">-iSS</a>
- <a href="printtarg.html#p">-pA4R</a> <a href="printtarg.html#p1">PrinterA</a><br>
- <span style="font-weight: bold;"><br>
- printtarg</span> reads the PrinterA.ti1 file, creates a
- PrinterA.ti2 file containing the layout information as well as the
- device values and expected CIE values, as well as a PrinterA.ps file
- containing the test chart. If the <span style="font-weight: bold;">-s</span>
- flag is used, one or more PrinterA.cht files is created to allow the
- <a href="scanin.html">scanin</a> program to recognize the chart.<br>
- <br>
- To create TIFF raster files rather than PostScript, use the <a
- href="printtarg.html#t"><span style="font-weight: bold;">-t</span></a>
- flag.<br>
- <br>
- <span style="font-weight: bold;">GSview</span> is a good program to
- use to check what the PostScript file will look like, without
- actually printing it out. You could also use <span
- style="font-weight: bold;">Photoshop</span> or <span
- style="font-weight: bold;">ImageMagick</span> for this purpose.<br>
- <br>
- The last step is to print the chart out.<br>
- <br>
- Using a suitable PostScript or raster file printing program,
- downloader, print the chart. If you are not using a TIFF test chart,
- and you do not have a PostScript capable printer, then an
- interpreter like GhostScript or even Photoshop could be used to
- rasterize the file into something that can be printed. Note that it
- is important that the PostScript interpreter or TIFF printing
- application and printer configuration is setup for a device
- profiling run, and that any sort of color conversion of color
- correction be turned off so that the device values in the PostScript
- or TIFF file are sent directly to the device. If the device has a
- calibration system, then it would be usual to have setup and
- calibrated the device before starting the profiling run, and to
- apply calibration to the chart values. If Photoshop was to be used,
- then either the chart needs to be a single page, or separate .eps or
- .tiff files for each page should be used, so that they can be
- converted and printed one at a time (see the <a
- href="printtarg.html#e">-e</a> and <a href="printtarg.html#t">-t</a>
- flags).<br>
- <br>
- <h4><a name="PP3"></a>Reading a print test chart using an instrument</h4>
- Once the test chart has been printed, the color of the patches needs
- to be read using a suitable instrument.<br>
- <br>
- Several different instruments are currently supported, some that
- need to be used patch by patch, some read a strip at a time, and
- some read a sheet at a time. See <a href="instruments.html">instruments</a>
- for a current list.<br>
- <br>
- The instrument needs to be connected to your computer before running
- the <a href="chartread.html">chartread</a> command. Both serial
- port and USB connected Instruments are supported. A serial port to
- USB adapter might have to be used if your computer doesn't have any
- serial ports, and you have a serial interface connected instrument.<br>
- <br>
- If you run <a href="chartread.html">chartread</a> so as to print
- out its usage message (ie. by using a <span style="font-weight:
- bold;">-?</span> or <span style="font-weight: bold;">--</span>
- flags), then it will list any identified serial ports or USB
- connected instruments, and their corresponding number for the <a
- href="chartread.html#c">-c</a> option. By default, <a
- href="chartread.html">chartread</a> will try to connect to the
- first available USB instrument, or an instrument on the first serial
- port.<br>
- <br>
- The only arguments required is to specify the basename of the .ti2
- file. If a non-default serial port is to be used, then the <span
- style="font-weight: bold;">-c</span> option would also be
- specified.<br>
- <br>
- e.g. for a Spectroscan on the second port:<br>
- <br>
- <a href="chartread.html">chartread</a> <a href="chartread.html#c">-c2</a>
- <a href="chartread.html#p1">PrinterA</a><br>
- <br>
- For a DTP41 to the default serial port:<br>
- <br>
- <a href="chartread.html">chartread</a><a href="chartread.html#i"></a>
- <a href="chartread.html#p1">PrinterA</a><br>
- <br>
- <span style="font-weight: bold;">chartread</span> will interactively
- prompt you through the process of reading each sheet or strip. See <a
- href="chartread.html">chartread</a> for more details on the
- responses for each type of instrument. Continue with <a
- href="Scenarios.html#PP5">Creating a printer profile</a>.<br>
- <br>
- <h4><a name="PP4"></a>Reading a print test chart using a scanner or
- camera<br>
- </h4>
- <br>
- Argyll supports using a scanner or even a camera as a substitute for
- a colorimeter. While a scanner or camera is no replacement for a
- color measurement instrument, it may give acceptable results in some
- situations, and may give better results than a generic profile for a
- printing device.<br>
- <br>
- The main limitation of the scanner-as-colorimeter approach are:<br>
- <br>
- * The scanner dynamic range and/or precision may not match the
- printers or what is required for a good profile.<br>
- * The spectral interaction of the scanner test chart and printer
- test chart with the scanner spectral response can cause color
- errors.<br>
- * Spectral differences caused by different black amounts in the
- print test chart can cause color errors. <br>
- * The scanner reference chart gamut may be much smaller than the
- printers gamut, making the scanner profile too inaccurate to be
- useful. <br>
- <br>
- As well as some of the above, a camera may not be suitable if it
- automatically adjusts exposure or white point when taking a picture,
- and this behavior cannot be disabled.<br>
- <br>
- The end result is often a profile that has a noticeable color cast,
- compared to a profile created using a colorimeter or spectrometer.<br>
- <br>
- <br>
- It is assumed that you have created a scanner or camera profile
- following the <a
- href="http://www.argyllcms.com/doc/Scenarios.html#PS1">procedure</a>
- outline above. For best possible results it is advisable to both
- profile the scanner or camera, and use it in scanning the printed
- test chart, in as "raw" mode as possible (i.e. using 16 bits per
- component images, if the scanner or camera is capable of doing so;
- not setting white or black points, using a fixed exposure etc.). It
- is generally advisable to create a LUT type input profile, and use
- the <a href="http://www.argyllcms.com/doc/colprof.html#u">-u</a>
- flag to avoid clipping scanned value whiter than the input
- calibration chart.<br>
- <br>
- Scan or photograph your printer chart (or charts) on the scanner or
+ + + + documentation</a>).<br> + <br> + To create the scanner .ti3 file, run the <b>scanin</b> tool as + follows (assuming an IT8 chart is being used):<br> + <br> + <a href="scanin.html"> scanin</a> -v scanner.tif It8.cht It8ref.txt<br> + <br> + "It8ref.txt" or "It8ref.cie" is assumed to be the name of the CIE + reference file supplied by the chart manufacturer. The resulting + file will be named "<b>scanner.ti3</b>".<br> + <br> + <span style="font-weight: bold;">scanin</span> will process 16 bit + per component .tiff files, which (if the scanner is capable of + creating such files), may improve the quality of the profile. + <br> + <br> + If you have any doubts about the correctness of the chart + recognition, or the subsequent profile's delta E report is unusual, + then use the scanin diagnostic flags <a href="scanin.html#d">-dipn</a> + and examine the <span style="font-weight: bold;">diag.tif</span> + diagnostic file, to make sure that the patches are identified and + aligned correctly. If you have problems getting good automatic + alignment, then consider doing a manual alignment by locating the + fiducial marks on your scan, and feeding them into scanin <a + href="scanin.html#F">-F</a> parameters. The fiducial marks should + be listed in a clockwise direction starting at the top left.<br> + <h4><a name="PS4"></a>Creating a scanner or camera input profile</h4> + Similar to a display profile, an input profile can be either a + shaper/matrix or LUT based profile. Well behaved input devices will + probably give the best results with a shaper/matrix profile, and + this may also be the best choice if your test chart has a small or + unevenly distributed set of test patchs (ie. the IT8.7.2). If a + shaper/matrix profile is a poor fit, consider using a LUT type + profile.<br> + <br> + When creating a LUT type profile, there is the choice of XYZ or + L*a*b* PCS (Device independent, Profile Connection Space). Often for + input devices, it is better to choose the XYZ PCS, as this may be a + better fit given that input devices are usually close to being + linearly additive in behaviour.<br> + <br> + If the purpose of the input profile is to use it as a substitute for + a colorimeter, then the <b>-u</b> flag should be used to avoid + clipping values above the white point. Unless the shaper/matrix type + profile is a very good fit, it is probably advisable to use a LUT + type profile in this situation.<br> + <br> + To create a matrix/shaper profile, the following suffices:<br> + <br> + <a href="colprof.html">colprof</a> <a href="colprof.html#v">-v</a> + <a href="colprof.html#E">-D"Scanner</a> <a href="colprof.html#E">A"</a> + <a href="colprof.html#q">-qm</a> <a href="colprof.html#a">-as</a> <a + href="colprof.html#p1">scanner</a><br> + <br> + For an XYZ PCS LUT based profile then the following would be used:<br> + <br> + <a href="colprof.html">colprof</a> <a href="colprof.html#v">-v</a> + <a href="colprof.html#E">-D"Scanner A"</a> <a href="colprof.html#q">-qm</a> + <a href="colprof.html#a">-ax</a> <a href="colprof.html#p1">scanner</a><br> + <br> + For the purposes of a poor mans colorimeter, the following would + generally be used:<br> + <br> + <a href="colprof.html">colprof</a> <a href="colprof.html#v">-v</a> + <a href="colprof.html#E">-D"Scanner A"</a> <a href="colprof.html#q">-qm</a> + <a href="colprof.html#a">-ax</a> <a href="colprof.html#u">-u</a> <a + href="colprof.html#p1">scanner</a><br> + <br> + Make sure you check the delta E report at the end of the profile + creation, to see if the sample data and profile is behaving + reasonably. Depending on the type of device, and the consistency of + the readings, average errors of 5 or less, and maximum errors of 15 + or less would normally be expected. If errors are grossly higher + than this, then this is an indication that something is seriously + wrong with the device measurement, or profile creation.<br> + <br> + If profiling a <span style="font-weight: bold;">camera</span> in <span + style="font-weight: bold;">RAW</span> mode, then there may be some + advantage in creating a pure matrix only profile, in which it is + assumed that the camera response is completely linear. This may + reduce extrapolation artefacts. If setting the white point will be + done in some application, then it may also be an advantage to use + the <span style="font-weight: bold;">-u</span> flag and avoid + setting the white point to that of the profile chart:<br> + <br> + <a href="colprof.html">colprof</a> <a href="colprof.html#v">-v</a> + <a href="colprof.html#E">-D"Camera"</a> <a href="colprof.html#q">-qm</a> + <a href="colprof.html#a">-am</a> <a href="colprof.html#u">-u</a> <a + href="colprof.html#p1">scanner</a><br> + <br> + <br> + <hr size="2" width="100%"> + <h3><a name="PP1"></a>Profiling Printers<br> + </h3> + The overall process is to create a set of device measurement target + values, print them out, measure them, and then create an ICC profile + from the measurements. If the printer is an RGB based printer, then + the process is only slightly more complicated than profiling a + display. If the printer is CMYK based, then some additional + parameters are required to set the total ink limit (TAC) and + black generation curve.<br> + <h4><a name="PP2"></a>Creating a print profile test chart</h4> + The first step in profiling any output device, is to create a set of + device colorspace test values. The important parameters needed are:<br> + <ul> + <li>What colorspace does the device use ?</li> + <li>How many test patches do I want to use/what paper size do I + want to use ?</li> + <li>What instrument am I going to use to read the patches ?<br> + </li> + <li>If it is a CMYK device, what is the total ink limit ?<br> + </li> + <li>What information do I already have about how the device + behaves ?</li> + </ul> + Most printers running through simple drivers will appear as if they + are RGB devices. In fact there is no such thing as a real RGB + printer, since printers use white media and the colorant must + subtract from the light reflected on it to create color, but the + printer itself turns the incoming RGB into the native print + colorspace, so for this reason we will tell targen to use the "Print + RGB" colorspace, so that it knows that it's really a subtractive + media. Other drivers will drive a printer more directly, and will + expect a CMYK profile. [Currently Argyll is not capable of creating + an ICC profile for devices with more colorants than CMYK. When this + capability is introduced, it will by creating an additional + separation profile which then allows the printer to be treated as a + CMY or CMYK printer.] One way of telling what sort of profile is + expected for your device is to examine an existing profile for that + device using <a href="http://www.argyllcms.com/doc/iccdump.html">iccdump</a>.<br> + <br> + The number of test patches will depend somewhat on what quality + profile you want to make, how well behaved the printer is, as well + as the effort needed to read the number of test values. Generally it + is convenient to fill a certain paper size with the maximum number + of test values that will fit.<br> + <br> + At a minimum, for an "RGB" device, a few hundred values are needed + (400-1000). For high quality CMYK profiles, 1000-3000 is not an + unreasonable number of patches.<br> + <br> + To assist the determination of test patch values, it can help to + have a rough idea of how the device behaves, so that the device test + point locations can be pre-conditioned. This could be in the form of + an ICC profile of a similar device, or a lower quality, or previous + profile for that particular device. If one were going to make a very + high quality Lut based profile, then it might be worthwhile to make + up a smaller, preliminary shaper/matrix profile using a few hundred + test points, before embarking on testing the device with several + thousand.<br> + <br> + The documentation for the <a + href="http://www.argyllcms.com/doc/targen.html">targen</a> tool + lists a <a href="http://www.argyllcms.com/doc/targen.html#Table">table</a> + of paper sizes and number of patches for typical situations.<br> + <br> + For a CMYK device, a total ink limit usually needs to be specified. + Sometimes a device will have a maximum total ink limit set by its + manufacturer or operator, and some CMYK systems (such as chemical + proofing systems) don't have any limit. Typical printing devices + such as Xerographic printers, inkjet printers and printing presses + will have a limit. The exact procedure for determining an ink limit + is outside the scope of this document, but one way of going about + this might be to generate some small (say a few hundred patches) + with targen & pritntarg with different total ink limits, and + printing them out, making the ink limit as large as possible without + striking problems that are caused by too much ink.<br> + <br> + Generally one wants to use the maximum possible amount of ink to + maximize the gamut available on the device. For most CMYK devices, + an ink limit between 200 and 400 is usual, but and ink limit of 250% + or over is generally desirable for reasonably dense blacks and dark + saturated colors. And ink limit of less than 200% will begin to + compromise the fully saturated gamut, as secondary colors (ie + combinations of any two primary colorants) will not be able to reach + full strength.<br> + <br> + Once an ink limit is used in printing the characterization test + chart for a device, it becomes a critical parameter in knowing what + the characterized gamut of the device is. If after printing the test + chart, a greater ink limit were to be used, the the software would + effectively be extrapolating the device behaviour at total ink + levels beyond that used in the test chart, leading to inaccuracies.<br> + <br> + Generally in Argyll, the ink limit is established when creating the + test chart values, and then carried through the profile making + process automatically. Once the profile has been made however, the + ink limit is no longer recorded, and you, the user, will have to + keep track of it if the ICC profile is used in any program than + needs to know the usable gamut of the device.<br> + <br> + <br> + Lets consider two devices in our examples, "PrinterA" which is an + "RGB" device, and "PrinterB" which is CMYK, and has a target ink + limit of 250%. <br> + <br> + The simplest approach is to make a set of test values that is + independent of the characteristics of the particular device:<br> + <br> + <a href="targen.html">targen</a> <a href="targen.html#v">-v</a> + <a href="targen.html#d">-d2</a> <a href="targen.html#f">-f1053</a> + <a href="targen.html#p1">PrinterA</a><br> + <br> + <a href="targen.html">targen</a> <a href="targen.html#v">-v</a> + <a href="targen.html#d">-d4</a> <a href="targen.html#l">-l260</a> + <a href="targen.html#f">-f1053</a> <a href="targen.html#p1">PrinterB</a><br> + <br> + The number of patches chosen here happens to be right for an A4 + paper size being read using a Spectroscan instrument. See the <a + href="targen.html#Table">table</a> in the <a + href="targen.html">targen</a> documentation for some other + suggested numbers.<br> + <br> + If there is a preliminary or previous profile called "OldPrinterA" + available, and we want to try creating a "pre-conditioned" set of + test values that will more efficiently sample the device response, + then the following would achieve this:<u><br> + </u><br> + <a href="targen.html">targen</a> <a href="targen.html#v">-v</a> + <a href="targen.html#d">-d2</a> <a href="targen.html#f">-f1053</a> + <a href="targen.html#c">-c OldPrinterA</a> <a + href="targen.html#p1">PrinterA</a><br> + <br> + <a href="targen.html">targen</a> <a href="targen.html#v">-v</a> + <a href="targen.html#d">-d4</a> <a href="targen.html#l">-l260</a> + <a href="targen.html#f">-f1053</a> <a href="targen.html#c">-c + OldPrinterB</a> <a href="targen.html#p1">PrinterB</a><br> + <a href="targen.html#p1"></a><br> + <br> + The output of <b>targen</b> will be the file PrinterA.ti1 and + PrinterB.ti1 respectively, containing the device space test values, + as well as expected CIE values used for chart recognition purposes.<br> + <br> + <h4><a name="PP2b"></a>Printing a print profile test chart<br> + <br> + </h4> + The next step is turn the test values in to a PostScript or TIFF + raster test file that can printed on the device. The basic + information that needs to be supplied is the type of instrument that + will be used to read the patches, as well as the paper size it is to + be formatted for.<br> + <br> + For an X-Rite DTP41, the following would be typical:<br> + <br> + <a href="printtarg.html">printtarg</a> <a href="printtarg.html#v">-v</a> + <a href="printtarg.html#i">-i41</a> <a href="printtarg.html#p">-pA4</a> + <a href="printtarg.html#p1">PrinterA</a><br> + <br> + For a Gretag Eye-One Pro, the following would be typical:<br> + <br> + <a href="printtarg.html">printtarg</a> <a href="printtarg.html#v">-v</a> + <a href="printtarg.html#i">-ii1</a> <a href="printtarg.html#p">-pA4</a> + <a href="printtarg.html#p1">PrinterA</a><br> + <br> + For using with a scanner as a colorimeter, the Gretag Spectroscan + layout is suitable, but the <a href="printtarg.html#s">-s</a> flag + should be used so as to generate a layout suitable for scan + recognition, as well as generating the scan recognition template + files. (You probably want to use less patches with <span + style="font-weight: bold;">targen</span>, when using the <span + style="font-weight: bold;">printtarg -s</span> flag, e.g. 1026 + patches for an A4R page, etc.) The following would be typical:<br> + <br> + <a href="printtarg.html">printtarg</a> <a href="printtarg.html#v">-v</a> + <a href="printtarg.html#s">-s</a> <a href="printtarg.html#i">-iSS</a> + <a href="printtarg.html#p">-pA4R</a> <a href="printtarg.html#p1">PrinterA</a><br> + <span style="font-weight: bold;"><br> + printtarg</span> reads the PrinterA.ti1 file, creates a + PrinterA.ti2 file containing the layout information as well as the + device values and expected CIE values, as well as a PrinterA.ps file + containing the test chart. If the <span style="font-weight: bold;">-s</span> + flag is used, one or more PrinterA.cht files is created to allow the + <a href="scanin.html">scanin</a> program to recognize the chart.<br> + <br> + To create TIFF raster files rather than PostScript, use the <a + href="printtarg.html#t"><span style="font-weight: bold;">-t</span></a> + flag.<br> + <br> + <span style="font-weight: bold;">GSview</span> is a good program to + use to check what the PostScript file will look like, without + actually printing it out. You could also use <span + style="font-weight: bold;">Photoshop</span> or <span + style="font-weight: bold;">ImageMagick</span> for this purpose.<br> + <br> + The last step is to print the chart out.<br> + <br> + Using a suitable PostScript or raster file printing program, + downloader, print the chart. If you are not using a TIFF test chart, + and you do not have a PostScript capable printer, then an + interpreter like GhostScript or even Photoshop could be used to + rasterize the file into something that can be printed. Note that it + is important that the PostScript interpreter or TIFF printing + application and printer configuration is setup for a device + profiling run, and that any sort of color conversion of color + correction be turned off so that the device values in the PostScript + or TIFF file are sent directly to the device. If the device has a + calibration system, then it would be usual to have setup and + calibrated the device before starting the profiling run, and to + apply calibration to the chart values. If Photoshop was to be used, + then either the chart needs to be a single page, or separate .eps or + .tiff files for each page should be used, so that they can be + converted and printed one at a time (see the <a + href="printtarg.html#e">-e</a> and <a href="printtarg.html#t">-t</a> + flags).<br> + <br> + <h4><a name="PP3"></a>Reading a print test chart using an instrument</h4> + Once the test chart has been printed, the color of the patches needs + to be read using a suitable instrument.<br> + <br> + Several different instruments are currently supported, some that + need to be used patch by patch, some read a strip at a time, and + some read a sheet at a time. See <a href="instruments.html">instruments</a> + for a current list.<br> + <br> + The instrument needs to be connected to your computer before running + the <a href="chartread.html">chartread</a> command. Both serial + port and USB connected Instruments are supported. A serial port to + USB adapter might have to be used if your computer doesn't have any + serial ports, and you have a serial interface connected instrument.<br> + <br> + If you run <a href="chartread.html">chartread</a> so as to print + out its usage message (ie. by using a <span style="font-weight: + bold;">-?</span> or <span style="font-weight: bold;">--</span> + flags), then it will list any identified serial ports or USB + connected instruments, and their corresponding number for the <a + href="chartread.html#c">-c</a> option. By default, <a + href="chartread.html">chartread</a> will try to connect to the + first available USB instrument, or an instrument on the first serial + port.<br> + <br> + The only arguments required is to specify the basename of the .ti2 + file. If a non-default serial port is to be used, then the <span + style="font-weight: bold;">-c</span> option would also be + specified.<br> + <br> + e.g. for a Spectroscan on the second port:<br> + <br> + <a href="chartread.html">chartread</a> <a href="chartread.html#c">-c2</a> + <a href="chartread.html#p1">PrinterA</a><br> + <br> + For a DTP41 to the default serial port:<br> + <br> + <a href="chartread.html">chartread</a><a href="chartread.html#i"></a> + <a href="chartread.html#p1">PrinterA</a><br> + <br> + <span style="font-weight: bold;">chartread</span> will interactively + prompt you through the process of reading each sheet or strip. See <a + href="chartread.html">chartread</a> for more details on the + responses for each type of instrument. Continue with <a + href="Scenarios.html#PP5">Creating a printer profile</a>.<br> + <br> + <h4><a name="PP4"></a>Reading a print test chart using a scanner or + camera<br> + </h4> + <br> + Argyll supports using a scanner or even a camera as a substitute for + a colorimeter. While a scanner or camera is no replacement for a + color measurement instrument, it may give acceptable results in some + situations, and may give better results than a generic profile for a + printing device.<br> + <br> + The main limitation of the scanner-as-colorimeter approach are:<br> + <br> + * The scanner dynamic range and/or precision may not match the + printers or what is required for a good profile.<br> + * The spectral interaction of the scanner test chart and printer + test chart with the scanner spectral response can cause color + errors.<br> + * Spectral differences caused by different black amounts in the + print test chart can cause color errors. <br> + * The scanner reference chart gamut may be much smaller than the + printers gamut, making the scanner profile too inaccurate to be + useful. <br> + <br> + As well as some of the above, a camera may not be suitable if it + automatically adjusts exposure or white point when taking a picture, + and this behavior cannot be disabled.<br> + <br> + The end result is often a profile that has a noticeable color cast, + compared to a profile created using a colorimeter or spectrometer.<br> + <br> + <br> + It is assumed that you have created a scanner or camera profile + following the <a + href="http://www.argyllcms.com/doc/Scenarios.html#PS1">procedure</a> + outline above. For best possible results it is advisable to both + profile the scanner or camera, and use it in scanning the printed + test chart, in as "raw" mode as possible (i.e. using 16 bits per + component images, if the scanner or camera is capable of doing so; + not setting white or black points, using a fixed exposure etc.). It + is generally advisable to create a LUT type input profile, and use + the <a href="http://www.argyllcms.com/doc/colprof.html#u">-u</a> + flag to avoid clipping scanned value whiter than the input + calibration chart.<br> + <br> + Scan or photograph your printer chart (or charts) on the scanner or camera previously profiled. <big><span style="font-weight: bold;">The @@ -1868,98 +1906,100 @@ href="http://www.xrite.com/documents/apps/public/digital_colorchecker_sg_l_a_b.t -
- scanner or camera must be configured and used exactly the same
- as it was when it was profiled.</span></big><br>
- <br>
- I will assume the resulting scan/photo input file is called <span
- style="font-weight: bold;">PrinterB.tif</span> (or <span
- style="font-weight: bold;">PrinterB1.tif</span>, <span
- style="font-weight: bold;">PrinterB2.tif</span> etc. in the case
- of multiple charts). As with profiling the scanner or camera, the
- raster file need only be roughly cropped so as to contain the test
- chart.<br>
- <br>
- The scanner recognition files created when <span
- style="font-weight: bold;">printtarg</span> was run is assumed to
- be called <span style="font-weight: bold;">PrinterB.cht</span>.
- Using the scanner profile created previously (assumed to be called <span
- style="font-weight: bold;">scanner.icm</span>), the printer test
- chart scan patches are converted to CIE values using the <span
- style="font-weight: bold;">scanin</span> tool:<br>
- <br>
- <a href="scanin.html">scanin</a> <a href="scanin.html#v">-v</a> <a
- href="scanin.html#c">-c</a> <a href="scanin.html#cp1">PrinterB.tif</a>
- <a href="scanin.html#cp2">PrinterB.cht</a> <a
- href="scanin.html#cp3">scanner.icm</a> <a href="scanin.html#cp4">PrinterB</a><br>
- <br>
- If there were multiple test chart pages, the results would be
- accumulated page by page using the <a href="scanin.html#ca">-ca</a>
- option, ie., if there were 3 pages:<br>
- <br>
- <a href="scanin.html">scanin</a> <a href="scanin.html#v">-v</a> <a
- href="scanin.html#c">-c</a> <a href="scanin.html#cp1">PrinterB1.tif</a>
- <a href="scanin.html#cp2">PrinterB1.cht</a> <a
- href="scanin.html#cp3">scanner.icm</a> <a href="scanin.html#cp4">PrinterB</a><br>
- <a href="scanin.html">scanin</a> <a href="scanin.html#v">-v</a> <a
- href="scanin.html#ca">-ca</a> <a href="scanin.html#cp1">PrinterB2.tif</a>
- <a href="scanin.html#cp2">PrinterB2.cht</a> <a
- href="scanin.html#cp3">scanner.icm</a> <a href="scanin.html#cp4">PrinterB</a><br>
- <a href="scanin.html">scanin</a> <a href="scanin.html#v">-v</a> <a
- href="scanin.html#ca">-ca</a> <a href="scanin.html#cp1">PrinterB3.tif</a>
- <a href="scanin.html#cp2">PrinterB3.cht</a> <a
- href="scanin.html#cp3">scanner.icm</a> <a href="scanin.html#cp4">PrinterB</a><br>
- <br>
- Now that the <span style="font-weight: bold;">PrinterB.ti3</span>
- data has been obtained, the profile continue in the next section
- with <span style="font-weight: bold;">Creating a printer profile</span>.<br>
- <br>
- If you have any doubts about the correctness of the chart
- recognition, or the subsequent profile's delta E report is unusual,
- then use the scanin diagnostic flags <a href="scanin.html#d">-dipn</a>
- and examine the <span style="font-weight: bold;">diag.tif</span>
- diagnostic file.<br>
- <h4><a name="PP5"></a>Creating a printer profile<br>
- </h4>
- Creating an RGB based printing profile is very similar to creating a
- display device profile. For a CMYK printer, some additional
- information is needed to set the black generation.<br>
- <br>
- Where the resulting profile will be used conventionally (ie. using <a
- href="collink.html">collink</a> <a href="collink.html#s">-s</a>,
- or <a href="cctiff.html">cctiff</a> or most other "dumb" CMMs) it
- is important to specify that gamut mapping should be computed for
- the output (B2A) perceptual and saturation tables. This is done by
- specifying a device profile as the parameter to the <a
- href="colprof.html">colprof</a> <a href="colprof.html#S">-S</a>
- flag. When you intend to create a "general use" profile, it can be a
- good technique to specify the source gamut as the opposite type of
- profile to that being created, i.e. if a printer profile is being
- created, specify a display profile (e.g. sRGB) as the source gamut.
- If a display profile is being created, then specify a printer
- profile as the source (e.g. Figra, SWOP etc.). When linking to
- the profile you have created this way as the output profile, then
- use perceptual intent if the source is the opposite type, and
- relative colorimetric if it is the same type.<br>
- <br>
- "Opposite type of profile" refers to the native gamut of the device,
- and what its fundamental nature is, additive or subtractive. An
- emissive display will have additive primaries (R, G & B), while
- a reflective print, will have subtractive primaries (C, M, Y &
- possibly others), irrespective of what colorspace the printer is
- driven in (a printer might present an RGB interface, but internally
- this will be converted to CMY, and it will have a CMY type of
- gamut). Because of the complimentary nature of additive and
- subtractive device primary colorants, these types of devices have
- the most different gamuts, and hence need the most gamut mapping to
- convert from one colorspace to the other.<br>
- <br>
- If you are creating a profile for a specific purpose, intending to
- link it to a specific input profile, then you will get the best
- results by specifying that source profile as the source gamut.<br>
- <br>
- If a profile is only going to be used as an input profile, or is
- going to be used with a "smart" CMM (e.g. <a href="collink.html">collink</a>
+ + + + scanner or camera must be configured and used exactly the same + as it was when it was profiled.</span></big><br> + <br> + I will assume the resulting scan/photo input file is called <span + style="font-weight: bold;">PrinterB.tif</span> (or <span + style="font-weight: bold;">PrinterB1.tif</span>, <span + style="font-weight: bold;">PrinterB2.tif</span> etc. in the case + of multiple charts). As with profiling the scanner or camera, the + raster file need only be roughly cropped so as to contain the test + chart.<br> + <br> + The scanner recognition files created when <span + style="font-weight: bold;">printtarg</span> was run is assumed to + be called <span style="font-weight: bold;">PrinterB.cht</span>. + Using the scanner profile created previously (assumed to be called <span + style="font-weight: bold;">scanner.icm</span>), the printer test + chart scan patches are converted to CIE values using the <span + style="font-weight: bold;">scanin</span> tool:<br> + <br> + <a href="scanin.html">scanin</a> <a href="scanin.html#v">-v</a> <a + href="scanin.html#c">-c</a> <a href="scanin.html#cp1">PrinterB.tif</a> + <a href="scanin.html#cp2">PrinterB.cht</a> <a + href="scanin.html#cp3">scanner.icm</a> <a href="scanin.html#cp4">PrinterB</a><br> + <br> + If there were multiple test chart pages, the results would be + accumulated page by page using the <a href="scanin.html#ca">-ca</a> + option, ie., if there were 3 pages:<br> + <br> + <a href="scanin.html">scanin</a> <a href="scanin.html#v">-v</a> <a + href="scanin.html#c">-c</a> <a href="scanin.html#cp1">PrinterB1.tif</a> + <a href="scanin.html#cp2">PrinterB1.cht</a> <a + href="scanin.html#cp3">scanner.icm</a> <a href="scanin.html#cp4">PrinterB</a><br> + <a href="scanin.html">scanin</a> <a href="scanin.html#v">-v</a> <a + href="scanin.html#ca">-ca</a> <a href="scanin.html#cp1">PrinterB2.tif</a> + <a href="scanin.html#cp2">PrinterB2.cht</a> <a + href="scanin.html#cp3">scanner.icm</a> <a href="scanin.html#cp4">PrinterB</a><br> + <a href="scanin.html">scanin</a> <a href="scanin.html#v">-v</a> <a + href="scanin.html#ca">-ca</a> <a href="scanin.html#cp1">PrinterB3.tif</a> + <a href="scanin.html#cp2">PrinterB3.cht</a> <a + href="scanin.html#cp3">scanner.icm</a> <a href="scanin.html#cp4">PrinterB</a><br> + <br> + Now that the <span style="font-weight: bold;">PrinterB.ti3</span> + data has been obtained, the profile continue in the next section + with <span style="font-weight: bold;">Creating a printer profile</span>.<br> + <br> + If you have any doubts about the correctness of the chart + recognition, or the subsequent profile's delta E report is unusual, + then use the scanin diagnostic flags <a href="scanin.html#d">-dipn</a> + and examine the <span style="font-weight: bold;">diag.tif</span> + diagnostic file.<br> + <h4><a name="PP5"></a>Creating a printer profile<br> + </h4> + Creating an RGB based printing profile is very similar to creating a + display device profile. For a CMYK printer, some additional + information is needed to set the black generation.<br> + <br> + Where the resulting profile will be used conventionally (ie. using <a + href="collink.html">collink</a> <a href="collink.html#s">-s</a>, + or <a href="cctiff.html">cctiff</a> or most other "dumb" CMMs) it + is important to specify that gamut mapping should be computed for + the output (B2A) perceptual and saturation tables. This is done by + specifying a device profile as the parameter to the <a + href="colprof.html">colprof</a> <a href="colprof.html#S">-S</a> + flag. When you intend to create a "general use" profile, it can be a + good technique to specify the source gamut as the opposite type of + profile to that being created, i.e. if a printer profile is being + created, specify a display profile (e.g. sRGB) as the source gamut. + If a display profile is being created, then specify a printer + profile as the source (e.g. Figra, SWOP etc.). When linking to + the profile you have created this way as the output profile, then + use perceptual intent if the source is the opposite type, and + relative colorimetric if it is the same type.<br> + <br> + "Opposite type of profile" refers to the native gamut of the device, + and what its fundamental nature is, additive or subtractive. An + emissive display will have additive primaries (R, G & B), while + a reflective print, will have subtractive primaries (C, M, Y & + possibly others), irrespective of what colorspace the printer is + driven in (a printer might present an RGB interface, but internally + this will be converted to CMY, and it will have a CMY type of + gamut). Because of the complimentary nature of additive and + subtractive device primary colorants, these types of devices have + the most different gamuts, and hence need the most gamut mapping to + convert from one colorspace to the other.<br> + <br> + If you are creating a profile for a specific purpose, intending to + link it to a specific input profile, then you will get the best + results by specifying that source profile as the source gamut.<br> + <br> + If a profile is only going to be used as an input profile, or is + going to be used with a "smart" CMM (e.g. <a href="collink.html">collink</a> <a href="collink.html#g">-g</a> or <a href="collink.html#G">-G</a>), then @@ -2018,83 +2058,85 @@ then -
- it can save considerable processing time and space if the -b flag is
- used, and the -S flag not used.<br>
- <br>
- For an RGB printer intended to print RGB originals, the following
- might be a typical profile usage:<br>
- <br>
- <a href="colprof.html">colprof</a> <a href="colprof.html#v">-v</a>
- <a href="colprof.html#E">-D"Printer A"</a> <a href="colprof.html#q">-qm</a>
- <a href="colprof.html#S">-S</a><a href="colprof.html#S"> sRGB.icm</a>
- <a href="colprof.html#c">-cmt</a> <a href="colprof.html#d">-dpp</a>
- <a href="colprof.html#p1">PrinterA</a><br>
- <br>
- or if you intent to print from Fogra, SWOP or other standard CMYK
- style originals:<br>
- <br>
- <a href="colprof.html">colprof</a> <a href="colprof.html#v">-v</a>
- <a href="colprof.html#E">-D"Printer A"</a> <a href="colprof.html#q">-qm</a>
- <a href="colprof.html#S">-S</a><a href="colprof.html#S">
- fogra39l.icm</a> <a href="colprof.html#c">-cmt</a> <a
- href="colprof.html#d">-dpp</a> <a href="colprof.html#p1">PrinterA</a><br>
- <br>
- If you know what colorspace your originals are in, use that as the
- argument to <span style="font-weight: bold;">-S</span>.<br>
- <br>
- If your viewing environment for the display and print doesn't match
- the ones implied by the <a href="colprof.html#c">-cmt</a> and <a
- href="colprof.html#d">-dpp</a> options, leave them out, and
- evaluate what, if any appearance transformation is appropriate for
- your environment at a later stage.<br>
- <br>
- Make sure you check the delta E report at the end of the profile
- creation, to see if the sample data and profile is behaving
- reasonably. Depending on the type of device, and the consistency of
- the readings, average errors of 5 or less, and maximum errors of 15
- or less would normally be expected. If errors are grossly higher
- than this, then this is an indication that something is seriously
- wrong with the device measurement, or profile creation.
- <h4><a name="PP6"></a>Choosing a black generation curve (and other
- CMYK printer options)<br>
- </h4>
- For a CMYK printer, it would be normal to specify the type of black
- generation, either as something simple, or as a specific curve. The
- documentation in <a href="colprof.html#k">colprof</a> for the
- details of the options.<span style="font-weight: bold;"><br>
- <br>
- Note</span> that making a good choice of black generation curve
- can affect things such as: how robust neutrals are given printer
- drift or changes in viewing lighting, how visible screening is, and
- how smooth looking the B2A conversion is.<br>
- <br>
- For instance, maximizing the level of K will mean that the neutral
- colors are composed of greater amounts of Black ink, and black ink
- retains its neutral appearance irrespective of printer behavior or
- the spectrum of the illuminant used to view the print. On the other
- hand, output which is dominantly from one of the color channels will
- tend to emphasize the screening pattern and any unevenness (banding
- etc.) of that channel, and the black channel in particular has the
- highest visibility. So in practice, some balance between the levels
- of the four channels is probably best, with more K if the screening
- is fine and a robust neutral balance is important, or less K if the
- screening is more visible and neutral balance is less critical. The
- levels of K at the edges of the gamut of the device will be fixed by
- the nature of the ink combinations that maximize the gamut (ie.
- typically zero ink for light chromatic colors, some combination for
- dark colors, and a high level of black for very dark near neutrals),
- and it is also usually important to set a curve that smoothly
- transitions to the K values at the gamut edges. Dramatic changes in
- K imply equally dramatic changes in CMY, and these abrupt
- transitions will reveal the limited precision and detail that can be
- captured in a lookup table based profile, often resulting in a
- "bumpy" looking output.<br>
- <br>
- If you want to experiment with the various black generation
- parameters, then it might be a good idea to create a preliminary
- profile (using <a href="colprof.html#q">-ql</a> <a
- href="colprof.html#b">-b</a> <a href="colprof.html#ni">-no</a>, <a
+ + + + it can save considerable processing time and space if the -b flag is + used, and the -S flag not used.<br> + <br> + For an RGB printer intended to print RGB originals, the following + might be a typical profile usage:<br> + <br> + <a href="colprof.html">colprof</a> <a href="colprof.html#v">-v</a> + <a href="colprof.html#E">-D"Printer A"</a> <a href="colprof.html#q">-qm</a> + <a href="colprof.html#S">-S</a><a href="colprof.html#S"> sRGB.icm</a> + <a href="colprof.html#c">-cmt</a> <a href="colprof.html#d">-dpp</a> + <a href="colprof.html#p1">PrinterA</a><br> + <br> + or if you intent to print from Fogra, SWOP or other standard CMYK + style originals:<br> + <br> + <a href="colprof.html">colprof</a> <a href="colprof.html#v">-v</a> + <a href="colprof.html#E">-D"Printer A"</a> <a href="colprof.html#q">-qm</a> + <a href="colprof.html#S">-S</a><a href="colprof.html#S"> + fogra39l.icm</a> <a href="colprof.html#c">-cmt</a> <a + href="colprof.html#d">-dpp</a> <a href="colprof.html#p1">PrinterA</a><br> + <br> + If you know what colorspace your originals are in, use that as the + argument to <span style="font-weight: bold;">-S</span>.<br> + <br> + If your viewing environment for the display and print doesn't match + the ones implied by the <a href="colprof.html#c">-cmt</a> and <a + href="colprof.html#d">-dpp</a> options, leave them out, and + evaluate what, if any appearance transformation is appropriate for + your environment at a later stage.<br> + <br> + Make sure you check the delta E report at the end of the profile + creation, to see if the sample data and profile is behaving + reasonably. Depending on the type of device, and the consistency of + the readings, average errors of 5 or less, and maximum errors of 15 + or less would normally be expected. If errors are grossly higher + than this, then this is an indication that something is seriously + wrong with the device measurement, or profile creation. + <h4><a name="PP6"></a>Choosing a black generation curve (and other + CMYK printer options)<br> + </h4> + For a CMYK printer, it would be normal to specify the type of black + generation, either as something simple, or as a specific curve. The + documentation in <a href="colprof.html#k">colprof</a> for the + details of the options.<span style="font-weight: bold;"><br> + <br> + Note</span> that making a good choice of black generation curve + can affect things such as: how robust neutrals are given printer + drift or changes in viewing lighting, how visible screening is, and + how smooth looking the B2A conversion is.<br> + <br> + For instance, maximizing the level of K will mean that the neutral + colors are composed of greater amounts of Black ink, and black ink + retains its neutral appearance irrespective of printer behavior or + the spectrum of the illuminant used to view the print. On the other + hand, output which is dominantly from one of the color channels will + tend to emphasize the screening pattern and any unevenness (banding + etc.) of that channel, and the black channel in particular has the + highest visibility. So in practice, some balance between the levels + of the four channels is probably best, with more K if the screening + is fine and a robust neutral balance is important, or less K if the + screening is more visible and neutral balance is less critical. The + levels of K at the edges of the gamut of the device will be fixed by + the nature of the ink combinations that maximize the gamut (ie. + typically zero ink for light chromatic colors, some combination for + dark colors, and a high level of black for very dark near neutrals), + and it is also usually important to set a curve that smoothly + transitions to the K values at the gamut edges. Dramatic changes in + K imply equally dramatic changes in CMY, and these abrupt + transitions will reveal the limited precision and detail that can be + captured in a lookup table based profile, often resulting in a + "bumpy" looking output.<br> + <br> + If you want to experiment with the various black generation + parameters, then it might be a good idea to create a preliminary + profile (using <a href="colprof.html#q">-ql</a> <a + href="colprof.html#b">-b</a> <a href="colprof.html#ni">-no</a>, <a href="colprof.html#no">-ni</a> and no <a href="colprof.html#S">-S</a>), @@ -2151,407 +2193,409 @@ then -
- and then used <a href="xicclu.html#g">xicclu</a> to explore the
- effect of the parameters.<br>
- <br>
- For instance, say we have our CMYK .ti3 file <span
- style="font-weight: bold;">PrinterB.ti3</span>. First we make a
- preliminary profile called <span style="font-weight: bold;">PrinterBt</span>:<br>
- <br>
- copy PrinterB.ti3 PrinterBt.ti3 (Use
- "cp" on Linux or OSX of course.)<br>
- <a href="colprof.html">colprof</a> <a href="colprof.html#v">-v</a>
- <a href="colprof.html#q">-qm</a> <a href="colprof.html#b">-b</a> <a
- href="colprof.html#c">-cmt</a> <a href="colprof.html#d">-dpp</a>
- <a href="colprof.html#p1">PrinterBt</a><br>
- <br>
- Then see what the minimum black level down the neutral axis can be.
- Note that we need to also set any ink limits we've decided on as
- well (coloprof defaulting to 10% less than the value recorded in the
- .ti3 file). In this example the test chart has a 300% total ink
- limit, and we've decided to use 290%:<br>
- <br>
- <a href="xicclu.html">xicclu</a> <a href="xicclu.html#g">-g</a> <a
- href="xicclu.html#k">-kz</a> <a href="xicclu.html#l">-l290</a> <a
- href="xicclu.html#f">-fif</a> <a href="xicclu.html#i">-ir</a> <a
- href="xicclu.html#p1">PrinterBt.icm</a><br>
- <br>
- Which might be a graph something like this:<br>
- <br>
- <img alt="Graph of CMYK neutral axis with minimum K"
- src="Kgraph1.jpg" style="width: 250px; height: 250px;"><br>
- <br>
- Note how the minimum black is zero up to 93% of the
- white->black L* curve, and then jumps up to 87%. This is because
- we've reached the total ink limit, and K then has to be substituted
- for CMY, to keep the total under the total ink limit.<br>
- <br>
- Then let's see what the maximum black level down the neutral axis
- can be:<br>
- <br>
- <a href="xicclu.html">xicclu</a> <a href="xicclu.html#g">-g</a> <a
- href="xicclu.html#k">-kx</a> <a href="xicclu.html#l">-l290</a> <a
- href="xicclu.html#f">-fif</a> <a href="xicclu.html#i">-ir</a> <a
- href="xicclu.html#p1">PrinterBt.icm</a><br>
- <br>
- Which might be a graph something like this:<br>
- <br>
- <img alt="Graph of CMYK neutral axis with maximum K"
- src="Kgraph2.jpg" style="width: 250px; height: 250px;"><br>
- <br>
- Note how the CMY values are fairly low up to 93% of the
- white->black L* curve (the low levels of CMY are helping set the
- neutral color), and then they jump up. This is because we've reach
- the point where black on it's own, isn't as dark as the color that
- can be achieved using CMY and K. Because the K has a dominant effect
- on the hue of the black, the levels of CMY are often fairly volatile
- in this region.<br>
- <br>
- Any K curve we specify must lie between the black curves of the
- above two graphs.<br>
- <br>
- Let's say we'd like to chose a moderate black curve, one that aims
- for about equal levels of CMY and K. We should also aim for it to be
- fairly smooth, since this will minimize visual artefacts caused by
- the limited fidelity that profile LUT tables are able to represent
- inside the profile.<br>
- <br>
- <img style="width: 340px; height: 258px;" alt="-k parameters"
- src="Kparams.jpg"><br>
- <br>
- <br>
- For minimum discontinuities we should aim for the curve to finish at
- the point it has to reach to satisfy the total ink limit at 87%
- curve and 93% black. For a first try we can simply set a straight
- line to that point: <br>
- <br>
- <a href="xicclu.html">xicclu</a> <a href="xicclu.html#g">-g</a> <a
- href="xicclu.html#k">-kp 0 0 .93 .87 1.0</a> <a
- href="xicclu.html#l">-l290</a> <a href="xicclu.html#f">-fif</a> <a
- href="xicclu.html#i">-ir</a> <a href="xicclu.html#p1">PrinterBt.icm</a><br>
- <br>
- <img alt="Graph of CMYK neutral axis with kp 0 0 1.0 1.0 1.0 -l290"
- src="Kgraph3.jpg" style="width: 250px; height: 250px;"><br>
- <br>
- The black "curve" hits the 93%/87% mark well, but is a bit too far
- above CMY, so we'll try making the black curve concave:<br>
- <br>
- <a href="xicclu.html">xicclu</a> <a href="xicclu.html#g">-g</a> <a
- href="xicclu.html#k">-kp </a><a href="xicclu.html#k">0 0 .93 .87
- 0.65</a> <a href="xicclu.html#l">-l290</a> <a
- href="xicclu.html#f">-fif</a> <a href="xicclu.html#i">-ir</a> <a
- href="xicclu.html#p1">PrinterBt.icm</a><br>
- <br>
- <img alt="Graph of CMYK neutral axis with -kp 0 .05 1 .9 1 -l290"
- src="Kgraph4.jpg" style="width: 250px; height: 249px;"><br>
- <br>
- This looks just about perfect, so the the curve parameters can now
- be used to generate our real profile:<br>
- <br>
- <a href="colprof.html">colprof</a> <a href="colprof.html#v">-v</a>
- <a href="colprof.html#E">-D"Printer B"</a> <a href="colprof.html#q">-qm</a>
- <a href="colprof.html#k">-kp </a><a href="xicclu.html#k">0 0 .93
- .87 0.65</a> <a href="colprof.html#S">-S</a><a
- href="colprof.html#S"> sRGB.icm</a> <a href="colprof.html#c">-cmt</a>
- <a href="colprof.html#d">-dpp</a> <a href="colprof.html#p1">PrinterB</a><br>
- <br>
- and the resulting B2A table black curve can be checked using xicclu:<br>
- <br>
- <a href="xicclu.html">xicclu</a> <a href="xicclu.html#g">-g</a> <a
- href="xicclu.html#f">-fb</a> <a href="xicclu.html#i">-ir</a> <a
- href="xicclu.html#p1">PrinterB.icm</a><br>
- <br>
- <img style="width: 250px; height: 250px;" alt="sadsadas"
- src="Kgraph5.jpg"><br>
- <br>
- <br>
- <hr style="margin-left: 0px; margin-right: auto; width: 20%; height:
- 2px;"><br>
- <span style="font-weight: bold;">Examples of other inkings:<br>
- <br>
- </span>A smoothed zero black inking:<br>
- <br>
- <a href="xicclu.html">xicclu</a> <a href="xicclu.html#g">-g</a> <a
- href="xicclu.html#k">-kp </a><a href="xicclu.html#k">0 .7 .93 .87
- 1.0</a> <a href="xicclu.html#l">-l290</a> <a
- href="xicclu.html#f">-fif</a> <a href="xicclu.html#i">-ir</a> <a
- href="xicclu.html#p1">PrinterBt.icm</a><br>
- <br>
- <img style="width: 250px; height: 250px;" alt="sadsadas"
- src="Kgraph6.jpg"><br>
- <br>
- A low black inking:<br>
- <br>
- <a href="xicclu.html">xicclu</a> <a href="xicclu.html#g">-g</a> <a
- href="xicclu.html#k">-kp </a><a href="xicclu.html#k">0 0 .93 .87
- 0.15</a> <a href="xicclu.html#l">-l290</a> <a
- href="xicclu.html#f">-fif</a> <a href="xicclu.html#i">-ir</a> <a
- href="xicclu.html#p1">PrinterBt.icm</a><br>
- <br>
- <img style="width: 250px; height: 250px;" alt="sadsadas"
- src="Kgraph7.jpg"><br>
- <br>
- <br>
- A high black inking:<br>
- <br>
- <a href="xicclu.html">xicclu</a> <a href="xicclu.html#g">-g</a> <a
- href="xicclu.html#k">-kp </a><a href="xicclu.html#k">0 0 .93 .87
- 1.2</a> <a href="xicclu.html#l">-l290</a> <a
- href="xicclu.html#f">-fif</a> <a href="xicclu.html#i">-ir</a> <a
- href="xicclu.html#p1">PrinterBt.icm</a><br>
- <br>
- <img style="width: 250px; height: 250px;" alt="sadsadas"
- src="Kgraph8.jpg"><br>
- <br>
- <span style="font-weight: bold;"></span>
- <h4>Overriding the ink limit<br>
- </h4>
- Normally the total ink limit will be read from the <span
- style="font-weight: bold;">PrinterB.ti3</span> file, and will be
- set at a level 10% lower than the number used in creating the test
- chart values using <a href="targen.html#l">targen -l</a>. If you
- want to override this with a lower limit, then use the <a
- href="colprof.html#l">-l flag</a>.<br>
- <br>
- <a href="colprof.html">colprof</a> <a href="colprof.html#v">-v</a>
- <a href="colprof.html#E">-D"Printer B"</a> <a href="colprof.html#q">-qm</a>
- <a href="colprof.html#S">-S</a><a href="colprof.html#S"> sRGB.icm</a>
- <a href="colprof.html#c">-cmt</a> <a href="colprof.html#d">-dpp</a>
- <a href="colprof.html#k">-kr</a> <a href="xicclu.html#l">-l290</a>
- <a href="colprof.html#p1">PrinterB</a><br>
- <br>
- Make sure you check the delta E report at the end of the profile
- creation, to see if the profile is behaving reasonably.<br>
- <br>
- One way of checking that your ink limit is not too high, is to use "<span
- style="font-weight: bold;">xicc -fif -ia</span>" to check, by
- setting different ink limits using the <span style="font-weight:
- bold;">-l</span> option, feeding Lab = 0 0 0 into it, and checking
- the resulting black point. Starting with the ink limit used
- with <span style="font-weight: bold;">targen</span> for the test
- chart, reduce it until the black point starts to be affected. If it
- is immediately affected by any reduction in the ink limit, then the
- black point may be improved by increasing the ink limit used to
- generate the test chart and then re-print and re-measuring it,
- assuming other aspects such as wetness, smudging, spreading or
- drying time are not an issue.<br>
- <br>
- <hr style="width: 100%; height: 2px;"><br>
- <h3><a name="PC1"></a>Calibrating Printers<br>
- </h3>
- <span style="font-weight: bold;">Profiling</span> creates a
- description of how a device behaves, while <span
- style="font-weight: bold;">calibration</span> on the other hand is
- intended to <span style="text-decoration: underline;">change</span>
- how a device behaves. Argyll has the ability to create per-channel
- device space calibration curves for print devices, that can then be
- used to improve the behavior of of the device, making a subsequent
- profile fit the device more easily and also allow day to day
- correction of device drift without resorting to a full re-profile.<br>
- <br>
- <span style="font-weight: bold;">NOTE:</span> Because calibration
- adds yet another layer to the way color is processed, it is
- recommended that it not be attempted until the normal profiling
- workflow is established, understood and verified.<br>
- <h4><a name="PC2"></a>Calibrated print workflows</h4>
- There are two main workflows that printer calibration curves can be
- applied to:<br>
- <br>
- <span style="text-decoration: underline;">Workflow <span
- style="font-weight: bold;">with</span> native calibration
- capability</span>:<br>
- <br>
- Firstly the printer itself may have the capability of using per
- channel calibration curves. In this situation, the calibration
- process will be largely independent of profiling. Firstly the
- printer is configured to have both its color management and
- calibration disabled (the latter perhaps achieved by loading linear
- calibration curves), and a print calibration test chart that
- consists of per channel color wedges is printed. The calibration
- chart is read and the resulting .ti3 file converted into calibration
- curves by processing it using <span style="font-weight: bold;">printcal</span>.
- The calibration is then installed into the printer. Subsequent
- profiling will be performed on the <span style="text-decoration:
- underline;">calibrated</span> printer (ie. the profile test chart
- will have the calibration curves applied to it by the printer, and
- the resulting ICC profile will represent the behavior of the
- calibrated printer.)<br>
- <br>
- <span style="text-decoration: underline;">Workflow <span
- style="font-weight: bold;">without</span> native calibration
- capability</span>:<br>
- <br>
- The second workflow is one in which the printer has no calibration
- capability itself. In this situation, the calibration process will
- have to be applied using the ICC color management tools, so careful
- coordination with profiling is needed. Firstly the printer is
- configured to have its color management disabled, and a print
- calibration test chart that consists of per channel color wedges is
- printed. The calibration chart is converted into calibration curves
- by reading it and then processing the resultant .ti3 using <span
- style="font-weight: bold;">printcal</span>,. During the subsequent
- <span style="text-decoration: underline;">profiling</span>, the
- calibration curves will need to be applied to the profile test chart
- in the process of using <span style="font-weight: bold;">printtarg</span>.
- Once the the profile has been created, then in subsequent printing
- the calibration curves will need to be applied to an image being
- printed either explicitly when using <span style="font-weight:
- bold;">cctiff</span> to apply color profiles <span
- style="text-decoration: underline;">and</span> calibration, <span
- style="font-weight: bold;">OR</span> by creating a version of the
- profile that has had the calibration curves incorporated into it
- using the <span style="font-weight: bold;">applycal</span> tool.
- The latter is useful when some CMM (color management module) other
- than <span style="font-weight: bold;">cctiff </span>is being used.<br>
- <br>
- Once calibration aim targets for a particular device and mode
- (screening, paper etc.) have been established, then the printer can
- be re-calibrated at any time to bring its per channel behavior back
- into line if it drifts, and the new calibration curves can be
- installed into the printer, or re-incorporated into the profile.
-
- <h4><a name="PC3"></a>Creating a print calibration test chart</h4>
- The first step is to create a print calibration test chart. Since
- calibration only creates per-channel curves, only single channel
- step wedges are required for the chart. The main choice is the
- number of steps in each wedge. For simple fast calibrations perhaps
- as few as 20 steps per channel may be enough, but for a better
- quality of calibration something like 50 or more steps would be a
- better choice.<br>
- <br>
- Let's consider two devices in our examples, "PrinterA" which is an
- "RGB" printer device, and "PrinterB" which is CMYK. In fact there is
- no such thing as a real RGB printer, since printers use white media
- and the colorant must subtract from the light reflected on it to
- create color, but the printer itself turns the incoming RGB into the
- native print colorspace, so for this reason we are careful to tell
- targen to use the "Print RGB" colorspace, so that it knows to create
- step wedges from media white to full colorant values.<br>
- <br>
- For instance, to create a 50 steps per channel calibration test
- chart for our RGB and CMYK devices, the following would be
- sufficient:<br>
- <br>
- <a href="targen.html">targen</a> <a href="targen.html#v">-v</a>
- <a href="targen.html#d">-d2</a> <a href="targen.html#s">-s50</a>
- <a href="targen.html#e">-e3</a> <a href="targen.html#f">-f0</a> <a
- href="targen.html#p1">PrinterA_c</a><br>
- <br>
- <a href="targen.html">targen</a> <a href="targen.html#v">-v</a>
- <a href="targen.html#d">-d4</a> <a href="targen.html#s">-s50</a>
- <a href="targen.html#e">-e4</a> <a href="targen.html#f">-f0</a> <a
- href="targen.html#p1">PrinterB_c</a><br>
- <a href="targen.html#p1"></a><br>
- For an outline of how to then print and read the resulting test
- chart, see <a href="Scenarios.html#PP2b">Printing a print
- profile test chart</a>, and <a href="Scenarios.html#PP3">Reading
- a print test chart using an instrument</a>. Note that the printer
- must be in an un-profiled and un-calibrated mode when doing this
- print. Having done this, there will be a PrinterA.ti3 or
- PrinterB.ti3 file containing the step wedge calibration chart
- readings.<br>
- <br>
- <span style="font-weight: bold;">NOTE</span> that if you are
- calibrating a raw printer driver, and there is considerable dot
- gain, then you may want to use the <a href="targen.html#p">-p</a>
- parameter to adjust the test chart point distribution to spread them
- more evenly in perceptual space, giving more accurate control over
- the calibration. Typically this will be a value greater than one for
- a device that has dot gain, e.g. values of 1.5, 2.0 or 2.5 might be
- good places to start. You can do a preliminary calibration and use
- the verbose output of printcal to recommend a suitable value for <span
- style="font-weight: bold;">-p</span>.<br>
- <h4><a name="PC4"></a>Creating a printer calibration<br>
- </h4>
- The <a href="printcal.html">printcal</a> tool turns a calibration
- chart <a href="File_Formats.html#.ti3">.ti3</a> file into a <a
- href="File_Formats.html#.cal">.cal</a> file. It has three main
- operating modes:- Initial calibration, Re-Calibration, and
- Verification. (A fourth mode, "Imitation" is very like Initial
- Calibration, but is used for establishing a calibration target that
- a similar printer can attempt to imitate.)<br>
- <br>
- The distinction between Initial Calibration and Re-Calibration is
- that in the initial calibration we establish the "aim points" or
- response we want out of the printer after calibration. There are
- three basic parameters to set this for each channel: Maximum level,
- minimum level, and curve shape.<br>
- <br>
- By default the maximum level will be set using a heuristic which
- attempts to pick the point when there is diminishing returns for
- applying more colorant. This can be overridden using the <span
- style="font-weight: bold;">-x# percent</span> option, where <span
- style="font-weight: bold;">#</span> represents the choice of
- channel this will be applied to. The parameter is the percentage of
- device maximum. <br>
- <br>
- The minimum level defaults to 0, but can be overridden using the <span
- style="font-weight: bold;">-n# deltaE</span> option. A minimum of
- 0 means that zero colorant will correspond to the natural media
- color, but it may be desirable to set a non-pure media color using
- calibration for the purposes of emulating some other media. The
- parameter is in Delta E units.<br>
- <br>
- The curve shape defaults to being perceptually uniform, which means
- that even steps of calibrated device value result in perceptually
- even color steps. In some situations it may be desirable to alter
- this curve (for instance when non color managed output needs to be
- sent to the calibrated printer), and a simple curve shape target can
- be set using the <span style="font-weight: bold;">-t# percent</span>
- parameter. This affects the output value at 50% input value, and
- represents the percentage of perceptual output. By default it is 50%
- perceptual output for 50% device input.<br>
- <br>
- Once a device has been calibrated, it can be re-calibrated to the
- same aim target.<br>
- <br>
- Verification uses a calibration test chart printed through the
- calibration, and compares the achieved response to the aim target.<br>
- <br>
- The simplest possible way of creating the <span style="font-weight:
- bold;">PrinterA.cal</span> file is:<br>
- <br>
- <a href="printcal.html">printcal</a> <a
- href="printcal.html#i">-i</a> <a href="colprof.html#p2">PrinterA_c</a><br>
- <br>
- For more detailed information, you can add the <span
- style="font-weight: bold;">-v</span> and <span
- style="font-weight: bold;">-p</span> flags:<br>
- <br>
- <a href="printcal.html">printcal</a> <a
- href="printcal.html#v">-v</a> <a href="printcal.html#p">-p</a> <a
- href="printcal.html#i">-i</a> <a href="colprof.html#p2">PrinterB_c</a><br>
- <br>
- (You will need to select the plot window and hit a key to advance
- past each plot).<br>
- <br>
- For re-calibration, the name of the previous calibration file will
- need to be supplied, and a new calibration<br>
- file will be created:<br>
- <br>
- <a href="printcal.html">printcal</a> <a
- href="printcal.html#v">-v</a> <a href="printcal.html#p">-p</a> <a
- href="printcal.html#r">-r</a> <a href="colprof.html#p1">PrinterB_c_old</a>
- <a href="colprof.html#p2">PrinterB_c_new</a><br>
- <br>
- Various aim points are normally set automatically by <span
- style="font-weight: bold;">printcal</span>, but these can be
- overridden using the <a href="colprof.html#x">-x</a>, <a
- href="colprof.html#n">-n</a> and <a href="colprof.html#t">-t</a>
- options. e.g. say we wanted to set the maximum ink for Cyan to 80%
- and Black to 95%, we might use:<br>
- <br>
- <a href="printcal.html">printcal</a> <a
- href="printcal.html#v">-v</a> <a href="printcal.html#p">-p</a> <a
- href="printcal.html#i">-i</a> <a href="colprof.html#x">-xc 80</a>
- <a href="colprof.html#x">-xk 95</a> <a href="colprof.html#p2">PrinterB_c</a><br>
- <br>
- <a href="colprof.html#p2"></a>
- <h4><a name="PC5"></a>Using a printer calibration</h4>
- The resulting calibration curves can be used with the following
- other Argyll tools:<br>
- <br>
+ + + + and then used <a href="xicclu.html#g">xicclu</a> to explore the + effect of the parameters.<br> + <br> + For instance, say we have our CMYK .ti3 file <span + style="font-weight: bold;">PrinterB.ti3</span>. First we make a + preliminary profile called <span style="font-weight: bold;">PrinterBt</span>:<br> + <br> + copy PrinterB.ti3 PrinterBt.ti3 (Use + "cp" on Linux or OSX of course.)<br> + <a href="colprof.html">colprof</a> <a href="colprof.html#v">-v</a> + <a href="colprof.html#q">-qm</a> <a href="colprof.html#b">-b</a> <a + href="colprof.html#c">-cmt</a> <a href="colprof.html#d">-dpp</a> + <a href="colprof.html#p1">PrinterBt</a><br> + <br> + Then see what the minimum black level down the neutral axis can be. + Note that we need to also set any ink limits we've decided on as + well (coloprof defaulting to 10% less than the value recorded in the + .ti3 file). In this example the test chart has a 300% total ink + limit, and we've decided to use 290%:<br> + <br> + <a href="xicclu.html">xicclu</a> <a href="xicclu.html#g">-g</a> <a + href="xicclu.html#k">-kz</a> <a href="xicclu.html#l">-l290</a> <a + href="xicclu.html#f">-fif</a> <a href="xicclu.html#i">-ir</a> <a + href="xicclu.html#p1">PrinterBt.icm</a><br> + <br> + Which might be a graph something like this:<br> + <br> + <img alt="Graph of CMYK neutral axis with minimum K" + src="Kgraph1.jpg" style="width: 250px; height: 250px;"><br> + <br> + Note how the minimum black is zero up to 93% of the + white->black L* curve, and then jumps up to 87%. This is because + we've reached the total ink limit, and K then has to be substituted + for CMY, to keep the total under the total ink limit.<br> + <br> + Then let's see what the maximum black level down the neutral axis + can be:<br> + <br> + <a href="xicclu.html">xicclu</a> <a href="xicclu.html#g">-g</a> <a + href="xicclu.html#k">-kx</a> <a href="xicclu.html#l">-l290</a> <a + href="xicclu.html#f">-fif</a> <a href="xicclu.html#i">-ir</a> <a + href="xicclu.html#p1">PrinterBt.icm</a><br> + <br> + Which might be a graph something like this:<br> + <br> + <img alt="Graph of CMYK neutral axis with maximum K" + src="Kgraph2.jpg" style="width: 250px; height: 250px;"><br> + <br> + Note how the CMY values are fairly low up to 93% of the + white->black L* curve (the low levels of CMY are helping set the + neutral color), and then they jump up. This is because we've reach + the point where black on it's own, isn't as dark as the color that + can be achieved using CMY and K. Because the K has a dominant effect + on the hue of the black, the levels of CMY are often fairly volatile + in this region.<br> + <br> + Any K curve we specify must lie between the black curves of the + above two graphs.<br> + <br> + Let's say we'd like to chose a moderate black curve, one that aims + for about equal levels of CMY and K. We should also aim for it to be + fairly smooth, since this will minimize visual artefacts caused by + the limited fidelity that profile LUT tables are able to represent + inside the profile.<br> + <br> + <img style="width: 340px; height: 258px;" alt="-k parameters" + src="Kparams.jpg"><br> + <br> + <br> + For minimum discontinuities we should aim for the curve to finish at + the point it has to reach to satisfy the total ink limit at 87% + curve and 93% black. For a first try we can simply set a straight + line to that point: <br> + <br> + <a href="xicclu.html">xicclu</a> <a href="xicclu.html#g">-g</a> <a + href="xicclu.html#k">-kp 0 0 .93 .87 1.0</a> <a + href="xicclu.html#l">-l290</a> <a href="xicclu.html#f">-fif</a> <a + href="xicclu.html#i">-ir</a> <a href="xicclu.html#p1">PrinterBt.icm</a><br> + <br> + <img alt="Graph of CMYK neutral axis with kp 0 0 1.0 1.0 1.0 -l290" + src="Kgraph3.jpg" style="width: 250px; height: 250px;"><br> + <br> + The black "curve" hits the 93%/87% mark well, but is a bit too far + above CMY, so we'll try making the black curve concave:<br> + <br> + <a href="xicclu.html">xicclu</a> <a href="xicclu.html#g">-g</a> <a + href="xicclu.html#k">-kp </a><a href="xicclu.html#k">0 0 .93 .87 + 0.65</a> <a href="xicclu.html#l">-l290</a> <a + href="xicclu.html#f">-fif</a> <a href="xicclu.html#i">-ir</a> <a + href="xicclu.html#p1">PrinterBt.icm</a><br> + <br> + <img alt="Graph of CMYK neutral axis with -kp 0 .05 1 .9 1 -l290" + src="Kgraph4.jpg" style="width: 250px; height: 249px;"><br> + <br> + This looks just about perfect, so the the curve parameters can now + be used to generate our real profile:<br> + <br> + <a href="colprof.html">colprof</a> <a href="colprof.html#v">-v</a> + <a href="colprof.html#E">-D"Printer B"</a> <a href="colprof.html#q">-qm</a> + <a href="colprof.html#k">-kp </a><a href="xicclu.html#k">0 0 .93 + .87 0.65</a> <a href="colprof.html#S">-S</a><a + href="colprof.html#S"> sRGB.icm</a> <a href="colprof.html#c">-cmt</a> + <a href="colprof.html#d">-dpp</a> <a href="colprof.html#p1">PrinterB</a><br> + <br> + and the resulting B2A table black curve can be checked using xicclu:<br> + <br> + <a href="xicclu.html">xicclu</a> <a href="xicclu.html#g">-g</a> <a + href="xicclu.html#f">-fb</a> <a href="xicclu.html#i">-ir</a> <a + href="xicclu.html#p1">PrinterB.icm</a><br> + <br> + <img style="width: 250px; height: 250px;" alt="sadsadas" + src="Kgraph5.jpg"><br> + <br> + <br> + <hr style="margin-left: 0px; margin-right: auto; width: 20%; height: + 2px;"><br> + <span style="font-weight: bold;">Examples of other inkings:<br> + <br> + </span>A smoothed zero black inking:<br> + <br> + <a href="xicclu.html">xicclu</a> <a href="xicclu.html#g">-g</a> <a + href="xicclu.html#k">-kp </a><a href="xicclu.html#k">0 .7 .93 .87 + 1.0</a> <a href="xicclu.html#l">-l290</a> <a + href="xicclu.html#f">-fif</a> <a href="xicclu.html#i">-ir</a> <a + href="xicclu.html#p1">PrinterBt.icm</a><br> + <br> + <img style="width: 250px; height: 250px;" alt="sadsadas" + src="Kgraph6.jpg"><br> + <br> + A low black inking:<br> + <br> + <a href="xicclu.html">xicclu</a> <a href="xicclu.html#g">-g</a> <a + href="xicclu.html#k">-kp </a><a href="xicclu.html#k">0 0 .93 .87 + 0.15</a> <a href="xicclu.html#l">-l290</a> <a + href="xicclu.html#f">-fif</a> <a href="xicclu.html#i">-ir</a> <a + href="xicclu.html#p1">PrinterBt.icm</a><br> + <br> + <img style="width: 250px; height: 250px;" alt="sadsadas" + src="Kgraph7.jpg"><br> + <br> + <br> + A high black inking:<br> + <br> + <a href="xicclu.html">xicclu</a> <a href="xicclu.html#g">-g</a> <a + href="xicclu.html#k">-kp </a><a href="xicclu.html#k">0 0 .93 .87 + 1.2</a> <a href="xicclu.html#l">-l290</a> <a + href="xicclu.html#f">-fif</a> <a href="xicclu.html#i">-ir</a> <a + href="xicclu.html#p1">PrinterBt.icm</a><br> + <br> + <img style="width: 250px; height: 250px;" alt="sadsadas" + src="Kgraph8.jpg"><br> + <br> + <span style="font-weight: bold;"></span> + <h4>Overriding the ink limit<br> + </h4> + Normally the total ink limit will be read from the <span + style="font-weight: bold;">PrinterB.ti3</span> file, and will be + set at a level 10% lower than the number used in creating the test + chart values using <a href="targen.html#l">targen -l</a>. If you + want to override this with a lower limit, then use the <a + href="colprof.html#l">-l flag</a>.<br> + <br> + <a href="colprof.html">colprof</a> <a href="colprof.html#v">-v</a> + <a href="colprof.html#E">-D"Printer B"</a> <a href="colprof.html#q">-qm</a> + <a href="colprof.html#S">-S</a><a href="colprof.html#S"> sRGB.icm</a> + <a href="colprof.html#c">-cmt</a> <a href="colprof.html#d">-dpp</a> + <a href="colprof.html#k">-kr</a> <a href="xicclu.html#l">-l290</a> + <a href="colprof.html#p1">PrinterB</a><br> + <br> + Make sure you check the delta E report at the end of the profile + creation, to see if the profile is behaving reasonably.<br> + <br> + One way of checking that your ink limit is not too high, is to use "<span + style="font-weight: bold;">xicc -fif -ia</span>" to check, by + setting different ink limits using the <span style="font-weight: + bold;">-l</span> option, feeding Lab = 0 0 0 into it, and checking + the resulting black point. Starting with the ink limit used + with <span style="font-weight: bold;">targen</span> for the test + chart, reduce it until the black point starts to be affected. If it + is immediately affected by any reduction in the ink limit, then the + black point may be improved by increasing the ink limit used to + generate the test chart and then re-print and re-measuring it, + assuming other aspects such as wetness, smudging, spreading or + drying time are not an issue.<br> + <br> + <hr style="width: 100%; height: 2px;"><br> + <h3><a name="PC1"></a>Calibrating Printers<br> + </h3> + <span style="font-weight: bold;">Profiling</span> creates a + description of how a device behaves, while <span + style="font-weight: bold;">calibration</span> on the other hand is + intended to <span style="text-decoration: underline;">change</span> + how a device behaves. Argyll has the ability to create per-channel + device space calibration curves for print devices, that can then be + used to improve the behavior of of the device, making a subsequent + profile fit the device more easily and also allow day to day + correction of device drift without resorting to a full re-profile.<br> + <br> + <span style="font-weight: bold;">NOTE:</span> Because calibration + adds yet another layer to the way color is processed, it is + recommended that it not be attempted until the normal profiling + workflow is established, understood and verified.<br> + <h4><a name="PC2"></a>Calibrated print workflows</h4> + There are two main workflows that printer calibration curves can be + applied to:<br> + <br> + <span style="text-decoration: underline;">Workflow <span + style="font-weight: bold;">with</span> native calibration + capability</span>:<br> + <br> + Firstly the printer itself may have the capability of using per + channel calibration curves. In this situation, the calibration + process will be largely independent of profiling. Firstly the + printer is configured to have both its color management and + calibration disabled (the latter perhaps achieved by loading linear + calibration curves), and a print calibration test chart that + consists of per channel color wedges is printed. The calibration + chart is read and the resulting .ti3 file converted into calibration + curves by processing it using <span style="font-weight: bold;">printcal</span>. + The calibration is then installed into the printer. Subsequent + profiling will be performed on the <span style="text-decoration: + underline;">calibrated</span> printer (ie. the profile test chart + will have the calibration curves applied to it by the printer, and + the resulting ICC profile will represent the behavior of the + calibrated printer.)<br> + <br> + <span style="text-decoration: underline;">Workflow <span + style="font-weight: bold;">without</span> native calibration + capability</span>:<br> + <br> + The second workflow is one in which the printer has no calibration + capability itself. In this situation, the calibration process will + have to be applied using the ICC color management tools, so careful + coordination with profiling is needed. Firstly the printer is + configured to have its color management disabled, and a print + calibration test chart that consists of per channel color wedges is + printed. The calibration chart is converted into calibration curves + by reading it and then processing the resultant .ti3 using <span + style="font-weight: bold;">printcal</span>,. During the subsequent + <span style="text-decoration: underline;">profiling</span>, the + calibration curves will need to be applied to the profile test chart + in the process of using <span style="font-weight: bold;">printtarg</span>. + Once the the profile has been created, then in subsequent printing + the calibration curves will need to be applied to an image being + printed either explicitly when using <span style="font-weight: + bold;">cctiff</span> to apply color profiles <span + style="text-decoration: underline;">and</span> calibration, <span + style="font-weight: bold;">OR</span> by creating a version of the + profile that has had the calibration curves incorporated into it + using the <span style="font-weight: bold;">applycal</span> tool. + The latter is useful when some CMM (color management module) other + than <span style="font-weight: bold;">cctiff </span>is being used.<br> + <br> + Once calibration aim targets for a particular device and mode + (screening, paper etc.) have been established, then the printer can + be re-calibrated at any time to bring its per channel behavior back + into line if it drifts, and the new calibration curves can be + installed into the printer, or re-incorporated into the profile. + + <h4><a name="PC3"></a>Creating a print calibration test chart</h4> + The first step is to create a print calibration test chart. Since + calibration only creates per-channel curves, only single channel + step wedges are required for the chart. The main choice is the + number of steps in each wedge. For simple fast calibrations perhaps + as few as 20 steps per channel may be enough, but for a better + quality of calibration something like 50 or more steps would be a + better choice.<br> + <br> + Let's consider two devices in our examples, "PrinterA" which is an + "RGB" printer device, and "PrinterB" which is CMYK. In fact there is + no such thing as a real RGB printer, since printers use white media + and the colorant must subtract from the light reflected on it to + create color, but the printer itself turns the incoming RGB into the + native print colorspace, so for this reason we are careful to tell + targen to use the "Print RGB" colorspace, so that it knows to create + step wedges from media white to full colorant values.<br> + <br> + For instance, to create a 50 steps per channel calibration test + chart for our RGB and CMYK devices, the following would be + sufficient:<br> + <br> + <a href="targen.html">targen</a> <a href="targen.html#v">-v</a> + <a href="targen.html#d">-d2</a> <a href="targen.html#s">-s50</a> + <a href="targen.html#e">-e3</a> <a href="targen.html#f">-f0</a> <a + href="targen.html#p1">PrinterA_c</a><br> + <br> + <a href="targen.html">targen</a> <a href="targen.html#v">-v</a> + <a href="targen.html#d">-d4</a> <a href="targen.html#s">-s50</a> + <a href="targen.html#e">-e4</a> <a href="targen.html#f">-f0</a> <a + href="targen.html#p1">PrinterB_c</a><br> + <a href="targen.html#p1"></a><br> + For an outline of how to then print and read the resulting test + chart, see <a href="Scenarios.html#PP2b">Printing a print + profile test chart</a>, and <a href="Scenarios.html#PP3">Reading + a print test chart using an instrument</a>. Note that the printer + must be in an un-profiled and un-calibrated mode when doing this + print. Having done this, there will be a PrinterA.ti3 or + PrinterB.ti3 file containing the step wedge calibration chart + readings.<br> + <br> + <span style="font-weight: bold;">NOTE</span> that if you are + calibrating a raw printer driver, and there is considerable dot + gain, then you may want to use the <a href="targen.html#p">-p</a> + parameter to adjust the test chart point distribution to spread them + more evenly in perceptual space, giving more accurate control over + the calibration. Typically this will be a value greater than one for + a device that has dot gain, e.g. values of 1.5, 2.0 or 2.5 might be + good places to start. You can do a preliminary calibration and use + the verbose output of printcal to recommend a suitable value for <span + style="font-weight: bold;">-p</span>.<br> + <h4><a name="PC4"></a>Creating a printer calibration<br> + </h4> + The <a href="printcal.html">printcal</a> tool turns a calibration + chart <a href="File_Formats.html#.ti3">.ti3</a> file into a <a + href="File_Formats.html#.cal">.cal</a> file. It has three main + operating modes:- Initial calibration, Re-Calibration, and + Verification. (A fourth mode, "Imitation" is very like Initial + Calibration, but is used for establishing a calibration target that + a similar printer can attempt to imitate.)<br> + <br> + The distinction between Initial Calibration and Re-Calibration is + that in the initial calibration we establish the "aim points" or + response we want out of the printer after calibration. There are + three basic parameters to set this for each channel: Maximum level, + minimum level, and curve shape.<br> + <br> + By default the maximum level will be set using a heuristic which + attempts to pick the point when there is diminishing returns for + applying more colorant. This can be overridden using the <span + style="font-weight: bold;">-x# percent</span> option, where <span + style="font-weight: bold;">#</span> represents the choice of + channel this will be applied to. The parameter is the percentage of + device maximum. <br> + <br> + The minimum level defaults to 0, but can be overridden using the <span + style="font-weight: bold;">-n# deltaE</span> option. A minimum of + 0 means that zero colorant will correspond to the natural media + color, but it may be desirable to set a non-pure media color using + calibration for the purposes of emulating some other media. The + parameter is in Delta E units.<br> + <br> + The curve shape defaults to being perceptually uniform, which means + that even steps of calibrated device value result in perceptually + even color steps. In some situations it may be desirable to alter + this curve (for instance when non color managed output needs to be + sent to the calibrated printer), and a simple curve shape target can + be set using the <span style="font-weight: bold;">-t# percent</span> + parameter. This affects the output value at 50% input value, and + represents the percentage of perceptual output. By default it is 50% + perceptual output for 50% device input.<br> + <br> + Once a device has been calibrated, it can be re-calibrated to the + same aim target.<br> + <br> + Verification uses a calibration test chart printed through the + calibration, and compares the achieved response to the aim target.<br> + <br> + The simplest possible way of creating the <span style="font-weight: + bold;">PrinterA.cal</span> file is:<br> + <br> + <a href="printcal.html">printcal</a> <a + href="printcal.html#i">-i</a> <a href="colprof.html#p2">PrinterA_c</a><br> + <br> + For more detailed information, you can add the <span + style="font-weight: bold;">-v</span> and <span + style="font-weight: bold;">-p</span> flags:<br> + <br> + <a href="printcal.html">printcal</a> <a + href="printcal.html#v">-v</a> <a href="printcal.html#p">-p</a> <a + href="printcal.html#i">-i</a> <a href="colprof.html#p2">PrinterB_c</a><br> + <br> + (You will need to select the plot window and hit a key to advance + past each plot).<br> + <br> + For re-calibration, the name of the previous calibration file will + need to be supplied, and a new calibration<br> + file will be created:<br> + <br> + <a href="printcal.html">printcal</a> <a + href="printcal.html#v">-v</a> <a href="printcal.html#p">-p</a> <a + href="printcal.html#r">-r</a> <a href="colprof.html#p1">PrinterB_c_old</a> + <a href="colprof.html#p2">PrinterB_c_new</a><br> + <br> + Various aim points are normally set automatically by <span + style="font-weight: bold;">printcal</span>, but these can be + overridden using the <a href="colprof.html#x">-x</a>, <a + href="colprof.html#n">-n</a> and <a href="colprof.html#t">-t</a> + options. e.g. say we wanted to set the maximum ink for Cyan to 80% + and Black to 95%, we might use:<br> + <br> + <a href="printcal.html">printcal</a> <a + href="printcal.html#v">-v</a> <a href="printcal.html#p">-p</a> <a + href="printcal.html#i">-i</a> <a href="colprof.html#x">-xc 80</a> + <a href="colprof.html#x">-xk 95</a> <a href="colprof.html#p2">PrinterB_c</a><br> + <br> + <a href="colprof.html#p2"></a> + <h4><a name="PC5"></a>Using a printer calibration</h4> + The resulting calibration curves can be used with the following + other Argyll tools:<br> + <br> <a href="printtarg.html#K">printtarg</a> To apply @@ -2617,8 +2661,10 @@ chart, -
- and/or to have it included in .ti3 file.<br>
+ + + + and/or to have it included in .ti3 file.<br> <a href="cctiff.html#p2">cctiff</a> To apply @@ -2684,8 +2730,10 @@ an -
- image file.<br>
+ + + + image file.<br> <a href="applycal.html#p1">applycal</a> @@ -2743,8 +2791,10 @@ an -
- To incorporate calibration into an ICC profile.<br>
+ + + + To incorporate calibration into an ICC profile.<br> <a href="chartread.html#I">chartread</a> To override @@ -2810,396 +2860,405 @@ a -
- profile chart.<br>
- <br>
- <br>
- In a workflow <span style="font-weight: bold;">with</span> native
- calibration capability, the calibration curves would be used with
- printarg during subsequent <span style="font-weight: bold;">profiling</span>
- so that any ink limit calculations will reflect final device values,
- while not otherwise using the calibration within the ICC workflow:<br>
- <br>
- <a href="printtarg.html">printtarg</a> <a
- href="printtarg.html#v">-v</a> <a href="printtarg.html#i">-ii1</a>
- <a href="printtarg.html#p">-pA4</a> <a href="printtarg.html#I">-I
- PrinterA_c.cal</a> <a href="printtarg.html#p1">PrinterA</a><br>
- <br>
- This will cause the .ti2 and resulting .ti3 and ICC profiles to
- contain the calibration curves, allowing all the tools to be able to
- compute final device value ink limits. The calibration curves must
- also of course be installed into the printer. The means to do this
- is currently outside the scope of Argyll (ie. either the print
- system needs to be able to understand Argyll CAL format files, or
- some tool will be needed to convert Argyll CAL files into the
- printer calibration format).<br>
- <br>
- <br>
- In a workflow <span style="font-weight: bold;">without</span>
- native calibration capability, the calibration curves would be used
- with printarg to <span style="text-decoration: underline;">apply</span>
- the calibration to the test patch samples during subsequent <span
- style="font-weight: bold;">profiling</span>, as well as embedding
- it in the resulting .ti3 to allow all the tools to be able to
- compute final device value ink limits:<br>
- <br>
- <a href="printtarg.html">printtarg</a> <a
- href="printtarg.html#v">-v</a> <a href="printtarg.html#i">-ii1</a>
- <a href="printtarg.html#p">-pA4</a> <a href="printtarg.html#K">-K
- PrinterA_c.cal</a> <a href="printtarg.html#p1">PrinterA</a><br>
- <a href="cctiff.html#p4"></a><br>
- To apply calibration to an ICC profile, so that a calibration
- unaware CMM can be used:<br>
- <br>
- <a href="applycal.html">applycal</a> <a
- href="applycal.html#p1">PrinterA.cal</a> <a
- href="applycal.html#p2">PrinterA.icm</a> <a
- href="applycal.html#p3">PrinterA_cal.icm</a><br>
- <br>
- To apply color management and calibration to a raster image:<br>
- <br>
- <a href="file:///D:/src/argyll/doc/cctiff.html">cctiff</a>
- <a href="file:///D:/src/argyll/doc/cctiff.html#p1">Source.icm</a> <a
- href="file:///D:/src/argyll/doc/cctiff.html#p1">PrinterA.icm</a> <a
- href="file:///D:/src/argyll/doc/cctiff.html#p2">PrinterA_c.cal</a>
- <a href="file:///D:/src/argyll/doc/cctiff.html#p3">infile.tif</a> <a
- href="file:///D:/src/argyll/doc/cctiff.html#p4">outfile.tif</a><br>
- <br>
- or<br>
- <br>
- <a href="file:///D:/src/argyll/doc/cctiff.html">cctiff</a>
- <a href="file:///D:/src/argyll/doc/cctiff.html#p1">Source.icm</a> <a
- href="file:///D:/src/argyll/doc/cctiff.html#p1">PrinterA_c.icm</a>
- <a href="file:///D:/src/argyll/doc/cctiff.html#p3">infile.tif</a> <a
- href="file:///D:/src/argyll/doc/cctiff.html#p4">outfile.tif</a><br>
- <br>
- [ Note that cctiff will also process JPEG raster images. ]<br>
- <br>
- Another useful tool is <a href="synthcal.html">synthcal</a>, that
- allows creating linear or synthetic calibration files for disabling
- calibration or testing.<br>
- Similarly, <a href="fakeread.html">fakeread</a> also supports
- applying calibration curves and embedding them in the resulting .ti3
- file<br>
- <br>
- If you want to create a pre-conditioning profile for use with <a
- href="targen.html#c">targen -c</a>, then use the PrinterA.icm
- profile, <b>NOT</b> PrinterA_c.icm that has calibration curves
- applied.<br>
- <h4><a name="PC6"></a>How profile ink limits are handled when
- calibration is being used.</h4>
- Even though the profiling process is carried out on top of the
- linearized device, and the profiling is generally unaware of the
- underlying non-linearized device values, an exception is made in the
- calculation of ink limits during profiling. This is made possible by
- including the calibration curves in the profile charts .ti2 and
- subsequent .ti3 file and resulting ICC profile <span
- style="font-weight: bold;">'targ'</span> text tag, by way of the <span
- style="font-weight: bold;">printtarg</span> <span
- style="font-weight: bold;">-I</span> or <span style="font-weight:
- bold;">-K</span> options. This is done on the assumption that the
- physical quantity of ink is what's important in setting the ink
- limit, and that the underlying non-linearized device values
- represent such a physical quantity.<br>
- <br>
- <br>
- <hr size="2" width="100%">
- <h3><a name="LP1"></a>Linking Profiles</h3>
- Two device profiles can be linked together to create a device link
- profile, than encapsulates a particular device to device transform.
- Often this step is not necessary, as many systems and tools will
- link two device profiles "on the fly", but creating a device link
- profile gives you the option of using "smart CMM" techniques, such
- as true gamut mapping, improved inverse transform accuracy, tailored
- black generation and ink limiting.<br>
- <br>
- The overall process is to link the input space and output space
- profiles using <a href="collink.html">collink</a>, creating a
- device to device link profile. The device to device link profile can
- then be used by cctiff (or other ICC device profile capable tools),
- to color correct a raster files.<br>
- <br>
- Three examples will be given here, showing the three different modes
- than <span style="font-weight: bold;">collink</span> supports.<br>
- <br>
- In <a href="collink.html#s">simple mode</a>, the two profiles are
- linked together in a similar fashion to other <span
- style="font-weight: bold;">CMMs</span> simply using the forward
- and backwards color transforms defined by the profiles. Any gamut
- mapping is determined by the content of the tables within the two
- profiles, together with the particular intent chosen. Typically the
- same intent will be used for both the source and destination
- profile:<br>
- <br>
- <a href="collink.html">collink</a> <a href="collink.html#v">-v</a>
- <a href="collink.html#q">-qm</a> <a href="collink.html#s">-s</a> <a
- href="collink.html#si">-ip</a> <a href="collink.html#so">-op</a>
- <a href="collink.html#p1">SouceProfile.icm</a> <a
- href="collink.html#p2">DestinationProfile.icm</a> <a
- href="collink.html#p3">Source2Destination.icm</a><br>
- <br>
- <br>
- In <a href="collink.html#g">gamut mapping mode</a>, the
- pre-computed intent mappings inside the profiles are not used, but
- instead the gamut mapping between source and destination is tailored
- to the specific gamuts of the two profiles, and the intent parameter
- supplied to <span style="font-weight: bold;">collink</span>.
- Additionally, source and destination viewing conditions should be
- provided, to allow the color appearance space conversion to work as
- intended. The colorimetric B2A table in the destination profile is
- used, and this will determine any black generation and ink limiting:<br>
- <br>
- <a href="collink.html">collink</a> <a href="collink.html#v">-v</a>
- <a href="collink.html#q">-qm</a> <a href="collink.html#g">-g</a> <a
- href="collink.html#si">-ip</a> <a href="collink.html#c">-cmt</a>
- <a href="collink.html#d">-dpp</a> <a href="collink.html#p1">MonitorSouceProfile.icm</a>
- <a href="collink.html#p2">DestinationProfile.icm</a> <a
- href="collink.html#p3">Source2Destination.icm</a><br>
- <br>
- [ If your viewing environment for the display and print doesn't
- match the ones implied by the <a href="colprof.html#c">-cmt</a> and
- <a href="colprof.html#d">-dpp</a> options, leave them out, and
- evaluate what, if any appearance transformation is appropriate for
- your environment at a later stage. ]<br>
- <br>
- In <a href="collink.html#G">inverse output table gamut mapping mode</a>,
- the pre-computed intent mappings inside the profiles are not used,
- but instead the gamut mapping between source and destination is
- tailored to the specific gamuts of the two profiles, and the intent
- parameter supplied to <span style="font-weight: bold;">collink</span>.
- In addition, the B2A table is <span style="font-weight: bold;">not</span>
- used in the destination profile, but the A2B table is instead
- inverted, leading to improved transform accuracy, and in CMYK
- devices, allowing the ink limiting and black generation parameters
- to be set:<br>
- <br>
- For a CLUT table based RGB printer destination profile, the
- following would be appropriate:<br>
- <br>
- <a href="collink.html">collink</a> <a href="collink.html#v">-v</a>
- <a href="collink.html#q">-qm</a> <a href="collink.html#G">-G</a> <a
- href="collink.html#si">-ip</a> <a href="collink.html#c">-cmt</a>
- <a href="collink.html#d">-dpp</a> <a href="collink.html#p1">MonitorSouceProfile.icm</a>
- <a href="collink.html#p2">RGBDestinationProfile.icm</a> <a
- href="collink.html#p3">Source2Destination.icm</a><br>
- <br>
- For a CMYK profile, the total ink limit needs to be specified (a
- typical value being 10% less than the value used in creating the
- device test chart), and the type of black generation also needs to
- be specified:<br>
- <br>
- <a href="collink.html">collink</a> <a href="collink.html#v">-v</a>
- <a href="collink.html#q">-qm</a> <a href="collink.html#G">-G</a> <a
- href="collink.html#si">-ip</a> <a href="collink.html#c">-cmt</a>
- <a href="collink.html#d">-dpp</a> <a href="collink.html#l">-l250</a>
- <a href="collink.html#k">-kr</a> <a href="collink.html#p1">MonitorSouceProfile.icm</a>
- <a href="collink.html#p2">CMYKDestinationProfile.icm</a> <a
- href="collink.html#p3">Source2Destination.icm</a><br>
- <br>
- Note that you should set the source (<a href="collink.html#c">-c</a>)
- and destination (<a href="collink.html#d">-d</a>) viewing conditions
- for the type of device the profile represents, and the conditions
- under which it will be viewed.<br>
- <br>
- <h3><a name="LP3"></a>Image dependent gamut mapping using device
- links<br>
- </h3>
- When images are stored in large gamut colorspaces (such as. L*a*b*
- or ProPhoto, etc.), then using the colorspace gamut as the source
- gamut for gamut mapping is generally a bad idea, as it leads to
- overly compressed and dull images. The correct approach is to use a
- source gamut that represents the gamut of the images themselves.
- This can be created using tiffgamut, and an example workflow is as
- follows:<br>
- <br>
- <a href="tiffgamut.html">tiffgamut</a> -f80 -pj -cmt ProPhoto.icm
- image.tif<br>
- <br>
- <a href="collink.html">collink</a> <a href="collink.html#v">-v</a>
- <a href="collink.html#q">-qh</a> <a href="collink.html#G">-G</a> <a
- href="collink.html#Gp">image.gam</a> <a href="collink.html#si">-ip</a>
- <a href="collink.html#c">-cmt</a> <a href="collink.html#d">-dpp</a>
- <a href="collink.html#p1">ProPhoto.icm</a> <a
- href="file:///D:/src/argyll/doc/collink.html#p2">RGBDestinationProfile.icm</a>
- <a href="file:///D:/src/argyll/doc/collink.html#p3">Source2Destination.icm</a><br>
- <br>
- <a href="file:///D:/src/argyll/doc/cctiff.html">cctiff</a> <a
- href="file:///D:/src/argyll/doc/cctiff.html#p1">Source2Destination.icm</a>
- <a href="file:///D:/src/argyll/doc/cctiff.html#p3">image.tif</a> <a
- href="file:///D:/src/argyll/doc/cctiff.html#p4">printfile.tif</a><br>
- <br>
- The printfile.tif is then send to the printer without color
- management, (i.e. in the same way the printer characterization test
- chart was printed), since it is in the printers native colorspace.<br>
- <br>
- You can adjust how conservatively the image gamut is preserved using
- the tiffgamut -f parameter. Omitting it or using a larger value (up
- to 100) preserves the color gradations of even the lesser used
- colors, at the cost of compressing the gamut more.<br>
- Using a smaller value will preserve the saturation of the most
- popular colors, at the cost of not preserving the color gradations
- of less popular colors.<br>
- <br>
- You can create a gamut that covers a set of source images by
- providing more than one image file name to tiffgamut. This may be
- more efficient for a group of related images, and ensures that
- colors are transformed in exactly the same way for all of the
- images.<br>
- <br>
- The arguments to collink should be appropriate for the output device
- type - see the collink examples in the above section.<br>
- <h3><a name="LP2"></a>Soft Proofing Link</h3>
- Often it is desirable to get an idea what a particular devices
- output will look like using a different device. Typically this might
- be trying to evaluate print output using a display. Often it is
- sufficient to use an absolute or relative colorimetric transform
- from the print device space to the display space, but while these
- provide a colorimetric preview of the result, they do not take into
- account the subjective appearance differences due to the different
- device conditions. It can therefore be useful to create a soft proof
- appearance transform using collink:<br>
- <br>
- <a href="collink.html">collink</a> <a href="collink.html#v">-v</a>
- <a href="collink.html#q">-qm</a> <a href="collink.html#G">-G</a> <a
- href="collink.html#si">-ila</a> <a href="collink.html#c">-cpp</a>
- <a href="collink.html#d">-dmt</a> <a href="collink.html#l">-t250</a> <a
- href="collink.html#k"></a><a href="collink.html#p1">CMYKDestinationProfile.icm</a>
- <a href="collink.html#p2">MonitorProfile.icm</a> <a
- href="collink.html#p3">SoftProof.icm</a><br>
- <br>
- We use the Luminance matched appearance intent, to preserve the
- subjective apperance of the target device, which takes into account
- the viewing conditions and assumes adaptation to the differences in
- the luminence range, but otherwise not attempting to compress or
- change the gamut.<br>
- <br>
- If your viewing environment for the display and print doesn't match
- the ones implied by the <a href="collink.html#c">-cpp</a> and <a
- href="collink.html#d">-dmt</a> options, then either leave them out
- or substitute values that do match your environment.<br>
-
- <hr size="2" width="100%"><br>
- <h3><a name="TR1"></a>Transforming colorspaces of raster files</h3>
- Although a device profile or device link profile may be useful with
- other programs and systems, Argyll provides the tool <a
- href="cctiff.html">cctiff</a> for directly applying a device to
- device transform to a <a href="File_Formats.html#TIFF">TIFF</a> or
- <a href="File_Formats.html#JPEG">JPEG</a> raster file. The cctiff
- tool is capable of linking an arbitrary sequence of device profiles,
- device links, abstract profiles and calibration curves. Each device
- profile can be preceded by the <span style="font-weight: bold;">-i</span>
- option to indicate the intent that should be used. Both 8 and 16 bit
- per component files can be handled, and up to 8 color channels. The
- color transform is optimized to perform the overall transformation
- rapidly.<br>
- <br>
- If a device link is to be used, the following is a typical example:<br>
- <br>
- <a href="cctiff.html">cctiff</a> <a href="cctiff.html#p1">Source2Destination.icm</a>
- <a href="cctiff.html#p3">infile.tif</a> <a href="cctiff.html#p4">outfile.tif</a><br>
- or<br>
- <a href="cctiff.html">cctiff</a> <a href="cctiff.html#p1">Source2Destination.icm</a>
- <a href="cctiff.html#p3">infile.jpg</a> <a href="cctiff.html#p4">outfile.jpg</a><br>
- <br>
- <i><br>
- </i>If a source and destination profile are to be used, the
- following would be a typical example:<br>
- <br>
- <a href="cctiff.html"> cctiff</a> <a href="cctiff.html#i">-ip</a>
- <a href="cctiff.html#p1i">SourceProfile.icm</a> <a
- href="cctiff.html#i">-ip</a> <a href="cctiff.html#p1o">DestinationProfile.icm</a>
- <a href="cctiff.html#p3">infile.tif</a> <a href="cctiff.html#p4">outfile.tif</a><br>
- or<br>
- <a href="cctiff.html"> cctiff</a> <a href="cctiff.html#i">-ip</a>
- <a href="cctiff.html#p1i">SourceProfile.icm</a> <a
- href="cctiff.html#i">-ip</a> <a href="cctiff.html#p1o">DestinationProfile.icm</a>
- <a href="cctiff.html#p3">infile.jpg</a> <a href="cctiff.html#p4">outfile.jpg</a><br>
- <br>
- <br>
- <hr size="2" width="100%"><br>
- <h3><a name="TV1"></a>Creating Video Calibration 3DLuts</h3>
- Video calibration typically involves trying to make your actual
- display device emulate an ideal video display, one which matches
- what your Video media was intended to be displayed on. An ICC device
- link embodies the machinery to do exactly this, to take device
- values in the target source colorspace and transform them into an
- actual output device colorspace. In the Video and Film industries a
- very similar, but less sophisticated means of doing this is to use
- 3DLuts, which come in a multitude of different format. ICC device
- links have the advantage of being a superset of 3dLuts, encapsulated
- in a standard file format.<br>
- <br>
- To facilitate Video calibration of certain Video systems, ArgyllCMS
- supports some 3DLut output options as part of <a
- href="collink.html">collink</a>.<br>
- <br>
- What follows here is an outline of how to create Video calibration
- 3DLuts using ArgyllCMS. First comes a general discussion of various
- aspects of video device links/3dLuts, and followed with some
- specific advice regarding the systems that ArgyllCMS supports. Last
- is some recommended scenarios for verifying the quality of Video
- calibration achieved.<br>
- <h5>1) How to display test patches.<br>
- </h5>
- Argyll's normal test patch display will be used by default, as long
- as any video encoding range considerations are dealt with (see
- Signal encoding below).<br>
- <br>
- An alternative when working with MadVR V 0.86.9 or latter, is to use
- the madTPG to display the patches in which case the MadVR video
- encoding range setting will operate. This can give some quality
- benefits due to MadVR's use of dithering. To display patches using
+ + + + profile chart.<br> + <br> + <br> + In a workflow <span style="font-weight: bold;">with</span> native + calibration capability, the calibration curves would be used with + printarg during subsequent <span style="font-weight: bold;">profiling</span> + so that any ink limit calculations will reflect final device values, + while not otherwise using the calibration within the ICC workflow:<br> + <br> + <a href="printtarg.html">printtarg</a> <a + href="printtarg.html#v">-v</a> <a href="printtarg.html#i">-ii1</a> + <a href="printtarg.html#p">-pA4</a> <a href="printtarg.html#I">-I + PrinterA_c.cal</a> <a href="printtarg.html#p1">PrinterA</a><br> + <br> + This will cause the .ti2 and resulting .ti3 and ICC profiles to + contain the calibration curves, allowing all the tools to be able to + compute final device value ink limits. The calibration curves must + also of course be installed into the printer. The means to do this + is currently outside the scope of Argyll (ie. either the print + system needs to be able to understand Argyll CAL format files, or + some tool will be needed to convert Argyll CAL files into the + printer calibration format).<br> + <br> + <br> + In a workflow <span style="font-weight: bold;">without</span> + native calibration capability, the calibration curves would be used + with printarg to <span style="text-decoration: underline;">apply</span> + the calibration to the test patch samples during subsequent <span + style="font-weight: bold;">profiling</span>, as well as embedding + it in the resulting .ti3 to allow all the tools to be able to + compute final device value ink limits:<br> + <br> + <a href="printtarg.html">printtarg</a> <a + href="printtarg.html#v">-v</a> <a href="printtarg.html#i">-ii1</a> + <a href="printtarg.html#p">-pA4</a> <a href="printtarg.html#K">-K + PrinterA_c.cal</a> <a href="printtarg.html#p1">PrinterA</a><br> + <a href="cctiff.html#p4"></a><br> + To apply calibration to an ICC profile, so that a calibration + unaware CMM can be used:<br> + <br> + <a href="applycal.html">applycal</a> <a + href="applycal.html#p1">PrinterA.cal</a> <a + href="applycal.html#p2">PrinterA.icm</a> <a + href="applycal.html#p3">PrinterA_cal.icm</a><br> + <br> + To apply color management and calibration to a raster image:<br> + <br> + <a href="cctiff.html">cctiff</a> + <a href="cctiff.html#p1">Source.icm</a> <a + href="cctiff.html#p1">PrinterA.icm</a> <a + href="cctiff.html#p2">PrinterA_c.cal</a> + <a href="cctiff.html#p3">infile.tif</a> <a + href="cctiff.html#p4">outfile.tif</a><br> + <br> + or<br> + <br> + <a href="cctiff.html">cctiff</a> + <a href="cctiff.html#p1">Source.icm</a> <a + href="cctiff.html#p1">PrinterA_c.icm</a> + <a href="cctiff.html#p3">infile.tif</a> <a + href="cctiff.html#p4">outfile.tif</a><br> + <br> + [ Note that cctiff will also process JPEG raster images. ]<br> + <br> + Another useful tool is <a href="synthcal.html">synthcal</a>, that + allows creating linear or synthetic calibration files for disabling + calibration or testing.<br> + Similarly, <a href="fakeread.html">fakeread</a> also supports + applying calibration curves and embedding them in the resulting .ti3 + file<br> + <br> + If you want to create a pre-conditioning profile for use with <a + href="targen.html#c">targen -c</a>, then use the PrinterA.icm + profile, <b>NOT</b> PrinterA_c.icm that has calibration curves + applied.<br> + <h4><a name="PC6"></a>How profile ink limits are handled when + calibration is being used.</h4> + Even though the profiling process is carried out on top of the + linearized device, and the profiling is generally unaware of the + underlying non-linearized device values, an exception is made in the + calculation of ink limits during profiling. This is made possible by + including the calibration curves in the profile charts .ti2 and + subsequent .ti3 file and resulting ICC profile <span + style="font-weight: bold;">'targ'</span> text tag, by way of the <span + style="font-weight: bold;">printtarg</span> <span + style="font-weight: bold;">-I</span> or <span style="font-weight: + bold;">-K</span> options. This is done on the assumption that the + physical quantity of ink is what's important in setting the ink + limit, and that the underlying non-linearized device values + represent such a physical quantity.<br> + <br> + <br> + <hr size="2" width="100%"> + <h3><a name="LP1"></a>Linking Profiles</h3> + Two device profiles can be linked together to create a device link + profile, than encapsulates a particular device to device transform. + Often this step is not necessary, as many systems and tools will + link two device profiles "on the fly", but creating a device link + profile gives you the option of using "smart CMM" techniques, such + as true gamut mapping, improved inverse transform accuracy, tailored + black generation and ink limiting.<br> + <br> + The overall process is to link the input space and output space + profiles using <a href="collink.html">collink</a>, creating a + device to device link profile. The device to device link profile can + then be used by cctiff (or other ICC device profile capable tools), + to color correct a raster files.<br> + <br> + Three examples will be given here, showing the three different modes + than <span style="font-weight: bold;">collink</span> supports.<br> + <br> + In <a href="collink.html#s">simple mode</a>, the two profiles are + linked together in a similar fashion to other <span + style="font-weight: bold;">CMMs</span> simply using the forward + and backwards color transforms defined by the profiles. Any gamut + mapping is determined by the content of the tables within the two + profiles, together with the particular intent chosen. Typically the + same intent will be used for both the source and destination + profile:<br> + <br> + <a href="collink.html">collink</a> <a href="collink.html#v">-v</a> + <a href="collink.html#q">-qm</a> <a href="collink.html#s">-s</a> <a + href="collink.html#si">-ip</a> <a href="collink.html#so">-op</a> + <a href="collink.html#p1">SouceProfile.icm</a> <a + href="collink.html#p2">DestinationProfile.icm</a> <a + href="collink.html#p3">Source2Destination.icm</a><br> + <br> + <br> + In <a href="collink.html#g">gamut mapping mode</a>, the + pre-computed intent mappings inside the profiles are not used, but + instead the gamut mapping between source and destination is tailored + to the specific gamuts of the two profiles, and the intent parameter + supplied to <span style="font-weight: bold;">collink</span>. + Additionally, source and destination viewing conditions should be + provided, to allow the color appearance space conversion to work as + intended. The colorimetric B2A table in the destination profile is + used, and this will determine any black generation and ink limiting:<br> + <br> + <a href="collink.html">collink</a> <a href="collink.html#v">-v</a> + <a href="collink.html#q">-qm</a> <a href="collink.html#g">-g</a> <a + href="collink.html#si">-ip</a> <a href="collink.html#c">-cmt</a> + <a href="collink.html#d">-dpp</a> <a href="collink.html#p1">MonitorSouceProfile.icm</a> + <a href="collink.html#p2">DestinationProfile.icm</a> <a + href="collink.html#p3">Source2Destination.icm</a><br> + <br> + [ If your viewing environment for the display and print doesn't + match the ones implied by the <a href="colprof.html#c">-cmt</a> and + <a href="colprof.html#d">-dpp</a> options, leave them out, and + evaluate what, if any appearance transformation is appropriate for + your environment at a later stage. ]<br> + <br> + In <a href="collink.html#G">inverse output table gamut mapping mode</a>, + the pre-computed intent mappings inside the profiles are not used, + but instead the gamut mapping between source and destination is + tailored to the specific gamuts of the two profiles, and the intent + parameter supplied to <span style="font-weight: bold;">collink</span>. + In addition, the B2A table is <span style="font-weight: bold;">not</span> + used in the destination profile, but the A2B table is instead + inverted, leading to improved transform accuracy, and in CMYK + devices, allowing the ink limiting and black generation parameters + to be set:<br> + <br> + For a CLUT table based RGB printer destination profile, the + following would be appropriate:<br> + <br> + <a href="collink.html">collink</a> <a href="collink.html#v">-v</a> + <a href="collink.html#q">-qm</a> <a href="collink.html#G">-G</a> <a + href="collink.html#si">-ip</a> <a href="collink.html#c">-cmt</a> + <a href="collink.html#d">-dpp</a> <a href="collink.html#p1">MonitorSouceProfile.icm</a> + <a href="collink.html#p2">RGBDestinationProfile.icm</a> <a + href="collink.html#p3">Source2Destination.icm</a><br> + <br> + For a CMYK profile, the total ink limit needs to be specified (a + typical value being 10% less than the value used in creating the + device test chart), and the type of black generation also needs to + be specified:<br> + <br> + <a href="collink.html">collink</a> <a href="collink.html#v">-v</a> + <a href="collink.html#q">-qm</a> <a href="collink.html#G">-G</a> <a + href="collink.html#si">-ip</a> <a href="collink.html#c">-cmt</a> + <a href="collink.html#d">-dpp</a> <a href="collink.html#l">-l250</a> + <a href="collink.html#k">-kr</a> <a href="collink.html#p1">MonitorSouceProfile.icm</a> + <a href="collink.html#p2">CMYKDestinationProfile.icm</a> <a + href="collink.html#p3">Source2Destination.icm</a><br> + <br> + Note that you should set the source (<a href="collink.html#c">-c</a>) + and destination (<a href="collink.html#d">-d</a>) viewing conditions + for the type of device the profile represents, and the conditions + under which it will be viewed.<br> + <br> + <h3><a name="LP3"></a>Image dependent gamut mapping using device + links<br> + </h3> + When images are stored in large gamut colorspaces (such as. L*a*b*, + ProPhoto, scRGB etc.), then using the colorspace gamut as the source + gamut for gamut mapping is generally a bad idea, as it leads to + overly compressed and dull images. The correct approach is to use a + source gamut that represents the gamut of the images themselves. + This can be created using tiffgamut, and an example workflow is as + follows:<br> + <br> + <a href="tiffgamut.html">tiffgamut</a> -f80 -pj -cmt ProPhoto.icm + image.tif<br> + <br> + <a href="collink.html">collink</a> <a href="collink.html#v">-v</a> + <a href="collink.html#q">-qh</a> <a href="collink.html#G">-G</a> <a + href="collink.html#Gp">image.gam</a> <a href="collink.html#si">-ip</a> + <a href="collink.html#c">-cmt</a> <a href="collink.html#d">-dpp</a> + <a href="collink.html#p1">ProPhoto.icm</a> <a + href="collink.html#p2">RGBDestinationProfile.icm</a> + <a href="collink.html#p3">Source2Destination.icm</a><br> + <br> + <a href="cctiff.html">cctiff</a> <a + href="cctiff.html#p1">Source2Destination.icm</a> + <a href="cctiff.html#p3">image.tif</a> <a + href="cctiff.html#p4">printfile.tif</a><br> + <br> + The printfile.tif is then send to the printer without color + management, (i.e. in the same way the printer characterization test + chart was printed), since it is in the printers native colorspace.<br> + <br> + You can adjust how conservatively the image gamut is preserved using + the tiffgamut -f parameter. Omitting it or using a larger value (up + to 100) preserves the color gradations of even the lesser used + colors, at the cost of compressing the gamut more.<br> + Using a smaller value will preserve the saturation of the most + popular colors, at the cost of not preserving the color gradations + of less popular colors.<br> + <br> + You can create a gamut that covers a set of source images by + providing more than one image file name to tiffgamut. This may be + more efficient for a group of related images, and ensures that + colors are transformed in exactly the same way for all of the + images.<br> + <br> + An alternative generating a gamut for a specific set of images, is + to use a general smaller gamut definition (i.e. the sRGB profile), + or a gamut that represents the typical range of colors you wish to + preserve.<br> + <br> + The arguments to collink should be appropriate for the output device + type - see the collink examples in the above section.<br> + <h3><a name="LP2"></a>Soft Proofing Link</h3> + Often it is desirable to get an idea what a particular devices + output will look like using a different device. Typically this might + be trying to evaluate print output using a display. Often it is + sufficient to use an absolute or relative colorimetric transform + from the print device space to the display space, but while these + provide a colorimetric preview of the result, they do not take into + account the subjective appearance differences due to the different + device conditions. It can therefore be useful to create a soft proof + appearance transform using collink:<br> + <br> + <a href="collink.html">collink</a> <a href="collink.html#v">-v</a> + <a href="collink.html#q">-qm</a> <a href="collink.html#G">-G</a> <a + href="collink.html#si">-ila</a> <a href="collink.html#c">-cpp</a> + <a href="collink.html#d">-dmt</a> <a href="collink.html#l">-t250</a> <a + href="collink.html#k"></a><a href="collink.html#p1">CMYKDestinationProfile.icm</a> + <a href="collink.html#p2">MonitorProfile.icm</a> <a + href="collink.html#p3">SoftProof.icm</a><br> + <br> + We use the Luminance matched appearance intent, to preserve the + subjective apperance of the target device, which takes into account + the viewing conditions and assumes adaptation to the differences in + the luminence range, but otherwise not attempting to compress or + change the gamut.<br> + <br> + If your viewing environment for the display and print doesn't match + the ones implied by the <a href="collink.html#c">-cpp</a> and <a + href="collink.html#d">-dmt</a> options, then either leave them out + or substitute values that do match your environment.<br> + + <hr size="2" width="100%"><br> + <h3><a name="TR1"></a>Transforming colorspaces of raster files</h3> + Although a device profile or device link profile may be useful with + other programs and systems, Argyll provides the tool <a + href="cctiff.html">cctiff</a> for directly applying a device to + device transform to a <a href="File_Formats.html#TIFF">TIFF</a> or + <a href="File_Formats.html#JPEG">JPEG</a> raster file. The cctiff + tool is capable of linking an arbitrary sequence of device profiles, + device links, abstract profiles and calibration curves. Each device + profile can be preceded by the <span style="font-weight: bold;">-i</span> + option to indicate the intent that should be used. Both 8 and 16 bit + per component files can be handled, and up to 8 color channels. The + color transform is optimized to perform the overall transformation + rapidly.<br> + <br> + If a device link is to be used, the following is a typical example:<br> + <br> + <a href="cctiff.html">cctiff</a> <a href="cctiff.html#p1">Source2Destination.icm</a> + <a href="cctiff.html#p3">infile.tif</a> <a href="cctiff.html#p4">outfile.tif</a><br> + or<br> + <a href="cctiff.html">cctiff</a> <a href="cctiff.html#p1">Source2Destination.icm</a> + <a href="cctiff.html#p3">infile.jpg</a> <a href="cctiff.html#p4">outfile.jpg</a><br> + <br> + <i><br> + </i>If a source and destination profile are to be used, the + following would be a typical example:<br> + <br> + <a href="cctiff.html"> cctiff</a> <a href="cctiff.html#i">-ip</a> + <a href="cctiff.html#p1i">SourceProfile.icm</a> <a + href="cctiff.html#i">-ip</a> <a href="cctiff.html#p1o">DestinationProfile.icm</a> + <a href="cctiff.html#p3">infile.tif</a> <a href="cctiff.html#p4">outfile.tif</a><br> + or<br> + <a href="cctiff.html"> cctiff</a> <a href="cctiff.html#i">-ip</a> + <a href="cctiff.html#p1i">SourceProfile.icm</a> <a + href="cctiff.html#i">-ip</a> <a href="cctiff.html#p1o">DestinationProfile.icm</a> + <a href="cctiff.html#p3">infile.jpg</a> <a href="cctiff.html#p4">outfile.jpg</a><br> + <br> + <br> + <hr size="2" width="100%"><br> + <h3><a name="TV1"></a>Creating Video Calibration 3DLuts</h3> + Video calibration typically involves trying to make your actual + display device emulate an ideal video display, one which matches + what your Video media was intended to be displayed on. An ICC device + link embodies the machinery to do exactly this, to take device + values in the target source colorspace and transform them into an + actual output device colorspace. In the Video and Film industries a + very similar, but less sophisticated means of doing this is to use + 3DLuts, which come in a multitude of different format. ICC device + links have the advantage of being a superset of 3dLuts, encapsulated + in a standard file format.<br> + <br> + To facilitate Video calibration of certain Video systems, ArgyllCMS + supports some 3DLut output options as part of <a + href="collink.html">collink</a>.<br> + <br> + What follows here is an outline of how to create Video calibration + 3DLuts using ArgyllCMS. First comes a general discussion of various + aspects of video device links/3dLuts, and followed with some + specific advice regarding the systems that ArgyllCMS supports. Last + is some recommended scenarios for verifying the quality of Video + calibration achieved.<br> + <h5>1) How to display test patches.<br> + </h5> + Argyll's normal test patch display will be used by default, as long + as any video encoding range considerations are dealt with (see + Signal encoding below).<br> + <br> + An alternative when working with MadVR V 0.86.9 or latter, is to use + the madTPG to display the patches in which case the MadVR video + encoding range setting will operate. This can give some quality + benefits due to MadVR's use of dithering. To display patches using MadVR rather than Argyll, start madTPG and then use the option "<b>-d -
- madvr</b>" in dispcal, dispread and dispwin. Leave the MadTPG
- "VideoLUT" and "3dluts" buttons in their default (enabled)
- state, as the various tools will automatically take care of
- disabling the 3dLut and/or calibration curves as needed.<br>
- <br>
- Another option is to use a <a
- href="http://en.wikipedia.org/wiki/Chromecast">ChromeCast</a>
- using the option "<b>-dcc</b>" in dispcal, dispread and dispwin.
- Note that the ChromeCast as a test patch source is probably the<b>
- least accurate</b> of your choices, since it up-samples the test
- patch and transforms from RGB to YCC and back, but should be
- accurate within ± 1 bit. You may have to modify any firewall to
- permit port 8081 to be accessed on your machine if it falls back to
- the Default receiver (see <a href="Installing.html">installation
- instructions</a> for your platform).
- <h5>2) White point calibration & neutral axis calibration.</h5>
- A Device Link is capable of embodying all aspects of the
- calibration, including correcting the white point and neutral axis
- behavior of the output device, but making such a Link just from two
- ICC profile requires the use of Absolute Colorimetric intent during
- linking, and this reduces flexibility. In addition, a typical ICC
- device profile may not capture the neutral axis behavior quite as
- well as an explicit calibration, since it doesn't sample the
- displays neutral axis behaviour in quite as much detail. It is often
- desirable therefore, to calibrate the display device so as to have
- the specific white point desired so that one of the white point
- relative linking intents can be used, and to improve the displays
- general neutral axis behavior so that subsequent profiling works to
- best advantage. In summary, there are basically 4 options in
- handling white point & neutral axis calibration:<br>
- <ul>
- <li>Don't bother correcting the white point. Most displays are
- close to the typical D65 target, and our eyes adapt to the white
- automatically unless it is very far from the daylight locus or
- we have something else to refer to. If this approach is taken,
- then display profiling and linking can ignore calibration, and
- one of the non Absolute Colorimetric intents (such as Relative
- Colorimetric) is chosen during profile linking. It is wise to
- make sure that the video card VideoLUTs are set to some known
- state (ie. linear using "dispwin -c" , or set by a an installed
- ICC display profile) though.<br>
- </li>
- <li>Calibrate the white point and linearise the neutral axis using
- the display controls. Many TV's have internal calibration
- controls that allow setting the white point, and possibly the
- neutral axis response. Either a dedicated Video calibration
+ + + + madvr</b>" in dispcal, dispread and dispwin. Leave the MadTPG + "VideoLUT" and "3dluts" buttons in their default (enabled) + state, as the various tools will automatically take care of + disabling the 3dLut and/or calibration curves as needed.<br> + <br> + Another option is to use a <a + href="http://en.wikipedia.org/wiki/Chromecast">ChromeCast</a> + using the option "<b>-dcc</b>" in dispcal, dispread and dispwin. + Note that the ChromeCast as a test patch source is probably the<b> + least accurate</b> of your choices, since it up-samples the test + patch and transforms from RGB to YCC and back, but should be + accurate within ± 1 bit. You may have to modify any firewall to + permit port 8081 to be accessed on your machine if it falls back to + the Default receiver (see <a href="Installing.html">installation + instructions</a> for your platform). + <h5>2) White point calibration & neutral axis calibration.</h5> + A Device Link is capable of embodying all aspects of the + calibration, including correcting the white point and neutral axis + behavior of the output device, but making such a Link just from two + ICC profile requires the use of Absolute Colorimetric intent during + linking, and this reduces flexibility. In addition, a typical ICC + device profile may not capture the neutral axis behavior quite as + well as an explicit calibration, since it doesn't sample the + displays neutral axis behaviour in quite as much detail. It is often + desirable therefore, to calibrate the display device so as to have + the specific white point desired so that one of the white point + relative linking intents can be used, and to improve the displays + general neutral axis behavior so that subsequent profiling works to + best advantage. In summary, there are basically 4 options in + handling white point & neutral axis calibration:<br> + <ul> + <li>Don't bother correcting the white point. Most displays are + close to the typical D65 target, and our eyes adapt to the white + automatically unless it is very far from the daylight locus or + we have something else to refer to. If this approach is taken, + then display profiling and linking can ignore calibration, and + one of the non Absolute Colorimetric intents (such as Relative + Colorimetric) is chosen during profile linking. It is wise to + make sure that the video card VideoLUTs are set to some known + state (ie. linear using "dispwin -c" , or set by a an installed + ICC display profile) though.<br> + </li> + <li>Calibrate the white point and linearise the neutral axis using + the display controls. Many TV's have internal calibration + controls that allow setting the white point, and possibly the + neutral axis response. Either a dedicated Video calibration package could be used, or ArgyllCMS <a href="dispcal.html">dispcal</a>'s @@ -3215,28 +3274,30 @@ a -
- interactive adjustment mode can be used to set the white point.
- Note that while adjusting the neutral axis for neutrality may
- help, the Device Link will override the transfer curve
- characteristic of the calibrated display, so aiming for a
- transfer curve approximately the same as the target and
- reasonably perceptually linear is all that is required. If this
- approach is taken, then display profiling and linking can ignore
- calibration, and one of the non Absolute Colorimetric intents is
- chosen during profile linking. It is wise to make sure that the
- video card VideoLUTs are set to some known state though.</li>
- <li>[<b>Recommended</b>] Calibrate the white point and neutral
- axis using ArgyllCMS <a href="dispcal.html">dispcal</a>. Since
- the Device Link will override the calibrated transfer curve
- characteristic of the display, there there may be no point in
- doing much more than a medium calibration, and choosing a
- standard that has a straight segment from black, such as L*a*b*,
- sRGB, Rec709 or SMPTE240 curve. The exact shape of the
- calibration curve is not critically important, as the profiling
- and 3dLut will set the final response. If this approach is
- taken, then the resulting calibration file should be provided to
- dispread as the <a href="dispcal.html#k">-k parameter</a> or <a
+ + + + interactive adjustment mode can be used to set the white point. + Note that while adjusting the neutral axis for neutrality may + help, the Device Link will override the transfer curve + characteristic of the calibrated display, so aiming for a + transfer curve approximately the same as the target and + reasonably perceptually linear is all that is required. If this + approach is taken, then display profiling and linking can ignore + calibration, and one of the non Absolute Colorimetric intents is + chosen during profile linking. It is wise to make sure that the + video card VideoLUTs are set to some known state though.</li> + <li>[<b>Recommended</b>] Calibrate the white point and neutral + axis using ArgyllCMS <a href="dispcal.html">dispcal</a>. Since + the Device Link will override the calibrated transfer curve + characteristic of the display, there there may be no point in + doing much more than a medium calibration, and choosing a + standard that has a straight segment from black, such as L*a*b*, + sRGB, Rec709 or SMPTE240 curve. The exact shape of the + calibration curve is not critically important, as the profiling + and 3dLut will set the final response. If this approach is + taken, then the resulting calibration file should be provided to + dispread as the <a href="dispcal.html#k">-k parameter</a> or <a href="dispcal.html#K">-K parameter</a>. See also below <b>Choice @@ -3249,476 +3310,478 @@ a -
- of where to apply display per channel calibration curves.</b></li>
- <li>Choose one of the Absolute Colorimetric intents in collink
- (ie. -i aw). This greatly reduces flexibility, and may not be
- quite as accurate as an explicit calibration.</li>
- </ul>
- If an explicit calibration is used, then it is a good idea to add
- some test points down the neutral axis when profiling (targen <a
- href="targen.html#g">-g parameter</a>). <br>
- <br>
- <b>3) Choice of where to apply display per channel calibration
- curves</b><br>
- <br>
- If calibration curves are going to be used, then it needs to be
- decided where they will be applied in the video processing chain.
- There are two options:<br>
- <br>
- <b>a)</b> Install the calibration curves in the playback system. On
- a PC the display, this can be done by loading the calibration curves
- into the Video Card temporarily using "dispwin calibration.cal", or
- installing the ICC profile into the system persistently using
- something like "<a href="dispwin.html#I">dispwin -I profile.icm</a>",<br>
- or when using MadVR 0.86.9 or latter by creating a 3dLut with
- appended calibration curves using <a href="collink#H">-H
- display.cal</a>.<br>
- <br>
- <b>b)</b> The calibration can be incorporated into the Device
- Link/3dLUT by providing it to collink as the <a
- href="collink.html#a">-a display.cal</a>. This is the only option
- if the video display path does not have some separate facility to
- handle calibration curves. Note that if the playback system has
- graphic card VideoLUTs then they will have to be set to a defined
- consistent state such as linear. When using MadVR 0.86.9 or latter
- this will be done automatically since the -a option will append a
- linear set of calibration curves to the 3dLut.<br>
- <br>
- The choice is dictated by a number of considerations:<br>
- <ul>
- <li>Does the video playback path have a facility for installing
- the calibration curves ? If playing back system is a PC, then
- typically the Graphics Card supports 1D VideoLUTs, thereby
- making a) a possible choice.<br>
- </li>
- <li>Does the video playback <u>always</u> play back through the
- Video Card VideoLUTs ? Some systems do not apply VIdeoLUTs to
- things like overlay plane rendering. If not, then you need to
- choose b), but also make sure that if it does use the Video Card
- VideoLUTs in some situations, that they are set to linear (ie.
- dispcal -c). One way of determining when the VideoLUTs get used
- or not is to load a distinct calibration such as "strange.cal"
- provided in the <b>ref</b> folder, and check visually if it is
- affecting the video or not, ie. "dispcal strange.cal". Note that
- using MadVR 0.86.9 or latter in combination with a 3dLut with
- appended calibration curves will apply the calibration even with
- overlay plane rendering.<br>
- </li>
- <li>Do you want/need other applications to share the calibration
- curves or profile or not ? If you do, then it is desirable to
- choose a).</li>
- <li>Quality considerations. VideoLUTs may or may not be of greater
- depth than the standard 8 bit per color component frame buffer.
- If they are, and the video path passes that extra depth through
- to the display, and the display is capable of using that extra
- depth, then a) may be a desirable choice from a quality point of
- view. You can get some idea whether this is the case by running
- "dispcal -R". If the VideoLUT depth is not better than 8 bits,
- then it may be more desirable to choose b), since renders like
- MadVR can use dithering to give better than 8 bits precision in
- the video playback.<br>
- </li>
- </ul>
- <h5>4) Output device calibration and profiling.</h5>
- Output device profiling should basically follow the guide above in <a
- href="#PM1b">Adjusting and Calibrating a displays</a> and <a
- href="#PM1">Profiling Displays</a>. The assumption is that either
- you are calibrating/profiling your computer display for video, or
- your TV is connected to the computer you are creating
- calibrations/profiles on, and that the connection between the PC and
- TV display is such that full range RGB signals are being used, or
- that the Video card has automatically or manually been configured to
- scale full range RGB values to Video levels for the TV. If the
- latter is not possible, then use the -E options on dispcal and
- dispread. (See <b>Signal encoding</b> bellow for more details on
- this). It may also improve the accuracy of the display profile if
- you use the <a href="dispread.html#Z">dispread -Z</a> option to
- quantize the test values to the precision of the display
- system. Don't use the -E options on dispcal and dispread, nor
- the -Z option on dispread if you are using MadVR to display test
- patches using the "-d madvr" option.<br>
- <br>
- Once the profile has been created, it is possible to then use the
- resulting Device Link/3DLut with signal encoding other than full
- range or Video level RGB. <br>
- <h5>5) Target colorspace<br>
- </h5>
- In practical terms, there are five common Video and Digital Cinema
- encoding colorspaces. <br>
- <br>
- For Standard Definition:<br>
- <br>
- EBU 3213 or "PAL 576i" primaries.<br>
- <br>
- SMPTE RP 145 or "NTSC 480i" primaries.<br>
- <br>
- For High Definition:<br>
- <br>
- Rec 709 primaries.<br>
- <br>
- For Ultra High Defintion<br>
- <br>
- Rec 2020 primaries.<br>
- <br>
- For Digital Cinema<br>
- <br>
- SMPTE-431-2 or "DCI-P3"<br>
- <br>
- PAL and NTSC have historically had poorly specified transfer curve
- encodings, and the Rec 709 HDTV encoding curve is the modern <a
- href="http://www.poynton.com/notes/DVAI/DVAI_TOC_full.html#23">recommendation</a>,
- but the overall interpretation of Video sources may in fact be
- partly determined by the expected standard Video display device
- characteristics (see <b>Viewing conditions adjustment and gamut
- mapping</b> below for more details).<br>
- <br>
- To enable targeting these colorspaces, ArgyllCMS provides 5 ICC
- profiles in the ref directory to use as source
- colorspaces: <br>
- <br>
- EBU3213_PAL.icm<br>
- <br>
- SMPTE_RP145_NTSC.icm<br>
- <br>
- Rec709.icm<br>
- <br>
- Rec2020.icm<br>
- <br>
- SMPTE431_P3.icm<br>
- <h5>6) Signal encoding</h5>
- Typical PC display output uses full range RGB signals (0 .. 255 in 8
- bit parlance), while typical Video encoding allows some head &
- footroom for overshoot and sync of digitized analog signals, and
- typically uses a 16..235 range in 8 bits. In many cases Video is
- encoded as luma and color difference signals YCbCr (loosely known as
- YUV as well), and this also uses a restricted range 16..235 for Y,
- and 16..240 for Cb and Cr in 8 bit encoding. The extended gamut
- xvYCC encoding uses 16..235 for Y, and 1..254 for Cb and Cr.<br>
- <br>
- The signal encoding comes into play in two situations: 1)
- Calibrating and profiling the display, and 2) Using the resulting
- Device Link/3DLut.<br>
- The encoding may need to be different in these two situations,
- either because different video source devices are being used for
- calibration/profiling and for video playback, or because the video
- playback system uses the Device Link/3DLut at a point in its
- processing pipeline that requires a specific encoding.<br>
- <br>
- For calibration & profiling, the display will be driven by a
- computer system so that dispcal and dispread can be used. By default
- these programs expect to output full range RGB signals, and it is
- assumed that either the display accepts full range signals, or that
- the graphics card or connection path has been setup to convert the
- full range values into Video range signals automatically or
- manually. If this is not the case, then both dispcal and dispread
- have a -E option that will modify them to output Video range RGB
- values.<br>
- <br>
- If MadVR is the target of the calibration and profiling, then there
- is an option to use it to display the calibration and profiling test
- patches (<b>-d madvr</b>). In this case, MadVR should be configured
- appropriately for full range or Video range encoding, and the -E
- flag should <u>not</u> be used with dispcal or dispread, since
- MadVR will be taking care of such conversions.<br>
- <br>
- If a calibration file was created using dispcal -E, then using it in
- dispread will automatically trigger Video level RGB signals during
- profiling. Any time such a Video level calibration is loaded into
- the Graphics card VideoLUTs using dispwin, or the calibration curve
- is converted to a 'vcgt' tag in a profile, the curve will also
- convert full range RGB to Video range RGB. This should be kept in
- mind so that if video playback is being performed with the
- calibration curves installed in the Graphics card VideoLUTs, that
- full range is converted only once to Video range (ie. In this
- situation MadVR output should be set to full range if being played
- back through the calibration curves in hardware, but only if dispcal
- -E has been used). On the other hand, if the calibration curves are
- incorporated into the DeviceLink/3dLUT, then the conversion to Video
- levels has to be done somewhere else in the pipeline, such as using
- MadVR video level output, or by the graphics card, etc.<br>
- <br>
- When creating the Device Link/3dLut, it is often necessary to
- specify one of the video encodings so that it fits in to the
- processing pipeline correctly. For instance the eeColor needs to
- have input and output encoding that suits the HDMI signals passing
- through it, typically Video Range RGB. MadVR needs Video Level RGB
- to match the values being passed through the 3dLut at that point.<br>
- <br>
- There are several version of YCbCr encoding supported as well, even
- though neither the eeColor nor the current version of MadVR need or
- can use them at present.<br>
- <h5>7) Black point mapping</h5>
- <p>Video encoding assumes that the black displayed on a device is a
- perfect black (zero light). No real device has a perfect black,
- and if a colorimetric intent is used then certain image values
- near black will get clipped to the display black point, loosing
- shadow detail. To avoid this, some sort of black point mapping is
- usually desirable. There are two mechanisms available in collink:
- a) Custom EOTF with input and/or output black point mapping, or b)
- using one of the smart gamut mapping intents that does black point
- mapping (e.g. la, p, pa, ms or s).<br>
- </p>
- <h5>8) Viewing conditions adjustment and gamut mapping</h5>
- <p> </p>
- <p>In historical TV systems, there is a viewing conditions
- adjustment being made between the bright studio conditions that TV
- is filmed in, and the typical dim viewing environment that people
- view it in. This is created by the difference between the encoding
- response curve gamma of about 2.0, and a typical CRT response
- curve gamma of 2.4. <br>
- </p>
- <p>In theory Rec709 defines the video encoding, but it seems in
- practice that much video material is adjusted to look as intended
- when displayed on a reference monitor having a display gamma of
- somewhere between 2.2 and 2.4, viewed in a dim viewing
- environment. The modern standard covering the display EOTF
- (Electro-Optical Transfer Curve) is <a
- href="http://www.itu.int/rec/R-REC-BT.1886-0-201103-I">BT.1886</a>,
- which defines a pure power 2.4 curve with an input offset and
- scale applied to account for the black point offset while
- retaining dark shadow tonality. So another means of making the
- viewing adjustment is to use the BT.1886-like EOTF for Rec709
- encoded material. Collink supports this using the <a
- href="collink.html#I">-I b</a>, and allows some control over the
- degree of viewing conditions adjustment by overriding the BT.1886
- gamma using the <a href="collink.html#Ib">-I b:g.g</a>
- parameter. This is the <b>recommended</b> approach to start with,
- since it gives good results with a single parameter.<br>
- </p>
- <p>The addition of a second optional parameter <a
- href="file:///D:/src/argyll/doc/collink.html#Ib">-I b:p.p:g.g</a>
- allows control over the degree of black point offset accounted for
- as an output offset, as opposed to input offset Once the effective
- gamma value has been chosen to suite the viewing conditions and
- set the overall contrast for mid greys, increasing the proportion
- of black offset accounted for in the output of the curve is a way
- of reducing the deep shadow detail, if it is being overly
- emphasized. </p>
- <p> An alternate approach to making this adjustment is to take
- advantage of the viewing conditions adjustment using the CIECAM02
- model available in collink. Some control over the degree of
- viewing conditions adjustment is possible by varying the viewing
- condition parameters. </p>
- <p>A third alternative is to combine the two approaches. The source
- is defined as Rec709 primaries with a BT.1886-like EOTF display in
- dim viewing conditions, and then CIECAM02 is used to adjust for
- the actual display viewing conditions. Once again, control over
- the degree of viewing conditions adjustment is possible by varying
- the viewing condition parameters<br>
- </p>
- <p><br>
- </p>
- <p><b>9) Correcting for any black point inaccuracy in the display
- profile</b><br>
- </p>
- <p>Some video display devices have particularly good black points,
- and any slight raising of the black due to innacuracies in the
- display profile near black can be objectionable. As well as using
- the <a href="targen.html#V">targen -V flag</a> to improve
- accuracy near black during profiling, if the display is known to
- be well behaved (ie. that it's darkest black is actually at RGB
- value 0,0,0), then the <a href="collink.html#b">collink -b</a>
- flag can be used, to force the source RGB 0,0,0 to map to the
- display 0,0,0.<br>
- </p>
- <h5>Putting it all together:</h5>
- In this example we choose to create a display calibration first
- using dispcal, and create a simple matrix profile as well:<br>
- <br>
- <tt>dispcal -v -o -qm -k0 -w 0.3127,0.3290 -gs -o TVmtx.icm
- TV</tt><br>
- <br>
- We are targeting a D65 white point (<tt>-w 0.3127,0.3290)</tt> and
- an sRGB response curve.<br>
- <br>
- If you are using the madTPG you would use:<br>
- <br>
- <tt>dispcal -v -d madvr -o -qm -k0 -w 0.3127,0.3290 -gs -o
- TVmtx.icm TV</tt><br>
- <br>
- Then we need to create a display patch test set. We can use the
- simple matrix to pre-condition the test patches, as this helps
- distribute them where they will be of most benefit. If have
- previously profiled your display, you should use that previous
- profile, or if you decided not to do a dispcal, then the Rec709.icm
- should be used as a substitute. Some per channel and a moderate
- number of full spread patches is used here - more will increase
- profiling accuracy, a smaller number will speed it up. Since the
- video or film material is typically viewed in a darkened viewing
- environment, and often uses a range of maximum brightnesses in
- different scenes, the device behavior in the dark regions of its
- response are often of great importance, and using the <a
- href="targen.html#V">targen -V</a> parameter can help improve the
- accuracy in this region at the expense of slightly lower accuracy in
- lighter regions.<br>
- <br>
- <tt>targen -v -d3 -s30 -g100 -f1000 -cTVmtx.icm -V1.8 TV</tt><br>
- <br>
- The display can then be measured:<br>
- <br>
- <tt>dispread -v -k -Z8 TV.cal TV</tt><br>
- <br>
- or using madTPG:<br>
- <br>
- dispread -v -d madvr -K TV.cal TV<br>
- <br>
- and then a cLUT type ICC profile created. Since we will be using
- collink smart linking, we minimize the B2A table size. We use the
- default colprof -V parameter carried through from targen:<br>
- <br>
- <tt>colprof -v -qh -bl TV</tt><br>
- <br>
- Make sure you check the delta E report at the end of the profile
- creation, to see if the sample data and profile is behaving
- reasonably. Depending on the type of device, and the consistency of
- the readings, average errors of 5 or less, and maximum errors of 15
- or less would normally be expected. If errors are grossly higher
- than this, then this is an indication that something is seriously
- wrong with the device measurement, or profile creation.<br>
- <br>
- If you would like to use the display ICC profile for general color
- managed applications, then you would compute a more complete
- profile:<br>
- <br>
- <tt>colprof -v -qh TV</tt><br>
- <br>
- The recommended approach then is to create a Device Link that uses a
- BT.1886 black point and viewing conditions adjustment, say one of
- the following:<br>
- <br>
- <tt> collink -v -Ib:2.4 -b -G -ir Rec709.icm TV.icm
- HD.icm # dark conditions</tt><tt><br>
- </tt><tt> collink -v -Ib -b -G -ir
- Rec709.icm TV.icm HD.icm # dim conditions - good
- default</tt><tt><br>
- </tt><tt> collink -v -Ib:2.1 -b -G -ir Rec709.icm TV.icm
- HD.icm # mid to dim conditions</tt><tt><br>
- </tt><tt> collink -v -Ib:2.0 -b -G -ir Rec709.icm TV.icm
- HD.icm # mid to light conditions</tt><br>
- <br>
- or you could do it using pure CIECAM02 adjustment and a black point
- mapping:<br>
- <br>
- <tt> collink -v -ctv -dmd -da:1 -G -ila Rec709.icm TV.icm
- HD.icm # very dark conditions</tt><tt><br>
- </tt><tt> collink -v -ctv -dmd -da:3 -G -ila Rec709.icm
- TV.icm HD.icm # dim conditions</tt><tt><br>
- </tt><tt> collink -v -ctv -dmd -da:7 -G -ila Rec709.icm
- TV.icm HD.icm # mid to dim conditions - good default</tt><tt><br>
- </tt><tt> collink -v -ctv -dmd -da:15 -G -ila Rec709.icm
- TV.icm HD.icm # mid conditions</tt><br>
- <br>
- or using both to model a reference video display system that is
- adapted to your viewing conditions:<br>
- <tt><br>
- </tt><tt> collink -v -Ib -c md -dmd -da:5 -G -ila
- Rec709.icm TV.icm HD.icm # very dark conditions</tt><tt><br>
- </tt><tt> collink -v -Ib -c md -dmd -da:10 -G -ila Rec709.icm
- TV.icm HD.icm # dim conditions</tt><tt><br>
- </tt><tt> collink -v -Ib -c md -dmd -da:18 -G -ila Rec709.icm
- TV.icm HD.icm # mid to dark conditions</tt><tt><br>
- </tt><tt> collink -v -Ib -c md -dmd -da:30 -G -ila Rec709.icm
- TV.icm HD.icm # mid to dark conditions</tt><br>
- <br>
- None of the above examples incorporate the calibration curves, so it
- is assumed that the calibration curves would be installed so that
- the Video Card applies calibration, ie:<br>
- <br>
- <tt>dispwin TV.cal</tt><br>
- <br>
- or the simple matrix profile installed:<br>
- <br>
- <tt>dispwin -I TVmtx.icm</tt><br>
- <br>
- or a the more complete display profile could be installed:<br>
- <br>
- dispwin -I TV.icm<br>
- <br>
- See also <a href="dispprofloc.html">here</a> for information on how
- to make sure the calibration is loaded on each system start. If not,
- then you will want to incorporate the calibration in the Device
- Link/3dlut by using collink "-a TV.cal".<br>
- <br>
- If the video path needs Video Level RGB encoding but does not
- provide a means to do this, then you will want to include the <b>-E</b>
- flag in the dispcal and dispread command lines above.<br>
- <br>
- Below are specific recommendation for the eeColor and MadVR that
- include the flags to create the .3dlut and encode the input and
- output values appropriately, but only illustrate using the
- recommended BT.1886 black point and viewing conditions adjustments,
- rather than illustrating CIECAM02 etc. use.<br>
- <br>
- For faster exploration of different collink option, you could omit
- the "colprof -bl" option, and use collink "-g" instead of "-G",
- since this<br>
- will greatly speed up collink. Once you are happy with the link
- details, you can then generate a higher quality link/3dLut using
- "collink -G ..".<br>
- <br>
- You can also increase the precision of the device profile by
- increasing the number of test patches measured (ie. up to a few
- thousand, depending on how long you are prepared to wait for the
- measurement to complete, and how stable your display and instrument
- are).<br>
- <br>
- Alternatives to relative colorimetric rendering ("-i r") or
- luminance matched appearance ("-i la") used in the examples above
- and below, are, perceptual ("-i p") which will ensure that the
- source gamut is compressed rather than clipped by the display, or
- even a saturation rendering ("-i ms"), which will expand the gamut
- of the source to the full range of the output.<br>
- <br>
- <br>
- <b>eeColor</b><br>
- <br>
- For PC use, where the encoding is full range RGB:<br>
- <br>
- <tt>collink -v -3e -Ib -b -G -ir -a TV.cal Rec709.icm TV.icm
- HD.icm </tt><br>
- <br>
- For correct operation both the 3DLut HD.txt and the per channel
- input curves HD-first1dred.txt, HD-first1dgreen.txt and
- HD-first1dblue.txt. the latter by copying them over the default
- input curve files uploaded by the TruVue application.<br>
- <br>
- See <a
- href="http://www.avsforum.com/t/1464890/eecolor-processor-argyllcms"><http://www.avsforum.com/t/1464890/eecolor-processor-argyllcms></a>
- for some more details.<br>
- <br>
- Where the eeColor is connected from a Video source using HDMI, it
- will probably be processing TV RGB levels, or YCbCr encoded signals
- that it converts to/from RGB internally, so<br>
- <br>
- <tt>collink -v -3e -et -Et -Ib -b -G -ir -a TV.cal
- Rec709.icm TV.icm HD.icm </tt><br>
- <br>
- in this case just the HD.txt file needs installing on the eeColor,
- but make sure that the original linear "first1*.txt files are
- re-installed, or install the ones generated by collink, which will
- be linear for -e t mode.<br>
- <br>
- <b>MadVR</b><br>
- <br>
- MadVR 0.86.9 or latter has a number of features to support accurate
- profiling and calibration, and is the recommended version to
- use. It converts from the media colorspace to the 3dLut input
- space automatically with the type of source being played, but has
- configuration for to 5 3dLuts, each one optimized for a particular
- source color space. The advantage of building and installing several
- 3dLuts is that unnecessary gamut clipping can be avoided.<br>
- <br>
- If you are just building one 3dLut then Rec709 source is a good one
- to pick.<br>
- <br>
- If you want to share the VideoLUT calibration curves between your
- normal desktop and MadVR, then it is recommended that you install
- the display ICC profile and use the -H option:<br>
- <br>
- <tt> collink -v -3m -et -Et -Ib -b -G -ir -H
- TV.cal Rec709.icm TV.icm HD.icm</tt><tt><br>
- </tt><tt> </tt><tt><br>
+ + + + of where to apply display per channel calibration curves.</b></li> + <li>Choose one of the Absolute Colorimetric intents in collink + (ie. -i aw). This greatly reduces flexibility, and may not be + quite as accurate as an explicit calibration.</li> + </ul> + If an explicit calibration is used, then it is a good idea to add + some test points down the neutral axis when profiling (targen <a + href="targen.html#g">-g parameter</a>). <br> + <br> + <b>3) Choice of where to apply display per channel calibration + curves</b><br> + <br> + If calibration curves are going to be used, then it needs to be + decided where they will be applied in the video processing chain. + There are two options:<br> + <br> + <b>a)</b> Install the calibration curves in the playback system. On + a PC the display, this can be done by loading the calibration curves + into the Video Card temporarily using "dispwin calibration.cal", or + installing the ICC profile into the system persistently using + something like "<a href="dispwin.html#I">dispwin -I profile.icm</a>",<br> + or when using MadVR 0.86.9 or latter by creating a 3dLut with + appended calibration curves using <a href="collink#H">-H + display.cal</a>.<br> + <br> + <b>b)</b> The calibration can be incorporated into the Device + Link/3dLUT by providing it to collink as the <a + href="collink.html#a">-a display.cal</a>. This is the only option + if the video display path does not have some separate facility to + handle calibration curves. Note that if the playback system has + graphic card VideoLUTs then they will have to be set to a defined + consistent state such as linear. When using MadVR 0.86.9 or latter + this will be done automatically since the -a option will append a + linear set of calibration curves to the 3dLut.<br> + <br> + The choice is dictated by a number of considerations:<br> + <ul> + <li>Does the video playback path have a facility for installing + the calibration curves ? If playing back system is a PC, then + typically the Graphics Card supports 1D VideoLUTs, thereby + making a) a possible choice.<br> + </li> + <li>Does the video playback <u>always</u> play back through the + Video Card VideoLUTs ? Some systems do not apply VIdeoLUTs to + things like overlay plane rendering. If not, then you need to + choose b), but also make sure that if it does use the Video Card + VideoLUTs in some situations, that they are set to linear (ie. + dispcal -c). One way of determining when the VideoLUTs get used + or not is to load a distinct calibration such as "strange.cal" + provided in the <b>ref</b> folder, and check visually if it is + affecting the video or not, ie. "dispcal strange.cal". Note that + using MadVR 0.86.9 or latter in combination with a 3dLut with + appended calibration curves will apply the calibration even with + overlay plane rendering.<br> + </li> + <li>Do you want/need other applications to share the calibration + curves or profile or not ? If you do, then it is desirable to + choose a).</li> + <li>Quality considerations. VideoLUTs may or may not be of greater + depth than the standard 8 bit per color component frame buffer. + If they are, and the video path passes that extra depth through + to the display, and the display is capable of using that extra + depth, then a) may be a desirable choice from a quality point of + view. You can get some idea whether this is the case by running + "dispcal -R". If the VideoLUT depth is not better than 8 bits, + then it may be more desirable to choose b), since renders like + MadVR can use dithering to give better than 8 bits precision in + the video playback.<br> + </li> + </ul> + <h5>4) Output device calibration and profiling.</h5> + Output device profiling should basically follow the guide above in <a + href="#PM1b">Adjusting and Calibrating a displays</a> and <a + href="#PM1">Profiling Displays</a>. The assumption is that either + you are calibrating/profiling your computer display for video, or + your TV is connected to the computer you are creating + calibrations/profiles on, and that the connection between the PC and + TV display is such that full range RGB signals are being used, or + that the Video card has automatically or manually been configured to + scale full range RGB values to Video levels for the TV. If the + latter is not possible, then use the -E options on dispcal and + dispread. (See <b>Signal encoding</b> bellow for more details on + this). It may also improve the accuracy of the display profile if + you use the <a href="dispread.html#Z">dispread -Z</a> option to + quantize the test values to the precision of the display + system. Don't use the -E options on dispcal and dispread, nor + the -Z option on dispread if you are using MadVR to display test + patches using the "-d madvr" option.<br> + <br> + Once the profile has been created, it is possible to then use the + resulting Device Link/3DLut with signal encoding other than full + range or Video level RGB. <br> + <h5>5) Target colorspace<br> + </h5> + In practical terms, there are five common Video and Digital Cinema + encoding colorspaces. <br> + <br> + For Standard Definition:<br> + <br> + EBU 3213 or "PAL 576i" primaries.<br> + <br> + SMPTE RP 145 or "NTSC 480i" primaries.<br> + <br> + For High Definition:<br> + <br> + Rec 709 primaries.<br> + <br> + For Ultra High Defintion<br> + <br> + Rec 2020 primaries.<br> + <br> + For Digital Cinema<br> + <br> + SMPTE-431-2 or "DCI-P3"<br> + <br> + PAL and NTSC have historically had poorly specified transfer curve + encodings, and the Rec 709 HDTV encoding curve is the modern <a + href="http://www.poynton.com/notes/DVAI/DVAI_TOC_full.html#23">recommendation</a>, + but the overall interpretation of Video sources may in fact be + partly determined by the expected standard Video display device + characteristics (see <b>Viewing conditions adjustment and gamut + mapping</b> below for more details).<br> + <br> + To enable targeting these colorspaces, ArgyllCMS provides 5 ICC + profiles in the ref directory to use as source + colorspaces: <br> + <br> + EBU3213_PAL.icm<br> + <br> + SMPTE_RP145_NTSC.icm<br> + <br> + Rec709.icm<br> + <br> + Rec2020.icm<br> + <br> + SMPTE431_P3.icm<br> + <h5>6) Signal encoding</h5> + Typical PC display output uses full range RGB signals (0 .. 255 in 8 + bit parlance), while typical Video encoding allows some head & + footroom for overshoot and sync of digitized analog signals, and + typically uses a 16..235 range in 8 bits. In many cases Video is + encoded as luma and color difference signals YCbCr (loosely known as + YUV as well), and this also uses a restricted range 16..235 for Y, + and 16..240 for Cb and Cr in 8 bit encoding. The extended gamut + xvYCC encoding uses 16..235 for Y, and 1..254 for Cb and Cr.<br> + <br> + The signal encoding comes into play in two situations: 1) + Calibrating and profiling the display, and 2) Using the resulting + Device Link/3DLut.<br> + The encoding may need to be different in these two situations, + either because different video source devices are being used for + calibration/profiling and for video playback, or because the video + playback system uses the Device Link/3DLut at a point in its + processing pipeline that requires a specific encoding.<br> + <br> + For calibration & profiling, the display will be driven by a + computer system so that dispcal and dispread can be used. By default + these programs expect to output full range RGB signals, and it is + assumed that either the display accepts full range signals, or that + the graphics card or connection path has been setup to convert the + full range values into Video range signals automatically or + manually. If this is not the case, then both dispcal and dispread + have a -E option that will modify them to output Video range RGB + values.<br> + <br> + If MadVR is the target of the calibration and profiling, then there + is an option to use it to display the calibration and profiling test + patches (<b>-d madvr</b>). In this case, MadVR should be configured + appropriately for full range or Video range encoding, and the -E + flag should <u>not</u> be used with dispcal or dispread, since + MadVR will be taking care of such conversions.<br> + <br> + If a calibration file was created using dispcal -E, then using it in + dispread will automatically trigger Video level RGB signals during + profiling. Any time such a Video level calibration is loaded into + the Graphics card VideoLUTs using dispwin, or the calibration curve + is converted to a 'vcgt' tag in a profile, the curve will also + convert full range RGB to Video range RGB. This should be kept in + mind so that if video playback is being performed with the + calibration curves installed in the Graphics card VideoLUTs, that + full range is converted only once to Video range (ie. In this + situation MadVR output should be set to full range if being played + back through the calibration curves in hardware, but only if dispcal + -E has been used). On the other hand, if the calibration curves are + incorporated into the DeviceLink/3dLUT, then the conversion to Video + levels has to be done somewhere else in the pipeline, such as using + MadVR video level output, or by the graphics card, etc.<br> + <br> + When creating the Device Link/3dLut, it is often necessary to + specify one of the video encodings so that it fits in to the + processing pipeline correctly. For instance the eeColor needs to + have input and output encoding that suits the HDMI signals passing + through it, typically Video Range RGB. MadVR needs Video Level RGB + to match the values being passed through the 3dLut at that point.<br> + <br> + There are several version of YCbCr encoding supported as well, even + though neither the eeColor nor the current version of MadVR need or + can use them at present.<br> + <h5>7) Black point mapping</h5> + <p>Video encoding assumes that the black displayed on a device is a + perfect black (zero light). No real device has a perfect black, + and if a colorimetric intent is used then certain image values + near black will get clipped to the display black point, loosing + shadow detail. To avoid this, some sort of black point mapping is + usually desirable. There are two mechanisms available in collink: + a) Custom EOTF with input and/or output black point mapping, or b) + using one of the smart gamut mapping intents that does black point + mapping (e.g. la, p, pa, ms or s).<br> + </p> + <h5>8) Viewing conditions adjustment and gamut mapping</h5> + <p> </p> + <p>In historical TV systems, there is a viewing conditions + adjustment being made between the bright studio conditions that TV + is filmed in, and the typical dim viewing environment that people + view it in. This is created by the difference between the encoding + response curve gamma of about 2.0, and a typical CRT response + curve gamma of 2.4. <br> + </p> + <p>In theory Rec709 defines the video encoding, but it seems in + practice that much video material is adjusted to look as intended + when displayed on a reference monitor having a display gamma of + somewhere between 2.2 and 2.4, viewed in a dim viewing + environment. The modern standard covering the display EOTF + (Electro-Optical Transfer Curve) is <a + href="http://www.itu.int/rec/R-REC-BT.1886-0-201103-I">BT.1886</a>, + which defines a pure power 2.4 curve with an input offset and + scale applied to account for the black point offset while + retaining dark shadow tonality. So another means of making the + viewing adjustment is to use the BT.1886-like EOTF for Rec709 + encoded material. Collink supports this using the <a + href="collink.html#I">-I b</a>, and allows some control over the + degree of viewing conditions adjustment by overriding the BT.1886 + gamma using the <a href="collink.html#Ib">-I b:g.g</a> + parameter. This is the <b>recommended</b> approach to start with, + since it gives good results with a single parameter.<br> + </p> + <p>The addition of a second optional parameter <a + href="collink.html#Ib">-I b:p.p:g.g</a> + allows control over the degree of black point offset accounted for + as an output offset, as opposed to input offset Once the effective + gamma value has been chosen to suite the viewing conditions and + set the overall contrast for mid greys, increasing the proportion + of black offset accounted for in the output of the curve is a way + of reducing the deep shadow detail, if it is being overly + emphasized. </p> + <p> An alternate approach to making this adjustment is to take + advantage of the viewing conditions adjustment using the CIECAM02 + model available in collink. Some control over the degree of + viewing conditions adjustment is possible by varying the viewing + condition parameters. </p> + <p>A third alternative is to combine the two approaches. The source + is defined as Rec709 primaries with a BT.1886-like EOTF display in + dim viewing conditions, and then CIECAM02 is used to adjust for + the actual display viewing conditions. Once again, control over + the degree of viewing conditions adjustment is possible by varying + the viewing condition parameters<br> + </p> + <p><br> + </p> + <p><b>9) Correcting for any black point inaccuracy in the display + profile</b><br> + </p> + <p>Some video display devices have particularly good black points, + and any slight raising of the black due to innacuracies in the + display profile near black can be objectionable. As well as using + the <a href="targen.html#V">targen -V flag</a> to improve + accuracy near black during profiling, if the display is known to + be well behaved (ie. that it's darkest black is actually at RGB + value 0,0,0), then the <a href="collink.html#b">collink -b</a> + flag can be used, to force the source RGB 0,0,0 to map to the + display 0,0,0.<br> + </p> + <h5>Putting it all together:</h5> + In this example we choose to create a display calibration first + using dispcal, and create a simple matrix profile as well:<br> + <br> + <tt>dispcal -v -o -qm -k0 -w 0.3127,0.3290 -gs -o TVmtx.icm + TV</tt><br> + <br> + We are targeting a D65 white point (<tt>-w 0.3127,0.3290)</tt> and + an sRGB response curve.<br> + <br> + If you are using the madTPG you would use:<br> + <br> + <tt>dispcal -v -d madvr -o -qm -k0 -w 0.3127,0.3290 -gs -o + TVmtx.icm TV</tt><br> + <br> + Then we need to create a display patch test set. We can use the + simple matrix to pre-condition the test patches, as this helps + distribute them where they will be of most benefit. If have + previously profiled your display, you should use that previous + profile, or if you decided not to do a dispcal, then the Rec709.icm + should be used as a substitute. Some per channel and a moderate + number of full spread patches is used here - more will increase + profiling accuracy, a smaller number will speed it up. Since the + video or film material is typically viewed in a darkened viewing + environment, and often uses a range of maximum brightnesses in + different scenes, the device behavior in the dark regions of its + response are often of great importance, and using the <a + href="targen.html#V">targen -V</a> parameter can help improve the + accuracy in this region at the expense of slightly lower accuracy in + lighter regions.<br> + <br> + <tt>targen -v -d3 -s30 -g100 -f1000 -cTVmtx.icm -V1.8 TV</tt><br> + <br> + The display can then be measured:<br> + <br> + <tt>dispread -v -k -Z8 TV.cal TV</tt><br> + <br> + or using madTPG:<br> + <br> + dispread -v -d madvr -K TV.cal TV<br> + <br> + and then a cLUT type ICC profile created. Since we will be using + collink smart linking, we minimize the B2A table size. We use the + default colprof -V parameter carried through from targen:<br> + <br> + <tt>colprof -v -qh -bl TV</tt><br> + <br> + Make sure you check the delta E report at the end of the profile + creation, to see if the sample data and profile is behaving + reasonably. Depending on the type of device, and the consistency of + the readings, average errors of 5 or less, and maximum errors of 15 + or less would normally be expected. If errors are grossly higher + than this, then this is an indication that something is seriously + wrong with the device measurement, or profile creation.<br> + <br> + If you would like to use the display ICC profile for general color + managed applications, then you would compute a more complete + profile:<br> + <br> + <tt>colprof -v -qh TV</tt><br> + <br> + The recommended approach then is to create a Device Link that uses a + BT.1886 black point and viewing conditions adjustment, say one of + the following:<br> + <br> + <tt> collink -v -Ib:2.4 -b -G -ir Rec709.icm TV.icm + HD.icm # dark conditions</tt><tt><br> + </tt><tt> collink -v -Ib -b -G -ir + Rec709.icm TV.icm HD.icm # dim conditions - good + default</tt><tt><br> + </tt><tt> collink -v -Ib:2.1 -b -G -ir Rec709.icm TV.icm + HD.icm # mid to dim conditions</tt><tt><br> + </tt><tt> collink -v -Ib:2.0 -b -G -ir Rec709.icm TV.icm + HD.icm # mid to light conditions</tt><br> + <br> + or you could do it using pure CIECAM02 adjustment and a black point + mapping:<br> + <br> + <tt> collink -v -ctv -dmd -da:1 -G -ila Rec709.icm TV.icm + HD.icm # very dark conditions</tt><tt><br> + </tt><tt> collink -v -ctv -dmd -da:3 -G -ila Rec709.icm + TV.icm HD.icm # dim conditions</tt><tt><br> + </tt><tt> collink -v -ctv -dmd -da:7 -G -ila Rec709.icm + TV.icm HD.icm # mid to dim conditions - good default</tt><tt><br> + </tt><tt> collink -v -ctv -dmd -da:15 -G -ila Rec709.icm + TV.icm HD.icm # mid conditions</tt><br> + <br> + or using both to model a reference video display system that is + adapted to your viewing conditions:<br> + <tt><br> + </tt><tt> collink -v -Ib -c md -dmd -da:5 -G -ila + Rec709.icm TV.icm HD.icm # very dark conditions</tt><tt><br> + </tt><tt> collink -v -Ib -c md -dmd -da:10 -G -ila Rec709.icm + TV.icm HD.icm # dim conditions</tt><tt><br> + </tt><tt> collink -v -Ib -c md -dmd -da:18 -G -ila Rec709.icm + TV.icm HD.icm # mid to dark conditions</tt><tt><br> + </tt><tt> collink -v -Ib -c md -dmd -da:30 -G -ila Rec709.icm + TV.icm HD.icm # mid to dark conditions</tt><br> + <br> + None of the above examples incorporate the calibration curves, so it + is assumed that the calibration curves would be installed so that + the Video Card applies calibration, ie:<br> + <br> + <tt>dispwin TV.cal</tt><br> + <br> + or the simple matrix profile installed:<br> + <br> + <tt>dispwin -I TVmtx.icm</tt><br> + <br> + or a the more complete display profile could be installed:<br> + <br> + dispwin -I TV.icm<br> + <br> + See also <a href="dispprofloc.html">here</a> for information on how + to make sure the calibration is loaded on each system start. If not, + then you will want to incorporate the calibration in the Device + Link/3dlut by using collink "-a TV.cal".<br> + <br> + If the video path needs Video Level RGB encoding but does not + provide a means to do this, then you will want to include the <b>-E</b> + flag in the dispcal and dispread command lines above.<br> + <br> + Below are specific recommendation for the eeColor and MadVR that + include the flags to create the .3dlut and encode the input and + output values appropriately, but only illustrate using the + recommended BT.1886 black point and viewing conditions adjustments, + rather than illustrating CIECAM02 etc. use.<br> + <br> + For faster exploration of different collink option, you could omit + the "colprof -bl" option, and use collink "-g" instead of "-G", + since this<br> + will greatly speed up collink. Once you are happy with the link + details, you can then generate a higher quality link/3dLut using + "collink -G ..".<br> + <br> + You can also increase the precision of the device profile by + increasing the number of test patches measured (ie. up to a few + thousand, depending on how long you are prepared to wait for the + measurement to complete, and how stable your display and instrument + are).<br> + <br> + Alternatives to relative colorimetric rendering ("-i r") or + luminance matched appearance ("-i la") used in the examples above + and below, are, perceptual ("-i p") which will ensure that the + source gamut is compressed rather than clipped by the display, or + even a saturation rendering ("-i ms"), which will expand the gamut + of the source to the full range of the output.<br> + <br> + <br> + <b>eeColor</b><br> + <br> + For PC use, where the encoding is full range RGB:<br> + <br> + <tt>collink -v -3e -Ib -b -G -ir -a TV.cal Rec709.icm TV.icm + HD.icm </tt><br> + <br> + For correct operation both the 3DLut HD.txt and the per channel + input curves HD-first1dred.txt, HD-first1dgreen.txt and + HD-first1dblue.txt. the latter by copying them over the default + input curve files uploaded by the TruVue application.<br> + <br> + See <a + href="http://www.avsforum.com/t/1464890/eecolor-processor-argyllcms"><http://www.avsforum.com/t/1464890/eecolor-processor-argyllcms></a> + for some more details.<br> + <br> + Where the eeColor is connected from a Video source using HDMI, it + will probably be processing TV RGB levels, or YCbCr encoded signals + that it converts to/from RGB internally, so<br> + <br> + <tt>collink -v -3e -et -Et -Ib -b -G -ir -a TV.cal + Rec709.icm TV.icm HD.icm </tt><br> + <br> + in this case just the HD.txt file needs installing on the eeColor, + but make sure that the original linear "first1*.txt files are + re-installed, or install the ones generated by collink, which will + be linear for -e t mode.<br> + <br> + <b>MadVR</b><br> + <br> + MadVR 0.86.9 or latter has a number of features to support accurate + profiling and calibration, and is the recommended version to + use. It converts from the media colorspace to the 3dLut input + space automatically with the type of source being played, but has + configuration for to 5 3dLuts, each one optimized for a particular + source color space. The advantage of building and installing several + 3dLuts is that unnecessary gamut clipping can be avoided.<br> + <br> + If you are just building one 3dLut then Rec709 source is a good one + to pick.<br> + <br> + If you want to share the VideoLUT calibration curves between your + normal desktop and MadVR, then it is recommended that you install + the display ICC profile and use the -H option:<br> + <br> + <tt> collink -v -3m -et -Et -Ib -b -G -ir -H + TV.cal Rec709.icm TV.icm HD.icm</tt><tt><br> + </tt><tt> </tt><tt><br> </tt><tt> collink -v -3m -et -Et -Ib -b -G -ir </tt><tt><tt>-H @@ -3742,9 +3805,11 @@ a -
- TV.cal </tt>EBU3213_PAL.icm TV.icm SD_PAL.icm</tt><tt><br>
- </tt><tt> </tt><tt><br>
+ + + + TV.cal </tt>EBU3213_PAL.icm TV.icm SD_PAL.icm</tt><tt><br> + </tt><tt> </tt><tt><br> </tt><tt> collink -v -3m -et -Et -Ib -b -G -ir </tt><tt><tt>-H @@ -3768,16 +3833,18 @@ a -
- TV.cal </tt>SMPTE_RP145_NTSC.icm TV.icm SD_NTSC.icm</tt><br>
- <br>
- For best quality it is better to let MadVR apply the calibration
- curves using dithering, and allow it to set the graphics card to
- linear by using the -a option:<br>
- <br>
- <tt> collink -v -3m -et -Et -Ib -b -G -ir -a
- TV.cal Rec709.icm TV.icm HD.icm</tt><tt><br>
- </tt><tt> </tt><tt><br>
+ + + + TV.cal </tt>SMPTE_RP145_NTSC.icm TV.icm SD_NTSC.icm</tt><br> + <br> + For best quality it is better to let MadVR apply the calibration + curves using dithering, and allow it to set the graphics card to + linear by using the -a option:<br> + <br> + <tt> collink -v -3m -et -Et -Ib -b -G -ir -a + TV.cal Rec709.icm TV.icm HD.icm</tt><tt><br> + </tt><tt> </tt><tt><br> </tt><tt> collink -v -3m -et -Et -Ib -b -G -ir </tt><tt><tt>-a @@ -3801,9 +3868,11 @@ a -
- TV.cal </tt>EBU3213_PAL.icm TV.icm SD_PAL.icm</tt><tt><br>
- </tt><tt> </tt><tt><br>
+ + + + TV.cal </tt>EBU3213_PAL.icm TV.icm SD_PAL.icm</tt><tt><br> + </tt><tt> </tt><tt><br> </tt><tt> collink -v -3m -et -Et -Ib -b -G -ir </tt><tt><tt>-a @@ -3827,182 +3896,184 @@ a -
- TV.cal </tt>SMPTE_RP145_NTSC.icm TV.icm SD_NTSC.icm</tt><br>
- <br>
- the consequence though is that the appearance of other application
- will shift when MadVR is using the 3dLut and loading the calibration
- curves.<br>
- <br>
- The 3dLut can be used by opening the MadVR settings dialog,
- selecting "calibration" and then selecting "calibrate this display
- by using an external 3DLUT file", and then using the file dialog to
- use it.<br>
- <br>
- If neither the -a no -H options are used, then no calibration curves
- will be appended to the 3dLut, and MadVR will not change the
- VideoLUTs when that 3dLut is in use. It is then up to you to manage
- the graphics card VideoLUTs in some other fashion.<tt><br>
- <br>
- </tt>
- <hr size="2" width="100%"><br>
- <h3><a name="TV2"></a>Verifying Video Calibration</h3>
- <p>Often it is desirable to verify the results of a video
- calibration and profile, and the following gives an outline of how
- to use ArgyllCMS tools to do this. It is only possible to expect
- perfect verification if a colorimetric intent was used during
- linking - currently it's not possible to exactly verify a
- perceptual or CIECAM02 viewing condition adjusted link.<br>
- <br>
- </p>
- <p>The first step is to create a set of test points. This is
- essentially the same as creating a set of test points for the
- purposes of profiling, although it is best not to create exactly
- the same set, so as to explore the colorspace at different
- locatioins. For the purposes here, we'll actually create a regular
- grid test set, since this makes it easier to visualize the
- results, although a less regular set would probably be better for
- numerical evaluation:<br>
- </p>
- <p> targen -v -d3 -e1 -m6 -f0 -W verify<br>
- </p>
- <p>We make sure there is at least one white patch usin g -e1, a 20%
- increment grid using -m6, no full spread patches, and create an
- X3DOM 3d visualization of the point set using the -W flag. It is
- good to take a look at the verifyd.x3d.html file using a Web
- browser. You may want to create several test sets that look at
- particular aspects, ie. neutral axis response, pure colorant
- responses, etc.<br>
- </p>
- <p>Next we create a reference file by simulating the expected
- response of the perfect video display system. Assuming the collink
- options were "-et -Et -Ib -G -ir Rec709.icm TV.icm HD.icm" then we
- would:<tt><tt><br>
- </tt></tt></p>
- <p><tt><tt> copy verify.ti1 ref.ti1<br>
- fakeread -v -b -Z8 TV.icm Rec709.icm ref<br>
- </tt></tt></p>
- <p>You should adjust the parameters as necessary, so that the
- reference matches the link options. For instance, if your link
- options included "-I b:0.2:2.15" then the equivalent fakeread
- option "-b 0.2:2.15:TV.icm" should be used, etc.<br>
- </p>
- <hr size="2" width="20%">
- <p>A sanity check we can make at this point is to see what the
- expected result of the profiling & calibration will be, by
- simulating the reproduction of this test set:<br>
- </p>
- <p><tt> copy verify.ti1 checkA.ti1</tt><tt><br>
- fakeread -v -et -Z8 -p HD.icm -Et TV.icm checkA<br>
- </tt></p>
- <p>If you used collink -a, then the calibration incorporated in the
- device link needs to be undone to match what the display profile
- expects:</p>
- <p><tt> fakeread -v -et -Z8 -p HD.icm -Et -K TV.cal TV.icm
- checkA</tt></p>
- <p><tt>and then you can verify:<br>
- </tt></p>
- <p><tt> colverify -v -n -w -x ref.ti3 checkA.ti3<br>
- </tt></p>
- <p>If you have targeted some other white point rather than video D65
- for the display, then use the -N flag instead of -n to align the
- white points. [ Note that there can be some small discrepancies in
- this case in some parts of the color space if a CIECAM02 linking
- intent was used, due to the slightly different chromatic
- adaptation algorithm it uses compared to the one used by verify to
- match the white points.]<tt><br>
- </tt></p>
- <p><tt> v</tt><tt>erify -v -N -w -x ref.ti3 checkA.ti3</tt><br>
- </p>
- <p>This will give a numerical report of the delta E's, and also
- generate an X3DOM plot of the errors in L*a*b* space. The
- important thing is to take a look at the checkA.x3d.html file, to
- see if gamut clipping is occurring - this is the case if the large
- error vectors are on the sides or top of the gamut. Note that the
- perfect cube device space values become a rather distorted cube
- like shape in the perceptual L*a*b* space. If the vectors are
- small in the bulk of the space, then this indicates that the link
- is likely to be doing the right thing in making the display
- emulate the video colorspace with a BT.1886 like black point
- adjustment. You could also check just the in gamut test points
- using:<br>
- </p>
- <p><tt> v</tt><tt>erify -v -N -w -x -L TV.icm ref.ti3
- checkA.ti3<br>
- <br>
- </tt></p>
- <hr size="2" width="20%">
- <p>You can explicitly compare the gamuts of your video space and
- your display using the gamut tools:<br>
- </p>
- <p><tt> iccgamut -ff -ia Rec709</tt><tt><br>
- </tt><tt> iccgamut -ff -ia TV.icm</tt><tt><br>
- </tt><tt> viewgam -i Rec709.gam TV.gam gamuts</tt><br>
- </p>
- <p>and look at the gamuts.x3d.html file, as well as taking notice of
- % of the video volume that the display intersects. The X3DOM solid
- volume will be the video gamut, while the wire frame is the
- display gamut. If you are not targetting D65 with your display,
- you should use iccgamut <b>-ir</b> instead of <b>-ia</b>, so as
- to align the white points.<br>
- </p>
- <hr size="2" width="20%">
- <p>The main verification check is to actually measure the display
- response and compare it against the reference. Make sure the
- display is setup as you would for video playback and then use
- dispread:<br>
- </p>
- <p><tt> copy verify.ti1 checkB.ti1</tt><tt><br>
- </tt><tt> dispread -v -Z8 checkB</tt><br>
- </p>
- <p>You would add any other options needed (such as <b>-y</b> etc.)
- to set your instrument up properly. If you are using madTPG, then
- configure madVR to use the 3dLut you want to measure as the
- default, and also use the dispread -V flag to make sure that the
- 3dLut is being used for the measurements: [<b>Note</b> that if the
- version of MadVR you are using does not have radio buttons in its
- calibration setup to indicate a default 3dLut, then the 3dLut
- under test should be the only one set - all others should be
- blank. ]<br>
- </p>
- <p><tt> dispread -v -d madvr -V checkB</tt><br>
- </p>
- <p>Verify the same way as above:<br>
- </p>
- <p><tt> v</tt><tt>erify -v -n -w -x ref.ti3 checkB.ti3<br>
- </tt></p>
- <p>If your display does not cover the full gamut of your video
- source, the errors are probably dominated by out of gamut colors.
- You can verify just the in gamut test values by asking verify to
- skip them, and this will give a better notion of the actual device
- link and calibration accuracy:<tt><br>
- </tt></p>
- <p><tt> v</tt><tt>erify -v -n -w -x -L TV.icm ref.ti3
- checkB.ti3</tt></p>
- <p><br>
- </p>
- <p> <br>
- </p>
- <p><br>
- <br>
- </p>
- <br>
- <br>
- <br>
- <br>
- <br>
- <br>
- <br>
- <br>
- <br>
- <br>
- <br>
- <br>
- <br>
- <br>
- <br>
- <br>
- <br>
- <br>
- </body>
-</html>
+ + + + TV.cal </tt>SMPTE_RP145_NTSC.icm TV.icm SD_NTSC.icm</tt><br> + <br> + the consequence though is that the appearance of other application + will shift when MadVR is using the 3dLut and loading the calibration + curves.<br> + <br> + The 3dLut can be used by opening the MadVR settings dialog, + selecting "calibration" and then selecting "calibrate this display + by using an external 3DLUT file", and then using the file dialog to + use it.<br> + <br> + If neither the -a no -H options are used, then no calibration curves + will be appended to the 3dLut, and MadVR will not change the + VideoLUTs when that 3dLut is in use. It is then up to you to manage + the graphics card VideoLUTs in some other fashion.<tt><br> + <br> + </tt> + <hr size="2" width="100%"><br> + <h3><a name="TV2"></a>Verifying Video Calibration</h3> + <p>Often it is desirable to verify the results of a video + calibration and profile, and the following gives an outline of how + to use ArgyllCMS tools to do this. It is only possible to expect + perfect verification if a colorimetric intent was used during + linking - currently it's not possible to exactly verify a + perceptual or CIECAM02 viewing condition adjusted link.<br> + <br> + </p> + <p>The first step is to create a set of test points. This is + essentially the same as creating a set of test points for the + purposes of profiling, although it is best not to create exactly + the same set, so as to explore the colorspace at different + locatioins. For the purposes here, we'll actually create a regular + grid test set, since this makes it easier to visualize the + results, although a less regular set would probably be better for + numerical evaluation:<br> + </p> + <p> targen -v -d3 -e1 -m6 -f0 -W verify<br> + </p> + <p>We make sure there is at least one white patch usin g -e1, a 20% + increment grid using -m6, no full spread patches, and create an + X3DOM 3d visualization of the point set using the -W flag. It is + good to take a look at the verifyd.x3d.html file using a Web + browser. You may want to create several test sets that look at + particular aspects, ie. neutral axis response, pure colorant + responses, etc.<br> + </p> + <p>Next we create a reference file by simulating the expected + response of the perfect video display system. Assuming the collink + options were "-et -Et -Ib -G -ir Rec709.icm TV.icm HD.icm" then we + would:<tt><tt><br> + </tt></tt></p> + <p><tt><tt> copy verify.ti1 ref.ti1<br> + fakeread -v -b -Z8 TV.icm Rec709.icm ref<br> + </tt></tt></p> + <p>You should adjust the parameters as necessary, so that the + reference matches the link options. For instance, if your link + options included "-I b:0.2:2.15" then the equivalent fakeread + option "-b 0.2:2.15:TV.icm" should be used, etc.<br> + </p> + <hr size="2" width="20%"> + <p>A sanity check we can make at this point is to see what the + expected result of the profiling & calibration will be, by + simulating the reproduction of this test set:<br> + </p> + <p><tt> copy verify.ti1 checkA.ti1</tt><tt><br> + fakeread -v -et -Z8 -p HD.icm -Et TV.icm checkA<br> + </tt></p> + <p>If you used collink -a, then the calibration incorporated in the + device link needs to be undone to match what the display profile + expects:</p> + <p><tt> fakeread -v -et -Z8 -p HD.icm -Et -K TV.cal TV.icm + checkA</tt></p> + <p><tt>and then you can verify:<br> + </tt></p> + <p><tt> colverify -v -n -w -x ref.ti3 checkA.ti3<br> + </tt></p> + <p>If you have targeted some other white point rather than video D65 + for the display, then use the -N flag instead of -n to align the + white points. [ Note that there can be some small discrepancies in + this case in some parts of the color space if a CIECAM02 linking + intent was used, due to the slightly different chromatic + adaptation algorithm it uses compared to the one used by verify to + match the white points.]<tt><br> + </tt></p> + <p><tt> v</tt><tt>erify -v -N -w -x ref.ti3 checkA.ti3</tt><br> + </p> + <p>This will give a numerical report of the delta E's, and also + generate an X3DOM plot of the errors in L*a*b* space. The + important thing is to take a look at the checkA.x3d.html file, to + see if gamut clipping is occurring - this is the case if the large + error vectors are on the sides or top of the gamut. Note that the + perfect cube device space values become a rather distorted cube + like shape in the perceptual L*a*b* space. If the vectors are + small in the bulk of the space, then this indicates that the link + is likely to be doing the right thing in making the display + emulate the video colorspace with a BT.1886 like black point + adjustment. You could also check just the in gamut test points + using:<br> + </p> + <p><tt> v</tt><tt>erify -v -N -w -x -L TV.icm ref.ti3 + checkA.ti3<br> + <br> + </tt></p> + <hr size="2" width="20%"> + <p>You can explicitly compare the gamuts of your video space and + your display using the gamut tools:<br> + </p> + <p><tt> iccgamut -ff -ia Rec709</tt><tt><br> + </tt><tt> iccgamut -ff -ia TV.icm</tt><tt><br> + </tt><tt> viewgam -i Rec709.gam TV.gam gamuts</tt><br> + </p> + <p>and look at the gamuts.x3d.html file, as well as taking notice of + % of the video volume that the display intersects. The X3DOM solid + volume will be the video gamut, while the wire frame is the + display gamut. If you are not targetting D65 with your display, + you should use iccgamut <b>-ir</b> instead of <b>-ia</b>, so as + to align the white points.<br> + </p> + <hr size="2" width="20%"> + <p>The main verification check is to actually measure the display + response and compare it against the reference. Make sure the + display is setup as you would for video playback and then use + dispread:<br> + </p> + <p><tt> copy verify.ti1 checkB.ti1</tt><tt><br> + </tt><tt> dispread -v -Z8 checkB</tt><br> + </p> + <p>You would add any other options needed (such as <b>-y</b> etc.) + to set your instrument up properly. If you are using madTPG, then + configure madVR to use the 3dLut you want to measure as the + default, and also use the dispread -V flag to make sure that the + 3dLut is being used for the measurements: [<b>Note</b> that if the + version of MadVR you are using does not have radio buttons in its + calibration setup to indicate a default 3dLut, then the 3dLut + under test should be the only one set - all others should be + blank. ]<br> + </p> + <p><tt> dispread -v -d madvr -V checkB</tt><br> + </p> + <p>Verify the same way as above:<br> + </p> + <p><tt> v</tt><tt>erify -v -n -w -x ref.ti3 checkB.ti3<br> + </tt></p> + <p>If your display does not cover the full gamut of your video + source, the errors are probably dominated by out of gamut colors. + You can verify just the in gamut test values by asking verify to + skip them, and this will give a better notion of the actual device + link and calibration accuracy:<tt><br> + </tt></p> + <p><tt> v</tt><tt>erify -v -n -w -x -L TV.icm ref.ti3 + checkB.ti3</tt></p> + <p><br> + </p> + <p> <br> + </p> + <p><br> + <br> + </p> + <br> + <br> + <br> + <br> + <br> + <br> + <br> + <br> + <br> + <br> + <br> + <br> + <br> + <br> + <br> + <br> + <br> + <br> + </body> +</html> |