Color management myths and misinformation video

[GWGill]

The thing is, as regards gamut, there is no "miles or kilometers" or any generally accepted thing that you could count - at least not in any sense that would be relevant to a non-geek.

Yes there is - distance in device independent space (ie. a colorspace directly related to what we see).
For a measure that can be compared in significance, using a perceptually uniform space is even better.
Hence the use of delta E as a measure of gamut size.

To count things, you have to be counting individual values, which immediately means you're in a particular file format.

Not at all. We don't measure the distance between things by seeing how many 1 meter (or 1 foot) rulers we can lay end to end, beyond elementary school. At some stage in our education we are introduced to real numbers rather than simple counting. So it is with measuring colorspaces.

[bjanes]

<nit-pick mode on> The number of discrete values expressible as an n-bit unsigned integer and as an n-bit floating point number are equal for all values of n in the set of positive integers, are they not? In both cases, the number of discrete values is 2^n. Actually, as I think about it, the number of discrete values expressible in floating point notation is somewhat less, since some bit combinations are not allowed, for instance if subnormal numbers aren't allowed. Then there's signed zero.<nit-pick mode off>

Good post, though. And I think Andrew is on the right track.

Jim

Touché! Also, in grammar one uses number for discrete things than be counted (integer values implied), but amount for things that be counted as explained here.

Bill

[smthopr]

I've been following this thread...as best I can

From something that started to explain color spaces to the un-initiated, it's become quite technical and even perceptual.

So I'd like to throw another wrench into the works:

I will assume that ProPhotoRGB is such a large color space, that it contains all the range of color that our digital capture devices are capable today.
So, by working in ProPhotoRGB, in a high enough bit depth, I'm basically maintaining all my captured image data.  So far, so good.

But, I need to process my RAW data and map it into ProPhotoRGB. OK, but, I if I have the best display available, I must STILL edit, and make my decisions viewing the data in Adobe RGB (or something close).  I'll leave final output to print, or whatever for later consideration.

But I have a question:  Isn't it possible convert from RAW directly into Adobe RGB without throwing away any data?  Simply by re-mapping all the values so that they fit into Adobe RGB?  Yes, I understand that the colors will look dull, at first, on the display.  But consider this:

Each color space contains the same number of addressable values.  So, if I can fit the image into ProPhotoRGB, then I can fit the same image into Adobe RGB, or even, sRGB.  Upon editing (manipulation of the values) I can choose which values to present in my final image, and which to throw away (clipped).  And, if working in floating point bit depth, I suppose the clipped data can still be saved with the image file.

So my point really is. No matter what we do, we are really working in the color space of our display device.  And no matter how we parse it, this will ALWAYS be our limitation.  If someone has an sRGB (or near sRGB) display device, they will be editing in sRGB no matter what. And, "soft proofing", which is a good aid to preview prints, still can not show any values outside of the ability of the display to present them.

We have a tendency to think "bigger is always better".  A 36mp camera is twice as good as an 18mp camera etc.  But, what we are really doing here is saying "11 is one louder than 10". (Joke from the movie "this is spinal tap")

[smthopr]

I've been following this thread...as best I can

From something that started to explain color spaces to the un-initiated, it's become quite technical and even perceptual.

So I'd like to throw another wrench into the works:

I will assume that ProPhotoRGB is such a large color space, that it contains all the range of color that our digital capture devices are capable today.
So, by working in ProPhotoRGB, in a high enough bit depth, I'm basically maintaining all my captured image data.  So far, so good.

But, I need to process my RAW data and map it into ProPhotoRGB. OK, but, I if I have the best display available, I must STILL edit, and make my decisions viewing the data in Adobe RGB (or something close).  I'll leave final output to print, or whatever for later consideration.

But I have a question:  Isn't it possible convert from RAW directly into Adobe RGB without throwing away any data?  Simply by re-mapping all the values so that they fit into Adobe RGB?  Yes, I understand that the colors will look dull, at first, on the display.  But consider this:

Each color space contains the same number of addressable values.  So, if I can fit the image into ProPhotoRGB, then I can fit the same image into Adobe RGB, or even, sRGB.  Upon editing (manipulation of the values) I can choose which values to present in my final image, and which to throw away (clipped).  And, if working in floating point bit depth, I suppose the clipped data can still be saved with the image file.

So my point really is. No matter what we do, we are really working in the color space of our display device.  And no matter how we parse it, this will ALWAYS be our limitation.  If someone has an sRGB (or near sRGB) display device, they will be editing in sRGB no matter what. And, "soft proofing", which is a good aid to preview prints, still can not show any values outside of the ability of the display to present them.

We have a tendency to think "bigger is always better".  A 36mp camera is twice as good as an 18mp camera etc.  But, what we are really doing here is saying "11 is one louder than 10". (Joke from the movie "this is spinal tap")

In addition to shooting still photographs, manipulating them on my computer, and printing, I'm also a cinematographer.  I've computer color graded 6 feature films, with myself at the controls.  The reason I bring this up, is that we don't have .icc profiles and rendering intents in this end of the photography business.  But we have the same challenges.

Our workflow is like this:

Capture in camera the most information that we can by recording RAW data, or by recording the full range of data into...sRGB space.  How do we do that? The camera processor de-bayers the image and maps the data to a logarithmic curve that fits entirely within the sRGB (or REC709) color space.  But we've recorded all the data!  And when viewed on an sRGB display...it looks very dull and washed out.

When we do the color correction, we work in the color space of our display device.  There are two standards: REC709 aka sRGB, and PCIp3 digital cinema projection color space.  That's it. Two choices.

When working, we use a concept akin to "adjustment layers" in photoshop, previewing the corrections on our calibrated display.  All the data is maintained...until rendering and final output, at which time, all out of gamut values are clipped and lost.

But my point is, is that we work, 90% of the time mastering and viewing in sRGB. (10% in P3 space).  Yet, we select our color values, from all the values that were captured in the camera.  No ProPhoto RGB necessary.

But we have one advantage over the still photographers:  Our "prints" or final output is on a display which is very close to the device used to make the color decisions.  With still photographs, the printer color gamut can reproduce some values beyond adobe RGB and can not print some values within adobe rgb (or the previewing device gamut).  And so, the idea of ProPhoto RGB begins to make some sense.  But you can't SEE the advantage...until you've made a print on a large gamut printer.

Thanks for reading my chain of consciousness essay on color!

[digitaldog]

I will assume that ProPhotoRGB is such a large color space, that it contains all the range of color that our digital capture devices are capable today.

Not necessarily, but you can go to the locked down "Stand Up comic" post and see the discussion of camera with respect to gamut and color mixing functions. But for this purpose, let's just agree with the above premise.

So, by working in ProPhotoRGB, in a high enough bit depth, I'm basically maintaining all my captured image data.  So far, so good.

Correct.

But, I need to process my RAW data and map it into ProPhotoRGB. OK, but, I if I have the best display available, I must STILL edit, and make my decisions viewing the data in Adobe RGB (or something close). 

Correct. So just be careful when editing such that if you are moving a slider as an example, and suddenly you stop seeing the preview appear to update, you're probably affecting colors you can't see. Back off!

But I have a question:  Isn't it possible convert from RAW directly into Adobe RGB without throwing away any data?

If you clip colors doing this because the working space is smaller than the gamut of the image, no. You clipped that data.

Simply by re-mapping all the values so that they fit into Adobe RGB?  Yes, I understand that the colors will look dull, at first, on the display. 

NO. They will not. Don't drink that Fong coolaid. It will only look 'dull' if you don't properly color manage the data (treat Adobe RGB as sRGB).

So my point really is. No matter what we do, we are really working in the color space of our display device.

Absolutely not. Since Photoshop 5, the display and how we edit our images has been divorced. That's why they introduced RGB working spaces, editing spaces that have nothing to do with your display.

We have a tendency to think "bigger is always better".

In this context, that's right. At least better unless you are OK clipping colors you can capture and reproduce.

[smthopr]

Not necessarily, but you can go to the locked down "Stand Up comic" post and see the discussion of camera with respect to gamut and color mixing functions. But for this purpose, let's just agree with the above premise. Correct.  Correct. So just be careful when editing such that if you are moving a slider as an example, and suddenly you stop seeing the preview appear to update, you're probably affecting colors you can't see. Back off! If you clip colors doing this because the working space is smaller than the gamut of the image, no. You clipped that data. NO. They will not. Don't drink that Fong coolaid. It will only look 'dull' if you don't properly color manage the data (treat Adobe RGB as sRGB). Absolutely not. Since Photoshop 5, the display and how we edit our images has been divorced. That's why they introduced RGB working spaces, editing spaces that have nothing to do with your display.In this context, that's right. At least better unless you are OK clipping colors you can capture and reproduce.

Andrew, I haven't drunk any kool-aide from you know who:)
And I'm completely serious. It is possible to fit all the camera data into sRGB.  It just will not display the way you expect.  But, it is possible to reverse the process and display it as YOU WANT. (not yelling, just trying to emphasize a little:)

And in the ultimate reality is that we WILL be editing in our display gamut, like it or NOT.

I think I explained this a little bit in the 2nd half of my post which came after your reply.

[digitaldog]

And I'm completely serious. It is possible to fit all the camera data into sRGB.

No. Not if your definition of the camera data is the color's resulting from a raw you could encode into a working space.

And in the ultimate reality is that we WILL be editing in our display gamut, like it or NOT

Yes and if that's your only output, use sRGB.
Here's the question to ask yourself. Do you want to retain all the color data you can but not necessarily see it on-screen, data you can output? Or do you want to limit the data so you can see it all but not use all you could have retained and used for output to another device? I have no issue which you pick. Pick the one that makes the most sense to you.

[smthopr]

No. Not if your definition of the camera data is the color's resulting from a raw you could encode into a working space. Yes and if that's your only output, use sRGB.
Here's the question to ask yourself. Do you want to retain all the color data you can but not necessarily see it on-screen, data you can output? Or do you want to limit the data so you can see it all but not use all you could have retained and used for output to another device? I have no issue which you pick. Pick the one that makes the most sense to you.

I guess what I'm thinking about is the case where I edit on a display (and make my decisions based on that display), and, I keep all the data which is outside the display gamut, for use when viewing on a device with a different gamut. My question is:  Will I like viewing the "newly visible" data? 

Maybe, maybe not?

And, this makes me think:  I can always edit and perfect my art in a smaller gamut and map it to a device with a larger gamut, and get the same exact result.  If I edit on "high gamut NEC display" (for example), but my working space is ProPhoto RGB, will I be pleasantly surprised at my output on a large gamut device?  Or will I be disappointed? Certainly, I will be surprised?

[digitaldog]

My question is:  Will I like viewing the "newly visible" data? 

Maybe, maybe not?

Soft proof and you'll know (pretty much).

[smthopr]

Soft proof and you'll know (pretty much).

How can soft proof show me colors my display can not reproduce? 

It can (not) show colors that my printer can't print, but it can't show me the colors that it can, that I can not display.

You haven't been drinking any kool-aid, have you  

[digitaldog]

How can soft proof show me colors my display can not reproduce?

One of these images is in sRGB, one in Adobe RGB (1998) and screen capture was made on a wide gamut display. You're making a mountain out of a molehill.

Now one in Adobe RGB and one in Epson Luster RGB:

[Tony Jay]

I could add something like: A deltaE of less than 1 between two colors is said to be imperceptible but to complicate matters, there are several formulas for calculating this metric. Further the ability of the eye distinguish two colors as different and is more limited for yellows but is better for greens and blues. This just adds even more difficulty in assigning a meaningful and accurate number of colors to these colors spaces.

Yes indeed, deltaE does not compute well with human colour perception.
I guess a decision would need to be made as to how helpful this is as "entry-level" information about colourspaces.
I mentioned it for completeness but I am not completely sure whether this kind of stuff fits in with "101" level of information.

Tony Jay

[GWGill]

Yes indeed, deltaE does not compute well with human colour perception.

I'm not sure why you say that, as it's not true. Delta E attempts to accord well
with human perception, whereas delta sRGB, delta AdobeRGB, delta printerCMYK or deltaXYZ
is very much worse, and makes no attempt to accord with human perception of color difference.

I guess a decision would need to be made as to how helpful this is as "entry-level" information about colourspaces.

It's pretty basic - you can't manipulate color in a meaningful way without introducing device independent color space, and the limitations of interpreting the significance of numbers in XYZ space lays a trap that will quickly catch the unwary.

[Tony Jay]

Andrew, I haven't drunk any kool-aide from you know who:)
And I'm completely serious. It is possible to fit all the camera data into sRGB.  It just will not display the way you expect.  But, it is possible to reverse the process and display it as YOU WANT. (not yelling, just trying to emphasize a little:)

And in the ultimate reality is that we WILL be editing in our display gamut, like it or NOT.

I think I explained this a little bit in the 2nd half of my post which came after your reply.

Just to emphasize what Andrew has said:
Nearly every camera can capture a gamut that is far larger than sRGB (and AdobeRGB for that matter) - so, no, once a file is imported from the camera using sRGB as an embedded colourspace a lot of colour information is potentially lost.
It is not possible to "reverse" the process and regain the lost colour information.
This is an example of what is called "early binding" in colour management and it means that you have taken a committed step that cannot be undone.
This is the reason most of us use a workflow that employs "late binding" - ie we only commit late in the process to embedding an ICC profile or colourspace to our images once we know exactly what we want to do with that image.
In this context the fact that we may be using ProPhotoRGB as our working colourspace is fine since it does not limit our decision-making and choices.

Tony Jay

[MarkM]

I'm not sure why you say that, as it's not true. Delta E attempts to accord well
with human perception, whereas delta sRGB, delta AdobeRGB, delta printerCMYK or deltaXYZ
is very much worse.

Agreed, but maybe worth restating: everything in CIE colorimetry, including ∆E values, is based on judging color matches in a very controlled and artificial environment. If you take a look at the Beau Lotto image on page 9 of this thread, you'll see an example of two very different "colors" with a ∆E of precisely zero. These tools are too blunt for asking nuanced questions like how many individual colors are in a real-world image if by 'color' we mean something other than a number.

[smthopr]

One of these images is in sRGB, one in Adobe RGB (1998) and screen capture was made on a wide gamut display. You're making a mountain out of a molehill.

Perhaps.  But, perhaps the digital dog, is too dogmatic?

My thinking here is:  You've told me my Epson printer has a larger color gamut than sRGB.  Why do I like the way it looks on my sRGB display, more than my print?  

And it's not just about back-lit vs. reflective.
And in your example, where are the colors from the wide gamut working space in your print?  Can you see them? Of course, I can't see them on my display, but in a print can you seem them?

I can now see how Gary got sucked into this Rabbit hole. It's not easy to explain, and often, the simple explanation involves, un-truths.

[smthopr]

Just to emphasize what Andrew has said:
Nearly every camera can capture a gamut that is far larger than sRGB (and AdobeRGB for that matter) - so, no, once a file is imported from the camera using sRGB as an embedded colourspace a lot of colour information is potentially lost.
It is not possible to "reverse" the process and regain the lost colour information.
This is an example of what is called "early binding" in colour management and it means that you have taken a committed step that cannot be undone.
This is the reason most of us use a workflow that employs "late binding" - ie we only commit late in the process to embedding an ICC profile or colourspace to our images once we know exactly what we want to do with that image.
In this context the fact that we may be using ProPhotoRGB as our working colourspace is fine since it does not limit our decision-making and choices.

Tony Jay

Sorry Tony, I think you misunderstand me.  If I lower the saturation by 1/2 I can fit my wide gamut image into sRGB for example. Then, I can increase my saturation and get back an image the retains the color detail, at the appropriate values for sRGB.  Nothing lost. Still "late binding". We do this all the time in motion capture.  Not a new idea.

[Tony Jay]

I'm not sure why you say that, as it's not true. Delta E attempts to accord well
with human perception, whereas delta sRGB, delta AdobeRGB, delta printerCMYK or deltaXYZ
is very much worse, and makes no attempt to accord with human perception of color difference.It's pretty basic - you can't manipulate color in a meaningful way without introducing device independent color space, and the limitations of interpreting the significance of numbers in XYZ space lays a trap that will quickly catch the unwary.

What I mentioned earlier about how different colours are more difficult to discriminate as different (such as the yellows) needs a delteE of up to 6, compared to the greens and blues where a deltaE of perhaps only 0.2 is sufficient for our vision to tell them apart.
So, in fact, there does appear to be a significant variation in visual discrimination across visible spectrum of colour that does not necessarily correspond to any specific deltaE.

I agree, personally, that none of this information should be above the comprehension of anyone who can use a camera and a computer well but I did not want to push the agenda and possibly skew it if it was felt that this level of detail was pehaps better suited to a "201" level.

Tony Jay

[Tony Jay]

Sorry Tony, I think you misunderstand me.  If I lower the saturation by 1/2 I can fit my wide gamut image into sRGB for example. Then, I can increase my saturation and get back an image the retains the color detail, at the appropriate values for sRGB.  Nothing lost. Still "late binding". We do this all the time in motion capture.  Not a new idea.

No worries!
Given the amount of misinformation that has been squirted around recently it was worthwhile making sure that everyone is on the same page though.

Tony Jay

[smthopr]

No worries!
Given the amount of misinformation that has been squirted around recently it was worthwhile making sure that everyone is on the same page though.

Tony Jay

Yup!

And then, I'm thinking here of the whole issue of luminance levels, or ranges.  Color spaces seem to assume fixed luminance ranges. Doesn't this effect the color gamut as well?  It's an interesting limitation to the "color space" concept.

I can squeeze my 16 stop Dynamic Range from my camera into any display range by showing a low-contrast image.  But what happens with the mapping of colors that we see in this low contrast image.  When we add an "s" curve to cram that into the display, or print, what happens to the color?

What I mean is that now we are dealing very much with perception.  And the whole idea that this is all kind of "automated" as long as one uses color management, is not really true.  Since we are thinking about how to explain this stuff to the novices, then I think, we should just forget about it. That's why it takes an "artist" to make a good print.  Even with a "soft proof", it still takes the interpretation of the artist to make the color space jumps successful.