skip to main content

Will the Real sRGB Profile Please Stand Up?

I compared 15 matrix sRGB profiles and found quite a bit of variation from one sRGB profile to the next. On this page I explore the differences between the various sRGB profiles and I point out the practical digital darkroom consequences. Even though Hewlett-Packard and Microsoft proposed the sRGB color space as a way to eliminate color management in a consumer-oriented workflow, today you need color management just to manage the proliferation of sRGB profiles.

This comparison is limited to variants of the original sRGB matrix profile, which should not be confused with the V4 lookup table "sRGB" variants, confusion over which could have been avoided altogether if had not decided to use "sRGB" as a sort of lump term to refer to several manifestly different profiles.

Written June 2012. Updated February 2015.

Fifteen sRGB Profiles Compared

Top to bottom: Gimp, Krita, Cinepaint, and ShowFoto, all offering to assign a built-in sRGB profile to an untagged image. Will they assign the same profile? Unfortunately, no. Each software has its own version of sRGB.

When you open an untagged (no embedded profile) sRGB image, do you allow your editing software to assign the software's built-in sRGB profile? I always did, until recently.

However, it came to my attention that different image editing software packages use different versions of the sRGB color space. Once I started looking, I found fifteen different sRGB profiles on my computer, and with the exception of Cinepaint and RawStudio, none of them was an exact match to any of the others.

Where the fifteen sRGB variants came from

Some of the sRGB variants that I compared were extracted (using the ArgyllCMS tool extracticc) from an untagged image file in which I asked the imaging software to embed its built-in sRGB profile (Cinepaint, Krita, ShowFoto, and a "mystery profile"). Some were extracted from files produced by raw processing software, after saving the interpolated image in the raw processor's built-in sRGB color spaces (DarkTable, dcraw, UFRaw).

The remaining sRGB variants were either downloaded from the internet (the LCMS, and Scarse variants) or were installed as sRGB ICC files as part of installing a software package (Argyll, Photivo, RawStudio, and RawTherapee).

I hesitated to include the mystery profile in my survey of sRGB profiles, as it came from a software package development version and I can no longer repeat the steps I took to extract it. But it is such a peculiar and instructive version of sRGB — it was in fact the variant that prompted this comparison — that I'm including it anyway.

Table Summary of the sRGB profile comparison

Having collected the fifteen profiles together, I examined them using the ICC Profile Examiner and xicclu, and then created an sRGB profile comparison spreadsheet that shows each profile's white point, black point, XYZ and xy values, and Tone Response Curve. I used the ArgyllCMS sRGB profile as a baseline for profile comparison. The table below summarizes my findings:

sRGB Profile Comparison
RGB XYZ Group Bradford-Adapted Profile white point Tone Response Curve Profile black point Built-in or File V2 or V4
ArgylLCMS (V1.4.0) 1 Yes D65 sRGB-1024 yes - zero software file V2
Cinepaint (V1.0-0) 4 Yes D65 sRGB-1024 no built-in V2, black point scaled 3 Yes D50 sRGB-1024 yes - non-zero downloaded file V2, no scaling ( no longer supplies this profile) 3 Yes D50 custom-1024 yes - non-zero downloaded file V2
DarkTable (early 2012) 4 Yes D50 sRGB-V4 no built-in V4
Dcraw (V9.12) 2 Yes D65 gamma=1.933594 yes, zero built-in V2
Krita (V2.4.1) 4 Yes D50 sRGB-V4 no built-in V4
LCMS 3 Yes D65 sRGB-1024 yes, zero software file V2
Photivo (2012-05-25) 3 Yes D65 sRGB-1024 yes, zero software file V2
RawStudio (V2.0) 4 Yes D65 sRGB-1024 no software file V2
RawTherapee (V4.0.9.2) 4 Yes D65 sRGB-4096 yes, zero software file V2
Scarse 2 Yes D65 gamma=2.199219 yes, zero downloaded file V2
ShowFoto (V2.5.0) 3 Yes D65 sRGB-1024 yes, zero built-in V2
UFRaw (V0.18) 4 Yes D65 sRGB-1024 no built-in V2
mystery profile 5 No D50 Custom-256 yes - zero built-in V2

As a very important aside, free/libre software changes quickly and in 2015 some of the software in the above chart is no longer using the same sRGB profile as was used in 2012. So take this chart as a snapshot in time and don't assume that Krita or Cinepaint or Darktable or etc are still using the same sRGB profile variant in 2015, as they were using back in 2012, when I did the sRGB profile comparison. For example, I know for a fact that the latest versions of Krita and darktable are no longer using the same sRGB profiles that they were using back in 2012.

Profile Differences and Practical Consequences

Different profile RGB XYZ values

When applied to an image, an ICC matrix profile's Red, Blue, and Green XYZ values determine the resulting colors. If you examine the spreadsheet, you will see that there is considerable disagreement between one sRGB variant and another, but the RGB XYZ values fall into five reasonably distinct groups of profiles:

  1. ArgylLCMS
  2. dcraw and Scarse don't agree with each other or anyone else, but their respective RGB XYZ values fall between the first and third group.
  3. The LCMS profile, the two profiles, plus Photivo and ShowFoto exactly agree with each other on the RGB XYZ values, but they differ from ArgyllCMS values in the fifth decimal place.
  4. Cinepaint, DarkTable, Krita, RawStudio, RawTherapee, and UFRaw agree closely or exactly with one another, but they differ from ArgyllCMS values in the fourth and fifth decimal places.
  5. The mystery profile differs from all the other profiles in the second decimal place.

Except for the mystery profile (see Bradford adaptation below), visually you would be hard-pressed to see any difference between one profile and the next, when applied in turn to the same sRGB image (discounting variations in tonality caused by different profile Tone Response Curves, discussed below).

However, Cinepaint, Krita, and RawStudio have exactly the same RGB XYZ values and also the greatest difference from the ArgyllCMS RGB XYZ values. So I devised a procedure to see where the color differences might be greatest between the Argyllcsm sRGB profile and the Cinepaint/Krita/RawStudio sRGB profiles:

  1. I added additional saturation to an already colorful sRGB image.
  2. I applied the ArgyllCMS version of sRGB to the original image and saved under a new name.
  3. Then I applied the Cinepaint version of sRGB to the original image, saved under a new name, and then converted the image to the ArgyllCMS version for comparsion. If the two profiles were identical, the conversion would be a null transaction, except for any rounding error in the conversion routine.
  4. Then I used the "difference" blend mode in Gimp, followed by flattening and an extreme levels adjustment, to compare image color differences resulting from variations in the respective profile RGB XYZ values.
On the left: An overly saturated rendition of an already colorful scene. On the right: Location of the colors in the image that are most affected by the differing ArgyllCMS and Cinepaint/Krita/RawStudio sRGB XYZ values. The red splotches correspond to saturated greens and cyans in the original image.

This image has a lot of saturated colors (even before I added additional saturation), covering not only reds, greens, yellows, and blues, but also cyan (more or less equal parts blue and green) and magenta. I gave the image additional saturation because the less saturated a color is, that is, the closer it is to being gray, the less of a difference there is when applying different icc profiles.

Practically speaking, it turns out that the only colors that show any difference between the ArgyllCMS and Cinepaint sRGB profiles are the saturated cyans and greens, and you would probably never see the differences just by looking. So unless you are photographing a lot of saturated cyans and greens (in which case you shouldn't be using sRGB anyway, as the sRGB color gamut is particularly weak in cyan and green), which sRGB profile you apply won't make a perceptible difference in your sRGB image colors, as long as you avoid variants that don't use a true sRGB tone curve or haven't been Bradford-adapted to D50.

Bradford adaptation (or lack thereof)

All of the sRGB variants except the mystery profile agree on the RGB xy/XYZ matrix values at least in the first three decimal places. The table below gives RGB xy values to three decimal places for the mystery profile and for all the other sRGB variants (xy values are derived from XYZ values):

xy values
Red x Red y Green x Green y Blue x Blue y
Mystery sRGB 0.640 0.330 0.300 0.600 0.150 0.060
Other Variants 0.648 0.331 0.321 0.598 0.156 0.066

If you are up on your color management you probably know exactly where the differences between the mystery profile and all the other profiles come from: unlike all the other variants, the mystery profile yx/XYZ values have not been Bradford-adapted to the standard D50 environment.

From a theoretical point of view, Bradford adaptation accounts for the fact that colors look different, depending on the ambient lighting. Think about the warm glow of candle light, vs the cold, drab colors you see on a rainy day. From a practical point of view, applying an sRGB profile variant that has not been properly Bradford-adapted to the ICC standard D50 environment changes the resulting image colors pretty drastically:

Left: ArgylLCMS sRGB variant, with correctly Bradford-D50-adapted XYZ values. Right: Mystery profile, with unadapted XYZ values and hence an incorrect bluish color cast.

Applying the ArgyllCMS sRGB profile, with properly Bradford-D50-adapted XYZ values, produces the (correct) image on the left. Applying the mystery profile, with its unadapted XYZ values, produces the (incorrect) image on the right. If your sRGB images have an unexpected blue cast, you might have run into an unadapted version of sRGB.

Different profile white points

Note: this section presumes a V2 workflow. V4 workflows don't respect the way V2 profiles were designed to work.

The original sRGB color space profile proposed by Hewlett-Packard and Microsoft back in 1996 had a D65 profile white point. The two profiles, DarkTable, Krita, and the mystery profile all use a D50 white point. The other variants all use the D65 white point.

From a practical point of view, applying two profiles that are identical except for the profile white point doesn't make any difference. Likewise, in a V2 workflow, when converting from one profile to another, as long as color space conversions are done using the relative colorimetric intent (rather than absolute colorimetric intent), the results will be the same (disregarding color gamut and black point issues, of course), regardless of the source and destination profile white points.

Left: Assign the Argyll sRGB variant (which has a D65 white point), convert to BetaRGB (which has a D50 white point) using the relative colorimetric intent (at which point the image will still look exactly the same as before the conversion), then convert back to the Argyll sRGB variant, but this time using the absolute colorimetric intent, at which point the image acquires a yellow color cast (scroll up to compare to the original, correct image). Right: Assign the Argyll sRGB variant (which has a D65 white point) and convert to BetaRGB (which has a D50 white point), using absolute colorimetric intent: the image acquires a blue cast (and not coincidentally looks like the image above right, to which the mystery profile with the non-adapted primaries has been applied).

Note: The ICC profile conversions shown above were done using Cinepaint, which used V2 ICC specification color management. V4 specification color management doesn't show any difference between relative and absolute colorimetric conversions.

When converting an image from one ICC profile to another using the absolute colorimetric intent, the images will still look the same, as long as the source and destination profiles have the same white point. However, as you can see from the images above, if the profile white points of the source and destination profiles are different, conversion using the absolute colorimetric intent will indeed give very different results.

If you examine the spreadsheet, you'll see that in addition to variations in the sRGB primaries, there is considerable variation between the profiles as to the correct XYZ values for a D65 or a D50 white point. The only time these differences could make any practical difference in your images is if you do an absolute colorimetric color conversion in a V2 workflow.

Different profile tone response curves

An ICC matrix profile Tone Response Curve ("TRC") determines image tonality. Assigning two different profiles with the exact same matrix values, but different TRCs, means the resulting colors (abstracted from tonality, of course) are the same, but the tonality — the rate of progression from darkest darks to lightest lights — is different.

If you've ever read a technical description of the sRGB TRC (also see sRGB), you know that it is mathematically messy, but nonetheless well-defined. Which makes it somewhat surprising to find considerable variation in TRCs in fifteen different ICC profiles, all calling themselves "sRGB":

Eight of the sRGB variants — ArgylLCMS, LCMS, Cinepaint, Photivo, RawStudio, ShowFoto, and UFRaw — use exactly the same standard 1024 point sRGB TRC. The Krita and DarkTable variants are V4 profiles with a parametric TRC that closely replicates the standard 1024 point TRC. The RawTherapee sRGB variant uses a 4096 point TRC that likewise closely replicates the standard 1024 point sRGB TRC.

Instead of the standard sRGB tone curve, the dcraw and Scarse sRGB profiles have a roughly gamma=2.2 TRC. The mystery profile has a 256 point TRC that also closely replicates a 2.2 gamma curve, except 0 and 1 both map to 0, which means that when applied to a 16-bit image, the first 512 tones get mapped to 0, thereby potentially destroying a good chunk of shadow detail. (I'll mention the profile TRCs in the following section on profile black points.)

To the right is a graph showing a gamma=2.2 TRC (the blue curve) superimposed over a true 1024-point sRGB tone curve (the red curve). As you can see from the superimposed curves, if you assign an sRGB profile variant with a true gamma=2.2 TRC to an image that really should have the standard sRGB curve,the shadows get crushed but not destroyed (starting in the lower left corner, the blue gamma=2.2 curve is below the red sRGB curve, and the midtones get lightened just a bit; but after around x=32767, the blue gamma=2.2 curve is above the red sRGB curve until they meet at 65535):

Left: Assign the ArgyllCMS version of sRGB. Right: Assign the Scarse version of sRGB (and then convert to the ArgyllCMS version of sRGB for display on the web).

In the ArgyllCMS version on the left (true sRGB TRC), you can see two torches dimly sillouetted against the dark sky. In the Scarse version on the right (simplified sRGB TRC), the tips of the palm fronds have vanished and the torch poles are much more difficult to discern.

The difference between the two images is admittedly subtle. Depending on your monitor, your monitor's calibration and profile, your browser, and the ambient lighting, the difference may be difficult or impossible to see. It would help if browsers respected black point compensation, but they don't. Try downloading the image and viewing it in color-managed image editor with black point compensation enabled.

From a programming point of view, it would be nice if the sRGB TRC just vanished, to be replaced with the much more tractable gamma=2.2 TRC. From a pragmatic point of view, that is not going to happen any time soon, if ever — there are just too many untagged sRGB images floating around that require the sRGB profile TRC, not to mention legacy software and all the cameras that produce sRGB jpegs.

There is nothing wrong with using a "simplified sRGB" with a gamma=2.2 TRC as a destination profile, such as raw processor output, or if it suits your workflow to convert from a real sRGB profile to a simplified, gamma=2.2 (or other gamma) "sRGB" profile. However, simplified versions of sRGB should not be assigned to an image that requires the real sRGB profile, with the real sRGB TRC.

Different profile black points

As you can see from the Summary table above, the ArgylLCMS, dcraw, LCMS, Photivo, RawTherapee, Scarse, ShowFoto profiles, and also the mystery profile, all have a zero black point. The Cinepaint, DarkTable, Krita, RawStudio, and UFRaw sRGB profiles don't have a profile black point. Opinions — official, learned, and otherwise — differ on whether ICC profiles ought to always have a black point. The ICC profile specifications say no, not necessary. I think the ICC is wrong, but my opinion falls into the "otherwise" category.

From a practical point of view, at least as far as matrix profiles go, I don't think it makes much difference — the profiles that don't have a black point seem to use the black point implied by the starting point of the TRC, which is zero for all of the sRGB variants I examined, except for one of the two sRGB profile:

Unlike the other sRGB variants, the two profiles whose TRCS are shown to the right have non-zero black points. On the one hand, the "no black scaling" version (the upper curve) has an sRGB-shaped 1024 point TRC that starts at (0, 819) on a scale from 0 to 65535 (roughly 3 on a scale from 0 to 255). On the other hand, the "black scaled" version (the lower curve; note: this profile is no longer available from the website) has the standard 1024 point sRGB TRC, which starts at (0,0). But both of the profiles have the same non-zero black point. (And yes, the sRGB profile names are confusing.)

An interesting thread over in the ArgyllCMS forums discusses some pitfalls when trying to use the V2 sRGB profiles. If I understand the ArgyllCMS forum thread correctly (the ICC has since changed the names of the profiles in an effort to make the purposes of the two profiles clearer), the "black scaled" profile is faulty because the black point contradicts the tone curve. And the "no black scaling" profile by definition isn't really an sRGB profile because it doesn't have a proper sRGB tone curve.

Because the "no scaling" profile has a non-zero black point, if you do a profile conversion without using black point compensation, there will be problems with the shadow areas of your images (again, has since removed this profile from their website). Top to bottom, in the "gray gradients" image above/to the right:

  1. The first bar is a gray gradient to which the ArgyllCMS sRGB profile has been assigned.
  2. The second bar was produced by converting the first bar to the "no scaling" profile, using relative colorimentric conversion, without using black point compensation. As you can see, the shadows got lighter.
  3. The third bar is a repeat of the first bar, to make comparisons easier.
  4. The fourth bar is the result of assigning the "no scaling" to the original gray gradient, and the converting to the ArgyllCMS sRGB using relative colorimetric conversion, again without using black point compensation. As you can see, the shadows get crushed to zero.
  5. The fifth (bottom) bar is the result of assigning the "no scaling" to the original gray gradient, and the converting to the ArgyllCMS sRGB using the absolute colorimetric intent. Not only are the shadows crushed to zero, but because of the differing profile white points, the gray gradient is now a blue gradient.

Clearly, if you don't keep your intents straight, color conversion between the "no scaling" profile and a "real" sRGB profile (or between the two profiles, but I will leave it up to you to experiment if you are curious) can lead to unexpected results.

There is nothing wrong with an ICC profile having a non-zero black point, if the profile is describing something like a printer profile (where the darkest dark is determined by the ink-paper combination) or an LCD monitor (where the darkest dark is determined by the type of back-lighting). And indeed, according to the official ICC explanation, the peculiar "no black scaling" profile with its non-zero black point actually is intended for use as a monitor profile in cases where a real monitor profile is not available.

As the original sRGB profile was based on the display characteristics of a CRT monitor, you might say the "no black scaling" sRGB profile is an updated version of sRGB to be used with LCD monitors (unlike today's LCD monitors, the old CRT monitors did have a zero black point, theoretically if not always in practice). But even the ICC says you'd be better off with a real monitor profile.

From a practical point of view, I use a real monitor profile, so I don't see any reason to let either of these sRGB profiles into my own digital darkroom. If you do decide to use the V2 ICC profiles, handle with care. (Update: the regrettably named "no black scaling" sRGB profile has been removed from the website. If you still have a copy of this profile floating around in your digital darkroom, you really shouldn't use it unless you really are using it as a substitute for a proper monitor profile. But please don't use it for sRGB images.)

The sRGB variants as working spaces

There are two basic criteria for a well-behaved ICC RGB working space profile: it should be color-balanced and normalized.

"Color-balanced" means is that if R=G=B, then the resulting color is neutral gray. If you are familiar with the cieLab reference color space, you know that if a color is neutral gray, its "a" and "b" Lab values are both equal to 0.

"Normalized" means that if R=G=B=0, then the equivalent Lab value is (0,0,0); and if R=G=B=the maximum value for the bit-depth of the image (255 for an 8-bit image), then the equivalent Lab value is (100,0,0).

How well do the sRGB variants meet these two criteria for a well-behaved working space? I decided to check one sRGB variant from each of the five "RGB XYZ" groups listed above. In the codebox below I've used xicclu to convert from 8-bit RGB values to Lab values, for the following RGB values: (0,0,0), (28,28,28), (53,53,53), (99,99,99), (186,186,186), and (255,255,255):

Group 1, ArgylLCMS
xicclu -s255 -pl srgb-argyll.icc
0 0 0 [RGB] -> MatrixFwd -> 0.000000 0.000000 0.000000 [Lab]
28 28 28 [RGB] -> MatrixFwd -> 10.263754 0.000000 0.000000 [Lab]
53 53 53 [RGB] -> MatrixFwd -> 22.160229 0.000000 -0.000000 [Lab]
99 99 99 [RGB] -> MatrixFwd -> 41.965067 0.000000 0.000000 [Lab]
186 186 186 [RGB] -> MatrixFwd -> 75.514811 0.000000 0.000000 [Lab]
255 255 255 [RGB] -> MatrixFwd -> 100.000000 0.000000 0.000000 [Lab]

Group 2, Scarse, with RGB XYZ values sort of close to dcraw:
xicclu -s255 -pl sRGB-scarse.icm
0 0 0 [RGB] -> MatrixFwd -> 0.000000 0.000000 0.000000 [Lab]
28 28 28 [RGB] -> MatrixFwd -> 7.013782 -0.000444 -0.000078 [Lab]
53 53 53 [RGB] -> MatrixFwd -> 20.670170 -0.000774 -0.000137 [Lab]
99 99 99 [RGB] -> MatrixFwd -> 41.974778 -0.001224 -0.000216 [Lab]
186 186 186 [RGB] -> MatrixFwd -> 76.047384 -0.001943 -0.000343 [Lab]
255 255 255 [RGB] -> MatrixFwd -> 100.001180 -0.002449 -0.000432 [Lab]

Group 3, LCMS, with RGB XYZ values closely or exactly matching
ShowFoto, Photivo, and the profiles:
xicclu -s255 -pl LCMS-srgb.icm
0 0 0 [RGB] -> MatrixFwd -> 0.000000 0.000000 0.000000 [Lab]
28 28 28 [RGB] -> MatrixFwd -> 10.263487 0.004137 -0.003811 [Lab]
53 53 53 [RGB] -> MatrixFwd -> 22.159841 0.006011 -0.005537 [Lab]
99 99 99 [RGB] -> MatrixFwd -> 41.964478 0.009131 -0.008411 [Lab]
186 186 186 [RGB] -> MatrixFwd -> 75.513880 0.014417 -0.013279 [Lab]
255 255 255 [RGB] -> MatrixFwd -> 99.998820 0.018274 -0.016832 [Lab]

Group 4, Cinepaint, with RGB XYZ values closely or exactly matching
DarkTable, UFRaw, RawStudio, RawTherapee, and Krita:
xicclu -s255 -pl srgb-cinepaint.icc
0 0 0 [RGB] -> MatrixFwd -> 0.000000 0.000000 0.000000 [Lab]
28 28 28 [RGB] -> MatrixFwd -> 10.263888 -0.000576 0.000510 [Lab]
53 53 53 [RGB] -> MatrixFwd -> 22.160423 -0.000837 0.000740 [Lab]
99 99 99 [RGB] -> MatrixFwd -> 41.965362 -0.001271 0.001125 [Lab]
186 186 186 [RGB] -> MatrixFwd -> 75.515276 -0.002006 0.001775 [Lab]
255 255 255 [RGB] -> MatrixFwd -> 100.000590 -0.002543 0.002250 [Lab]

Group 5, the mystery profile:
xicclu -s255 -pl mystery.icc
0 0 0 [RGB] -> MatrixFwd -> 0.000000 0.000000 0.000000 [Lab]
28 28 28 [RGB] -> MatrixFwd -> 7.002190 -0.430781 -3.763281 [Lab]
53 53 53 [RGB] -> MatrixFwd -> 20.656823 -0.755325 -6.131752 [Lab]
99 99 99 [RGB] -> MatrixFwd -> 41.960736 -1.194298 -9.695354 [Lab]
186 186 186 [RGB] -> MatrixFwd -> 76.039748 -1.896507 -15.395904 [Lab]
255 255 255 [RGB] -> MatrixFwd -> 100.001180 -2.390239 -19.404041 [Lab]

Putting aside the mystery profile (which would make a horrible working space profile), how should the Lab values in the codebox be interpreted? The only variant that is color-balanced and normalized is the ArgyllCMS variant. It's a little surprising to me how far from being color-balanced and normalized the other sRGB variants are, given that they are in such widespread use.

Many (by no means all) standard RGB working spaces besides the many sRGB profile variations will show imbalances even with the degree of precision that the xicclu tool allows. For instance, here are the values for the BetaRGB color space:

xicclu -s255 -pl BetaRGB.icc
0 0 0 [RGB] -> MatrixFwd -> 0.000000 0.000000 0.000000 [Lab]
28 28 28 [RGB] -> MatrixFwd -> 7.013568 0.000000 0.000224 [Lab]
53 53 53 [RGB] -> MatrixFwd -> 20.669797 0.000000 0.000390 [Lab]
99 99 99 [RGB] -> MatrixFwd -> 41.974188 0.000000 0.000616 [Lab]
186 186 186 [RGB] -> MatrixFwd -> 76.046448 0.000000 0.000979 [Lab]
255 255 255 [RGB] -> MatrixFwd -> 100.000000 0.000000 0.001233 [Lab

And from a practical point of view? On the one hand, the "errors", if you will, are small enough that unless you are doing a lot of color space profile conversion, combined with using outrageous amounts of added color saturation, I doubt you'll ever produce visibly different colors by using one of the sRGB variants that isn't completely color-balanced and normalized.

On the other hand, it seems a shame that software packages capable of handling 16- and 32-bit images end up giving away a little bit of potential color accuracy by using a not-color-balanced, not-normalized built-in version of a standard working space.

Conclusion: We need color management to manage our sRGB profiles

The whole point of the sRGB color space was to eliminate any need to worry about color management. Unfortunately, given the proliferation of sRGB variants, today we need color management to manage our sRGB profiles.

It would be nice if all the software packages that we use would agree on just one sRGB profile. It would be nice if that one sRGB profile were color-balanced and normalized. However, it is not likely that the various open source and proprietary software developers are ever going to agree on "one" sRGB color space profile. (By the way, if you dig around, you'll find multiple variants of all the standard working spaces; the proliferation of profile variants is not confined to sRGB.)

Fortunately, most of the sRGB variants are close enough to one another (same tone curve, zero or no black point, and very similar red, blue, and green xy/XYZ values) that, practically speaking, usually the differences don't make much of a difference. Just be aware of the D65 vs D50 white points in the different sRGB variants if you use the absolute colorimetric intent when doing a color space profile conversion in a V2 workflow.

Also, be on the alert for any off-beat, weird sRGB profiles like the mystery profile and the very peculiar V2 sRGB profiles. And be careful when using sRGB profiles with "simplified" tone curves. "Simplified sRGB" is useful for image editing. But if the image in question is an untagged sRGB image, first you assign the real sRGB (whichever one you think is real!) to the untagged image, then you convert to the simplified sRGB.

From a practical point of view, in my own digital darkroom I've decided to use the ArgyllCMS variant of sRGB for all of my untagged sRGB images, for two reasons: First, most of my untagged images come from my Canon cameras, and the ArgyllCMS sRGB variant is very close to the Canon sRGB profile that came with my cameras. Second, I like the fact that the ArgyllCMS variant is color-balanced and normalized. So whenever my editing software asks if it should assign a "built-in" or "Internet Standard" sRGB profile, I say no and select the ArgyllCMS sRGB profile instead.

Two final notes: First, there are many other "metadata" differences between the various ICC profiles (who made the profile, the copyright data, the intended viewing conditions, and so forth). You might find it entertaining to use the ICC Profile Inspector, the ArgyllCMS iccdump tool, iccToXml, and/or Exiftool to take a look for yourself. Much (but not all) of this metadata information can be stripped out or modified without making any difference in how the profile functions in your digital darkroom. But do tread carefully, verify with testing, be careful regarding copyrights (the ArgyllCMS profile is public domain; the profiles are under a strong copyright), and make sure you have a backup copy before altering your ICC profiles.


This article was written in June of 2012. Since then I've learned how to make my own RGB working space profiles, and in the process, learned a bit about what actually happens during the ICC profile making process. I've learned that just as multiple variants of sRGB are made and distributed, so multiple variants of other standard RGB working spaces are made and distributed. And just as most of the sRGB variants are not well behaved, so most of the variants of these other RGB working spaces are not well behaved.

Why such a cacophany of profile variants? Although there is reasonably good agreement among profile makers on the correct unadapted primaries to use when making any given RGB working space profile, there is considerably less agreement as to the correct values for the source white point. Some profile makers consult available profile specifications, and some use values given by other authoritative sources. Different source white points means different resulting profiles, even when the same unadapted primaries are used.

The reason some RGB working space profile variants are well behaved and others are not can be traced to hexadecimal rounding errors during the profile making process — some combinations of source white points and unadapted primaries are very susceptible to hexadecimal rounding errors, others less so. If hexadecimal rounding errors are compensated for during the profile making process, the resulting profile is well behaved.

The Real sRGB

So which sRGB is the real sRGB? sRGB is defined by its profile specifications. The specifications provide the xy values for the source white point and the unadapted red, green, and blue primaries:

sRGB specifications xy values
White Red Green Blue
x y x y x y x y
0.3127 0.3290 0.6400 0.3300 0.3000 0.6000 0.1500 0.0600

The xy values in the above table, taken directly from the sRGB specifications , are used to make an actual sRGB profile by Bradford adapting the sRGB red, blue, and green primaries from the sRGB D65 color space white point to the ICC profile D50 white point. (Also see Poynton's Color FAQ, Question 17, Basic sRGB Math from the Wayback archive of the original Hewlett-Packard/Microsoft sRGB website, sRGB, A Standard Default Color Space for the Internet - sRGB and A Standard Default Color Space for the Internet: sRGB, — essentially the same information hosted by the W3C and the ICC, respectively).

The resulting actual sRGB profile V2 XYZ values are given the next table:

sRGB profile XYZ values
White 0.95045471 1.00000000 1.08905029
Red 0.43603516 0.22244263 0.01390076
Green 0.38510132 0.71693420 0.09707642
Blue 0.14306641 0.06062317 0.71392822

In a V4 sRGB ICC profile, the information carried in the V2 profile's white point is carried in the profile "chad" (chromatic adaptation) tag. Other than that, the V2 and V4 XYZ values are exactly the same.

Comparing all the sRGB profile variants with the calculated XYX values, it turns out that the ArgyllCMS sRGB profile, the only sRGB variant that is completely color-balanced, also seems to be the real sRGB profile.

This article is the result of a lot of tedious back and forth testing, plus copying a lot of values back and forth. If you catch any mistakes, or if I've made any conceptual errors, I would be very grateful if you would let me know.