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.
Answer
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: 
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.
No comments:
Post a Comment