22
\$\begingroup\$

Is sRGB included in Adobe RGB, and Adobe RGB included in ProPhoto RGB? Meaning that a photo in a "lower space" will look like exactly the same in a "higher space", e.g. a sRGB photo will look like exactly the same in a Adobe RGB space.

I noticed the size of a sRGB photo is bigger than the same one in Adobe RGB, which I don't understand since the color space is bigger.

\$\endgroup\$
2
  • \$\begingroup\$ What file format are you saving as? Some compression algorithms are not deterministic, and saving the same image again and again can result in slight differences in final file size. \$\endgroup\$
    – jrista
    Commented Jul 22, 2011 at 16:52
  • \$\begingroup\$ JPEG. And reading the following answers, I just realised that it was simply coming from the compression. \$\endgroup\$ Commented Jul 22, 2011 at 23:03

3 Answers 3

33
\$\begingroup\$

Check out this image by Jeff Schewe from wikipedia. It's a 2D slice of what's really a three-dimensional space, but it makes the basic concept clear: color spaces

So: sRGB is a subset of AdobeRGB, which is a subset of ProPhoto RGB.

You can also see how ProPhoto RGB extends outside of the curved shape which represents visible colors. And you can see how AdobeRGB is a better fit for printing on matte paper than sRGB — and how far outside what can be printed on paper the ProPhoto space extends.

But this isn't the whole story, because of the issue of bit depth. In common file formats used for display, color information is stored in integers, not analog values — there's a discrete, countable number of colors that can be described at a certain bit depth. Think of the color space like a box of Crayola crayons of different colors. Each color space has the same number of crayons. In the larger spaces, some of that limited number has to be used up for the wider coverage — in ProPhoto RGB, you've got a number of "crayons" devoted to colors that humans can't even see. sRGB has the same number of crayons packed into a smaller range. That means, in exchange for not being able to represent those far-out cyans and greens, you get more fine distinction between the blues and purples and reds (and the greens which are there).

In 8-bit-per-channel color depth (24 bits overall), there's about 16.8 million crayons, which is a lot, but enough that there's still a chance for color artifacts in subtle gradients. And, when you map from one color space to another, the crayons don't necessarily line up. ProPhoto RGB may contain all of sRGB, but if you're working in 8 bits, it's lossy to go back and forth.

Imagine that you've got three different shades of red in one crayon box, and two shades of red in a different box (because that second box needs the extra crayon for ultramarine). If you're trying to duplicate a picture drawn from the first box, you have to compromise on your rendition of red. And if you then go to make another copy with your first crayons but without looking at the first image, you'll probably not pick the same mapping from those two reds to the more expressive three.

However, if you can work in 16 bits per channel, this is really not an issue. That's because for each crayon in 8-bits-per-channel, 16 bits gives you 16.8 million crayons. That's a lot of subtle gradation — almost certainly beyond what the human eye can distinguish. (The overall number of distinct colors in 16-bit color depth is over 281 trillion.) So, if you're using an application like Adobe Lightroom that works in 16 bit color depth, switching color spaces isn't a concern — but you do have to decide what compromises you want when you want to go down to a final output value, because we don't really have good, standard, popular, well-supported 16-bit high-gamut-color-space file formats yet.

As for the size of the resulting file: that's basically just going to be a quirk of how the compression worked out. The actual span of the color space makes no difference in the file size, since, again, same overall number of crayons in any case. It's possible that your sRGB photo is bigger because the Adobe RGB version "collapsed" some of the subtle color distinctions into the same value (not enough different kinds of red crayon?). But it's probably just a quirk of how the "reassignment" of crayons causes the data to be different and therefore the compression to be different.

\$\endgroup\$
11
  • \$\begingroup\$ So I was writing my answer and at the same time you added the part on file size... \$\endgroup\$
    – ysap
    Commented Jul 22, 2011 at 14:08
  • \$\begingroup\$ This is quite awesome. Thank you for the great dumb downed examples and bringing it all back down to earth with the Lightroom reference. Great answer @mattdm! \$\endgroup\$
    – dpollitt
    Commented Jul 22, 2011 at 19:07
  • 1
    \$\begingroup\$ @Julio: a display device should be profiled with its own "native" color space — the actual colors which can be shown with the color phosphors, lighting technology, or inks of the medium. Any image is always "translated" to that simply by physical reality. Having a profile for your monitor lets your software know how to do this correctly — otherwise, it just assumes that sRGB will come out well enough. [con't...] \$\endgroup\$
    – mattdm
    Commented Jul 24, 2011 at 0:00
  • 1
    \$\begingroup\$ But in any case, an image in sRGB and one in Adobe RGB will get mapped to the real display in some way. Since the colors within the color space are slightly different (even with in the sRGB gamut), the result may be slightly different, but if everything is working correctly, the difference will be hard to spot — subtle shifts in gradients. If you see big, overall color shifts, something is not set up right. \$\endgroup\$
    – mattdm
    Commented Jul 24, 2011 at 0:04
  • 1
    \$\begingroup\$ On top of this, many cheap LCD displays actually only do 6-bits-per-channel, so 8-bits-per-channel images lose "crayons" on-screen like-it-or-not. (That's 16.8 million down to 262 thousand.) In that case, the discrepancies in in-sRGB-gamut rendition of sRGB and Adobe RGB images will be overwhelmed by that large cut. \$\endgroup\$
    – mattdm
    Commented Jul 24, 2011 at 0:05
10
\$\begingroup\$

If you have a Mac, you can visualize differences between color spaces in 3D - run ColorSync Utility, and select a large color space (like ProPhotoRGB or AdobeRGB). Then click on the arrow at the upper left corner of the plot, and select "hold for comparison". Then select a different space to see it plotted on top of the other one, you can rotate all around.

You may have to open up folders at the bottom of the color space list to see more spaces, if you have Photoshop installed.

Practically you can use this to gain understanding of differenced between spaces, but also to see how custom printer profiles fall within a space.

An example showing AdobeRGB inside of the ProPhotoRGB whale:

enter image description here

\$\endgroup\$
1
  • 1
    \$\begingroup\$ You want to see that whale eaten by a giant... something larger than a whale? Try Microsoft's crazy scRGB. :) \$\endgroup\$
    – mattdm
    Commented Jul 22, 2011 at 15:55
5
\$\begingroup\$

To add to @mattdm's great answer - but unless I missed it, there is no explanation to the file size - I would speculate that when shooting aRGB and then transforming to sRGB with an intent that saturates the overflowed color (relative colorimetric), then since in the range of the aRGB gamut that is not transformed (not clipped) there are less discrete color levels (b/c the total # of levels is the same - 256), you end up with a "posterized" image. That is, your sRGB image contains less individual color values than the original image. Due to this decimation, the small gamut compressed image is smaller than the full gamut compressed image.

From a different perspective, if the aRGB and sRGB images look the same, it means that the original scene was not color-rich, so it "fits" into the sRGB limited gamut. But, using aRGB for capturing this scene means that you use only a subset of the available discrete colors. This, again, leads to a better compression ratio and a smaller file.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.