dispcalGUI—Open Source Display Calibration and Characterization powered by Argyll CMS

Platforms:: Linux/Unix with X11
Mac OS X >= 10.4
Windows 2000 and newer
Versions:: 0.5.8.0 (Linux)
0.5.8.0 (Mac OS X)
0.5.8.0 (Windows)
0.5.8.0 (Source)
Changelog
Updated:: 2010-07-25 13:19 (UTC)
Author:: Florian Höch
License:: GPL Version 3

Bug reports, questions, comments, suggestions? Feel free to use the dispcalGUI-users mailing list, issue tracker, support and discussion forums, or drop me a mail: dispcalGUI ‹at› hoech . net
If you just want to be notified of new releases, you may sign up to the dispcalGUI-news mailing list (but if you already joined dispcalGUI-users, there's no need to join this list as new release notifications are sent to both).

About
- Screenshots
Disclaimer
A note about colorimeters, wide-gamut displays and dispcalGUI
Download
Quick setup guide
Prerequisites
Installation
Basic concept of display calibration
Usage
Menu commands
Known issues / solutions
To-Do / planned features
Thanks and acknowledgements
Version history / changelog
Definitions

About

dispcalGUI is a graphical frontend for several utilities from the open source color management system Argyll CMS by Graeme W. Gill, specifically dispcal, dispread, colprof and dispwin, which when used together allow you to calibrate and profile your display using a measurement device. Of course, you can do a lot more with Argyll CMS, but this is not the scope of this document—refer to the Argyll CMS documentation for in-depth information and usage scenarios.
dispcalGUI opens a main GUI^[4] window when run, and a terminal-like window will be shown at the beginning of interactive display adjustment, which is currently needed for direct keyboard interaction with the Argyll CMS tools. It will be replaced with a graphical interface in the future. The main window is used to set options and access functionality.

Screenshots

GNOME

GNOME: Gamut Mapping Options

GNOME: Edit Testchart

GNOME: Display Adjustment

GNOME: Measure

GNOME: View Curves

KDE4

Mac OS X

Windows 7

Disclaimer

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

dispcalGUI is written in Python and uses the 3rd-party packages appscript (AppleScript library, only on Mac OS X), demjson (JSON^[6] library) and wxPython (GUI^[4] toolkit). It also makes extensive use of several Argyll CMS utilities. The build system to create standalone executables additionally uses setuptools and py2app on Mac OS X or py2exe on Windows. All of these software packages are © by their respective authors.

A note about colorimeters, wide-gamut displays and dispcalGUI

Colorimeters need a correction matrix in hardware or software to obtain correct measurements from wide-gamut displays. The latter is currently not supported by dispcalGUI, so if you own a wide-gamut display and colorimeter which has not been specifically tuned for this display (i.e. does not contain a correction matrix in hardware), you will need a spectrometer to accurately measure such a screen. If you buy a screen bundled with a colorimeter, the instrument usually has been matched to the screen in some way. But it may be the case that you have to use the supplied software to get correct results, if the correction matrix isn't implemented in the instrument's hardware.

Download

Linux DEB/RPM packages

Native packages for several distributions are available via my openSUSE Build Service repository:

Linux Autopackage

Universal install that should work on a multitude of distributions.

Autopackage (Python 2.5, 2.6 and 2.7, x86 and x86_64)

Stand-alone executable

This is what you should get if you don't have Python installed or cannot satisfy all prerequisites.

Mac OS X DMG
Windows Installer | ZIP

Source code

This is what you need to compile from source. You need to have a working Python installation and all prerequisites.

All platforms Tarball

Alternatively, if you don't mind trying out development code, browse the SVN [8] repository of the latest development version (or do a full checkout using svn co https://dispcalgui.svn.sourceforge.net/svnroot/dispcalgui dispcalGUI). But please note that the development code might contain bugs or not run at all, or only on some platform(s). Use at your own risk.

Quick setup guide

This short guide intends to get you up and running quickly, but if you run into a problem, you should refer to the full Prerequisites and Installation sections.

Get and install the latest release of dispcalGUI. It is recommended to first remove all previous versions.
Download and unpack the Argyll CMS archive file: Linux | Mac OS | Windows. Put the extracted directory (Argyll_VX.X.X) in a convenient place on your harddisk.

If you want to use the HCFR colorimeter on Mac OS X: Follow the instructions under installing Argyll CMS on Mac OS X to enable it.

If you use Windows Vista/7 64-bit: Read installing Argyll USB drivers on Windows Vista/7 64-bit
Launch dispcalGUI. If it cannot determine the path to the Argyll CMS binaries, it will prompt you to select the location manually on first launch.

If your measurement device is a Spyder 2: Choose “Enable Spyder 2 colorimeter...” from dispcalGUI's “Tools” menu. If you don't have the spyder software installed or its location cannot be determined, you will be prompted to select the setup executable that came with the instrument's installation media to enable it.
Connect your measurement device to your computer.
Driver installation - Windows only: If you already have drivers for your measurement device installed, read “Adding Argyll drivers to existing drivers” (if you are using vendor drivers) or “Updating Argyll drivers” (if you use a prior version of the Argyll drivers) in Installing Argyll CMS on Microsoft Windows. If this is a fresh install, a “Found new hardware” dialog should appear:
- Under Windows Vista/7...
  - Select “Locate and install driver software (recommended)”.
  - If a “User Account Control” window pops up, select “Continue”.
  - Select “Don't search online”.
  - Select “I don't have the disc, show me other options”.
  - Select “Browse my computer for driver software (advanced)”.
- Under XP...
  - In the window “Can Windows connect to Windows Update to search for software?” select “No, not this time” and “Next”.
  - Select “Install from a list or specific location (advanced)” then “Next”.
  - Select “Search for the best driver in these locations”, “Include this location in the search” and “Browse...”.
- Under 2000...
  - Select “Next”, then “Search for a suitable driver for my device (recommended)”, and “Next” again.
  - Tick the “Specify a location” box, then select “Next”.
  - In the window “Insert the manufacturer's installation disk” select “Browse...”.
- Locate the “libusbw” subdirectory in your Argyll_VX.X.X directory (under Windows 2000, you also need to select the .inf file that corresponds to your device, then select “Open” and “OK”). Select “Next”.
- Under Windows Vista/7, if a “Windows Security” dialog pops up, select “Install this driver software anyway”.
- A window stating the successful installation of the driver should show. Click “Finish”/“Close”.
The instrument should show up in the dropdown menu within about 10 seconds.

If you cannot access your instrument, first try unplugging and reconnecting it, or a reboot.
Linux only: If that doesn't help, read Installing Argyll CMS on Linux: Setting up instrument access.
Refer to the Usage instructions.

Prerequisites

Argyll CMS

To use dispcalGUI, you need to download and install Argyll CMS (>= v1.0.0).

If you do not know Argyll CMS yet, be sure to look at the documentation, specifically the list of supported instruments and installation instructions (also, please pay attention to the installation instructions for your measurement device).

Additional prerequisites for unattended calibration and profiling

Normally, the Argyll command line utilities require keyboard input before any measurements. Starting from dispcalGUI v0.2.5b, when using an instrument that is supported by the unattended feature (see below), it is no longer necessary to manually start the measurements for profiling after calibration.

Unattended calibration and profiling currently supports the following instruments:

X-Rite DTP94
X-Rite/GretagMacbeth i1 Display 2
Datacolor/ColorVision Spyder 2
Datacolor/ColorVision Spyder 3 *

* Argyll CMS >= 1.1.0

Additional prerequisites for using the non-standalone release and source code

You can skip this section if you downloaded a standalone executable of dispcalGUI for your operating system and do not want to install any of the python package releases or compile from source.

All platforms:

Python >= v2.5 < v3.0 (2.6 is the recommended version. Mac OS X users: If you want to compile dispcalGUI from source, it is advisable to first install XCode and then the official python.org Python)
wxPython GUI^[4] toolkit

Mac OS X:

py-appscript

Windows:

pywin32
WMI

Optional for all platforms:

NumPy (when installed, it enables the curve viewer)

Additional prerequisites for compiling

You can skip this section if you downloaded a python package of dispcalGUI for your operating system and do not want to compile from source.

Linux:

GCC and development headers for Python + X11 + Xrandr + Xinerama + Xxf86vm if not already installed, they should be available through your distribution's packaging system

Mac OS X:

XCode
py2app if you want to build a standalone executable (install setuptools first: sudo python util/ez_setup.py -Z setuptools)

Windows:

a C-compiler (e.g. MS Visual C++ Express or MinGW. If you're using the official python.org Python 2.6 or later I'd recommend Visual C++ Express as it works out of the box)
py2exe if you want to build a standalone executable

You can run directly from (compiled) source without installation if you want. To do this, you need to build the extension modules “in-place”:

Open a shell.
cd into the source directory (dispcalGUI-<version>).
Run python setup.py build_ext -i (on Linux, you can also untar RealDisplaySizeMM.py<PYTHON_VERSION>.<PLATFORM>.so.tar inside the dispcalGUI subdirectory instead)

You can then run python dispcalGUI.pyw (or launch it by double-clicking).

Installation

It is recommended to first remove all previous versions.

Linux Autopackage (.package)

Before installing the autopackage, first install wxPython (on some systems called python-wxGTK) and optionally numpy (enables the curve viewer) using your system's package management software. To install the autopackage, follow “How to install Linux autopackages in 4 easy steps” (off-site link).

Standalone executable

Mac OS X

Mount the disk image and drag the application icon to your “Applications” folder, then simply run it from there.

Windows (Installer)

Launch the installer which will guide you trough the required setup steps.

Windows (ZIP)

Unpack and then simply run dispcalGUI from the created folder.

Source code (all platforms)

See the “Prerequisites” section to run directly from source without installation.

Starting with dispcalGUI 0.2.5b, you can use standard distutils/setuptools commands with setup.py to build, install, and create packages. sudo python setup.py install will compile the extension modules and do a standard installation. Run python setup.py --help or python setup.py --help-commands for more information. A few additional commands and options which are not part of distutils or setuptools (and thus do not appear in the help) are also available:

Additional setup commands

bdist_appdmg (Mac OS X only): Creates a DMG of a previously created (by the py2app or bdist_standalone commands) application bundle.
bdist_deb (Linux/Debian-based): Create an installable Debian (.deb) package, much like the standard distutils command bdist_rpm for RPM packages. Prerequisites: You first need to install alien and rpmdb, create a dummy RPM database via sudo rpmdb --initdb, then edit (or create from scratch) the setup.cfg (you can have a look at misc/setup.ubuntu9.cfg for a working example).
bdist_standalone: Creates a standalone executable that does not require a Python installation. Uses bbfreeze on Linux, py2app on Mac OS X and py2exe on Windows. setup.py will try and automatically download/install these packages for you if they are not yet installed and if not using the --use-distutils switch. Note: On Mac OS X, py2app is not able to access files inside python “egg” files (which are basically zip-compressed folders). Setuptools, which is needed by py2app, will normally be installed in “egg” form, thus preventing py2app from accessing its contents. To fix this, you need to remove any installed setuptools-<version>-py<python-version>.egg files from your Python installation's site-packages directory (normally found under /Library/Frameworks/Python.framework/Versions/Current/lib). Then, run sudo python util/ez_setup.py -Z setuptools which will install setuptools unpacked, thus allowing py2app to acces all its files.
buildservice: Creates control files for openSUSE Build Service (also happens implicitly when invoking sdist).
finalize_msi (Windows only): Adds icons and start menu shortcuts to the MSI installer previously created with bdist_msi. Successful MSI creation needs a patched msilib (additional information).
inno (Windows only): Creates an Inno Setup install script for an executable created with the py2exe or bdist_standalone commands.
purge: Removes the build, dispcalGUI.egg-info directories and their contents.
purge_dist: Removes the dist directory and its contents.
readme: Creates README.html by parsing misc/README.template.html and substituting placeholders like date and version numbers.
uninstall: Uninstalls the package. You can specify the same options as for the install command.

Additional setup options

--cfg=<name>: Use an alternate setup.cfg, e.g. tailored for a given Linux distribution. The original setup.cfg is backed up and restored afterwards. The alternate file must exist as misc/setup.<name>.cfg
-n, --dry-run: Don't actually do anything. Useful in combination with the uninstall command to see which files would be removed.
--skip-instrument-configuration-files: Skip installation of udev rules and hotplug scripts.
--use-distutils: Force setup to use distutils (default) instead of setuptools. This is useful in combination with the bdist* commands, because it will avoid an artificial dependency on setuptools. This is actually a switch, use it once and the choice is remembered until you specify the --use-setuptools switch (see next paragraph).
--use-setuptools: Force setup to try and use setuptools instead of distutils. This is actually a switch, use it once and the choice is remembered until you specify the --use-distutils switch (see above).

Basic concept of display calibration and profiling

If you have previous experience, skip to Usage. If you are new to display calibration, here is a quick outline of the basic concept.

First, the display behavior is measured and adjusted to meet user-definable target characteristics, like brightness, gamma and white point. This step is generally referred to as calibration. Calibration is done by adjusting the monitor controls, and the output of the graphics card (via calibration curves, also called LUT^[7] curves, but please note the difference between these curves and so-called LUT profiles) to get as close as possible to the chosen target.
To meet the user-defined target characteristics, it is generally advisable to get as far as possible by using the monitor controls, and only thereafter by manipulating the output of the video card via calibration curves, which are loaded into the so-called video card gamma table, to get the best results.

Second, the calibrated displays behavior is measured and an ICC^[5] profile describing the response of the display is created.

Optionally and for convenience purposes, the calibration is stored in the profile, but both still need to be used together to get correct results. This can lead to some ambiguity, because loading the calibration curves from the profile is generally the responsibility of a third party utility or the OS (currently, the only OS that applies calibration curves out-of-the-box is Mac OS X—for other OS's, dispcalGUI takes care of creating an appropriate loader), while applications using the profile to do color transforms usually rely on the calibration being already loaded. Even non-color-managed applications will benefit from a loaded calibration because it is stored in the graphics card—it is “global”. But the calibration alone will not yield accurate colors—only fully color-managed applications will make use of display profiles and the necessary color transforms. Regrettably there are several image viewing and editing applications that only implement half-baked color management by not using the system's display profile (or any display profile at all), but an internal and often unchangeable “default” color space like sRGB, and sending output unaltered to the display after converting to that default colorspace. If the display's actual response is close to sRGB, you might get pleasing (albeit not accurate) results, but on displays which behave differently, for example wide-color-gamut displays, even mundane colors can get a strong tendency towards neon.

Usage

Through the GUI^[4], you can choose your settings. When running calibration measurements, a terminal-like window will be shown during the interactive part of display adjustment, which is currently needed for direct keyboard interaction with the Argyll CMS tools. It will be replaced with a graphical interface in the future.

Settings file

Here, you can load a calibration (.cal) or ICC profile (.icc / .icm) file from a previous run. This will set options to those stored in the file and also load calibration curves (if any) into the video card. If the file contains only a subset of settings, you will get a message showing which settings were loaded.

If a calibration file or profile is loaded in this way, its name will show up here to indicate that the settings reflect those in the file.
Also, if a calibration is present it can be used as the base when “Just Profiling”.
The chosen settings file will stay as long as you do not change any of the calibration or profiling settings, with one exception: When a .cal file with the same base name as the settings file exists in the same directory, adjusting the quality and profiling controls will not cause unloading of the settings file. This allows you to use an existing calibration with new profiling settings for “Just Profiling”, or to update an existing calibration with different quality and/or profiling settings. If you change settings in other situations, the file will get unloaded (but current settings will be retained—unloading just happens to remind you that the settings no longer match those in the file), and current display profile's calibration curves will be restored (if present, otherwise they will reset to linear).

When a calibration file is loaded or present, the “Update calibration” checkbox will become available, which takes less time than a calibration from scratch. If an ICC^[5] profile with the same base name as the settings file exists in the same directory, the “Update profile” checkbox will also be available. If you place a check in that box, all options and the “Calibrate & profile” and “Just profile” buttons at the bottom will get grayed out, but don't worry, the “Calibrate” button takes care of the profile in that case.

Predefined settings (presets)

Starting with dispcalGUI v0.2.5b, predefined settings for several use cases are selectable in the settings dropdown. I strongly recommend to NOT view these presets as the solitary “correct” settings you absolutely should use unmodified if your use case matches their description. Rather view them as starting points, from where you can work towards your own, optimized (in terms of your requirements, hardware, surroundings, and personal preference) settings.

Why has a default gamma of 2.2 been chosen for the presets?

Many displays, be it CRT or LCD type, have a default response characteristic close to a gamma of approx. 2.2-2.4 (for CRTs, this is the actual native behaviour; and LCDs typically try to mimic CRTs). A target response curve for calibration that is reasonably close to the native response of a display should help to minimize calibration artifacts like banding, because the adjustments needed to the video card's gamma tables via calibration curves will not be as strong as if a target response farther away from the display's native response had been chosen. Of course, you can and should change the calibration response curve to a value suitable for your own requirements. For example, you might have a display that offers hardware calibration or gamma controls, that has been internally calibrated/adjusted to a different response curve, or your display's response is simply not close to a gamma of 2.2 for other reasons. You can run “Report on uncalibrated display device” from the “Tools” menu to measure the approximated overall gamma among other info.

Choosing the display to calibrate and the measurement device

Those can be selected through the drop-down boxes at the top. If you launch dispcalGUI without an instrument connected, you can connect the device afterwards and it should show up in the drop-down box after a few seconds. If this doesn't work, there's also a menu item “Detect displays and instruments” in the “Options” menu, but normally you shouldn't need this (if you can't seem to get your instrument to appear in the dropdown, please make sure that Argyll recognizes your instrument before filing a bug report).

Calibration settings

White point

Allows setting the target white point locus to the equivalent of a daylight or black body spectrum of the given temperature in degrees Kelvin, or as chromaticity co-ordinates. By default the white point target will be the native white of the display, and it's color temperature and delta E to the daylight spectrum locus will be shown during monitor adjustment, and adjustments will be recommended to put the display white point directly on the Daylight locus. If a daylight color temperature is given, then this will become the target of the adjustment, and the recommended adjustments will be those needed to make the monitor white point meet the target. Typical values might be 5000 for matching printed output, or 6500, which gives a brighter, bluer look. A white point temperature different to that native to the display may limit the maximum brightness possible.

If you want to find out the current uncalibrated whitepoint of your display, you can run “Report on uncalibrated display device” from the “Tools” menu to measure it.

If you want to adjust the whitepoint to the chromaticities of your ambient lighting, or those of a viewing booth as used in prepress and photography, and your measurement device has ambient measuring capability (e.g. like the i1 Pro or i1display2 with their respective ambient measurement heads), you can use the “Measure” button next to the whitepoint settings. If you want to measure ambient lighting, place the instrument upwards, beside the display. Or if you want to measure a viewing booth, put a metamerism-free gray card inside the booth and point the instrument towards it. Further instructions how to measure ambient may be available in your instrument's documentation.

White level

Set the target brightness of white in cd/m². If this number cannot be reached, the brightest output possible is chosen, consistent with matching the white point target. Note that many of the instruments are not particularly accurate when assessing the absolute display brightness in cd/m². NOTE that some LCD screens behave a little strangely near their absolute white point, and may therefore exhibit odd behavior at values just below white. It may be advisable in such cases to set a brightness slightly less than the maximum such a display is capable of.

If you want to find out the current uncalibrated white level of your display, you can run “Report on uncalibrated display device” from the “Tools” menu to measure it.

Black level

Set the target brightness of black in cd/m². Setting too high a value may give strange results as it interacts with trying to achieve the target “advertised” tone curve shape. Using a black output offset of 100% tries to minimize such problems.

Tone curve / gamma

The target response curve is normally an exponential curve (output = input^gamma), and defaults to 2.2 (which is close to a typical CRT displays real response). Four pre-defined curves can be used as well: the sRGB colorspace response curve, which is an exponent curve with a straight segment at the dark end and an overall response of approximately gamma 2.2, the L* curve, which is the response of the CIE L*a*b* perceptual colorspace, the Rec. 709 video standard response curve and the SMPTE 240M video standard response curve.

Note that a real display can't reproduce any of these ideal curves, since it will have a non-zero black point, whereas all the ideal curves assume zero light at zero input. For gamma values, you can also specify wheter it should be interpreted relative, meaning the gamma value provided is used to set an actual response curve in light of the non-zero black of the actual display that has the same relative output at 50% input as the ideal gamma power curve, or absolute, which allows the actual power to be specified instead, meaning that after the actual displays non-zero black is accounted for, the response at 50% input will probably not match that of the ideal power curve with that gamma value. To allow for the non-zero black level of a real display, by default the target curve values will be offset so that zero input gives the actual black level of the display (output offset). This ensures that the target curve better corresponds to the typical natural behavior of displays, but it may not be the most visually even progression from display minimum. This behavior can be changed using the black output offset option (see further below).

Also note that many color spaces are encoded with, and labelled as having a gamma of approximately 2.2 (ie. sRGB, REC 709, SMPTE 240M, Macintosh OS X 10.6), but are actually intended to be displayed on a display with a typical CRT gamma of 2.4 viewed in a darkened environment. This is because this 2.2 gamma is a source gamma encoding in bright viewing conditions such as a television studio, while typical display viewing conditions are quite dark by comparison, and a contrast expansion of (approx.) gamma 1.1 is desirable to make the images look as intended. So if you are displaying images encoded to the sRGB standard, or displaying video through the calibration, just setting the gamma curve to sRGB or REC 709 (respectively) is probably not what you want! What you probably want to do, is to set the gamma curve to about gamma 2.4, so that the contrast range is expanded appropriately, or alternatively use sRGB or REC 709 or a gamma of 2.2 but also specify the actual ambient viewing conditions via a light level in Lux, so that an appropriate contrast enhancement can be made during calibration. If your instrument is capable of measuring ambient light levels, then you can do so.
[For in-depth technical information about sRGB, see “A Standard Default Color Space for the Internet: sRGB” at the ICC^[5] website for details of how it is intended to be used]

If you're wondering what gamma value you should use, you can run “Report on uncalibrated display device” from the “Tools” menu to measure the approximated overall gamma among other info. Setting the gamma to the reported value can then help to reduce calibration artifacts like banding, because the adjustments needed for the video card's gamma table should not be as strong as if a gamma further away from the display's native response was chosen.

Ambient light level

As explained for the tone curve settings, often colors are encoded in a situation with viewing conditions that are quite different to the viewing conditions of a typical display, with the expectation that this difference in viewing conditions will be allowed for in the way the display is calibrated. The ambient light level option is a way of doing this. By default calibration will not make any allowances for viewing conditions, but will calibrate to the specified response curve, but if the ambient light level is entered or measured (which you may also do during the interactive display controls portion of the calibration), an appropriate viewing conditions adjustment will be performed. For a gamma value or sRGB, the original viewing conditions will be assumed to be that of the sRGB standard viewing conditions, while for REC 709 and SMPTE 240M they will be assumed to be television studio viewing conditions. By specifying or measuring the ambient lighting for your display, a viewing conditions adjustment based on the CIECAM02 color appearance model will be made for the brightness of your display and the contrast it makes with your ambient light levels.

Please note your measurement device needs ambient measuring capability (e.g. like the i1 Pro or i1display2 with their respective ambient measurement heads) to measure the ambient light level.

Black output offset

Real displays do not have a zero black response, while all the target response curves do, so this has to be allowed for in some way. The default way of handling this (equivalent to 100% black output offset) is to allow for this at the output of the ideal response curve, by offsetting and scaling the output values. This defined a curve that will match the responses that many other systems provide and may be a better match to the natural response of the display, but will give a less visually even response from black. The other alternative is to offset and scale the input values into the ideal response curve so that zero input gives the actual non-zero display response. This ensures the most visually even progression from display minimum, but might be hard to achieve since it is different to the naturally response of a display. A subtlety is to provide a split between how much of the offset is accounted for as input to the ideal response curve, and how much is accounted for at the output, where the degree is 0.0 accounts for it all as input offset, and 100% accounts for all of it as output offset.

Black point correction

Normally dispcal will attempt to make all colors down the neutral axis (R=G=B) have the same hue as the chosen white point. Near the black point, red, green or blue can only be added, not subtracted from zero, so the process of making the near black colors have the desired hue, will lighten them to some extent. For a device with a good contrast ratio or a black point that has nearly the same hue as the white, this is not a problem. If the device contrast ratio is not so good, and the black hue is noticeably different to that of the chosen white point (which is often the case for LCD type displays), this could have a noticeably detrimental effect on an already limited contrast ratio. Here the amount of black point hue correction can be controlled. By default a factor of 100% will be used, which is usually good for CRT and also by default a factor of 0% is used for LCD type displays, but you can override these with a custom value between 0% (no correction) to 100% (full correction). If less than full correction is chosen, then the resulting calibration curves will have the target white point down most of the curve, but will then cross over to the native or compromise black point.

Black point correction rate

If the black point is not being set completely to the same hue as the white point (ie. because the factor is less than 100%), then the resulting calibration curves will have the target white point down most of the curve, but will then blend over to the native or compromise black point that is blacker, but not of the right hue. The rate of this blend can be controlled. The default value 400, which results in a target that switches from the white point target to the black, moderately close to the black point. While this typically gives a good visual result with the target neutral hue being maintained to the point where the crossover to the black hue is not visible, it may be asking too much of some displays (typically LCD type displays), and there may be some visual effects due to inconsistent color with viewing angle. For this situation a smaller value may give a better visual result (e.g. try values of 300 or 200. A value of 100 will set a pure linear blend from white point to black point). If there is too much coloration near black, try a larger value, e.g. 600 or 800.

Calibration quality

Determines how much time and effort to go to in calibrating the display. The higher the quality, the more test readings will be done, the more refinement passes will be done, the tighter will be the accuracy tolerance, and the more detailed will be the calibration of the display. The result will ultimately be limited by the accuracy of the instrument, the repeatability of the display and instrument, and the resolution of the video card gamma table entries and digital or analogue output (RAMDAC).

Interactive display adjustment

Turning this off skips straight to calibration measurements instead of giving you the opportunity to alter the display's contrast, brightness and white point controls first. You will normally want to keep this checked, to be able to use the controls to get closer to the chosen target characteristics.

Profiling settings

Testchart file

You can choose the test patches used when profiling the display here. The default ones are automatically chosen based on profile quality and type, but you can also use and create your own using the built-in testchart editor (click on the colored patches next to the testchart file selector or choose “Edit testchart...” from the “File” menu to launch it).

Testchart editor

Normally you will not need or want to create your own test charts, but allowing you to do so ensures maximum flexibility when characterizing a display.

You can enter the amount of patches to be generated for each patch type (white, gray, single channel, iterative and multidimensional cube steps). The iterative algorythm can be tuned if more than zero patches are to be generated. What follows is a quick description of the several available iterative algorythms, with “device space” meaning in this case RGB coordinates, and “perceptual space” meaning the (assumed) XYZ numbers of those RGB coordinates. The assumed XYZ numbers can be influenced by providing a previous profile, thus allowing optimized test point placement.

Optimized Farthest Point Sampling (OFPS) will optimize the point locations to minimize the distance from any point in device space to the nearest sample point
Incremental Far Point Distribution incrementally searches for test points that are as far away as possible from any existing points
Device space random chooses test points with an even random distribution in device space
Perceptual space random chooses test points with an even random distribution in perceptual space
Device space filling quasi-random chooses test points with a quasi-random, space filling distribution in device space
Perceptual space filling quasi-random chooses test points with a quasi-random, space filling distribution in perceptual space
Device space body centered cubic grid chooses test points with body centered cubic distribution in device space
Perceptual space body centered cubic grid chooses test points with body centered cubic distribution in perceptual space

You can set the degree of adaptation to the known device characteristics used by the default full spread OFPS algorithm. A preconditioning profile should be provided if adaptation is set above a low level. By default the adaptation is 10% (low), and should be set to 100% (maximum) if a profile is provided. But, if for instance, the preconditioning profile doesn't represent the device behavior very well, a lower adaption than 100% might be appropriate.

For the body centered grid distributions, the angle parameter sets the overall angle that the grid distribution has.

The “limit samples to sphere” option is used to define an L*a*b* sphere to filter the test points through. Only test points within the sphere (defined by it's center and radius) will be in the generated testchart. This can be good for targeting supplemental test points at a troublesome area of a device. The accuracy of the L*a*b* target will be best when a reasonably accurate preconditioning profile for the device is chosen. Note that the actual number of points generated can be hard to predict, and will depend on the type of generation used. If the OFPS, device and perceptual space random and device space filling quasi-random methods are used, then the target number of points will be achieved. All other means of generating points will generate a smaller number of test points than expected. For this reason, the device space filling quasi-random method is probably the easiest to use.

Controls for the spreadsheet-like patch editor are as follows:

To select patches, click and drag the mouse over table cells, or hold SHIFT (select range) or CTRL/CMD (add/remove single cells/rows to/from selection)
To add a patch below an existing one, double-click a row label
To delete patches, select them, then hold CTRL (Linux, Windows) or CMD (Mac OS X) and hit DEL or BACKSPACE (will always delete whole rows even if only single cells are selected)
CTRL-C/CTRL-V/CTRL-A = copy/paste/select all

If you want to insert a certain amount of patches generated in a spreadsheet application (as RGB coordinates in the range 0.0-100.0 per channel), the easiest way to do this is probably to copy the values from the spreadsheet app, entering the testchart editor, generating a corresponding amount of patches and then overwriting them by doing CTRL-A, CTRL-V.

Profile quality

Sets the level of effort and/or detail in the resulting profile. For table based profiles (LUT^[7]), it sets the main lookup table size, and hence quality in the resulting profile. For matrix profiles it sets the per channel curve detail level and fitting “effort”.

Profile type

Generally you can differentiate between two types of profiles: LUT^[7] based and matrix based.

Matrix based profiles are smaller in filesize, somewhat less accurate (though in most cases smoother) compared to LUT^[7] based types, and usually have the best compatibility across CMM^[2]s, applications and systems — but only support the colorimetric intent for color transforms. For matrix based profiles, the PCS is always XYZ. You can choose between using individual curves for each channel (red, green and blue), a single curve for all channels, individual gamma values for each channel or a single gamma for all channels. Curves are more accurate than gamma values. A single curve or gamma can be used if individual curves or gamma values degrade the gray balance of an otherwise good calibration.

LUT^[7] based profiles are larger in filesize, more accurate (but may sacrifice smoothness), in some cases less compatible (applications might not be able to use or show bugs/quirks with LUT^[7] type profiles, or certain variations of them). When choosing a LUT^[7] based profile type, advanced gamut mapping options become available which you can use to create perceptual and/or saturation tables inside the profile in addition to the default colorimetric tables which are always created. L*a*b* or XYZ can be used as PCS, with XYZ being recommended especially for wide-gamut displays bacause their primaries might exceed the ICC^[5] L*a*b* encoding range. Under Windows, XYZ LUT^[7] types are only available in dispcalGUI if using Argyll CMS >= 1.1.0 because of a requirement for matrix tags in the profile, which are not created by prior Argyll versions. As it is hard to verify if the LUT^[7] of an combined XYZ LUT^[7] + matrix profile is actually used, you may choose to create a profile with a swapped R ↔ G matrix (which I'd recommend), so it will be obvious if an application uses it instead.

Note: LUT^[7]-based profiles (which contain three-dimensional LUTs) might be confused with video card LUT^[7] (calibration) curves (one-dimensional LUTs), but they're two different things. Both LUT^[7]-based and matrix-based profiles may include calibration curves which can be loaded into a video card's gamma table hardware.

Advanced gamut mapping options

Normally, profiles created by dispcalGUI only incorporate the colorimetric rendering intent, which means colors outside the display's gamut will be clipped to the next in-gamut color. LUT-type profiles can also have gamut mapping by implementing perceptual and/or saturation rendering intents. You can choose if and which of those you want after clicking “Advanced...”, by specifying a source profile and marking the appropriate checkboxes. Note that a input, output, display or device colororspace profile should be specified as source, not a non-device colorspace, device link, abstract or named color profile. You can also choose viewing conditions which describe the intended use of both the source and the display profile that is to be generated. An appropriate source viewing condition is chosen automatically based on the source profile type.

For more information on why a source gamut is needed, see “About ICC profiles and Gamut Mapping” in the Argyll CMS documentation.

One strategy for getting the best perceptual results with display profiles is as follows: Select a CMYK profile as source for gamut mapping. Then, when converting from another RGB profile to the display profile, use relative colorimetric intent, and if converting from a CMYK profile, use the perceptual intent.
Another approach which especially helps limited-gamut displays is to choose one of the larger (gamut-wise) source profiles you usually work with for gamut mapping, and then always use perceptual intent when converting to the display profile.
Please note that not all applications support setting a rendering intent for display profiles and might default to colorimetric (e.g. Photoshop normally uses relative colorimetric with black point compensation, but can use different intents via custom soft proofing settings).

Profile name

As long as you do not enter your own text here, the profile name is auto generated from the chosen calibration and profiling options. The current auto naming mechanism creates quite verbose names which are not necessarily nice to read, but they can help in identifying the profile.
Also note that the profile name is not only used for the resulting profile, but for all intermediate files as well (filename extensions are added automatically) and all files are stored in a folder of that name. You can choose where this folder is created by clicking the disk icon next to the field (it defaults to your system's default location for user data).
Here's an example under Linux, on other platforms some file extensions and the location of the home directory will differ (you can mouse over the filenames to get a tooltip with a short description what the file is for):

Chosen profile save path: ~/.local/share/dispcalGUI/storage
Profile name: mydisplay

The following folder will be created: ~/.local/share/dispcalGUI/storage/mydisplay

During calibration & profiling the following files will be created:
~/.local/share/dispcalGUI/storage/mydisplay/mydisplay.all.sh ~/.local/share/dispcalGUI/storage/mydisplay/mydisplay.cal ~/.local/share/dispcalGUI/storage/mydisplay/mydisplay.colprof.sh ~/.local/share/dispcalGUI/storage/mydisplay/mydisplay.dispcal.sh ~/.local/share/dispcalGUI/storage/mydisplay/mydisplay.dispread.sh ~/.local/share/dispcalGUI/storage/mydisplay/mydisplay.dispwin.sh ~/.local/share/dispcalGUI/storage/mydisplay/mydisplay.icc ~/.local/share/dispcalGUI/storage/mydisplay/mydisplay.ti1 ~/.local/share/dispcalGUI/storage/mydisplay/mydisplay.ti3

(the .sh files can be used to re-run without GUI^[4] but same settings from a shell)

Calibrating / profiling

If you are unclear about the difference between calibration and profiling (also called characterisation), see “Calibration vs. Characterization” in the Argyll CMS documentation.

Please let the screen stabilize for at least half an hour after powering it up before doing any measurements or assessing its color properties. The screen can be used normally with other applications during that time.

After you have set your options, click on one of the three buttons at the bottom to start the actual calibration/profiling process. The main GUI^[4] will hide during measurements, and should pop up again after they are completed (or after an error). You can always cancel out of running measurements by pressing ESC or Q in the terminal window if it is shown, or using the “Cancel” button in the progress dialog. Viewing the informational log window (from the “Tools” menu) after measurements will give you access to the raw output of the Argyll CMS commandline tools and other verbose information.

Adjusting a display before calibration

If you clicked “calibrate” or “calibrate & profile” and have not turned off “interactive display adjustment”, you will be presented with a text menu from Argyll's dispcal utility which contains several options to help you bring a display's characteristics closer to the chosen target values. Depending on wheter you have a CRT- or LCD-type display, I will try to give some recommendations here which options to adjust, and which to skip.

Adjusting a LCD display

For LCD displays, you will in most cases only want to adjust white point (if the screen has RGB gain or other whitepoint controls) and white level (with the white level also affecting the black level unless you have a local dimming LED model), as many LCDs lack the necessary “offset” controls to adjust the black point (and even if they happen to have them, they often change the overall color temperature, not only the black point). Also note that for most LCD screens, you should leave the “contrast” control at (factory) default.

White level: Start with the white level adjustment. If you have set a target white level, dispcal will instruct you to reduce or increase the brightness of your screen (ideally using only the backlight) until the desired value is reached. If you haven't set a target, simply adjust the screen to a visually pleasing brightness that doesn't cause eye strain.
White point: If your screen has RGB gain, colortemperature or other whitepoint controls, the next step should be adjusting the whitepoint. Note that you may also benefit from this adjustment if you have set the target whitepoint to “native”, as it will allow you to bring it closer to the daylight or blackbody locus, which can help the human visual system to better adapt to the whitepoint. Follow dispcal's recommendations shown during the measurements to adjust RGB gains and minimize the delta E to the shown target whitepoint.

Adjusting a CRT display

Black level: On CRTs, this adjustment is done using the “brightness” control. Argyll's dispcal utility will instruct you to reduce or increase the brightness of your screen until the desired level is reached.
White level: Continue with the white level adjustment. On CRTs this is done using the “contrast” control. If you have set a target white level, dispcal will instruct you to reduce or increase contrast until the desired value is reached. If you haven't set a target, simply adjust the screen to a visually pleasing level that doesn't cause eye strain.
White point: The next step should be adjusting the whitepoint, using the display's RGB gain controls or other means of adjusting the whitepoint. Note that you may also benefit from this adjustment if you have set the target whitepoint to “native”, as it will allow you to bring it closer to the daylight or blackbody locus, which can help the human visual system to better adapt to the whitepoint. Follow dispcal's recommendations shown during the measurements to adjust RGB gains and minimize the delta E to the shown target whitepoint.
Black point: If your display has RGB offset controls, you can adjust the black point as well, in much the same way that you adjusted the whitepoint. Just note that many instruments are not very accurate at low luminance levels, in which case you're probably better off skipping this option altogether.

Finishing adjustments (CRT/LCD) and starting calibration/charaterisation

After the adjustments, you can run “check all” from the menu to verify the achieved values. If adjusting one setting adversely affected another, you can then simply repeat the respective menu option as necessary until the target parameters are met.

If you want the calibration curves to be adjusted for your ambient lighting conditions, and you have not set an ambient light level in the GUI or want to change it, you may do so by selecting “measure and set ambient for viewing condition adjustment”. You need an instrument that can measure ambient light levels using Argyll, like the i1 Display 2 or i1 Pro. The effects of this viewing condition adjustment can vary depending on other calibration parameters. Please also see the documentation for tone curve / gamma and ambient light level. You'll probably want to skip this step to maximize available gamma table tone values after calibration (you can check the effect of calibration curves on the amount of available tone values with the curve viewer in the “tools” menu).

Finally, select “continue on to calibration” to start the non-interactive part. You may want to get a coffee or two as the process can take a fair amount of time, especially if you selected a high quality level. If you only wanted dispcal to help you adjust the display and don't want/need calibration curves to be created, you can also choose “exit” and then select “profile only” from the GUI.
If you originally selected “calibrate & profile” and fulfil the requirements for unattended calibration & profiling, the characterisation measurements for the profiling process should start automatically after calibration is finished. Otherwise, keyboard interaction is needed to start them manually.

Profile installation

When installing a profile after creating or updating it, a shortcut to load its calibration curves automatically on login will be created in your user startup directory (on Windows and Linux, Mac OS X does not need a loader).

Menu commands

“File” menu

Load settings...: Loads settings from a profile created by dispcalGUI, or a calibration file, as described under “settings file”.
Choose testchart file...: Loads a testchart .ti1 file used for profiling (existing profiles created with Argyll CMS or dispcalGUI can also be selected as source).
Edit testchart...: Opens the testchart editor/creator.
Choose save path...: Allows you to select a directory to store the files created by dispcalGUI during calibration/profiling.
Locate Argyll CMS executables...: Normally dispcalGUI will look for and use the Argyll CMS binaries using your system's PATH variable, but you may specify a different location.

“Options” menu

Create profile from measurement data...: Allows you to create a profile from existing .ti3 measurement data (existing profiles created with Argyll CMS or dispcalGUI can also be selected as source).
Install display device profile...: Install an existing profile for the currently selected display.
Load calibration curves from calibration file or profile...: Unlike “load settings....” from the “file” menu, loads just calibration curves for the currently selected display into the video card without changing settings.
Load calibration curves from current display device profile: Tries to determine the profile associated to the currently selected display and loads its calibration curves from the 'vcgt' tag.
Reset video card gamma table: Resets the video card gamma table for the currently selected display to linear, clearing any calibration curves, such that input = output.
Detect displays and instruments: Normally dispcalGUI will automatically detect changes in display setup or instrument configuration, but as it may take a few seconds for changes to be recognized, you can instantly run the detection using this menu entry.
Use separate video card gamma table acccess: Because of the difficulty caused by TwinView and MergedFB in X11 based systems, you can optionally specify a separate display for accessing the video card gamma table hardware during calibration. You may be able to calibrate one screen, and then share the calibration with another screen. Profiling can be done independently to calibration on each screen. Normally dispcalGUI will automatically detect if separate video card gamma table access is needed (and appropriate controls need to be displayed), but you may force it by selecting this menu entry.
Allow skipping of spectrometer self-calibration: Spectrometers require a sensor calibration before measurements. If this option is checked, dispcalGUI will try to skip the sensor calibration for characterization measurements if they are run directly after display calibration measurements (unattended calibration & profiling). NOTE even if this option is checked, you may be forced to do a sensor calibration if the instrument requires it.
Restore defaults: Restores all settings except language, selected display, instrument, measurement mode and profile name to default.

“Tools” menu

Report on uncalibrated display device

Does some quick measurements on the currently selected display, first resetting the video card gamma table, and displays information about the measured response like luminance, approx. gamma, color temperature, and video card gamma table bit depth.

Report on calibrated display device

Does some quick measurements on the currently selected display, keeping the video card gamma table, and displays information about the measured response like luminance, approx. gamma, and color temperature.

Verify calibration

Run verify measurements on the selected display as it is currently setup (ie. video card gamma table). This will use the usual input parameters to establish the expected (target) characteristic. Note that if the initial calibration was modified due to it being out of gamut of the display, verify will show the resulting discrepancy.

Verify profile

Do verification measurements to assess the display chain's (profile - video card and the calibration curves in its gamma table - monitor) fit to the measured data, or to find out about the soft proofing capabilities of the display chain.
To do the former, you have to select a CGATS^[1] testchart file containing device values (RGB). The measured values are then compared to the values obtained by feeding the device RGB numbers through the profile (measured vs expected values). The default verification chart contains 24 patches and can be used, for example, to check if a display needs to be re-profiled. If a RGB testchart with gray patches (R=G=B) is measured, like the default and extended verification charts, you also have the option to evaluate the graybalance through the calibration only, by placing a check in the corresponding box on the report.
To perform a check on the soft proofing capabilities, you have to provide a CGATS reference file containing XYZ or L*a*b* data which will be fed through the profile to lookup corresponding device (RGB) values, which will then be sent to the display and measured. Afterwards, the measured values are compared to the original XYZ or L*a*b* values, which can give a hint how suitable (or unsuitable) the display is for softproofing to the colorspace indicated by the reference file.

The profile that is used for verification is the one currently selected under “settings”, or the current display profile if any. Otherwise, a file dialog will appear to allow choosing a profile. The report files generated after the verification measurements are plain HTML with some embedded JavaScript, and are fully self-contained. They also contain the reference and measurement data, which consists of device RGB numbers, original measured XYZ values, and D50-adapted L*a*b* values computed from the XYZ numbers, and which can be examined as plain text directly from the report at the click of a button.

How were the nominal and recommended aim values chosen?

The nominal tolerances, with the whitepoint, average, maximum and gray balance stemming from UGRA/Fogra Media Wedge and UDACT aim values, are pretty generous, so I've included somewhat stricter “recommended” numbers which I've chosen more or less arbitrarily to provide a bit “extra safety margin”.
For reports generated from reference files that contain CMYK numbers in addition to L*a*b* or XYZ values, you can also select the official Fogra Media Wedge V3 aim values for paper white, CMYK solids and CMY grey, if the chart contains the right CMYK combinations.

How are the results of the profile verification report to be interpreted?

This depends on the chart that was measured. The explanation in the first paragraph sums it up pretty well: If you have calibrated and profiled your display, and want to check how well the profile fits a set of measurements (profile accuracy), or if you want to know if your display has drifted and needs to be re-calibrated/re-profiled, you select a chart containing RGB numbers for the verification. Note that directly after profiling, accuracy can be expected to be high if the profile characterizes the display well, which will usually be the case if the display behaviour is not very non-linear, in which case creating a LUT profile instead of a “curves + matrix” one, or increasing the number of measured patches for LUT profiles, can help.
If you want to know how well your profile can simulate another colorspace (softproofing), select a reference file containing L*a*b* or XYZ values, like one of the Fogra Media Wedge subsets (be warned though, only wide-gamut displays will handle a larger offset printing colorspace like FOGRA39 or similar well enough).
In both cases, you should check that atleast the nominal tolerances are not exceeded. For a bit “extra safety margin”, look at the recommended values instead.
Note that both tests are “closed-loop” and will not tell you an “absolute” truth in terms of “color quality” or “color accuracy” as they may not show if your instrument is faulty/measures wrong (a profile created from wrong measurements will usually still verify well against other wrong measurements if they don't fluctuate too much) or does not cope with your display well (which is especially true for colorimeters and wide-gamut screens, as such combinations need a correction matrix in hardware or software to obtain accurate results—this problem does not exist with spectrometers, which do not need a correction matrix for wide-gamut, but have lately been discovered to have issues measuring the correct brightness of some LED backlit displays), or if colors on your screen match an actual colored object next to it (like a print). It is perfectly possible to obtain good verification results but the actual visual performance being sub-par. It is always wise to combine such measurements with a test of the actual visual appearance via a “known good” reference, like a print or proof (although it should not be forgotten that those also have tolerances, and illumination also plays a big role when assessing visual results). Keep all that in mind when admiring (or pulling your hair out over) verification results :)

How are profiles evaluated against the measured values?

Different softwares use different methods (which are not always disclosed in detail) to compare and evaluate measurements. This section aims to give interested users a better insight how dispcalGUI's profile verification feature works “under the hood”.

General

There are currently two slightly different paths depending if a testchart or reference file is used for the verification measurements, as outlined above. In both cases, Argyll's icclu utility is run behind the scenes and the values of the testchart or reference file are fed relative colorimetrically through the profile to obtain corresponding L*a*b* (in the case of RGB testcharts) or device RGB numbers (in the case of XYZ or L*a*b* reference files). Then, the original RGB values from the testchart, or the looked up RGB values for a reference file are sent to the display through the calibration curves of the profile that is going to be evaluated (actually the calibration curves are loaded before the RGB numbers are sent to the display for measurement with dispread). A reference white of D50 (ICC default) and complete chromatic adaption of the viewer to the display's whitepoint is always assumed, so the measured XYZ values (and also those in reference files if they don't contain L*a*b* numbers) are adapted to D50 (with the measured whitepoint as source reference white) using the Bradford transform (see Chromatic Adaption on Bruce Lindbloom's website for the formula and matrix that is used by dispcalGUI) and converted to L*a*b*. The L*a*b* values are then compared by the generated dynamic report, using a user-selectable ΔE (delta E) formula for the overview, and all implemented formulas for the summary.

How is the whitepoint ΔE calculated?

In a report, the correlated color temperature and assumed target whitepoint, as well as the whitepoint ΔE, do warrant some further explanations: The whitepoint ΔE is calculated as difference between the measured whitepoint's and the assumed target whitepoint's normalized XYZ values, which are first converted to L*a*b*. The assumed target whitepoint color temperature shown is simply the rounded correlated color temparature (100K threshold) calculated from the measured XYZ values. The XYZ values for the assumed target whitepoint are obtained by calculating the chromaticity (xy) coordinates of a CIE D illuminant of that color temperature and converting them to XYZ. You can find all the used formulas on Bruce Lindbloom's website.

How is the gray balance “range” evaluated?

The gray balance “range” uses a combined delta a/delta b absolute deviation (e.g. if max delta a = -0.5 and max delta b = 0.7, the range is 1.2). Because results in the extreme darks can be problematic due to lack of instrument accuracy and other effects like a black point which has a different chromaticity than the whitepoint, all gray balance checks in dispcalGUI only take into account gray patches with a minimum measured luminance of 1% (i.e. if white luminance = 120 cd/m², then only patches with at least 1.2 cd/m² will be taken into account).

What does the “evaluate gray balance through calibration only” checkbox on a report actually do?

It sets the nominal (target) L* value to the measured L* value and a*=b*=0, so the profile is effectively ignored and only the calibration (if any) will influence the results of the gray balance checks. Note that this option will not make a difference for a “single curve + matrix” profile, as the single curve effectively already achieves a similar thing (the L* values can be different, but they are ignored for the gray balance checks and only influence the overall result).

Enable Spyder 2 colorimeter...

The Spyder 2 instrument cannot function without the presence of the instrument vendors PLD firmware pattern for the device. This firmware is not provided with Argyll CMS nor dispcalGUI, since it has not been made available under a compatible license.
The purchaser of a Spyder 2 instrument should have received a copy of this firmware along with their instrument from the original vendor, as part of the instrument setup files.
On Microsoft Windows or Mac OS X, if the vendors drivers have been installed on the users machine, the firmware pattern can usually be located from there. If the vendors drivers have not been installed, or the user does not wish to install them, or no vendors drivers are available for the users platform (i.e. Linux), then the Spyder 2 installation CDROM will also be searched if present. If your Linux system is not running automount, or your automount is setup to mount CDROM's somewhere other than /media, /mnt/cdrom, /media/cdrom or /cdrom, then you will have to mount the CDROM manually, and select the path to the CDROM setup/setup.exe file.

Show curves

Shows/hides the curve viewer, which graphs calibration and profile tone response curves and also shows the percentage and amount of tone values for calibration curves. Please note that if profile tone response curves are graphed and the selected profile is a table-based (LUT) profile, the displayed curves will be from the additional (and optional) matrix 'rTRC'/'gTRC'/'bTRC' tags, not some representation of the lookup table!

Show actual calibration curves from video card gamma table

When this menu entry is checked, the curve viewer will show the actual calibration curves from the video card gamma table instead of showing the curves of the currently active profile.

Show log window

Shows/hides the informational log window.

Show log window automatically

Shows the log window automatically after actions like measurements or creating a profile.

Known issues and solutions

General: Wacky image colors (red and green swapped)
Photoshop: “The monitor profile […] appears to be defective. Please rerun your monitor calibration software.”
MS Windows Vista and 7, 64-bit: Driver signature enforcement prevents the installation of unsigned Argyll USB drivers
MS Windows Vista and 7: The display profile isn't used if it was installed for the current user
MS Windows Vista: The calibration gets unloaded when a “User Access Control” prompt is shown
MS Windows: Enabling the Spyder 2 colorimeter might fail when not running as administrator
MS Windows: Installing a display profile system-wide might fail when not running as administrator
Photoshop CS3 (Mac OS X): The brush cursor looks funny (box around brush)
Linux/Windows: No video card gamma table access (“calibrate only” and “calibrate & profile” buttons grayed, “profile only” button available)
Linux (KDE): The application does not look native
General: Some text is still in english, even though another language is selected

General: Wacky image colors (red and green swapped)
Solution: This happens when you created a “XYZ LUT + R ↔ G swapped matrix” profile (which is the default for the “Prepress” and “Photo” presets) and is a way to alert you that the software you're using does not support XYZ LUT profiles and falls back to the included matrix (which generally means you'd loose accuracy). If you're having this situation only in some applications, creating a “XYZ LUT + matrix” profile will remedy it (but please keep in mind that those applications not supporting XYZ LUT will still fall back to the matrix, so results can be different from applications that support XYZ LUT correctly). If all colormanaged applications you use show swapped colors, you should create a matrix profile instead. Note that you do not have to re-run any measurements: In dispcalGUI, choose a profile type as suggested previously, adjust quality and profile name if you want, then choose “Create profile from measurement data...” in the “Options” menu and select the profile you had the issue with.

Photoshop: “The monitor profile […] appears to be defective. Please rerun your monitor calibration software.”
Solution: If you see a similar message when launching Photoshop, with the options “use profile regardless” and “ignore profile”, I'd try to “use profile regardless” as I've seen this message appearing even with perfectly good profiles. The exact cause of this issue is still unbeknownst to me, and there is quite a lot, sometimes contradicting information to be found about this or similar issues on the web. Adobe has some information, but it seems rather outdated. If you can shed light on this issue, I'd be interested to hear about it.

MS Windows Vista and 7, 64-bit: Driver signature enforcement prevents the installation of unsigned Argyll USB drivers
Solution: Beginning with Argyll CMS >= 1.1.0, you may use one of the following workarounds. One method is to self sign the drivers and put your system in test mode. The procedure for doing this is a little complicated though, and beyond the scope of this documentation. You might want to refer to “installing unsigned drivers on Vista 64”. If you take this path then make sure you sign the libusb0.sys and libusb0_x86.sys files in the Argyll_VX.X.X/libusbw directory before you install the device, otherwise you will have to remove & delete the driver using device manager, and also manually delete the libusb0 and libusb0_x86 .sys and .dll files from Windows\system32, Windows\System32\drivers and Windows\SysWOW64 and start again.
If you don't want/can't sign the driver files or enable test mode, another workaround is to allow loading unsigned drivers by pressing F8 when the system boots, and selecting the boot option to “Disable Driver Signature Enforcement”. Note that you have to do this every time you boot and want to use the USB instruments (you may still get a warning about an unsigned driver not being loaded after plugging the instrument in, booting or installing the driver, but take these messages with a grain of salt, and check in device manager and also whether the instruments are actually accessible).

MS Windows Vista and 7: The display profile isn't used if it was installed for the current user
Solution: Open the Windows start menu, select “Control Panel”, then “Color Management” (you may have to select “Classic View” under Vista and anything other than “Category View” under Windows 7 to see it). Under the “Devices” tab, select your display device, then tick “Use my settings for this device”.

MS Windows Vista: The calibration gets unloaded when a “User Access Control” prompt is shown.
Solution: This Windows Vista bug seems to have been fixed under Windows 7, and can be remedied under Vista by either manually reloading calibration, or disabling UAC—but please note that you sacrifice security by doing this. To manually reload the calibration, either open dispcalGUI and select “Load calibration curves from current display profile” in the “Options” menu, or (quicker) open the Windows start menu and select “dispcalGUI Calibration Loader (Display <number>)” in the “Startup” subfolder. To disable UAC^[9] (not recommended!), open the Windows start menu and enter “msconfig” in the search box. Click on the Tools tab. Select the line “Disable UAC” and click the “Launch” button. Close msconfig. You need to reboot your system for changes to apply.

MS Windows: Enabling the Spyder 2 colorimeter might fail when not running as administrator
Solution: Run dispcalGUI as admin. Right-click dispcalGUI's icon and choose “Run as administrator...”

MS Windows: Installing a display profile system-wide might fail when not running as administrator
Solution: Run dispcalGUI as admin. Right-click dispcalGUI's icon and choose “Run as administrator...”

Photoshop CS3 (Mac OS X): Under Mac OS X, the brush cursor in Photoshop CS3 looks funny (box around brush).
Solution: This seems to be a bug which shows with LUT^[7]-type profiles that have only one rendering intent. You can try to overcome it by selecting “Advanced...” next to the profile type dropdown, selecting an existing ICC^[5] profile (for hints as to which profile to select, see “Advanced gamut mapping options” under “Profiling settings”) and tick at least one of the “Apply gamut mapping to” checkboxes before profiling. To do that for an existing profile, adjust quality and profile name if you want, choose “Create profile from measurement data...” from the “Options” menu and select the profile. Note that this does not always solve the issue. Trying another profile type (XYZ LUT instead of L*a*b* LUT) might also help.

Linux/Windows: No video card gamma table access (“calibrate only” and “calibrate & profile” buttons grayed, “profile only” button available)
Solution: Under Linux, please refer to the Argyll CMS documentation, “Installing the software on Linux with X11” and “Fixing access to Video LUTs” therein. Under Windows, please see calibration cannot be loaded if you are under Windows 7 and make sure you have a recent driver for your video card installed.

Linux (KDE): The application does not look native
Solution: You need the GTK-Qt Theme Engine for native KDE look. Most Linux distributions offer ready-made packages through their packaging systems, search for “gtk-qt” (there will likely be separate packages for KDE3 and KDE4). Another alternative is gtk-kde4.

General: Some text is still in english, even though another language is selected in the menu.
Solution: All output from the Argyll utilities is always english, and on Mac OS X, also the menuitems in the application menu. This is not changeable by me.

To-Do / planned features (in no particular order)

Better interface to GNOME Color Manager
Measure and report on screen homogenity / evenness of illumination
Get rid of the terminal and implement a proper GUI for the interactive part of calibration
Better user interface for profile verification: If a test set contains multiple value formats (CMYK, RGB, XYZ, L*a*b*), allow selection which one(s) should be used in a “setup” window
Add gamut coverage percentages to the profile verification report if the test set contains reference values (not *.ti1): Calculate profiles from test set and verification measurements on-the-fly and create gamut volumes from test set profile, evaluated profile, and verification measurements profile using Argyll's iccgamut tool. Compare gamut volumes using Argyll's viewgam tool with -i option and include the results in the report (coverage calculation for test set reference and profile to be evaluated could be done before the actual measurements and also shown in the yet-to-be-implemented profile verification “setup” window).
~~Complete the documentation in the README~~
German language README (postponed)
~~Profile verification (feed XYZ or L*a*b* to display profile, display corresponding RGB values, measure, output Delta E)~~ (implemented in v0.3.6+)
~~“Before” / “After” switch when calibration / profiling complete~~ (implemented in v0.2+)
~~Store all settings in profile, allow loading of settings from profile in addition to .cal file~~ (implemented in v0.2+)
~~Document the code~~ (code documentation could still be enhanced, for now it'll do)
~~Code cleanup~~ (mostly done)

Thanks and acknowledgements

I would like to thank the following people:
Graeme Gill, for creating Argyll CMS.
Loïc Guégant (french translation).
Roberto Quintero (spanish translation).
Tommaso Schiavinotto (italian translation).
And everyone who sent me feedback or bug reports, suggested features, or simply uses dispcalGUI.

Acknowledgements
Part of the comprehensive Argyll CMS documentation has been used in this document, and was only slightly altered to better fit dispcalGUI's behavior and notations.

Version history / changelog

2010-07-25 13:19 (UTC) 0.5.8.0

0.5.8.0

Fixed in this release:

The timeout of 10 seconds for the startup of Argyll tools and instrument initialization was too short for some instruments and is now increased to 30 seconds. If the timeout is ever exceeded, dispcalGUI should now also abort automatically and no longer hang.
When previewing the calibration upon profile installation, use a linear calibration if no display profile is present when toggling the preview on and off (fixes the curve viewer not updating).
Fixed closing the log window not re-enabling the “show log automatically” menuitem.
Linux (Autopackage install): Fixed menu entry sometimes disappearing permanently after logging out under GNOME.
Linux: Fixed dispcalGUI not working if libX11 or libXrandr do not expose certain functions (e.g. under Mandriva 2009).
Linux: Fixed not being able to install a profile using GNOME Color Manager when the profile was not writable.
Linux: Fixed not being able to install a profile using Oyranos when the profile was not located in ~/.color/icc/devices/display.
Linux/Mac OS X: Saving a log file from the log window now works correctly.
Mac OS X: The terminal should no longer lose its focus when the measurement area is shown. This should also make the mouse cursor reappear which is otherwise hidden by dispcal/dispread.
Mac OS X 10.6: The current display profile should now be determined correctly (e.g. for the curve viewer) when loading its calibration curves or selecting the “<Current>” settings.
Windows (installer): An unused console window is no longer shown when launching dispcalGUI via the installed shortcuts.
Windows (installer): Fixed executable not working under Windows 2000.

Changed in this release:

Do not pass through the “hit any key to retry” message from Argyll CMS tools to the progress dialog in case of misreads/port communication problems (retries happen automatically, so there is no need and also no possibility for keyboard interaction).
Enabling the Spyder 2 is now less cumbersome if the original installation CD is not available (especially on Mac OS X, where the firmware couldn't be found if a recent version of the Spyder 2 software was installed) and should work with the downloadable Spyder 2 software installers (but they need to be run to install the software first because the firmware can't be extracted from the installer binaries directly). Messages are now hopefully more informative to give a better idea of what to do. If the firmware can't be extracted from the Spyder 2 software installer, you are asked to install the software and try again. If that can't be done because of platform incompatibility (Linux), the last choice is to locate the Spyder.lib/CVSpyder.dll file manually (it must be copied from a Mac OS X or Windows system in that case).
Linux: Allow installation of profiles using GNOME Color Manager even if XRandR is not working/available.
Linux: Installation now checks for existing udev rules/hotplug scripts for instruments and only installs its own rules if none exist yet.
Linux/Windows: The profile loader will now show a warning dialog if a profile couldn't be loaded.
Linux/Windows: Device model and manufacturer are added to profiles if EDID^[7] info is available.

+ Numerous other small fixes and changes.

2010-06-29 19:23 (UTC) 0.4.9.2

0.4.9.2

Fixed in this release:

Spectrometer sensor calibration sometimes accidentally occured when the instrument was still attached to the screen, leading to erroneous subsequent readings.
Immediately close a profile after reading to avoid locking it (fixes not being able to delete files from within the GUI).
Fixed quirks in “update calibration” and “update profile” operation.
The system-wide installation option in the profile install dialog is no longer hidden just because a profile has no embedded calibration curves (vcgt tag).
If the calibration curves of the current display profile couldn't be loaded for some reason (broken video card gamma table access, or no profile set), the curve viewer was not yet shown, and then a profile under “Settings” was selected, and then deleted, and then the curve viewer called up, an unhandled exception was raised.
Fixed ambient measurement via the “Measure” buttons timing out with the ColorMunki and various error handling issues regardless of instrument which could lead to an un-cancelable, forever looping progress bar.
Fixed ambient color temperature measurement via the “Measure” button not updating the kelvin field if selected.
Linux (only if the detected filesystem encoding is not UTF-8), Mac OS X and Windows: When installing a profile with “special” characters in the filename (everything not representable as 7-bit ASCII), it is now given an unique name containing the display number and MD5 hash, which fixes a few problems with filename encoding under Linux and Mac OS (under Linux the profile couldn't be successfully installed, under Mac OS X system-wide installation partly broke). This also fixes an issue under Windows where a profile whose name starts with the same first few characters (but has not the same name) as an already existing file in the system profile directory could accidentally overwrite that file, because I had not considered that filenames returned by win32api.GetShortPathName are only unique for the directory where a given file resides—and upon installation, that is the profile storage directory, not the system profile directory.
Linux, Mac OS X: When installing a profile, interaction with the curves window works now while the installation dialog is shown.
Windows (standalone executable): Fixed ambient measurement via the “Measure” buttons reproducably hanging (regardless of instrument) if the MS Visual C++ 2008 Redistributable Package (x86) was not installed.

Added in this release:

Linux: Oyranos support. If it is available, profiles are imported to the Oyranos database using oyranos-monitor upon installation, and an appropriate autostart entry is created to load calibration curves and setup the X _ICC_PROFILE atoms on login.
Linux: Rudimentary support for GNOME Color Manager. If it is available and XRandR is working, profiles are imported to GCM upon installation. Any calibration loaders created previously by dispcalGUI will be removed (except the possible oyranos-monitor entry). You then still have to manually assign the profile to a display in the GCM preferences by selecting it and then choosing the profile from the dropdown menu (in the future, this process will be made obsolete by using GCM library functions). Loading of calibration curves and setting up the X _ICC_PROFILE atom and XRandR output properties is then handled by GCM.
Menu option to automatically show the log window after certain operations (measurements, profile creation).

Changed in this release:

The terminal window is now only shown when required (e.g. keyboard interaction during interactive display adjustment). Also, the terminal used is no longer an external application, but a minimal emulator that just passes keyboard input to the Argyll CMS tools.
All measurements which do not require keyboard interaction with Argyll CMS tools now show a progress dialog with the option to cancel the measurements. All output that was previously visible through the terminal is still available via the log window (“Tools” menu) and -file.
Always load calibration curves before installing a profile, even if the profile has no vcgt tag (resets calibration to linear).
Automatically scroll to bottom when messages are added to the log window.
Store calibration and profiling settings in extra sections inside the TI3 file instead of the profile copyright tag. Use “generic” copyright information (“Created with dispcalGUI <version> and Argyll CMS <version>”), overridable by adding a line copyright = My copyright information in dispcalGUI's configuration file.
Made sure that only 7-bit ASCII gets written to a profile's copyright, ASCII description, and ASCII device model description. ICC v2 Unicode and Mac ScriptCode descriptions are now also written by default.
Presets default to high profile quality.
Remember visible state of curves, log window and testchart editor.
Updated french translation (thanks).
Linux: Unattended calibration & profiling no longer depends on xautomation.
Linux: EDID^[7] is now used (if available) when generating descriptive identifiers for displays.
Linux: When determining a display's associated profile, check XrandR _ICC_PROFILE output properties first if available.
Linux: The option to install a profile system-wide is not offered if using GNOME Color Manager to install profiles (GCM has its own way to set profiles as system default).
Linux (only when GCM is not installed or XRandR is not working), Mac OS X, Windows: Installing a profile system-wide now also sets it as default for the current user.
Windows Vista and later: The option to install a profile system-wide is no longer offered if using Argyll CMS <= 1.1.1 (system scope in Argyll releases up to 1.1.1 acts like user scope on those systems).

+ Numerous other small fixes and changes. There is now also a mailing list for discussion and support as well as announcements (see at the top of this document).

2010-05-07 22:36 (UTC) 0.3.9.9

0.3.9.9

Fixed in this release:

Fixed unreliable (hanging occasionally) profile install when using system scope under Linux and Mac OS X (regression of a change in SVN r391 / 0.3.9.3).
Fixed ICC profile truncation if actual tag data is not in the same order as the tag table (regression of a change in SVN r274 / 0.3.0.7. Argyll profiles were not affected).
Fixed potential invalid profile name being generated if some unicode characters can't be conveyed in the file system encoding (Windows, Linux).
Fixed possible backslash in profile name due to wrong escaping when replacing invalid characters.
Fixed support for codepages 65000 (UTF-7) and 65001 (UTF-8) in the main application under Windows. This is actually a fix for shortcomings of Python.

2010-05-03 18:45 (UTC) 0.3.9.3

0.3.9.3

Added in this release:

Show percentage and amount of tone values per channel (+ grayscales) for calibration curves in the curve viewer and profile verification reports.
Profile verification: Enabled gray balance evaluation for all RGB charts containing grayscales (R=G=B). Added option to verify graybalance through calibration only (sets the target L* of each grayscale patch to the measured L* and target a*=b*=0).
Added documentation for the interactive display adjustment part of calibration.
Added further documentation of the profile verification feature with detailed information about underlying technical aspects.

Fixed in this release:

Fixed an unicode error after creating a profile verification report in a path containing unicode characters and a few other unrelated (potential) unicode errors.
Fixed potential unhandled exception if a JSON language file is malformed.
Fixed unhandled exception (local variable referenced before assignment) if trying to view calibration curves of an output with no video card gamma table access.
Fixed rare unhandled exception (local variable referenced before assignment) if logfile couldn't be renamed or removed during rollover.
Fail more gracefully (omit traceback from error message) if temp directory couldn't be created.
Fixed handling of XDG_CONFIG_DIRS and the system-wide autostart directory if the preferred configuration directory does not exist under Linux when installing a profile in local system scope, which prevented the system-wide autostart entry to be created.
Correctly determine system display profile under Windows Vista and 7 if no user profile is set. Fall back to sRGB if no display profile is set.

Changed in this release:

Changed default gamma from 2.4 to 2.2 in an attempt to increase the amount of available gamma table tone values after calibration for LCD screens, which often have a native response that is closer to a gamma of 2.2 than 2.4.
Changed default profile type to single curve + matrix.
Profile verification: Only evaluate grayscales (R=G=B) if their luminance is atleast 1% of the white luminance. Also evaluate combined Δa and Δb range.
Moved instrument feature details to separate JSON configuration file.
Made compatible with wxPython 2.8.6.0.

2010-03-31 15:24 (UTC) 0.3.8.0

0.3.8.0

Added in this release:

“Very large” testchart with 912 patches.
Profile verification: Support (non-Argyll) profiles which use chromatic adaption.

Fixed in this release:

Improved error message when Argyll binaries are not found (only files not found are now shown, together with alternatives). Automatically fall back to xicclu if icclu is not found (eg. Ubuntu's Argyll 1.0.3 package doesn't contain icclu).
Fixed 'invalid syntax' error when running under Python 2.5.
Profile verification report: Fixed a parsing error when reference or measurement data contained numbers in exponential notation.
Linux: Unhandled exception if DISPLAY environment variable is in the format [host]:displaynumber instead of [host]:displaynumber.screennumber (eg. :0 instead of :0.0).
Mac OS X: Fixed values entered in combo boxes not updating the configuration correctly under some circumstances.

Changed in this release:

Profile verification: Lookup device values relative colorimetrically and adapt the measured values to D50 before comparison (using Bradford matrix), so that the measured whitepoint corresponds to L*a*b* 100 0 0. Please note that verification results obtained with reference files measured in earlier versions of dispcalGUI should not be compared to those obtained via this new approach if the display whitepoint is not D50, as the results are likely to be different as an effect of the relative lookup and the chromatic adaption.
Profile verification: Improved support for non-Argyll CGATS text files. Handling is as follows:
- If the file contains RGB_R RGB_G RGB_B fields, it is handled like a Argyll *.ti1 (testchart) file—any XYZ or Lab data is ignored and the RGB numbers are sent to the display and measured. Afterwards, the measured values are compared to the expected values, which are obtained by sending the RGB numbers through the profile. If RGB values above 100 are found, a range of 0-255 is assumed. Otherwise, a range of 0-100 (like Argyll *.ti1) is assumed.
- If the file doesn't contain RGB_R RGB_G RGB_B fields, but XYZ_X XYZ_Y XYZ_Z or LAB_L LAB_A LAB_B, it is handled like a Argyll measurement data (*.ti3) file—the values are used to lookup corresponding RGB numbers through the profile and these are then sent to the display and measured. Afterwards, the measured values are compared to the original XYZ or Lab values.
Profile verification report: Show measured whitepoint and assumed target color temperature (based on closest daylight temperature), and use them to calculate the Delta E for the whitepoint. A few performance improvements when processing large datasets with several hundred or thousand measurements.
GUI and ReadMe: Changed all occurences of the term “LUT curves” to “calibration curves” and also changed all occurences of the term “video LUT” to “video card gamma table” to better distinguish from “LUT profile”. Also renamed the “LUT viewer” to curve viewer as a more accurate description of its functionality.

2010-03-17 18:50 (UTC) 0.3.6.4

0.3.6.4

Added in this release:

Profile verification: CGATS-compatible text files (*.txt) containing measurement data can now be selected in addition to Argyll testchart (*.ti1) and measurement data (*.ti3) files.
Profile verification report: Depending on the chart used, you can now choose among different evaluation criteria from within the report. Also added Fogra Media Wedge V3 tolerance values for CMYK testcharts.

Fixed in this release:

Profile verification: Error 'Unknown color representation Lab' when trying to verify a L*a*b* LUT profile.
Profile verification: Wrong XYZ scaling when reading from *.ti3 files containing XYZ, but no L*a*b* values.
Profile verification: When measuring a display other than the first one, the calibration curves were erroneously still loaded to the 1st display.

Changed in this release:

Profile verification report: Show nominal and actual measured values as L*a*b* instead of XYZ. Reduced visible decimals in report to increase readability.
Split the cramped “Extra” menu into “Options” and “Tools”.

2010-03-13 06:31 (UTC) 0.3.6.2

0.3.6.2

Added in this release:

Profile verification by measurements. Argyll testchart (*.ti1) and measurement data (*.ti3) files can be measured.

Fixed in this release:

Testchart editor: Do not automatically select a saved testchart (regression of a change in 0.3.3.5). Do not show empty rows when creating a testchart using an algorythm that does not create the expected number of rows.
Bumped wxPython version check to 2.8.8.0 so a proper error message is displayed if wxPython is too old.
Linux: When using TwinView or Xinerama, the size of the measurement window was sometimes not correct.
Linux: Failure in get_argyll_version if Argyll utilities have alternate names (eg. argyll-targen instead of targen), which could prevent being able to open the testchart editor (regression of a change in 0.3.3.5).
Mac OS X 10.4: Fall back to ColorSyncScripting if Image Events does not return a display profile.

Changed in this release:

Linux: Info window no longer stays always on top.
Linux: When getting the current profile for a display, also look at the _ICC_DEVICE_PROFILE atom (see draft ICC Profiles in X Specification 0.4).

2010-03-02 20:12 (UTC) 0.3.3.6

0.3.3.6

Fixed in this release:

Linux/Mac OS X: 'tcgetattr failed' when trying to calibrate or profile.

Changed in this release:

Linux: Updated udev rules.

2010-03-01 06:27 (UTC) 0.3.3.5

0.3.3.5

Added in this release:

Capability to set whitepoint or ambient light level for viewing condition adjustment by measuring ambient light.
Profile name %tpa placeholder (test patch amount).
Documentation for ambient light level viewing conditions adjustment, advanced profiling options (gamut mapping) and testchart editor in the ReadMe. Also a few additions to the existing whitepoint/white level and tone curve documentation (mostly taken from the Argyll CMS documentation).
Two entries to the known issues & solutions section in the ReadMe (swapped colors and Photoshop “Monitor profile appears to be defective”).

Changed in this release:

New improved testcharts and presets, with lower patch counts: 12 patches default for gamma+matrix profiles, 48 patches default for curves+matrix profiles (former chart had 91 patches), 124 patches default for LUT profiles which should actually be usable this time around when coupled with a profile quality setting of “high”, unlike its predecessor with 127 patches which yielded mediocre results at best (but for increased accuracy, the new 238-patch “extended” testchart is recommended). 396 and 2386-patch charts (the new “large” and “massive” quantity) are also included.
Default to high profile quality (and force for gamma+matrix profiles, as there is no processing penalty like for curves+matrix or LUT profiles).
Removed limit for remembered settings files.
When calibration or profiling measurements fail, first show the main application window, then the error message (small dialog boxes are sometimes hard to spot on big screens if the application context is missing).
Moved profile quality, type and advanced settings above testchart selector (this order is more logical, as profile quality and type influences testchart selection).
Testchart editor: Default to adaption of 10% for testchart creation using optimized farthest point sampling (OFPS). Support both device and L*a*b* diagnostic VRML files when creating testcharts using Argyll >= 1.1.0. No longer calculate the amount of white/gray/single color patches or multidimensional cube steps if info is missing in testchart file (calculations take way too long for little added benefit).
Cleaned up the known issues & solutions section in the ReadMe.

Fixed in this release:

Wrong value for adaption settings in testchart editor being stored.
Linux (cosmetic): Incorrect special characters in console window when using non-english locale under certain configurations (regression of a change introduced in 0.3.0.7).
Non-critical: File information in Argyll CGATS TI1 to TI3 conversion.
Testchart editor: Do not allow overwriting of predefined testcharts when saving. Correctly remember last used filename when “saving as...”.
Log window: Correctly remember last used filename when saving.
Typo in the ReadMe (the second “Report on calibrated display device” entry under “Menu commands” should have been “Report on uncalibrated display device”).

2010-02-17 15:53 (UTC) 0.3.1.0

0.3.1.0

Fixed in this release:

Running “Calibrate & profile” several times in succession no longer fails on the 2nd and subsequent runs.
Linux: Missing wxPython version check for the measurement window subprocess.

2010-02-15 17:27 (UTC) 0.3.0.9

0.3.0.9

Added in this release:

Test chart editor: Support for Argyll 1.1.0 perceptual space-filling quasi-random test patch distribution.

2010-02-13 16:36 (UTC) 0.3.0.8

0.3.0.8

Fixed in this release:

#2951168 Windows: Critical bug with win32 API calls to get the display name returning 8-bit characters where only ASCII was expected.

2010-02-12 20:13 (UTC) 0.3.0.7

0.3.0.7

Added in this release:

Support for Argyll >= 1.1.0 adaptive emissive measurement mode with the i1 Pro spectrometer.
All of Argyll's profile types are now available (XYZ LUT on Windows only if using Argyll >= 1.1.0).
Support for “very low” calibration quality.
Optionally create a fast matrix/shaper profile when just calibrating.
“Reset video card gamma table” checkbox in the dialog shown when just profiling.
Information how to install Argyll >= 1.1.0 USB drivers on Windows Vista/7 64-bit to the “known issues and solutions” section in the ReadMe.
ReadMe, license, bug tracker and support forum can now be accessed from the “Help” menu.
“Check for update...” in the help menu (launches a web browser and displays the dispcalGUI homepage if a new version is found).
Curve viewer: Capability to show the actual curves from the video card.
Curve viewer: Capability to show a matrix profile's rTRC/gTRC/bTRC curves.

Changed in this release:

When restoring defaults, selected display/instrument/measurement mode, language and profile name are retained.
The display/instrument selector is only enabled if more than one device detected respectively.
Changed i1 Pro highres measurement mode from implicit to user choice.
Gamut mapping: When selecting a source profile, pre-select a source viewing condition based on profile class (monitor or printer).
Updated defaults and presets to Argyll 1.1.0 values (i.e. black output offset).
Short display name placeholder (%dns) for profile name should not yield single numbers or model name without model number any more (or atleast less likely).
Log messages from most informational and all error dialogs.
Show file paths in most dialogs involving file processing.
Documentation in the ReadMe has been updated and is now more or less complete for the main application (testchart editor docs are still to be done). Setup instructions have also been streamlined.
Moved information how to fix video card gamma table access under Linux/X11 to the “known issues and solutions” section in the ReadMe.
Linux: Updated udev rules to those provided with Argyll 1.1.0. Removed obsolete permissions and policy files.
Linux: In multi-display setups using separate X screens, it should no longer be necessary to launch dispcalGUI on the display you want to measure.
Windows: Get names of displays via additional Windows API calls (should yield more descriptive names than “DISPLAY1”, “DISPLAY2” etc.)
Windows (cosmetic): Use default command prompt text color, and a darker variant only when doing measurements.
dispcalGUI version now corresponds to SVN revision number, split into its digit components. Build system (setup.py) uses SVN to generate version information.

Fixed in this release:

Curve viewer: When no display is selected (i.e. when Argyll binaries are not found), it will now try to show the vcgt of the 1st display's profile.
Curve viewer: When hiding the viewer and loading different calibration curves, those changes were not reflected when showing the viewer again.
Curve viewer: If a profile does not contain a 'vcgt' tag, clear canvas and disable R/G/B checkboxes.
Selection of display used for video card gamma table access not working correctly.
Loading of calibration upon initial preview in profile installation dialog if profile does not contain dispcalGUI settings.
Do not show failure message if user cancels profile installation via the password dialog when installing in system scope.
In some cases, values read from the configuration file were not correctly validated (would only show with deliberately altered or broken config file).
colprof output is no longer swallowed when creating a matrix profile with Argyll versions <= 1.0.4.
Linux: Fall back to ASCII if detected encoding is not UTF-8 to fix profile install issues.
Linux/Mac OS X: Enabling the Spyder 2 colorimeter might need elevated privileges.
Linux/Mac OS X: When installing a profile in local system scope, the necessary password was not accepted under newer Linux distros and also Mac OS X > 10.4.11
Mac OS X (cosmetic): Suppress spurious AppleScript messages.
Windows: Get display profile via registry instead of Windows API because the latter does not reflect runtime changes to profile associations (you still need to refresh the curve viewer when changing profile associations outside of dispcalGUI while it is running).

Known issues in this release:

Linux: You can't interact with the drop-down menu or the checkboxes in the curve viewer while a profile installation dialog is shown.

2009-07-16

Fixed a glitch in the Linux Autopackage installer where it would install even if required libraries were missing.

2009-06-30 0.2.6b3 (SVN r239)

fix (Windows): Fixed a critical bug in the Windows codepath which tried to access non-existent paths when certain settings were used.

2009-06-26 0.2.6b2

fix: Only look at <major>.<minor> during the Python version check (fixes a critical error on Ubuntu 9.10 Beta, where the Python revision number has an unexpected value).
fix: The curve viewer is now also able to plot calibration curves from *.cal files.
fix (Linux): If launched on an X display which is not the first display, the measurement window's location no longer determines the display which is used for measurements. This allows non-Xinerama multiscreen configurations to work with dispcalGUI. Note: You need to launch dispcalGUI on the display you want to measure, e.g. `DISPLAY=:0.1 dispcalGUI`.
fix (Linux): Get the profile from the correct display when loading a display's calibration curves into the curve viewer.
fix (Linux, cosmetic): Suppress CUPS warnings encountered on some systems when using the curve viewer.
fix (Mac OS X): Do not offer 'Network' scope during profile installation if /Network/Library/ColorSync/Profiles does not exist.
fix (Windows, cosmetic): Made sure the message "Debug: src/helpers.cpp(140): 'CreateActCtx' failed with error 0x0000007b (the filename, directory name, or volume label syntax is incorrect.)" is not shown when launching the standalone Windows executable, by changing the way *.pyd files are bundled (they are now copied to the executable's directory and are no longer part of the executable itself).
chg: The curve viewer resets to linear if a display without associated profile is selected.

2009-06-22 0.2.6b

fix: calibration preview checkbox in the “install profile” dialog should now correctly toggle between previous and new calibration.
fix: profiling failed when creating a profile on top of an existing calibration.
fix: correctly decode environment variables (should fix a failure when trying to create a profile and the username contains non-ASCII characters).
fix: automatic restoration of defaults before loading settings from a profile or cal file should no longer restore “do not show again” dialogs.
fix (Windows): several errors related to character encoding.
chg: unattended calibration and profiling: wait 10 seconds instead of 5 after calibration before trying to start profiling measurements (some instruments seem to need longer to initialize than others, e.g. Spyder 2).
chg (Python packages and source): instead of requiring wxPython 2.8.x specifically, only ensure a minimal version of 2.8.
add: Curve viewer.

2009-06-11 21:33 (UTC)

Added Linux Autopackage download.
Renamed 55-Argyll.rules to 92-Argyll.rules, so it can work on Debian too.
Removed “Creating a standalone executable from source” section from the ReadMe (the topic is still handled under “Installing from source” / “Additional setup.py commands”).

2009-06-07 0.2.5b4

fix: “TypeError: coercing to Unicode: need string or buffer, instance found” when calling any of the get*Description() methods of an ICCProfile instance, which caused profile creation from existing profile to fail.
fix: (Windows Vista) application exit on launch if autostart directory did not exist.
fix: (source, Debian and RPM packages) use the correct wxPython version
fix: tab-key traversal of calibration settings controls.
fix: automatically scroll into view focused calibration settings controls if scrollbars are shown.
fix: properly clean & remove temporary directory.
fix: (cosmetic) added some padding to calibration settings right-hand side so scrollbar won't overlap if shown.
chg: (cosmetic) enable auto-sizing (fit to contents) for colortemp locus, trc type and profile type selectors.
chg: (cosmetic) do not show vendor name in instrument select dropdown (conserve some space).
chg: (cosmetic) made the instrument selector a little narrower (needs less space now to display instrument name because the vendor name is stripped) and the measure mode selector a bit wider (to accommodate for projector mode).
chg: only try to re-start within terminal if running as standalone executable.
chg: show application restart request in the chosen language after changing it.
chg: allow resizing/maximizing of main window (a minimal size is forced to prevent layout glitches).
chg: (Linux) install from source or package will try to automatically setup access to your instrument. Some services (PolicyKit/HAL or udev) may need to be restarted to get the updated configuration recognized. If in doubt, a reboot should work in all cases.
add: french translation (by Loïc Guégant, thanks!)
add: bdist_deb command and --cfg option for setup.py

2009-05-16 0.2.5b3

Fixed calibration loader autostart entry creation (“access denied” error) under Windows Vista and later with User Account Control enabled.

2009-05-07 0.2.5b2

Fixed “error: nothing to repeat” when using a spectrometer.

2009-05-05 0.2.5b

fix: encoding-related issues on all platforms and strange Unicode-related problems with AppleScript and Terminal on Mac OS X 10.4 (Details).

Prerequisites to reproduce Unicode-related issues under Mac OS X 10.4: Terminal closed, or with atleast one window opened. Script inside an AppleScript bundle, the bundle filename contains UTF-8 characters. “main.command” (executable shell script) inside Contents/Resources subfolder of the bundle.

Not working (messagebox “Resource not found”):

tell application "Terminal"
	activate
	do script quoted form of (POSIX path of (path to resource "main.command"))
end tell

Not working (messagebox “Resource not found”):

tell application "Terminal"
	activate
	do script quoted form of (POSIX path of (path to resource "main.command")) in first window
end tell

Not working (message “No such file or directory” printed to Terminal window):

set shellscript to quoted form of (POSIX path of (path to resource "main.command"))
tell application "Terminal"
	activate
	do script shellscript
end tell

Working:

set shellscript to quoted form of (POSIX path of (path to resource "main.command"))
tell application "Terminal"
	activate
	do script shellscript in first window
end tell

fix: (Windows) several actions unexpectedly failing under Windows 7 (dispcalGUI created temporary files via system calls on several occasions, but on Windows, this does not create the file in the user's temp directory as one would expect, but in the ROOT directory e.g. C:\—a sane method is now being used instead).
fix: bug in sorting function caused leading and trailing zeroes of numbers in testchart filenames to get lost, thus failing to load such files.
fix: (Linux) “No module named _md5” error with the standalone executable on some Linux distros (apparently an OpenSSL-related issue, because normally it wouldn't fall back to the legacy _md5 module which is not even built by default in recent Python versions). The fallback _md5 module is now included.
fix: calibration was not automatically added & selected in the dropdown menu when only calibrating.
fix: dropping a profile which was not created in dispcalGUI onto the application window no longer results in an unhandled error.
fix: when trying to load calibration curves from a profile which actually does not contain any, an error message is now shown instead of resetting the video card gamma table to linear and erroneously stating the curves were succesfully loaded.
fix: add display device name as device model description when profiling.
fix: when creating a new profile from an existing profile, use that profile's device model description if present.
fix: also create .app/.sh/.cmd files when creating a new profile from existing measurement data.
fix: restore advanced gamut mapping options to default if selecting a profile which does not contain those settings.
fix: allow free selection of source and target viewing conditions in advanced gamut mapping options for LUT^[7] profiles regardless of source profile type.
fix: if the screen or instrument that was selected in a previous session is not available, select an available one.
fix: (Mac) the “enable spyder 2” menu item would not allow to select files other than “setup.exe”.
fix: [src] (Mac) if dispcalGUI was installed as application and then run from (separate) source, multiple copies were launched at certain occasions.
fix: selecting a different Argyll binary directory than the previous one now actually works.
chg: the previously empty entry at the top of the settings dropdown (settings which are not associated to a profile or .cal file) is now named “<current settings>”.
chg: changed settings which are associated to a profile or .cal file are now marked with a leading asterisk in the settings dropdown.
chg: default to a gamma of 2.4 (Argyll default).
chg: warn before changed settings are discarded.
chg: new default profile naming scheme.
chg: new default file locations on all platforms.
- On Linux, dispcalGUI now adheres to the XDG Base Directory Specification—the configuration file is saved as $XDG_CONFIG_HOME/dispcalGUI/dispcalGUI.ini ($XDG_CONFIG_HOME defaults to ~/.config if not set), all files created during calibration/profiling go into $XDG_DATA_HOME/dispcalGUI/storage/ ($XDG_DATA_HOME defaults to ~/.local/share if not set) by default, and logfiles into $XDG_DATA_HOME/dispcalGUI/logs/
Any old (pre v0.2.5b) configuration data is retained in the file ~/.dispcalGUI and may be safely deleted after using v0.2.5b or newer for the first time.
- On Mac OS, the configuration is saved as ~/Library/Preferences/dispcalGUI/dispcalGUI.ini, all files created during calibration/profiling go into ~/Library/Application Support/dispcalGUI/storage/ by default, and logfiles into ~/Library/Logs/dispcalGUI/
Any old (pre v0.2.5b) configuration data is retained in the file ~/Library/Preferences/dispcalGUI Preferences and may be safely deleted after using v0.2.5b or newer for the first time.
- On Windows, the configuration file is saved as %APPDATA%\dispcalGUI\dispcalGUI.ini, all files created during calibration/profiling go into %APPDATA%\dispcalGUI\storage\ by default, and logfiles into %APPDATA%\dispcalGUI\logs\
Any old (pre v0.2.5b) configuration data is retained in the registry key HKEY_CURRENT_USER\Software\dispcalGUI.
chg: [build/src] (Windows) removed MS Visual C++ 2008 Redistributable DLLs from the source package. Users who build under Windows will have them anyway as they are installed with Python 2.6, so they are now copied directly from %SystemRoot%\WinSxS (Windows side-by-side assemblies) if possible.
chg: [build/src] SendKeys is now a dependency on Windows when running or building from source.
chg: [build/src] made dispcalGUI a distutils package, so it can be built/installed via setup.py.
chg: default locations are now also searched for resource files ($XDG_DATA_HOME/dispcalGUI, $XDG_DATA_DIRS/dispcalGUI on Linux, ~/Library/Application Support/dispcalGUI, /Library/Application Support/dispcalGUI on Mac OS X, %APPDATA%\dispcalGUI, %COMMONAPPDATA%\dispcalGUI and %COMMONPROGRAMFILES%\dispcalGUI on Windows) in addition to the current working directory (which is always searched first if it differs from the executable directory) and the executable directory (which is always searched last).
chg: better error handling. For unhandled exceptions, a message box is shown and an entry is written to the logfile.
chg: (Linux) the calibration loader will no longer try and handle gnome-screensaver quirks—it was working too unreliably, and should really be fixed in gnome-screensaver. The current recommendation is to not use a screensaver at all if possible, and instead rely on the system's energy saving options.
chg: (Linux) there's no longer an installer for the Linux version.
chg: cancelling of certain operations like profile calculation and testchart generation is now also supported when using Python 2.5
chg: when searching for Argyll executables, also search for files with “argyll-” prefix or “-argyll” suffix (thanks to Mark Whitis for report).
chg: disable measurement mode selection when using a spectrometer.
add: logging (also see the change related to file-storage). Logfiles are created per-date. A maximum of 5 old ones is being kept as backup.
add: placeholders like display name, measurement device, whitepoint etc. can now be used in the profile name.
add: unattended calibration and profiling for some instruments, meaning it is no longer necessary to press a key after calibration to start the measurements for profiling (needs xautomation under Linux).
add: settings and related files can be deleted.
add: (Linux, Mac, Vista) profile install scope can be selected (note: local system scope install is broken with current Argyll versions under Linux).
add: version and translation information in the about window.
add: projector mode when using Argyll 1.1.0 Beta or newer with the X-Rite ColorMunki.

2009-01-01

Linux and sourcecode bugfix update: Creation of the autostart entry failed when the autostart directory did not yet exist.

2008-12-24 0.2.1b

fix: video card gamma table access check always returned false when no display profile was set.
chg: (Linux) dispcalGUI now uses the autostart specification from freedesktop.org for the profile loader under Linux when installing profiles. NOTE for users: This also means you should manually remove any autostarts from previous versions, e.g.
rm ~/.gnome2/dispwin-*.sh rm ~/.kde/Autostart/dispwin-*.sh
and then re-install your current profile so the new loader is created. The new loader will be created in $XDG_CONFIG_HOME/autostart/ (if set) or ~/.config/autostart/ (if not set), with the filename dispcalGUI-Calibration-Loader-Display-x.desktop, where x is the display number.
chg: the calibration loader will check if gnome-screensaver is running and if so, exit it before loading the calibration, then start it again to prevent resetting the calibration when activated.
chg: .sh/.cmd file in profile folder is no longer created when just installing a profile.
add: message box when selecting LUT^[7] as profile type with recommendation to use more samples for higher quality profiles.
add: default to english locale if translation doesn't exist.

2008-12-18 0.2b

fix: no longer possible to introduce invalid value types through a malformed config file (which could lead to dispcalGUI not launching).
fix: windows can no longer be moved permanently out of the visible screen area.
fix: spaces and special chars in the profile name should work now (should have from the start, but I had some superfluous code which broke it).
fix: spaces in the path to dispcalGUI should work now under Linux and Mac OS X too (Windows had no problem)
fix: measurement file no longer gets deleted after successful measurement if profile generation fails (was a simple oversight on my side).
fix: [cosmetic] logo header now always spans the whole width of the window.
fix: [cosmetic] (Mac OS X) on first launch, a second, unused, terminal window is no longer opened.
fix: windows will now try to adjust its height to fit on small screens (scrollbars might appear).
chg: “Calibration file” renamed to “Settings” and moved to the top, is now a dropdown box remembering the last 10 used files. Settings are stored in and loaded from profiles.
chg: renamed “Display type” to “Measurement mode” and moved over to measurement device selector.
chg: default to “LCD” for measurement mode.
chg: default testchart file names are now localized.
chg: new default testcharts, four flavours: matrix default (91 patches), LUT^[7] default (127 patches), large (512 patches) and massive (3012 patches).
chg: testchart selector is now a dropdown box, shows all testchart files in chosen directory plus the default testcharts.
chg: [build/src] new and improved build system.
chg: [build/src] Python 2.6 is now the recommended version to run and/or build dispcalGUI. Python 2.5 is still supported, but you will not be able to cancel profile or testchart creation through the GUI^[4].
chg: (Linux) externally installed wxGTK is no longer a dependency for executables.
chg: [build] Executables are now completely self-contained. The following paths are searched for additional language files: <user home directory>/dispcalGUI/lang, <dispcalGUI root directory>/lang
add: all settings now stored in profile whenever possible.
add: “Install” button next to settings dropdown to install selected profile.
add: dropdown to choose the display to use for video card gamma table access if all of the following applies:
- more than one display connected
- one of those displays seems to have non-working video card gamma table access (detected on startup)
- one of those displays seems to have working video card gamma table access (detected on startup)
add: show patch count of selected testchart next to dropdown.
add: ability to select an icc profile (if it contains appropriate data) or measurement data file (.ti3) as testchart (converted on-the-fly).
add: testchart generator with editing cabability (experimental)
- to select patches, click and drag the mouse over table cells, or hold SHIFT (select range) or CTRL/CMD (add/remove single cells/rows to/from selection)
- to add a patch, double-click a row label
- to delete patches, select them, then hold CTRL or CMD and hit DEL or BACKSPACE (will always delete whole rows even if only single cells selected)
- CTRL-C/CTRL-V/CTRL-A = copy/paste/select all
add: advanced gamut mapping options for LUT^[7]-type profiles, can also be used to overcome an apparent Photoshop CS3 bug under Mac OS X where the brush cursor shows strange artifacts when using LUT^[7]-profiles with only one intent (thanks to Klaus Karcher for reporting this).
add: ability to generate profile from existing measurement data, even from an existing profile (if it contains appropriate data).
add: drag and drop calibration files (.cal), profiles (.icc/.icm), testcharts (.ti1) and measurement data files (.ti3) to the main window to process/select them (does not work very reliably on Mac OS X depending on where you drop the files, and you also get no optical feedback during the drag operation like the changed mouse cursor on Linux/Windows. Your best bet when dropping any files is perhaps the unoccupied area below “Settings”).
add: fully movable/resizable measurement window.
add: profile and testchart creation can be aborted (when running from source only if using Python >= 2.6).
add: “Before” / “After” switch when calibration / profiling complete.
add: menu item to enable Spyder 2 from within dispcalGUI.
add: italian and spanish GUI^[4] translations (thanks contributors!)
Numerous other small fixes/changes.

2008-08-21

Executable-only update for Linux (thanks to Patrice Vetsel for bug report): dispcalGUI is now built against wxGTK 2.8.7.1, which becomes a dependency.

2008-08-18 0.1b

First public release.

Definitions

[1] CGATS: Graphic Arts Technologies Standards, CGATS.5 Data Exchange Format (ANSI CGATS.5-1993 Annex J)
[2] CMM / CMS: Color Management Module / Color Management System
[3] GPL: GNU General Public License — gnu.org/licenses/gpl.html
[4] GUI: Graphical User Interface
[5] ICC: International Color Consortium — color.org
[6] JSON: JavaScript Object Notation, a lightweight data-interchange format — json.org
[7] LUT: Look Up Table — en.wikipedia.org/wiki/Lookup_table
[8] SVN: Subversion, a version-control system — subversion.tigris.org
[9] UAC: User Account Control — en.wikipedia.org/wiki/User_Account_Control
[10] EDID: Extended Display Identification Data — en.wikipedia.org/wiki/EDID

dispcalGUI—Open Source Display Calibration and Characterization powered by Argyll CMS

Table of contents

About

Screenshots

Disclaimer

A note about colorimeters, wide-gamut displays and dispcalGUI

Download

Linux DEB/RPM packages

Linux Autopackage

Stand-alone executable

Source code

Quick setup guide

Prerequisites

Argyll CMS

Additional prerequisites for unattended calibration and profiling

Additional prerequisites for using the non-standalone release and source code

Additional prerequisites for compiling

Installation

Linux Autopackage (.package)

Standalone executable

Mac OS X

Windows (Installer)

Windows (ZIP)

Source code (all platforms)

Additional setup commands

Additional setup options

Basic concept of display calibration and profiling

Usage

Settings file

Predefined settings (presets)

Why has a default gamma of 2.2 been chosen for the presets?

Choosing the display to calibrate and the measurement device

Calibration settings

Profiling settings

Calibrating / profiling

Adjusting a display before calibration

Adjusting a LCD display

Adjusting a CRT display

Finishing adjustments (CRT/LCD) and starting calibration/charaterisation

Profile installation

Menu commands

“File” menu

“Options” menu

“Tools” menu

How were the nominal and recommended aim values chosen?

How are the results of the profile verification report to be interpreted?

How are profiles evaluated against the measured values?

General

How is the whitepoint ΔE calculated?

How is the gray balance “range” evaluated?

What does the “evaluate gray balance through calibration only” checkbox on a report actually do?

“Language” menu

Known issues and solutions

To-Do / planned features (in no particular order)

Thanks and acknowledgements

Version history / changelog

0.5.8.0

Fixed in this release:

Changed in this release:

0.4.9.2

Fixed in this release:

Added in this release:

Changed in this release:

0.3.9.9

Fixed in this release:

0.3.9.3

Added in this release:

Fixed in this release:

Changed in this release:

0.3.8.0

Added in this release:

Fixed in this release:

Changed in this release:

0.3.6.4

Added in this release:

Fixed in this release:

Changed in this release:

0.3.6.2

Added in this release:

Fixed in this release: