Color management myths and misinformation video

[Rhossydd]

I would say you were correct that an AdobeRGB files can make a better print, but only got lucky that his test agreed with you.

Everyone that refused to make a prediction just played into his hands by refusing to offer the most basic simple advice.
We use wide gamut colourspaces to make better prints. Is it really so hard to agree on such a basic concept ?

[fdisilvestro]

Everyone that refused to make a prediction just played into his hands by refusing to offer the most basic simple advice.
We use wide gamut colourspaces to make better prints. Is it really so hard to agree on such a basic concept ?

I would say that we use color management to make better prints and yes, by using wide gamut you may be able to print more saturated colors in some areas.
The issue with making a prediction is that it was not evident that the proponent of the test knew or used color management properly.

[Bart_van_der_Wolf]

I would say that we use color management to make better prints and yes, by using wide gamut you may be able to print more saturated colors in some areas.

Correct, assuming one uses proper color management.

The issue with making a prediction is that it was not evident that the proponent of the test knew or used color management properly.

I think it's worse, his proclamation that green couldn't clip because it is in the middle of the spectrum suggested that he didn't master a basic understanding of color management (way worse than over-simplifying a visual illustration of the potential issues), which would make predicting the outcome of any test performed by him a crapshoot, at best. Good for 'Rhossydd' that sheer luck was on his side.

However, I don't see much connection with what's being discussed in this informative thread, so let's try not getting sidetracked more than occasionally warranted.

The thing that has become even more clear than it already was (to me anyway), is that there is a lot of confusion about basic (color management/profiles) concepts amongst casual (and even some more advanced) photographers and how those concepts may influence one's results, i.e. image quality, now and in the future. This is especially important if an individual is interested enough to improve his/her skill level over time, and wants to avoid the negative effects of what's called 'early binding' (e.g. shooting in sRGB, or setting one's workingspace for Raw conversion to sRGB).

It's good to keep some options open for future improvements (e.g. by using a wider gamut encoding space than sRGB), but that also requires a little effort to avoid the negative consequences when the basic color management rules of the game are not met, such as converting between profiles instead of assigning, or even letting things up to undefined processes (unknown compliance with proper handling of images tagged with a profile, like with some on-line print services or web-browsers).

Cheers,
Bart

[fdisilvestro]

I'd like to share another experiment I did with Bruce Lindbloom's RGB image with all possible values in 8 bit.

A few pages back in this same thread, some posters claimed it was possible to take a image that would require a wide gamut to avoid clipping, desaturate it, converto to a smaller color space such as sRGB and you would keep all the information. Then when going back to a wide gamut space resaturate and you will be fine.

I thought at first that it would not work, so I decided to put this to a test.

I opened the image and assigned ProPhotoRGB
Then I softproofed using sRGB as the destination space to see how much desaturation I had to apply to avoid clipping. It turns out it required a value of -82 in PS (rather extreme) so that there were no clipped pixels at all.

Finally I converted the image to sRGB.

In the attached images, you can see:

1.- Original reference image
2.- Image desaturated (-82) and converted to sRGB

The second part was to convert back to Prophoto RGB and increase the saturation trying to compensate the previous desaturation. For this purpose I copied this version as a layer on top of the original file, set blending mode to difference and increased the saturation until the resulting image was as black as possible.
 
To my surprise I could get a perfectly black image by increasing the saturation the same magnitude (82).

Image 3 shows the resulting black image from the difference, which means both are equivalent

I looked closely and there were minor differences barely perceptible. Image 4 shows the differences applying a ridiculously aggresive curve to make the differences extreme

Well, this was using 8 bits. I repeated the test with 16 bits and the differences were almost nil even with the extreme curve applied.

Initially I thought it would not work, so I was wrong. In any case, I question the usefulness of such method, since I cannot see what edit I can possibly perform on such a desaturated and dull image other than cropping or straightening a crooked horizon.

Regards,

[sandymc]

Sandy, this calculation makes sense on a mathematical level, and, although I could quibble with the terminology, I don't find it too much of a stretch. Whether CIEL*a*b* is the right metric is also open to debate, but it has the advantage of familiarity.
.
.
.
.

I think that actually mostly we're (with some exceptions) on the same page. What I was trying to say, perhaps not successfully,  is no different to the folks at Chromix, "...this volume number is a rough estimate, not a precise one - and it works well for and is intended for making comparisons between profiles, not for defining absolute volume numbers".

So if you want something that works as sort of a hand waving approximation, that's fine. I mean, whatever. But as an actual hard measure, the use of delta E as a gamut measure is flawed, for all sorts of reasons as discussed previously, and laid out by Chromix.

Frankly, I'm not sure why that's controversial, but clearly it is.

Sandy

[Bart_van_der_Wolf]

[...]
Image 3 shows the resulting black image from the difference, which means both are equivalent

I looked closely and there were minor differences barely perceptible. Image 4 shows the differences applying a ridiculously aggresive curve to make the differences extreme

Well, this was using 8 bits. I repeated the test with 16 bits and the differences were almost nil even with the extreme curve applied.

Hi Frank,

Interesting indeed. However, we do have to account for the fact that smooth gradients may show errors, where very 'busy' images may hide the subtle errors. Also, a difference of 1 may mean that one color is -1 and another neighboring color is +1 off of the original color, which also may become easier to see in smooth regions.

Another aspect is that the desaturation was applied at the 'final' stage of processing. Introducing such a loss of precision earlier in the workflow would almost certainly wreak havoc later, although 16-bit/channel might save us a bit.

Having said that, it does show that we may be able to do some localized desaturation before converting to a smaller gamut space, and perhaps push that saturation a bit once we are in that smaller space, because it might be easier to see what we can get away with, especially when our display, or softproofing quality, is lacking the capability to show us those out-of-gamut colors well enough.

Initially I thought it would not work, so I was wrong. In any case, I question the usefulness of such method, since I cannot see what edit I can possibly perform on such a desaturated and dull image other than cropping or straightening a crooked horizon.

In general, I'm satisfied with an approach (saved as a PS action) that creates and uses a (down-)converted duplicate version of the file in the destination space, as a layer on top of my original. Then a difference layer selection will allow to specifically target the problematic colors, which I may desaturate, or adjust lightness, or shift color, a bit, before ultimately converting my original to a copy in the destination space.

So one can selectively do what you did, but it may fail a bit if the differences are too extreme.

Cheers,
Bart

[smthopr]

Thank you Frank for your demonstration.

I can think of one advantage of starting with a desaturated image in the smaller working space: you can resaturate to taste until the image looks best, like creating your own rendering intent.

[MHMG]

FWIW:
In 16-bit, using the example, ColorThink reports them as 144.1/255.0/240.2 and 144.2/255/240.2.
In 8-bit, using the example, ColorThink reports  them  as 144.0/255.0/241.0 for both.
Save both out as a color list for CT for it's dE report. On is 0.06 dE, the other 0.24. That's using dE2000. As such, I think we have to agree, they are the same color.

They are the same color only when considered as what I like to call "color for color's sake", rather than as "color in context" of a complex arrangement of colors and tones (i.e. a real photographic image, film or digital) and only when meeting other important requirements of the CIELAB color model, namely using a standardized illuminant, subtending a defined viewing angle (i.e, the 2 degree or the 10 degree observer), and when presented against a neutral gray surrounding scene. In a typical image of a scene that most people would want to photograph or otherwise record, the complex arrangements of tone and color will conspire to emphasize these two LAB specified color values as being different or to disguise them as being the same. At least one example of the exact same addressed LAB value appearing as a different color in different parts of the scene has been posted already. There are countless examples, and we could also create images where two different specified LAB values appear to be the same when embedded in different parts of a real image.  As a simple analogy to just how complex scene imagery can get for the human observer to evaluate, think of how camouflage works. I remember reading those "Where's Waldo" books to my young children, where a little man in brightly colored clothing gets hidden within the scene so well that it takes considerable time to discern his existence in the picture. Yet isolate the little guy against a uniform gray surrounding field, and the game of finding him becomes trivial. The specified color values in the little guy haven't changed, only the surrounding colors and tones have to change for the Waldo figure to be "easily recognizable" rather than "just barely noticeable".

For Andrew, as you work towards your new tutorial:

What I've been trying to say in perhaps less than concise language is that CIELAB (and the other variants based on tristimulus functions) is a color model that works exceptionally well as a way of specifying colors independently of each output device's proprietary handling of RGB or CMYK data.  Using an open source, reproducible, repeatable way to assign color values (like CIELAB) to pixels is what makes color management work properly, and the elegance of using independently assigned color specification at the pixel level rather than device assigned color specification is huge...but it's still just a reference color specification. The CIELAB model is not sophisticated enough to predict color appearance in the complex viewing conditions that every photograph presents to the viewer. This realization is why I started to move away in my own understanding of image tone and color reproduction from dwelling solely on CIELAB for specifying Lightness, hue, and chroma properties and Delta E for determining how different those color are. CIELAB does quite well, albeit with room for improvement, but not if limited only to the three appearance properties of lightness, hue, and chroma.  Thus, dividing color and tone reproduction into two distinct categories, color and tone, where "color" refers to hue and choma properties while "tone" describes lightness and contrast properties extends the CIELAB model much further than do delta E color difference models.  

I wrote the following statement about color in an article Jim Kasson mentioned earlier in this thread (you can find the article here: http://aardenburg-imaging.com/cgi-bin/mrk/_4842ZGxkLzBeMTAwMDAwMDAwMTIzNDU2Nzg5LyoxMQ== ):

"If one considers color information in an image as a signal then hue is analogous to the color signal frequency, and chroma is analogous to the color signal amplitude. Similarly, the spatial information content is essentially carried by the tone signal. Local area image contrast represents modulation in the tone signal amplitude. The I* method of sample selection at equi-spaced distances over the full image area correlates to the sampled spatial frequency of the tone signal".

Some people in an audience will understand the concept of a signal being comprised of a frequency and amplitude although perhaps not as many as understand weights and distances (Gary Fong totally missed it when he threw away frequencies in his diagram of the color spectrum as analogous to "smaller color spaces"). However, if we describe color information as a signal, then we can simply state that color spaces like sRGB versus aRGB differ in their ability to encode the amplitude of the color signal (amplitude being subjectively described with terms like "colorfulness" "saturation" "vividness" and/or "chroma"). The color frequency (i.e. hue) is equally encodable in all of the various RGB color spaces. Likewise, the tone signal (lightness and contrast) which conveys the vast majority of the spatial information content (if not, B&W images would be pretty useless) is equally rendered for all practical purposes in any one of the RGB working spaces since the encodable L* values which give rise to image contrast relationships range equally from 0 to 100 L* units in all of these different RGB color spaces.

Thus, it all really boils down to "use aRGB or Prophoto RGB" when you need to preserve higher levels of color saturation in the image than can be properly encoded in the sRGB color space. If you don't have any need to preserve higher color saturation levels, for example, when converting a color scene to Black & White, then you aren't giving up any color and tone fidelity.  There is no technical advantage to the "bigger" RGB working spaces except in their ability to encode higher color saturation. How do you know when a color space is "too small" to encode your chosen image color saturation values correctly? One fairly straight-forward way is to use the histogram function in Lightroom, for example, to see if there is R, G, and/or B channel clipping and if it goes away when choosing a different "bigger" RGB color space.

cheers,
Mark
http://www.aardenburg-imaging.com

[MarkM]

I'd like to share another experiment I did with Bruce Lindbloom's RGB image with all possible values in 8 bit.

Francisco, I found this a while ago, but your post reminded me. Thought you would enjoy it in case you get tired of the Lindbloom image: http://allrgb.com

[digitaldog]

They are the same color only when considered as what I like to call "color for color's sake", rather than as "color in context" of a complex arrangement of colors and tones (i.e. a real photographic image, film or digital) and only when meeting other important requirements of the CIELAB color model, namely using a standardized illuminant, subtending a defined viewing angle (i.e, the 2 degree or the 10 degree observer), and when presented against a neutral gray surrounding scene.

I agree but further, I'd prefer to say we have two different color values than two different colors. Both examples fall well below a dE of 1 so color in context or not, can we call them two different colors? We can say they define two different color values. We can say we are able to define 16.7 million color values but we can't see them all.

Thus, it all really boils down to "use aRGB or Prophoto RGB" when you need to preserve higher levels of color saturation in the image than can be properly encoded in the sRGB color space.

Short, sweet and concise!

There is no technical advantage to the "bigger" RGB working spaces except in their ability to encode higher color saturation.

Agreed.

How do you know when a color space is "too small" to encode your chosen image color saturation values correctly? One fairly straight-forward way is to use the histogram function in Lightroom, for example, to see if there is R, G, and/or B channel clipping and if it goes away when choosing a different "bigger" RGB color space.

Indeed and I illustrate that using the 'boat image' in my Gamut video. Clipping in sRGB disappears when one toggles to ProPhoto RGB.

[digitaldog]

Playing devils advocate with the idea that, if you can't see it, it's not a color, suppose the following: you have a 4096x4096 document and every pixel exact two are the same color value. All of 16 odd million pixels are identical, but two are not and further, they are far greater in difference than a dE of 1. We are viewing the image on-screen to fit. We can't see the two pixels, they are too small unless we zoom in to see individual pixels side by side and in the image where these two outliners reside. Are the two pixels different colors no matter the zoom ratio?
This might be a similar question to "if a tree falls in the forest and no one is around..." And this does go back to a post or two about optical illusions like simultaneous contrast.

This is even more ammo to suggest that it's just a really bad idea to associate color values with colors (we can see) in a gamut of a color space. There's just too many factors that can dismiss what the metric of the color number is supposed to be. The encoding of the color values shouldn't be up to debate. Even if those values fall outside the spectrum locus.

[MarkM]

There is no technical advantage to the "bigger" RGB working spaces except in their ability to encode higher color saturation.

Agreed.

Is that really true? It seems that larger spaces like ProPhotoRGB extend above smaller spaces like sRGB on L* axis suggesting they can encode both more saturated colors as well as lighter colors.

[digitaldog]

It seems that larger spaces like ProPhotoRGB extend above smaller spaces like sRGB on L* axis suggesting they can encode both more saturated colors as well as lighter colors.

I'm not seeing that viewing the two in 3D in ColorThink. Unless I'm misunderstanding what you are saying or how I'm viewing. At least at L*100. But there IS a difference as the larger space moves down from that point.

[digitaldog]

You might have an excellent point here Mark:

[MarkM]

Yes, that's what I was thinking. Or to put another way:
sRGB's red primary at [255, 0, 0] has a LAB value of 54, 81, 70. ProPhoto will happily accommodate 60, 81, 70 which is out of the sRGB gamut.

[digitaldog]

sRGB's red primary at [255, 0, 0] has a LAB value of 54, 81, 70. ProPhoto will happily accommodate 60, 81, 70 which is out of the sRGB gamut.

I get ProPhoto showing a LAB value of 61/128/105 for 255/0/0 so yes, big difference.

[MHMG]

Agreed.


Is that really true? It seems that larger spaces like ProPhotoRGB extend above smaller spaces like sRGB on L* axis suggesting they can encode both more saturated colors as well as lighter colors.

LAB is intended for reflected not emitted light and 100 means a 100 % perfectly reflecting and diffusing surface. While we could encode, say, L =100, a* = 1 or higher, b* =1 or higher, it would be an imaginary color since LAB 100,0,0  is defined as reflecting 100% of all light falling on the surface hence hue is undefined, so no chroma either. Brightness is another visual phenomenon, similar to lightness, but not to be confused or used interchangeably with lightness. We can and do perceive pure white specular highlights in a reflection print as being brighter in appearance than the brightness of the diffuse media white point, but the L* value of that specular white highlight if measured would be the same as the media whitepoint even though in the image it looks brighter.

What people do gain from aRGB or ProPhotoRGB is more headroom for color saturation in color values that are very close to L* =100 but not at 100. Same as they do in mid tone and shadow areas as well.

[MarkM]

LAB is intended for reflected not emitted light and 100 means a 100 % perfectly reflecting and diffusing surface. While we could encode, say, L =100, a* = 1 or higher, b* =1 or higher, it would be an imaginary color since LAB 100,0,0  is defined as reflecting 100% of all light falling on the surface hence hue is undefined, so no chroma either. Brightness is another visual phenomenon, similar to lightness, but not to be confused or used interchangeably with lightness. We can and do perceive pure white specular highlights in a reflection print as being brighter in appearance than the brightness of the diffuse media white point, but the L* value of that highlight if measured would be the same as the media whitepoint even though in the image it looks brighter.

What people do gain from aRGB or ProPhotoRGB is more headroom for color saturation in color values that are very close to L* =100 but not at 100. Same as they do in mid tone and shadow areas as well.

I'm not sure we're talking about the same thing. I'm thinking of a value like xyY [0.64, .33, .21] That's sRGB's red primary. Move straight up on the Y axis and it goes out of sRGB's gamut, but it can still be within ProPhoto's or AdobeRGB's. For example xyY (.64, .33,  .25) is the same chromaticity as the sRGB primary but out of gamut on the Y axis. It is in both ProPhoto's and AdobeRGB's gamut. The larger gamut buys you additional volume on all three dimensions not just chromaticity.

[MHMG]

Yes, that's what I was thinking. Or to put another way:
sRGB's red primary at [255, 0, 0] has a LAB value of 54, 81, 70. ProPhoto will happily accommodate 60, 81, 70 which is out of the sRGB gamut.

Yes, but you can produce a red value at L=60 in sRGB as well and with the same hue using a different RGB triplet as the starting value. It's just that the color you assign won't be as saturated, but it can have same lightness and hue assigned to it thus preserving appropriate visual contrast relationships if your ICC profile and CMM doesn't also attempt to alter hue and lightness relationships too much as well when remapping all of the image color values. As such, the resulting lower saturated red value won't degrade the image information content all that much for most images, just perhaps an image that really really depends for critical color fidelity on squeezing as much color vividness out of a particular red object in the scene. To the viewer, the lowly sRGB rendering is capable of revealing to the viewer the same exact hue, the same lightness, and same contrast relationships in most cases. The red Ferrari will still be a red Ferarri  That said, I concede the color management remapping process can go awry at times which is why many folks call the soft proofing feature the "make it look ugly button".  The subsequent image quality loss which is typically so disconcerting is usually about losses in global and local area image contrast and less about losses in color saturation.

[MarkM]

Yes, but you can produce a red value at L=60 in sRGB as well and with the same hue using a different RGB triplet as the starting value. It's just that the color you assign won't be as saturated,

Or you can have the same hue and saturation, it just won't be as bright, which is another way of saying a larger gamut buys you volume on every dimension, not just saturation.

But I think I now understand the point your making — correct me if I'm wrong: while a larger space extends the upper limit of saturation it doesn't extend the limit on the L* axis. To put another way if I have an sRGB color with 100% saturation, proPhotoRGB might allow a color that is essentially 110% saturation in sRGB, but neither space can exceed 100% L*. I don't think anyone can disagree with that.

My point was that at a particular chromaticity, larger spaces allow higher lightness for that particular chromaticity.