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 color.org V4 lookup table "sRGB" variants, confusion over which could have been avoided altogether if color.org had not decided to use "sRGB" as a sort of lump term to refer to several manifestly different profiles.
Fifteen sRGB Profiles Compared
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, recently 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, color.org 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:
|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|
|Color.org, black point scaled||3||Yes||D50||sRGB-1024||yes - non-zero||downloaded file||V2|
|Color.org, no scaling||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|
|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 (V126.96.36.199)||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|
|mystery profile||5||No||D50||Custom-256||yes - zero||built-in||V2|
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:
- 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.
- The lcms profile, the two color.org 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.
- 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.
- 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:
- I added additional saturation to an already colorful sRGB image.
- I applied the Argyllcms version of sRGB to the original image and saved under a new name.
- 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.
- 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.
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):
|Red x||Red y||Green x||Green y||Blue x||Blue y|
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:
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 color.org 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.
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.
Even though the original sRGB had a D65 white point, I think a good case can be made that it makes more sense in a D50 workflow to use D50 as the white point for sRGB, at least when using sRGB as a working space rather than a CRT monitor profile. But that's just my opinion. Also, if you examine the spreadsheet, you'll see that 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.
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 color.org 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):
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 color.org sRGB profile:
Unlike the other sRGB variants, the two color.org 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) has the standard 1024 point sRGB TRC, which starts at (0,0). But both of the color.org profiles have the same non-zero black point. (And yes, the color.org sRGB profile names are confusing.)
An interesting thread over in the Argyllcms forums discusses some pitfalls when trying to use the color.org 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. Top to bottom, in the "gray gradients" image above/to the right:
- The first bar is a gray gradient to which the Argyllcms sRGB profile has been assigned.
- The second bar was produced by converting the first bar to the "no scaling" color.org profile, using relative colorimentric conversion, without using black point compensation. As you can see, the shadows got lighter.
- The third bar is a repeat of the first bar, to make comparisons easier.
- The fourth bar is the result of assigning the "no scaling" color.org 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.
- The fifth (bottom) bar is the result of assigning the "no scaling" color.org 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" color.org profile and a "real" sRGB profile (or between the two color.org 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 color.org sRGB profiles into my own digital darkroom. If you do decide to use the color.org V2 ICC profiles, handle with care.
The sRGB variants as working spaces
There are two basic criteria for a well-behaved working space ICC 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 color.org 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.
However, if you push the values out beyond the six decimal places that the xicclu tool shows, most working spaces will turn out to be not completely color-balanced and normalized, because the ICC matrix profile only holds 8 decimal places, so there are rounding errors. And many (by no means all) standard working spaces 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:
BetaRGB 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 color.org 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, 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.
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.