# What's the difference between colour space and bit depth?

I know that there are different types of colour space and that sRGB is the most common. Bit depth defines the variations of a colour channel, where (I think) 8 and/or 16 bits are the most common.

Some might say they are totally different and other might say they aren't mutually exclusive.

Can anyone explain the differences? If you increase bit depth, why aren't you also increasing the colour space?

Basically, life color information is like a box of chocolates crayons...

Color information is stored in integers, not analog values — there are a discrete, countable number of colors that can be described at a certain bit depth.

Think of the color space like a box of crayons of different colors. A color space describes the types of crayons that are available. Think "bold colors", "pastels", or the like. The bit depth describes the number of crayons.

Here's an example of two different boxes of crayons:

Both have 16 crayons, but they have a different range of colors — specifically, the lower set doesn't extend as far into red. Since there are 16 colors, that's 4 bits of color depth (2⁴ = 16).

A "real" color space is three-dimensional, and this just has one dimension. (That is, the hue.) But it makes a model which I hope helps. The top "box" has a color space which has a very red "primary" color at the extreme edges, while the lower one only extends to a reddish orange.

The top color space seems, at first, to be obviously superior (you can't even draw something red with the bottom one!), but consider the situation where you are drawing a landscape with sky, water, and trees. The bottom set of crayons may actually be much better, because it uses more of its "bits" on representing subtle shades of green and blue.

If, instead. you bought the same color ranges in 64-crayon sets, there would be three new crayons between every existing one. The lower set would still have more options for blue and green, but because of the new crayons, the top set would also have a lot more choices in that range than the 16-crayon set. Since the upper set also covers red, with enough crayons it would be objectively better.

However, one can imagine a choice where both boxes have something missing. It's a little easier to see how that might be the if we go to a little more complicated visualization, here of real sRGB (as a TV or consumer-level computer monitor) and standard "SWOP" CMYK inks:

Here, you can see that the CMYK SWOP colorspace¹ extends further into the cyans, magenta/purples, and yellows than can be represented in sRGB. Even if we add more bits to distinguish between the available distinguishable steps, the colorspace determines the border. Likewise, adding more bits to the CMYK representation doesn't help represent the far corners of red, green, and blue covered by sRGB. (And of course all of them are a poor representation of the gamut of human vision, represented by the outer shape — if you've ever wondered why it's so hard to get digital photos of greenery to look natural, this is part of the story!)

In real life, 24 bit color spaces (8 bits per channel),you have 16.8 million colors to work with. That's generally fine, and widely considered to be more colors than the human eye can distinguish but if your color space is really large, you may actually have this same effect where the jump between individual colors in the middle is larger than ideal, and it's possible that it'd be noticeable in certain situations.

In fact, some "wide" color spaces like ProPhoto RGB have colors at the edge of the space which do not correspond to anything in human vision. They're theoretical, "imaginary" colors which make the color space work, but are effectively wasted. When you use a color space like that with a small number of crayons (low bit depth), you have fewer options for actually useful colors, making the possibility of missing steps more of an issue. Something like sRGB can't cover far-out cyans and greens (just like the missing red in the set above), but in exchange, you get more fine distinction between the blues and purples and reds (and the greens which are there).

If we go to 16 bits per channel (48 bits total), there are 16.8 million additional "crayons" between every shade in the box. This is complete overkill (both in what humans could possibly distinguish and in the practical reality of representing that subtle of a difference on screen or in print), but that overkill guarantees that smooth transitions are always available. And since in real life, color spaces are all roughly designed to cover human vision (even if they don't line up exactly), you don't really run into the situation where your color space has no red at all — it just might be not quite as deep or subtle.

The other thing worth considering is that sRGB is designed not just to be a decent match for human vision, but to be representable on most consumer devices, and it's the default assumption for non-color-managed display. That means that when you're using sRGB, you have the best chance that the "crayons" you are using will correspond to the "crayons" that your viewers' devices use. That's why I recommend saving to sRGB for web viewing and sharing — higher bit depths aren't a widespread option, and most people don't have the ability to swap out for a set of crayons of your choice. (Hopefully this will get better in the future, but it doesn't really seem to be a priority for consumer device manufacturers. Maybe when the 3D and 4K hoopla settles down we can get more emphasis on "deep color" — higher bit depths for consumer displays.

(Some of this borrowed from my earlier answer to How do color spaces like sRGB and Adobe RGB overlap?)

Footnote

1. This particular example is an oversimplification and glosses over the real representation of CMYK images and some other details; it makes a good example, though, because most real color spaces are designed to overlap as much as possible and this shows something that has a mismatch.

• OK. So, lets say the top colour space (top row of crayons) has double the bit depth of the bottom one, theoretically it could cover all the colours/shades as the bottom one? However, if both are the same in bit depth, then no. It can't cover the same colours/shades. So, even though you're not changing the colour space, increasing the bit depth (of a colour space) has the potential to cover the same colours as a different colour space? Commented May 27, 2014 at 0:42
• @BBking Well, it's three-dimensional rather than the one-dimensional line the crayon example gives, but in either case the question of coverage basically has to do with the extremes. Look at the second row — adding more bits isn't going to add in the red extremes. But going the other way, yes, because of the way I constructed it, enough more bits in the top will make it cover more colors — it won't be exactly the same one, but it'll still be a smoother gradient. If you go to more than 2×, the top row will be a superset of the lower one. Commented May 27, 2014 at 0:54
• However, I could have constructed the lower row so it extends in a direction the top row doesn't cover — it could be that the extremes don't overlap, and no amount of adding bits will change that. (See the [overlap question for more.) Commented May 27, 2014 at 0:56
• I see. Now I don't know if I should change yours to the answer... :/ Commented May 27, 2014 at 3:33
• @BBking Well, let me know what else could be more clear! :) Commented May 27, 2014 at 6:18

Bit depth and color space are not the same thing, and neither are they mutually exclusive. They are different things that exist simultaneously. For a particularly simple explanation:

• Bit depth determines the fineness with which each distinct color is graded.

• Color space determines the extent within which those colors are distributed.

Let's take sRGB and AdobeRGB as color spaces, and 8-bit and 16-bit color as bit depths. sRGB is a small color space, while AdobeRGB is a larger color space. Color spaces, or gamuts, define the extent with which colors can be chosen from the entire range of color visible to the human eye (or, even, beyond that range, as would be the case with ProPhotoRGB or some of the new 10-bpc TV gamuts). If you map the color "Pure Green" in sRGB, that color will indeed be a numerically pure green...however it may not be the most perceptually accurate pure green. Map the same color "Pure Green" is AdobeRGB, and while numerically it is the same green, when mapped in AdobeRGB it's more saturated and vibrant. (Further, map the same color in ProPhotoRGB, and it will again be even more saturated than in AdobeRGB...assuming, of course, that the device your viewing this mapped color in is actually capable of achieving that level of color saturation...very few devices actually are.)

Now, in comes bit depth. The difference between Pure Green in 8-bit and 16-bit is 0,255,0 vs. 0,65535,0. A much larger number is used to describe the green channel in pure green in 16-bit color than in 8-bit color. If we bring in a Medium Green, the value in 8-bit might be 0,128,0 while in 16-bit it would be 0,32768,0. Same color, but the number of distinct colors on the grade between Pure Green and Medium Green is far higher with 16-bit color. You have a total of 32768 distinct levels of green between those two levels in 16-bit, vs. a mere 128 distinct levels in 8-bit. Lets say we pick a lighter green, say 0,192,0 in 8-bit. That same color would be 0,49152,0 in 16-bit. This increase in potential distinct colors means that gradients become considerably smoother and more finely delineated when using a higher bit depth.

Finally, how do bit depths and color spaces work together? With a narrow gamut, like sRGB, you have a restricted color space within which to map distinct colors. With sRGB and 8-bit color, each color is going to be truly distinct as you go through all the greens from from 0,1,0 through 0,128,0 to 0,255,0. What happens if you have a 16-bit image in the sRGB space? Numerically, your image has the ability to represent over 280 trillion distinct colors (16+16+16 bits is 48 bits total, 2^48 is 281.5 trillion). Perceptually...when numeric RGB values are mapped to gamut-restricted colors, a significant amount of that 280 trillion colors will end up getting mapped to the exact same "color coordinate" within the color space. Your image file still contains full precision color data, however when it is rendered to the screen (or rendered to print), the actual number of distinct colors is ultimately going to be limited by the color space.

If we move up to AdobeRGB, the gamut grows, it's a larger color space and can therefor encompass a greater number of distinct color mappings. With an 8-bit color depth, your effectively going to be sparsely mapping into this larger gamut. Technically speaking, the gamut is capable of describing more colors than your bit depth is allowing you to reference. Your limiting factors have now swapped...instead of the gamut being restrictive, bit depth is being restrictive. If we go with 16-bit color in the AdobeRGB color space, there is more room for our 280 trillion potential colors to reference distinct colors. It's likely that multiple colors will still map to the same actual coordinates in AdobeRGB space, however there will be far fewer collisions in this larger space than with sRGB.

So, while color space/gamut and bit depth are distinct things, they are interrelated. You are not required to use a larger gamut when using a higher bit depth to store your image data, however it is advisable to get the most out of that higher bit depth. Conversely, if you are saving images with a lower bit depth, there is often less value in rendering those images with anything more than sRGB.

To fully take advantage of high bit depth color information in an image file, larger gamuts, and concurrently better screens that can actually display those gamuts, become valuable. To render 10, 12, and 16 bit color on TVs or computer screens, gamuts larger than AdobeRGB, and even larger than ProPhotoRGB, are often necessary to take full advantage of human visual perception. Our eyes are amazing devices, and capable of incredible dynamic range and extremely wide color sensitivity. Modern day 10-bit screens with 12-, 14-, and 16-bit hardware LUTs (3D Color Look Up Tables) are capable of displaying 1.07 billion concurrent colors, selected from a total of 68.7 billion (12-bit), 4.4 trillion (14-bit) or 281.5 trillion (16-bit) colors that are very accurately described by the LUT.

• "The difference between Pure Green in 8-bit and 16-bit is 0,255,0 vs. 0,65535,0." Perfect! That made me understand a lot better. Commented May 26, 2014 at 10:35
• Color space isn't just "extent" (gamut); it encompasses the entire topology of the colors in the space. Consider non-RGB color spaces such as YUV, HSL (often represented as a cylinder instead of a cube), CMYK (a 4-dimensional space), etc. Commented May 27, 2014 at 10:56
• @Jason: The term "extent" works for three-dimensional spatial objects. It does not mean just a two-dimensional extent such as a triangle superimposed on top of the full brightness/saturation plot of Lab space. Extent means the entire extent of the color space, in all three dimensions, regardless of the actual shape that extent takes. I'd also state that sRGB, AdobeRGB, etc. are color spaces, while RGB, YUV, HSL, CMYK, etc. are color models, not color spaces. Color spaces ARE 3D, but generally they have odd mushed diamond shapes, they are never cylindrical or cubic. Commented May 27, 2014 at 16:51
• From a numeric standpoint, yes. From a rendering standpoint, it depends on the color space. ;) Commented May 28, 2014 at 3:58
• Using Matt's example colors, it would probably end up bright yellow (255,255,0), since that is the closest viable option. If you mean (255,0,0) then it would end up orange. There are various rendering intents that can be used when mapping numeric color values to color-space coordinates: Absolute, Relative, Saturation, Perceptual. Depending on the intent, the exact color outcome (the "rendered" color) will be slightly (or maybe wildly, really depends on the color space and ICC profile) different. Commented May 28, 2014 at 23:11

These are independent things. Color-space represents all possible colors and is a continuous space. Digital devices require a discretization of the space. This means the steps at each they can represent colors that are within the color space.

Here is a simple analogy: Thing about the height between two floors as a color-space. That is the space between the floors. Now how many steps you need to build a staircase from the lower floor to the upper one? The answer depends on the size if the step. That is the bit-depth.

Now when you talk about bit-depths used in file-formats, the situation is more complex because not all steps are the size that is because bit-depth is not uniformly distributed in the linear sense. Sometimes the steps follow a preceptual-based curve, a gamma curve or a log curve.

Generally if you increase the bit-depth you get more gradation within a color-space but its boundaries remain the same. There are however HDR file-formats that use floating point or fixed point values which may even be negative in order to represent colors outside of the special color-space.

• I think I'm still at the same level of understanding. Your building analogy confused me even more. If you had said that Colour Space are like the amount of levels in a building (each level representing a colour) while the steps in the building can be the bit depth. So, within the same colour space you can have different bit depths. If a building is sRGB with 8 bit steps, this will have less colour detail than a 16 bit step sRGB building. However, increasing the bit depth in creases the building size. Therefore, changing (but not greatly) the colour space?? Commented May 26, 2014 at 4:53
• @BBking: That isn't quite correct. The two are not linked in that way. The building size doesn't have to change if you move to 16 steps, because you can make the steps be closer together than when you have only 8 steps. Bit depth is the closeness of the steps, while color space is the size of the building. I've added an answer that may help. Commented May 26, 2014 at 7:23
• Note that a color space does not intrinsically represent all possible colors, most don't. Or did you want to say something like "the color space of X describes the set of possible colors in X"? Commented May 26, 2014 at 7:32
• @BBking Increasing the bit depth in the same color space doesn't increase the building size. It decreases the distance between each step on the staircase. It's still 21.25 feet from one floor to the next, but now the staircase has 65,536 steps that are each only 1/256 of an inch higher than the one before it, whereas with 8-bit you had 256 steps that were each one inch tall. So the second staircase looks more like a smooth ramp than the first one does. Increasing the bit-depth makes continuous tones smoother. Commented Feb 1, 2021 at 20:41

Lets try a simple example. Lets say we have a color space called "rainbow". It contains the colors of a rainbow, so it is made up of red, orange, yellow, green, blue and violet. The color space describes a range of colors that are covered by the gamut.

Bit depth on the other hand defines how many distinct colors we can make within that space. If we only had a couple bits, we'd only be able to represent the basic colors of the rainbow, but if we had a bunch of bits, we could make dark reds and bright reds and medium reds, etc. With more bits, we can define more unique values and so have more colors, but they are still all shades of red, orange, yellow, green, blue and violet.

This is why it is actually possible to have a higher bit depth represent a smaller range of color, you just end up with far more precision within the colors that are covered.

More technically, the bit rate defines the granularity of the colors within the color space and the color space defines the min and max values of the color (and possibly some other things too, depending on the space), but you could have any number of steps in-between those values.

The extra bits to expand the color space you cover, give more fine control of the colors within the color space, or do some combination of the two.

An easy way to think about such things is that color spaces are containers. They contain the color values of the color space they were created for. If they are RGB color spaces the values are RGB- 0-255 in each channel. If CMYK 0-100 values.

Those values do not change if the volume of the color space does. What changes the volume of a color space is the CIEXYZ values that define that space. A larger volume color space generally can contain colors that are more saturated. An example of that is sRGB a small color space by volume, and ProPhoto, a large color space by volume. Opening an sRGB image in Photoshop produces an expected result, but then assigning the ProPhoto ICC profile drastically changes the image color, and makes it more saturated but the RGB values have not changed. Just their relationship to CIELab. Those CIEXYZ values that define the volume of the color space are converted to CIELab and then to the destination space.

Bit depth is the amount of color information available in a pixel. That's explained very well Here Higher Bit depth applied to photography and digital images allow more picture information in each pixel. This higher bit depth provides greater adjustability when opening up shadows or bringing back highlight details. Remember that is rendered pixel bit depth not captured bit depth. Remember that once bits or color space is reduced, it can not be expanded. Taking an 8 bit image to 16 bits does not create more bits per pixel, it simply doubles the bits in the 8 bit pixel. Same thing with color spaces. If the image was rendered into sRGB and now you would like all of those bright colors from the orig image printed on your large gamut printer, sorry those colors do not exist any more in that sRGB image. Start over and render those pixels into the larger color space.