RGB numbers can describe over 16 million colors in a 24 bit file. But looking at the L*a*b* numbers in Photoshop, that space can only describe just over 6.5 million colors. (L* has 0-100, a* and b* allow -128 to 127)
And LAB supposedly includes all colors, right? Colors outside of a typical RGB editing space. So that would mean even fewer colors to define an RGB space.
So, wouldnt that lead to problems when converting to LAB, or when Photoshop uses LAB as a Profile Connection Space?

CIELAB (or Lab) describes the whole range of human vision (with some limitations due to mathematical models and perceptual uniformity).

The sheer *number* of colors per se does not tell the whole story. It's the position of the colors in the color space that matters. Depending on how they are encoded, colors look different in different color spaces.

For example, the same set of numerical RGB triplets produces a certain appearance in, say, sRGB as compared to their appearance in, say, ProPhoto RGB. It's something you can easily see for yourself by assigning different RGB profiles to an image, and seeing the changes in appearance on screen.

>RGB numbers can describe over 16 million colors in a 24 bit file. But looking at the L*a*b* numbers in Photoshop, that space can only describe just over 6.5 million colors. (L* has 0-100, a* and b* allow -128 to 127)

This calculation of number of colours presumes that values of L* are
integers. Are they? Or does Photoshop use all 8 bit values 0 to 255
mapped into this domain?

>So, wouldnt that lead to problems when converting to LAB, or when Photoshop uses LAB as a Profile Connection Space?

You may get significant benefits from one of the design aims of
L*a*b*: perceptual uniformity. While RGB may include countless colour
values you can't actually tell apart, L*a*b* should map these banks of
similar colours into closer values.

Photoshop uses L*=0..100, a*=-128 to +128, b*=-128 to +128
(not -128 to +127). L* is coded in a TIFF by 0 to 255.

Meanwhile I've tested by a brute force counting the number
of available colors in Lab for three RGB spaces:

Define RGB space
N=0
For L*=0 To 100 Step 1 Do
For a*=-128 To +128 Step 1 Do
For b*=-128 To +128 Step 1 Do
Begin
Convert L*,a*,b* to R,G,B
If R,G,B in [0,255] Then N=N+1
End
Print N

The result, number of colors in Lab:
0.832.752 sRGB % almost one million
1.208.912 AdobeRGB(1998) % more than one million
2.659.728 ProPhotoRGB % almost three millions

In simple words: scan Lab by steps 1 and increment
the counter if the resulting RGB values are in the
allowed range 0..255.
Actually, the stepsize was 2 and the total result
was multiplied by 8.

Some more information is here in chapter 18:
http://www.fho-emden.de/~hoffmann/cielab03022003.pdf

Many conversions between RGB and CieLab, both for
8 bits per channel, back and forth, don't do much harm
(they are not 'destructive'), as shown, proved or
pretended by Dan Margulis, author of 'Photoshop Lab'.
I'm sharing his opinion, based on experience by much
practical image processing for offset printing.

According to a test image, black
Lab=0/0/0 and white Lab=100/0/0
appear as hex values in the TIFF as
Lab=00/00/00 and Lab=FF/00/00.
L=100 is mapped to 255.
I'm remembering that this was already
discussed years ago with the same result.

Interesting. I can't argue with the experimental results. Maybe I
misread the specification.

Did you do the same test for Photoshop? It does make sense to use
0..255 values. There is no particular difficulty here. After all, CMYK
values are stored as 0..255 but presented in the dialogs as being
percentages.

I just did a little research. Using unofficial information on
http://magnetiq.com/docs/PhotoshopColorBook.txt, it says "The
lightness percentage is quantized to 255. To its value, divide by 255,
multiply with 100 and round to the nearest integer. "

This would make sense, would match TIFF, and would also mean that the
apparent reduction in representable colours doesn't actually exist.
(Though the question of how many of the L,a,b triplets are imaginary
colours isn't answered, and is an interesting one).

Sorry, a mistake:
The input-, output- and code-range for a*,b*
is -128 to +127 (number space for signed byte).
Wrong was -128 to +128. I'm wondering from where
I got this information. It's perhaps valid
for internal calculations.

Another observation: counting the numbers in Lab
for color spaces sRGB, aRGB and pRGB (Prophoto)
was IMO correct, but pRGB has two of three primaries
outside the human gamut. Therefore a subset of
colors in gamut for pRGB consists of 'imaginary'
colors.

IMO I don't think the number of DIFFERING colors in any ENCODED space has any relevance. See how far apart you can come up with RGB triplet combo variations between two colors of the same hue viewed in PS's color picker swatch window before you start noticing a difference between them.

When you couple that with the limited color space of available devices to view all those milions of colors it doesn't make a lot of sense to be concerned with how MANY colors there actually are available to work with.

There seems to be quite a bit of redundancy and waste of color space because human vision can only detect only a certain amount of colors as it is. The main concern is the amount of steps in hue/sat/lum available to any color to form adequately smooth gradation between colors without introducing posterization which our eyes are far more sensitive to. And I think the math combined with the device use to view all these colors, not the color space has far more influence over that than anything else.

Lab doesn't have a mathematical limit in the amount of colors contained within the space. All three values are allowed an infinite amount of decimal places and I believe that the a and b variables are allowed to continue either positively or negatively to infinity. The limits are human color perception which I'm not sure about where the bounds exist in Lab values, and more specific to the question, the arbitrary adobe limits of +/- 128 for a/b and the rounding of decimal places to the closest whole number.

As far as I can tell, ProPhoto RGB has only the Blue primary outside the spectrum locus of human-visible colors.

"Imaginary colors" is Dan Margulis' terminology, and I am not fond of it, personally. There's a valid reason for the Blue primary in ProPhoto RGB being outside the spectrum locus, as that increases the range of visible colors encompassed by the profile.

"Visible" and "imaginary" are two different things, in my opinion. The former is fact, the latter is a veiled put-down used to dismiss the use of wide-gamut working space profiles.

""Visible" and "imaginary" are two different things, in my opinion. The former is fact, the latter is a veiled put-down used to dismiss the use of wide-gamut working space profiles. "

How so? Dan is pretty clear when he describes imaginary colors as colors that are beyond the scope of human vision, so we have to IMAGINE them. I just don't see how that's a put-down in any way, shape or form. Have you read The Canyon Connundrum from cover to cover, or are you just guessing at his meaning?

Dan has made no mystery of his disdain for those who promote the use of wide-gamut working spaces. He has used large doses of heavy-handed ridicule, of which the use of "imaginary" (as in "out there") is only a small part.

Have I read the "Canyon Conundrum"? No, thanks. I value my time too much... :-)

Am I guessing at his meaning? No. Search the ColorTheory archives and see if I know Dan enough to have a pretty good idea.

> Have I read the "Canyon Conundrum"? No, thanks. I value my time too much..

C'mon now, Marco. Don't throw the baby out with the bath water.

Whatever you may feel about Dan's style, it's hard to deny that he's offered some innovative ideas about color correction. His L*a*b techniques are truly useful tools. And they have nothing to do with color management - the main point of contention between the Dan-o's and the anti-Dan-o's.

I actually think Marco is the one with the agenda here. What are you afraid of? Maybe finding out that not everything you believe in is true. I'm one of the biggest proponents of a fully calibrated and color managed workflow, and yet, somehow, I've found The Canyon Connundrum to the the single best book I've ever read concerning any aspect of digital imaging. The book is so good and so deep that I can't think of a single person who could digest it all in one pass. I've gone through it probably five or six time so far and am do for another go'round soon. It's the single book, and I've got plenty, where more lightbulbs went off as Dan's clear explanations completely changed the way I think about imaging. On any given day I employ his techniques fifteen or twenty times, and it saves me time while netting me better images. Maybe wasting a little of your time reading would be in order.

Marco's probably forgotten about including me in his private email exchange after a particularly viscious thread on the Color Theory newslist that I had participated in. I won't share them here, but suffice to say that they clearly show who has the agenda. The level of vitriol for Dan was singularly disgusting.

I think Evan and Tim hit the nail on the head in respect of the OP's question.

Much as I have my own views about it, and about the quality of the key pieces of literature in this area, I don't believe the use of image processing techniques in L*a*b is relevant to this question, hence I commend Marco's initiative to end that digression.

>ow so? Dan is pretty clear when he describes imaginary colors as colors that are beyond the scope of human vision, so we have to IMAGINE them.

Color, is a perceptual property. So if you can't see it it's not a
color. Color is not a particular wavelength of light. It is a
cognitive perception that is the end result of the excitation of
photoreceptors followed by retinal processing and ending in the
visual cortex. We define colors based on perceptual experiments.

A coordinate in a "colorspace" outside the spectrum locus is not a
color. We often refer to these as "imaginary colors" but this is by
and large also erroneous (you can't map an imaginary color from one
colorspace to another as the math (and experimental data) for each
colorspace breaks down outside the spectrum locus.

ProPhoto has IMO the blue and the green primary outside
the human gamut: page 2 here:
http://www.fho-emden.de/~hoffmann/cielab03022003.pdf
Of course, this is not a proof - may be checked by other
docs.

Personally I don't like the nomenclatur 'Imaginary
Color' in color science (no imaginary numbers, not a
color at all), but I would accept it in Dan Margulis'
book, because he excludes any mathematics on purpose.

Many years ago I found it very disturbing that a color
might be real if just inside the horseshoe contour, and
not existing if just outside, maybe caused by round-off
errors. How can a color vanish by infinitesimal shifts
of the numbers in the chromaticity diagram ?
The answer is now simple (for me): colors as defined by
numbers outside the human gamut are mathematically
existing. They have to be mapped into the human gamut
by a gamut compression.