Pages: 1 [2]   Go Down

### AuthorTopic: What is the quantitative definition of "gamut" with respect to 'bit depth'  (Read 5603 times)

#### bwana

• Full Member
• Offline
• Posts: 188
##### Re: What is the quantitative definition of "gamut" with respect to 'bit depth'
« Reply #20 on: June 11, 2014, 12:23:51 AM »

...Going from a large space to a small space can result in values larger than the space can represent (i.e. > 255 in 8 bit images).
....

but that is what i thought my question was at the beginning of this post ... how many bits in the 'small' space and is it different than a 'larger' space. But from what I've read here and elsewhere, bits are not used to define the colorspace. Yes adobeRGB has more colors than sRGB but they both have to get 'shoehorned' into an image that 'only' has 16 bits to store a shade of red. A 16 bit image in Adobe RGB can only have one of 2^16 shades of red at a given pixel. A 16 bit image in sRGB likewise can only have one of 2^16 shades of red.  Manipulating an image in either space still gives a number that has to fall within 0 and 2^16 for R,G, and B for each pixel, no?.The number is then translated to a different number by the 'colorspace adjuster' just before the image is shipped to the display driver. sRGB and aRGB have different colors so the image is 'scaled more' when being displayed as aRGB.  Where/how is a 'colorspace handicap' applied when we manipulate an image?  Yes,  sRGB is a subset of aRGB. Converting to either space will result in 'color scaling' but isnt that AFTER all the manipulations are done?
Logged

#### MarkM

• Sr. Member
• Offline
• Posts: 428
##### Re: What is the quantitative definition of "gamut" with respect to 'bit depth'
« Reply #21 on: June 11, 2014, 04:07:06 AM »

but that is what i thought my question was at the beginning of this post ... how many bits in the 'small' space and is it different than a 'larger' space. But from what I've read here and elsewhere, bits are not used to define the colorspace. Yes adobeRGB has more colors than sRGB but they both have to get 'shoehorned' into an image that 'only' has 16 bits to store a shade of red. A 16 bit image in Adobe RGB can only have one of 2^16 shades of red at a given pixel. A 16 bit image in sRGB likewise can only have one of 2^16 shades of red.  Manipulating an image in either space still gives a number that has to fall within 0 and 2^16 for R,G, and B for each pixel, no?.The number is then translated to a different number by the 'colorspace adjuster' just before the image is shipped to the display driver. sRGB and aRGB have different colors so the image is 'scaled more' when being displayed as aRGB.  Where/how is a 'colorspace handicap' applied when we manipulate an image?  Yes,  sRGB is a subset of aRGB. Converting to either space will result in 'color scaling' but isnt that AFTER all the manipulations are done?

Okay, I think I understand where you're coming from. And you're right, it's a little confusing.

A few things that might help:

Primaries like RG & B in an additive systems can only go from completely off to 100% on — kind of like a light on a dimmer switch. 100% is the most saturated red you'll get – in an 8-bit representation you'll call that [255, 0, 0] or in 16-bit [65535, 0, 0]. Those values between 0 and 1.0 are what is represented by the math: with 8 bit images you get 256 steps between 0 and 1.0 with 16 bit you get 2^16 steps between 0 and 1.0. But whether it's an 8 bit or 16 bit representation it doesn't make sense to turn the dimmer to a number below zero or above 100%. Adding more steps between 0 and 100& doesn't change the extremes of the system—or to put another way doesn't change the gamut.

Another way to think about it that reflects how colorimetry actually works is to start with an RGB color like sRGB [255, 0, 0] and convert to XYZ. It makes it easier to see that 255 isn't just an abstract number in this context; it is tied to the the XYZ value of the sRGB primaries. That's why this specifies a precise color metric value and not just an integer. In XYZ (and D65 white point) that color lands right around XYZ[.41, .21, .02]. From there you can convert to Adobe RGB and you'll get something around [.85, .002, .0006] - basically the AdobeRGB red primary at 85%. In an 8 bit representation this would be about [219, 0, 0] or in 16-bit [56361, 131, 39]. That all works well because the sRGB primary is within the gamut of AdobeRGB. You can specify the same XYZ coordinate in both working spaces.

If you try to to the opposite — start with AdobeRGB[255, 0 0] and go to sRGB you run into trouble. Converting to XYZ you get XYZ[.58, .30, .03]. Now when you try to go from here to sRGB you end up with RGB values[1.4, 0.002, 0.223] (without gamma correction). You need your red primary to fire at 140% (or in 8-bit terms 357) to hit this XYZ value, which by definition it can't do. Whether you encode that in 8 bits or 16 bits you still can't have a primary at 140%.

I think a good simple, analogy for all this is stereo volume. I might have an average stereo system, which when I turn the volume up to 10 (its highest setting) is about 100dB. It's going to be 100dB at full blast whether my volume control has detents at every integer giving me ten steps or every 10th of an integer giving me 100 steps between 0 and 10. My friend has a rock concert set up also with a volume knob that goes to 10. But when his is set at 10 it produces 150bD. Again it doesn't matter how many steps his volume knob has, full blast is full blast. He can simulate my full blast of 100dB by turning his volume knob down a couple notches until the system is producing a 100dB, but there's nothing I can do on my system to produce 150db. His system has a larger volume 'gamut.' If both our knobs have detents at integers, I can take some comfort that between 0 and 100dB I can dial finer distinctions that he can because my 10 steps are spread from 0 to 100, while his are ten steps over 150dB.
« Last Edit: June 11, 2014, 04:25:02 AM by MarkM »
Logged

#### bwana

• Full Member
• Offline
• Posts: 188
##### Re: What is the quantitative definition of "gamut" with respect to 'bit depth'
« Reply #22 on: June 11, 2014, 08:59:59 AM »

Thank you for the stereo analogy. But to take that a little further. Srgb and argb are different amplifiers. What happens in PS is the preamp. The signal in the preamp is the same, it just sounds different when it comes out the amp. So when I convert a raw image to sRGB And do 'Photoshop' to it I get a certain palate of colors on my wide gamut (argb) monitor. But Photoshop is dealing with an abstract set of numbers that have nothing to do with colorspace (which is a property of the display chain) When I convert the same raw image to argb and photoshop it exactly the same way, I get a different palette of colors on the same monitor. Now when I CONVERT the srgb ps image to argb, it should look identical to the originally argb converted image because the underlying numbers (pixel values)for both images are the same in PS. I do not get why people say that WORKING in argb is better than WORKING In srgb. Yes, I understand that the monitor shows different colors in the two color spaces but that is literally window dressing. Yes?
Logged

#### Jim Kasson

• Sr. Member
• Offline
• Posts: 1832
##### Re: What is the quantitative definition of "gamut" with respect to 'bit depth'
« Reply #23 on: June 11, 2014, 01:03:42 PM »

But Photoshop is dealing with an abstract set of numbers that have nothing to do with colorspace (which is a property of the display chain) When I convert the same raw image to argb and photoshop it exactly the same way, I get a different palette of colors on the same monitor. Now when I CONVERT the srgb ps image to argb, it should look identical to the originally argb converted image because the underlying numbers (pixel values)for both images are the same in PS. I do not get why people say that WORKING in argb is better than WORKING In srgb. Yes, I understand that the monitor shows different colors in the two color spaces but that is literally window dressing. Yes?

I can't seem to get it across to you. I've tried several different ways, but nothing has done it yet. I consider that my problem, not yours. I just haven't found the way to say it that will make it clear to you. Analogies aren't working at all. Let's try to diagram a color managed image editor such as Photoshop:

What's stored in the image file is information about the colors in the image; not some arbitrary representation. Thus the underlying values depend on the working color space. As you edit the image, Ps, the OS, and the display driver, and, in some cases the display itself, work together to create a set of colorants (in this case voltages sent to the display pixels) that should produce the colors in the underlying image file on the display. The display turns those colorants into colors, which you see as you fiddle with the Ps tools. When you go to print, Ps, the OS, the printer driver, and the printer cooperate to come up with colorants (for example, colored ink drops) that, when they hit the paper will form colors that you and your customers can observe.

If all goes well, the colors on the display "match" (there's a world of complexity in the simple word) those on the printer. However, the gamut of colors that you can see on the display is the intersection (in the mathematical sense of the word) of the working space gamut and the display gamut. If a color is outside either gamut, you won't see it. Similarly, the gamut of colors that you can see on the print is the intersection of the working space gamut and the print gamut (which varies with printer, inkset, paper, and a few other things). If a color is outside either gamut, you won't see it.

Jim
« Last Edit: June 11, 2014, 01:32:43 PM by Jim Kasson »
Logged

#### digitaldog

• Sr. Member
• Offline
• Posts: 12187
##### Re: What is the quantitative definition of "gamut" with respect to 'bit depth'
« Reply #24 on: June 11, 2014, 01:33:54 PM »

I do not get why people say that WORKING in argb is better than WORKING In srgb.
Watch this:
Everything you thought you wanted to know about color gamut
A pretty exhaustive 37 minute video examining the color gamut of RGB working spaces, images and output color spaces. All plotted in 2D and 3D to illustrate color gamut.

High resolution: http://digitaldog.net/files/ColorGamut.mov
Logged
Andrew Rodney
Author “Color Management for Photographers”
http://digitaldog.net/

#### MarkM

• Sr. Member
• Offline
• Posts: 428
##### Re: What is the quantitative definition of "gamut" with respect to 'bit depth'
« Reply #25 on: June 11, 2014, 01:41:34 PM »

But Photoshop is dealing with an abstract set of numbers that have nothing to do with colorspace (which is a property of the display chain) When I convert the same raw image to argb and photoshop it exactly the same way, I get a different palette of colors on the same monitor. Now when I CONVERT the srgb ps image to argb, it should look identical to the originally argb converted image because the underlying numbers (pixel values)for both images are the same in PS.

So this is basically wrong and I think it's the crux of the confusion. Photoshop is dealing with numbers, but those numbers have everything to do with colorspace — colorspace gives those colors meaning. It's what makes Photoshop a colorspace aware application. If you do the experiment you suggest here, you'll find that it doesn't work the way you describe.

Take an sRGB image that is a solid saturated green — say [0, 200, 0]. Now perform some manipulation on it with the saturation adjustment by increasing saturation +50. Now what color is your green? It's still [0, 200, 0], right? That's because it's already at 100% saturation in sRGB and since sRGB is your working space you can't move beyond it. This color — sRGB [0,200,0] —  matches [112, 99, 47] in AdobeRGB and probably something similar in the space of a wide gamut monitor.

So now if you take the matched color in AdobeRGB, which we've established is [112, 99, 47] and perform the same photoshop on it (+50 saturation) you end up with an entirely different color, AdobeRGB[106, 244, 0]. This color is outside the sRGB gamut. If you are using a monitor that can display it you'll see a color shift when you try to convert back to sRGB.

So the experiment fails starting with sRGB performing some photoshop on it and then starting with aRGB and perfuming the exact same photoshop results in two different colors. In this case colors only available in AdobeRGB.

#### MarkM

• Sr. Member
• Offline
• Posts: 428
##### Re: What is the quantitative definition of "gamut" with respect to 'bit depth'
« Reply #26 on: June 11, 2014, 02:23:59 PM »

One additional thing that's kind of fun and (maybe) useful in this context is to take the small gamut space to the extreme. I've attached an RGB icc profile that you can try using as a working space. It has a very small gamut, so small in fact that it has practically no saturation. But it's still an RGB space. I'll also attach an image in this space that you can convert or assign to other spaces to test your assumptions about how photoshop works. It doesn't look like it, but it's an RGB file — you can confirm that with the info pallet. It should work in every way like an RGB image in photoshop allowing you to adjust the saturation and channel curves etc. You can also think about what is happening when these RGB numbers are sent to your wide gamut monitor. You can convert to another RGB space and the appearance should be maintained — any RGB space should easily contain its gamut. If you assign an RGB space then you'll see what these RGB numbers mean in a different context.

[edit - one thing you will notice – if you click on the attached image it becomes obvious that the Lula forum software strips the profile of the the thumbnail, but not the larger preview ]
« Last Edit: June 12, 2014, 03:24:43 AM by MarkM »
Logged

#### bwana

• Full Member
• Offline
• Posts: 188
##### Re: What is the quantitative definition of "gamut" with respect to 'bit depth'
« Reply #27 on: June 13, 2014, 12:24:41 AM »

Thank you Mark, Anthony and Jim for the time and energy you have given to explaining this. I have obviously been confused. All this time I imagined that Lightroom and PS have been working in some kind of mythical 'raw space' and only applying the colorspace transformation at the end. In fact, the colorspace is baked into the actual pixel values the moment the image is raw converted.

Mark, the extra small profile really helped me understand this  because assigning that profile made changes to the image that stood out. Manipulations in the extra small space made visible changes to the image but then I could not 'get the colors back' by going to a larger space. Even though the image was in RAM and not saved to disk, the information was IRREVERSIBLY changed when I assigned a different profile.

Interestingly, I could not convert a raw image to the 'extra small' color space. no matter where i put the profile on my machine.  for example the adobe 1998 profile lives here:
System/Library/ColorSync/Profiles/
putting the extra small profile in this folder (and saying yes to the authentication dialog)  and then rebooting and restarting PS did not give me the option to convert images using this profile. And the extra small profile does not show up when I select the " convert profile " command from the edit menu, either.
« Last Edit: June 13, 2014, 12:44:55 AM by bwana »
Logged

#### MarkM

• Sr. Member
• Offline
• Posts: 428
##### Re: What is the quantitative definition of "gamut" with respect to 'bit depth'
« Reply #28 on: June 13, 2014, 01:30:07 AM »

Interestingly, I could not convert a raw image to the 'extra small' color space. no matter where i put the profile on my machine.  for example the adobe 1998 profile lives here:
System/Library/ColorSync/Profiles/
putting the extra small profile in this folder (and saying yes to the authentication dialog)  and then rebooting and restarting PS did not give me the option to convert images using this profile. And the extra small profile does not show up when I select the " convert profile " command from the edit menu, either.

Hmm, it is a pretty messed up profile that I made for easily testing when a system was ignoring profiles. I'm not surprised that it doesn't entirely behave. You might try seeing if it shows up when you attempt to assign rather than convert. I'll have to tinker with it and see what's missing.

Pages: 1 [2]   Go Up