skip to main content

Elle Stone's Well-Behaved ICC Profiles and Code

This article provides well-behaved ICC RGB working space profiles, plus Gray, XYZ, and LAB profiles, plus code for making your own V2 and V4 profiles using LittleCMS version 2 ("LCMS").

Written September 2013. Last updated May 2016.

Introduction and why I distribute ICC profiles and profile-making code

My ICC profile-making code makes a variety of RGB working space profiles, plus Gray profiles, plus XYZ and LAB identity profiles. The code includes the most commonly used RGB working space profiles (including ACES, ACEScg, AdobeRGB1998, ProPhotoRGB, Rec.2020, and sRGB/Rec.709), plus an assortment of less commonly used profiles.

Each RGB working space profile "family" is provided with the profile's standard Tone Reproduction Curve ("TRC"), the linear gamma, gamma 1.8, and gamma 2.2 TRCs, and the sRGB, LAB "L", and Rec709 TRCs, in both V2 and V4 versions.

The profiles and code can be downloaded from github at elles_icc_profiles . If there is a profile you need that isn't already included in the code or profile pack, let me know and I'll try to add the code to make the new profile.

As a very important aside, I couldn't make these profiles without using ArgyllCMS to prequantize the primaries. If you are interested in making a contribution to open source/free-libre image editing, the ArgyllCMS developer does need monetary contributions in order to continue developing ArgyllCMS.


To the best of my knowledge, all the profiles included in my ICC profile pack and profile-making code are free from known copyright restrictions. I am not a lawyer, so use at your own risk. The downloadable premade profiles are released under the Creative Commons Attribution-Share-Alike Unported license, version 3.0. The profile-making code is released as GPLv2+. Both of these licenses are on the Fedora and Debian lists of free software licenses. This article is also released as GPLv2+, for facilitating the use of the provided profile descriptions in free software.

The profiles, code, and the information on this page is distributed in the hope that they will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Why I distribute ICC profiles and profile-making code

I distribute ICC profiles and profile-making code for three reasons:

  1. I think everyone should have access to well-behaved, properly made ICC profiles that aren't encumbered by onerous copyrights.
  2. Many profile vendors don't supply linear gamma versions of the various ICC RGB working space profiles, even though more and more artists and photographers are choosing to edit in linear gamma color spaces to take advantage of proper color mixing.
  3. I did a survey of profiles provided by various profile vendors, and didn't like the results:

For more information about assorted problems with various vendor-supplied RGB working space profiles, see:

  1. What Makes a Color Space Well-Behaved?
  2. Are Your Working Space Profiles Well Behaved?
  3. In Quest of Well Behaved Working Spaces
  4. Survey of Free and Open Source ICC RGB Working Space Profiles

Software used to make the profiles

My profile-making code uses the LittleCMS open source color management engine ("LCMS"). However, by itself LCMS often can't create well-behaved profiles because unlike the ArgyllCMS profile-making code, the LCMS profile-making code doesn't compensate for hexadecimal quantization. Unfortunately, without somehow compensating for hexadecimal quantization, using LCMS to make sRGB, AdobeRGB1998, and quite a few other color space profiles will result in profiles that aren't well behaved. The AdobeRGB1998 specifications not only give the D65 xy and XYZ values for the AdobeRGB1998 color space, but also the D50-adapted XYZ values. Because LCMS doesn't account for hexadecimal quantization, AdobeRGB1998 profiles made with LCMS don't exactly match the AdobeRGB1998 specifications.

As already noted, ArgyllCMS's profile-making code does compensate for hexadecimal quantization. So for profiles that are affected by hexadecimal quantization, I used the ArgyllCMS profile-making source code (located in "src/mkDispProf.c") to calculate the properly quantized D50-adapted XYZ values. Then I used a spreadsheet to "back-Bradford-adapt" from the ArgyllCMS D50-adapted XYZ values to the source color space white point to calculate "prequantized" xy values to feed to LCMS. These "prequantized" xy values allow me to use LCMS to make profiles that are well-behaved, with colorants that match the corresponding ArgyllCMS profiles (when there is one; my profile pack and code does include profiles that ArgyllCMS doesn't distribute). And I used ArgyllCMS's xicclu utility to confirm that all the profiles included in my profile pack are indeed well-behaved.

The profile TRC variants and ICC spec versions

TRC variants

Each profile "family", for example, sRGB or ProPhotoRGB or Rec.2020, is supplied with several variants. Each profile is supplied with its standard TRC, the linear gamma (gamma=1.0), gamma=1.8, and gamma=2.2 TRCs, plus the sRGB, LAB "L" (perceptually uniform), and Rec709 TRCs. Also the Gray profiles are provided with the linear gamma, gamma=1.8, and gamma=2.2 TRCs, plus the sRGB, LAB "L", and Rec.709 TRCs. Each profile variant is supplied in V2 and V4 versions.

All nominally "Gamma=2.2" profiles that I supply have a gamma=2.19921875 TRC, in keeping with the gamma value used in nominally "gamma=2.2" V2 profiles. This gamma value reflects hexadecimal rounding that was unavoidable in V2 profiles and is explicitly given on page 10 of the AdobeRGB1998 color space specifications.

All nominally "Gamma=1.8" profiles that I supply have a gamma=1.80078125 TRC, in keeping with the gamma value used in nominally "gamma=1.8" V2 profiles. This gamma value reflects hexadecimal rounding that was unavoidable in V2 profiles.

V4 profiles can encode gamma curves that are exactly gamma=1.8 and gamma=2.2. But using gamma=1.8 and gamma=2.2 for V4 profiles would mean that V2 and V4 versions of standard RGB working space profiles would use slightly different TRCS, and this seems to me to be not a good idea.

V2 and V4 versions

Well, that's already a lot of profiles. But there's more. For reasons explained below, each profile variant is provides as a V4 profile and also as a V2 profile.

When to use V4 profiles and when to use V2 profiles:

For anyone who wants the simplest possible "rule of thumb" regarding when to use V2 profiles and when to use V4 profiles:

  • Use V4 profiles for editing images using high bit depth image editors that use LCMS as the Color Management Module. This includes Krita, digiKam/showFoto, and GIMP 2.9.
  • Use V2 profiles for exporting finished images to be uploaded to the web or for use with imaging software that can't read V4 profiles.

What does "V2" and "V4" even mean?

In short:

The International Color Consortium ("the ICC", founded in 1993) is responsible for setting specifications for ICC profiles:

V2 ICC profiles are made according to the V2 specs, released around 1995.

V4 ICC profiles are made according to the V4 specs, released around 2001 and last revised around 2010.

In more detail:

A lot changed between V2 and V4, causing a huge uproar and a lot of disagreement and unhappiness. This disagreement and unhappiness is a major reason why some very important softwares (such as ArgyllCMS and other profiling software) still make and use V2 profiles.

Currently I'm supplying true V2 ICC profiles. The "V2" profiles that I used to supply were actually "V2 profiles made according to V4 specs". These profiles were readable by V2 software such as ArgyllCMS and LCMS version 1. But they didn't provide all the functionality you would get from a real V2 profile when using color management software that was programmed to use the V2 ICC specs.

Please note that LCMS version 2 provides ICC profile color management following V4 specs, not V2 specs. So Krita, GIMP, RawTherapee, showFoto, and all other imaging software that uses LCMS version 2 can read real V2 profiles, but even true V2 profiles are treated as if they were V4 profiles.

Why do I supply V2 and also V4 profiles?

In short:

On the one hand, even today some software packages can't read V4 profiles. This includes Firefox when set to its default color management settings.

On the other hand, LCMS quantizes RGB data when doing an ICC profile conversion to (and from?) a profile that is made with a point TRC. For example, V2 profiles that use the sRGB, Rec.709 or LAB L TRC all have "point curve" TRCs.

So I supply true V2 profiles for use with software that can't read V4 profiles and for use in software that uses true V2 color management. And I supply V4 profiles (with parametric curves instead of point curves) for use with Krita and other image editing software that uses LCMS to do ICC profile conversions.

When editing 8-bit images, it doesn't matter whether the image's ICC profile has a point curve or a parametric curve, because the RGB data is already quantized below the level of precision provided by the point curves. But for high bit depth editing, it's better to use V4 profiles with parametric curves.

In more detail:

The V2 profiles that I supply that have point curves (the sRGB, Rec.709, and LAB "L" TRCs) have "point curve" TRCs that control how fast the RGB colors get lighter as the RGB values range from (0,0,0) to (1,1,1) on a floating point scale. Similar statements apply to the V2 profiles with the Rec709 and LAB companding curve TRCs.

My V4 sRGB profile, and also my other V4 profiles with the sRGB TRC, use a parametric curve that closely follows the original sRGB TRC specified by Hewlett-Packard and Microsoft when they released the sRGB color space specs (different from ICC profile specs!) back in 1996. Similar statements apply to the V4 profiles with the Rec709 and LAB companding curve TRCs.

LCMS can "look up" an infinite number of RGB values along a parametric curve TRC, limited only by the precision of the floating point computations. So there's no quantization for V4 TRCs with the parametric sRGB curve.

Parametric curves were introduced as part of the V4 specs. They weren't available for V2 profiles. So software that uses V2 color management can't read parametric curves (unless updates are made to allow reading V4 profiles, as I believe was done for Cinepaint.

The original sRGB TRC as specified by Hewlett-Packard and Microsoft only had 1024 points. My impression is that most color management software interpolates between the points (for example, ArgyllCMS interpolates between the points). LCMS merely quantizes. This isn't in the ICC V4 specs and possibly this particular LCMS behavior changed in the 2.7 release, but I haven't checked. In partial compensation for not interpolating between the points, the V2 point curves have 4096 points instead of only 1024 points.

Note: This issue of "quantization with V2 point curves" vs "no quantization with V4 parametric curves" only affects the profiles in the profile pack that have file names that end with "-srgbtrc.icc", "-rec709.icc" or "-labl.icc". For profiles with true gamma curves (that is, all the profiles with file names that end in "-g10.icc", "-g18.icc", or "-g22.icc"), you can use V2 or V4 versions without worrying about point curve quantization.

Profile descriptions

Currently my profile pack and code includes the following RGB working space profiles:

  1. ACES
  2. ACEScg
  3. AdobeRGB1998
  4. AllColorsRGB
  6. IdentityRGB
  7. ProphotoRGB
  8. Rec.2020
  9. WideGamutRGB
  10. sRGB

The profile pack and code also includes the following non-RGB profiles:

  1. Gray ICC profiles
  2. LCMS built-in LAB and XYZ Identity ICC profiles

As already noted, the linear gamma profiles should only be used for high bit depth image editing. This is because there are too few tonal steps in the shadows of linear gamma color spaces, so for 8-bit images, shadows are posterized. (As an aside, those extra tonal steps that aren't in the shadows of linear gamma images didn't just vanish — compared to perceptually uniform RGB color spaces, there are many more tonal steps in the highlights of linear gamma color spaces.)

Use notes that apply to all the RGB working space profiles:

  1. Which color space should you use?

    Everyone wants to know "what's the best RGB working space" and the answer depends in part on what you want to do, including how large a color gamut you need to encompass the colors you want to edit. However, contrary to what you might think, the size of the color gamut is not the only consideration.

    About RGB Colourspace Models Performance takes a look at various color spaces from the point of view of how well selected multiplication operations emulate what would happen if you did the same calculations using spectral data. The study ranks the most commonly encountered RGB color spaces on how closely results in each color space emulate results obtained using spectral data.

    The About RGB Colourspace Models Performance study can be critiqued; in particular I wish the study had included actual ICC profile working spaces instead of just the color spaces not adapted to D50. Nonetheless the findings are interesting. Some color spaces you might not have ever used ranked near the top of the study's ranking, including Rec.2020 and the ACEScg color space (both of which are included in my profile-making code and profile pack). And some of the more well-known and commonly used RGB working spaces, including sRGB, AdobeRGB1998 and ProPhotoRGB, ranked rather poorly, with sRGB ranking second from the bottom.

    Anyway, I encourage you to think about breaking with the "sRGB/AdobeRGB1998/ProPhotoRGB" trio of commonly-used color spaces, and experiment with the Rec.2020 and ACEScg color spaces. I also encourage you to try using linear gamma color spaces, but of course only if you can use a high bit depth image editor (GIMP 2.9 requires special considerations when choosing an RGB working space). And when you need a color space with a perceptually uniform TRC, try the "labl" version of your preferred linear gamma color space.

  2. The profiles that end in "-g10.icc" are linear gamma (gamma=1.0, "linear light", etc) profiles and should only be used when editing at high bit depths (16-bit floating point, 16-bit integer, 32-bit floating point, 32-bit integer). Many editing operations produce better results in linear gamma color spaces.
  3. The profiles that end in "-labl.icc" have perceptually uniform TRCs. A few editing operations really should be done on perceptually uniform RGB. Make sure you use the V4 versions for editing high bit depth images.
  4. The profiles that end in "-srgbtrc.icc", "-g22.icc", and "-rec709.icc" have approximately but not exactly perceptually uniform TRCs. ProPhotoRGB's gamma=1.8 TRC is not quite as close to being perceptually uniform.
  5. When editing 8-bit images, you should use a profile with a small color gamut and an approximately or exactly uniform TRC. Of the profiles supplied in my profile pack, only the sRGB and AdobeRGB1998 (ClayRGB) color spaces are small enough for 8-bit editing. Even with the AdobeRGB1998 color space you need to be careful to not cause posterization. And of course you can't use the linear gamma versions of these profiles for 8-bit editing.
  6. The profiles that end in "-srgbtrc.icc" can be used with high bit depth GIMP 2.9 to mitigate some of the problems caused by GIMP's hard coded sRGB parameters.

ACES, D60, gamma=1.0

White point, standard TRC, and color space specification:


Quoting Wikipedia, "'Academy Color Encoding System (ACES) is a color image encoding system proposed by the Academy of Motion Picture Arts and Sciences that will allow for a fully encompassing color accurate workflow, with "seamless interchange of high quality motion picture images regardless of source'."


White point, standard TRC, and color space specification:


The ACEScg color space is smaller than the ACES color space, but large enough to contain the "Rec-2020 gamut and the DCI-P3 gamut", and has chromaticities that fall just barely outside the horseshoe-shaped locus of real colors on the xy chromaticity diagram.


White point, standard TRC, and color space specification:


To avoid possible copyright infringement issues, I used "ClayRGB" (following ArgyllCMS) as the base name for these profiles. As used below, "Compatible with Adobe RGB 1998" is terminology suggested in the preamble to the AdobeRGB 1998 color space specifications.

The Adobe RGB 1998 color gamut covers a higher percentage of real-world cyans, greens, and yellow-greens than sRGB, but still doesn't include all printable cyans, greens, yellow-greens, especially when printing using today's high-end, wider gamut, ink jet printers. BetaRGB (not included in the profile pack) and Rec.2020 are better matches for the color gamuts of today's wide gamut printers.

The Adobe RGB 1998 color gamut is a reasonable approximation to some of today's high-end wide gamut monitors.


White point, standard TRC, and color space specification:

  • White point: D50 (ICC specs for D50).
  • Standard TRC: Gamma=1.0.
  • Color space specification: See the Description below:


This profile's color gamut is roughly the same size and shape as the ACES color space gamut, and like the ACES color space, AllColorsRGB holds all possible real colors. But AllColorsRGB actually has a slightly larger color gamut (to capture some fringe colors that barely qualify as real when viewed by the standard observer) and uses the D50 white point.

Just like the ACES color space, AllColorsRGB holds a high percentage of imaginary colors. See the Completely Painless Programmer's Guide to XYZ, RGB, ICC, xyY, and TRCs for more information about imaginary colors.

I can't think of any particular reason why anyone would want to use this profile for editing, unless you have a burning need to make sure your color space really does hold all possible real colors.

AllColorsRGB chromaticities for red and blue were calculated from, and the green chromaticity was calculated using simple linear algebra:

blue 375nm red 780nm, plus Y intercepts:
Color Wavelength (): 375 nm.
Spectral Locus coordinates: X:0.17451 Y:0.005182
Color Wavelength (): 780 nm.
Spectral Locus coordinates: X:0.734690265 Y:0.265309735
X1:0.17451 Y1:0.005182
X2:0.734690265 Y2:0.265309735
X3:0.00Y3:? Solve for Y3:
y=mx+b let x=0; y=b


White point, standard TRC, and color space specification:

  • White point: E (ASTM).
  • Standard TRC: linear gamma.
  • Color space specification: see the Description below.


This profile is included mostly for its historical significance. It's the color space that was used in the original color matching experiments that led to the creation of the XYZ reference color space.

The ASTM E white point is probably the right E white point to use when making the CIERGB color space profile. It's not clear to me what the correct CIERGB primaries really are. Lindbloom gives one set. The LCMS version 1 tutorial gives a different set. I asked a friend to ask a bonified expert in the field, who said the real primaries should be calculated from the spectral wavelengths, so I did.

These web pages give the spectral wavelengths:

This page has resources for calculating xy values given a spectral color wavelength:

This page does the calculations for you:

Plugging the wavelengths into the ledtuning website gives the following CIE RGB xy primaries, which I used to make the profiles:

  • 700.0 nm has Spectral Locus coordinates: x:0.734690023 y:0.265309977
  • 546.1 nm has Spectral Locus coordinates: x:0.2736747378 y:0.7174284409
  • 435.8 nm has Spectral Locus coordinates: x:0.1665361196 y:0.0088826412


White point, standard TRC, and color space specification:

  • White point: D50.
  • Standard TRC: linear gamma.
  • Color space specification: See the Description below.


The IdentityRGB working space is included in the profile pack because it's a mathematically obvious way to include all possible visible colors, though it has a higher percentage of imaginary colors than the ACES and AllColorsRGB color spaces. I can't think of any reason why you'd ever want to actually edit images in the IdentityRGB working space.


White point, standard TRC, and color space specification:

  • White point: D50 as given in the RIMM/ROMM specs.
  • Standard TRC: Gamma=1.80078125. The original specs called for a point curve that approximated the gamma=1.8 TRC, but had a linear portion in the shadows. A ProPhotoRGB profile with the original point curve TRC is available from ArgyllCMS. PhotoShop and probably all other image editing programs use ProPhotoRGB made with a simple gamma curve.
  • Color space specification: See Reference Input/Output Medium Metric RGB Color Encodings (RIMM/ROMM RGB), by Kevin E. Spaulding, Geoffrey J. Woolfe and Edward J. Giorgianni, Eastman Kodak Company, Rochester, New York, U.S.A. ("RIMM" refers to ProPhotoRGB with the linear gamma TRC. "ROMM" refers to ProPhotoRGB with the approximately gamma=1.8 TRC.)


To avoid possible copyright infringement issues, I used "LargeRGB" (following RawTherapee) as the base name for these profiles.

Kodak designed the RIMM/ROMM (ProPhotoRGB) color gamut to include all printable and most real world colors. It includes some imaginary colors and excludes some of the real world blues and violet blues that can be captured by digital cameras. It also excludes some very saturated "camera-captured" yellows as interpreted by some (and probably many) camera matrix input profiles.

The ProPhotoRGB primaries are hard-coded into Adobe products such as Lightroom and the Dng-DCP camera "profiles". However, other than being large enough to hold a lot of colors, ProPhotoRGB has no particular merit as an RGB working space. Personally I recommend the Rec.2020 or ACEScg profiles over ProPhotoRGB. But if you have an already well-established workflow using ProPhotoRGB, you might find a shift to another RGB working space a little odd, at least at first, and so you have to weight the pros and cons of changing your workflow.


White point, standard TRC, and color space specification:


Rec.2020 is the up-and-coming replacement for the thoroughly outdated sRGB color space. As of June 2015, very few (if any) display devices (and certainly no affordable display devices) can display all of Rec.2020. However, display technology is closing in on Rec.2020, movies are already being made for Rec.2020, and various cameras offer support for Rec.2020. And in the digital darkroom Rec.2020 is much more suitable as a general RGB working space than the exceedingly small sRGB color space.

sRGB and Rec.709

The sRGB and Rec.709 color spaces have the same primaries and white point, but slightly different TRCS.

White point, standard TRC, and color space specification:


Hewlett-Packard and Microsoft designed sRGB to match the color gamut of consumer-grade CRTs from the 1990s. sRGB is the standard color space for the world wide web and is still the best choice for exporting images to the internet. sRGB shares primaries with Rec.709, which was designed in 1990 as a standard for high-definition television.

The sRGB/Rec.709 color gamut was a good match to calibrated decent quality CRTs. But sRGB is not a good match to many consumer-grade LCD monitors, which often can't display the more saturated sRGB blues and magentas. The good news: as color display technology progresses, much wider than sRGB/Rec.709 display devices are making their appearance.

Although widely used in photographic image editing, printer color gamuts can easily exceed the sRGB color gamut in cyans, greens, and yellow-greens. Colors from interpolated camera raw files also often exceed the sRGB color gamut.

As a very relevant aside, using perceptual intent when converting to sRGB for photographic image editing does not magically makes otherwise out of gamut colors fit inside the sRGB color gamut! The standard sRGB color space (along with all the other the RGB profiles provided in my profile pack) is a matrix profile, and matrix profiles don't have perceptual intent tables.

Special use notes:

  • sRGB-elle-V2-srgbtrc.icc: This sRGB profile can be assigned to DCF R03 camera-generated jpegs, and also can be used for editing 8-bit images. For maximum compatibility with color-managed browsers, use this variant for images posted to the internet.
  • sRGB-elle-V4-srgbtrc.icc: This sRGB profile can be assigned to DCF R03 camera-generated jpegs. It can be used for editing 8-bit and also high bit depth images.

    For finished images, it's better to assign the "sRGB-elle-V2-srgbtrc.icc" profile before uploading the image to the internet. This extra step probably only benefits Firefox users who have calibrated and profiled their monitors, but haven't changed the default Firefox color management settings, which is to say, probably not very many people.

  • sRGB primaries combined with the Rec.709 TRC gives you the Rec.709 color space, and so the resulting profiles are named Rec709-elle-V2-rec709.icc and Rec709-elle-V4-rec709.icc.


White point, standard TRC, and color space specification:

  • White point: D50 as given in the RIMM/ROMM specs.
  • Standard TRC: Gamma=2.19921875.
  • Color space specification: See Danny Pascale: A review of RGB color spaces. Although Adobe designed the WideGamutRGB color space, Adobe doesn't seem to supply any color space specifications for this color space.


To avoid possible copyright infringement issues, I used "WideRGB" as the base name for these profiles.

WideGamutRGB was designed by Adobe to be a wide gamut color space that uses spectral colors as its primaries. Pascale's primary values produce a profile that matches old V2 Widegamut profiles from Adobe and Canon. It's an interesting color space, but shortly after its introduction, Adobe switched their emphasis to the ProPhotoRGB color space.

Gray ICC profiles

White point, standard TRC, and color space specification:

  • White point: D50.
  • Standard TRC: There isn't one. Pick the one that matches the TRC of the profile of the image that you just converted from RGB to gray.
  • Color space specification: There is none. See the Description below.


These profiles are for use with RGB images that have been converted to monotone gray (black and white). The main reason to convert from RGB to Gray is to save the file space needed to encode the image. Google places a premium on fast-loading web pages, and images are one of the slower-loading elements of a web page. So converting black and white images to Grayscale images does save some kilobytes. For grayscale images uploaded to the internet, convert the image to the V2 Gray profile with the sRGB TRC.

Supplied profile variants:

  • Gray-D50-elle-V2-g10.icc; Gray-D50-elle-V4-g10.icc
  • Gray-D50-elle-V2-g18.icc; Gray-D50-elle-V4-g18.icc
  • Gray-D50-elle-V2-g22.icc; Gray-D50-elle-V4-g22.icc
  • Gray-D50-elle-V2-labl.icc; Gray-D50-elle-V4-labl.icc
  • Gray-D50-elle-V2-rec709.icc; Gray-D50-elle-V4-rec709.icc
  • Gray-D50-elle-V2-srgbtrc.icc; Gray-D50-elle-V4-srgbtrc.icc

LCMS built-in LAB and XYZ Profile variants:

White point, standard TRC, and color space specification:

  • White point: D50 (as given in the ICC specs).
  • Standard TRC: Not applicable.
  • Color space specification: Not applicable.


These are identity LUT ("look up table") profiles.

Supplied profile variants:

  1. Lab-D50-Identity-elle-V2.icc; Lab-D50-Identity-elle-V4.icc
  2. XYZ-D50-Identity-elle-V4.icc

Note: I don't think LCMS version 2 (the version of LittleCMS that was used to write the profile-making code) can make a V2 XYZ profile.

How to compile the profile-making code

Many readily available RGB working space profiles are made using the wrong source white point and/or the wrong unadapted primaries. Many readily available RGB working space profiles are not well behaved. I supply not just well-behaved profiles, but also source code that you can modify and compile to make your own RGB working space profiles.

For the three video profiles (PAL, SMPTE-C, and NTSC) and the two old monitor-based working spaces (Apple and ColorMatch), I included the profile's primaries, white point, and tone response curve information but not the actual profile making code. It should be obvious how to add the appropriate code if you want to make these profiles.

Pre-quantized unadapted primaries

Making an RGB working space profile requires a source white point and a set of unadapted primaries. As discussed in In Quest of Well Behaved Working Spaces and Survey of Free and Open Source ICC RGB Working Space Profiles, the resulting profile's illuminant, white point/chad tag, and adapted primaries are subject to hexadecimal rounding or quantization during the profile making process. If this quantization isn't somehow compensated for, the resulting profile's adapted primaries sometimes deviate from the theoretically correct adapted primaries. A side effect for profiles so affected is they end up being not well behaved.

In addition to the standard unadapted primaries, for the profiles that are affected by hexadecimal rounding, my profile-making code includes "pre-quantized" unadapted primaries that compensate for hexadecimal quantization. These pre-quantized unadapted primaries were back-calculated from profiles made using Argyllcms version 1.6.3, which does compensate for hexadecimal quantization. Profiles made using the "pre-quantized" primaries are well behaved.

How to compile the code to make your own ICC profiles

To make your own ICC profiles:

  1. If you run Linux, you probably already have gcc installed. Otherwise you'll need to set up a development environment.
  2. Install a recent version of LittleCMS version 2. As of Jun, 2015, I'm using LCMS 2.7.

    As an aside, if you want LCMS transicc terminal readout that matches the Argyllcms xicclu readout, you'll need to download and modify the LCMS source code as explained in In Quest of Well Behaved Working Spaces, and compile and install the modified code. Whether or not you've modifed LCMS, the code given below will produce well behaved profiles because the primaries have been pre-quantized.

    Compiling LCMS from source requires that you install the development versions of various LCMS dependencies (according to Gentoo Portage: jpeg, tiff, zlib, and coreutils).

    If you run into a libtool mismatch error, see libtool version mismatch error for ways to deal with the problem.

  3. Download and unpack the code, notes, licences, and profiles.
  4. Make whatever modifications you want to make to the code and the profile names, descriptions, copyright information, and so on.

    If you do modify the code, please respect the GPL2.0+ copyright.

    If you modify the code in such a way as to make modified profiles, please remove my name from the file name and the profile description and copyright, and put in your own information.

    If you directly modify the profiles themselves, please respect the Creative Commons V3 unported BY-SA copyright.

    It should be obvious from the examples provided how to code up additional ICC profiles if there's another working space that you want, that doesn't have primaries and/or white points and/or tone response curves as provided in the current code. But if there's a profile that you want added, send me an email and I'll see if I can add the profile.

    I couldn't find the LCMS function for creating a V2 XYZ profile. If you know how to do this, please send me an email.

  5. Compile the profile-making code in the usual way (a sample compile command is in the code comments).
  6. To actually make the ICC profiles, type "./make-elles-profiles" (suitably modified if you created an executable with a different name) at the command line.
  7. Copy the resulting ICC profiles to wherever you want to keep your ICC profiles. If you run Linux, you'll probably need to be root to copy them to "/usr/share/color/icc".