0

This question was in part motivated by this MathematicaSE question and Matteo Niccoli's geophysics blog post on color schemes. The underlying concept of Niccoli's perceptually-balanced color schemes was to create a color scheme that approximately enforces L*-linearity. For example, Niccoli presents the following illustration:

enter image description here

Throughout the 7-post series, Niccoli argues that perceptual intensity of a color is largely due to its L*-component, and thus if magnitude information is present, it should be encoded via L*; likewise, for phase or azimuth encoding, a constant-L* map should be used. Corroborating this, Bernice Rogowitz wrote

The perceptual reason your method works has to do with the fact that magnitude perception is based on the luminance component of the color scale. Luminance “carries” magnitude information. The goal is for equal data steps to be perceived as equal perceptual steps, and this is well approximated by having the luminance component be monotonic.

I've taken this advice to heart when creating color schemes, and have had both great and bad results with it. Since my question title indicates concern about the use of L*, I'll get straight to the bad. Consider the following map f from the interval [-2, 2] to RGB space:

enter image description here

Here is a plot of 2 UnitTriangle[Sqrt[(x + 1)^2 + y^2]] - 2 UnitTriangle[Sqrt[(x - 1)^2 + y^2]], ie a pair of cones (this SE site unfortunately does not support MathJax), with the previous color scheme:

enter image description here

This function is radially linear, and thus the banded appearance is due to artifacts induced by the color scheme. To that end, here is a picture of the scheme's L*-profile:

enter image description here

It's evident that there is a rough correspondence between bands in the pair of cones and regions of low-modulus L*-derivative. To that end, let's straighten things out!

With a bit of math, it's possible to determine a function g such that the composition fg has roughly constant L*-derivative. Here is a picture of the resulting L*-profile:

enter image description here

And here is the result of applying the resulting function to the same pair of radial cones:

enter image description here

Now (at least on my monitor) while it is evident that while this is better at representing height data than the uncorrected scheme, it still has noticeable artifacts, including a sudden jump from red to yellow and a sudden pointlike transition from yellow to white in the right cone, and a semi-"flat" region after blue turns to light blue in the left cone, along with a white spot of larger radius than is seen in the right cone. So my question is:

  • If L*-linearity does not give a perceptually-linear appearance, what metric gives the complete information?

My first guess was that L* alone can't be the complete picture (since many different colors have the same L* values). Instead, the RGB colorspace can be endowed with the CIE2000 metric (not sure if it satisfies the triangle inequality, but whatever LOL), and this induces a "perceptual velocity" for any path parametrized in colorspace.

Here is a plot of the perceptual velocity of the previous L*-corrected color scheme:

enter image description here

Notice the correspondence between sharp features in the previous cones picture and lumps of high CIE2000 perceptual velocity. From this, I concluded that perhaps CIE2000 velocity is another good measure of the quality of a color scheme, and applied the previous correction mathematics to get some color schemes with constant perceptual velocity; like with L*-correction, I've had both good results and bad results, but I think this question is long enough as is so I won't elaborate unless someone asks.

Just to reiterate: what is the proper metric on color space that one should aim to make uniform when constructing color schemes for data visualization purposes? Alternately, is there no single metric that covers everything? It seems like the whole topic of color is incredibly complex.

closed as off-topic by mattdm, dpollitt, MikeW, Nir, chuqui Dec 21 '14 at 19:21

  • This question does not appear to be about photography within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 4
    This question appears to be off-topic because it is about color for data visualisation in a way that seems unlikely to be useful to photographers. – mattdm Dec 21 '14 at 1:06
  • I don't understand what this has to do with photography. Maybe I'm just too dumb. – dpollitt Dec 21 '14 at 1:37
  • @mattdm: True. However, there does not appear to be any other site in the StackExchange network where this would be considered on-topic, and this is the closest fit I could find, with the largest proportion of people who would be likely to know an answer; my previous posting on MathematicsSE was deemed off-topic because it was about generating images, and it's unlikely to be considered on-topic at Scientific Computing SE. Likewise, this has nothing to do with computer science, so it's technically off-topic at StackOverflow, although they rarely close anything, so maybe I could post there. – DumpsterDoofus Dec 21 '14 at 14:26
  • @dpollitt: This arguably has nothing to do with photography, so if this is closed as off-topic I won't be offended. – DumpsterDoofus Dec 21 '14 at 14:28
1

Now (at least on my monitor) while it is evident that while this is better at representing height data than the uncorrected scheme, it still has noticeable artifacts, including a sudden jump from red to yellow and a sudden pointlike transition from yellow to white in the left cone, and a semi-"flat" region after blue turns to light blue in the right cone, along with a white spot of larger radius than is seen in the left cone. So my question is:

I suspect that there are too many variables between the mathematical generation of the gradients and the moment the light of the monitor reaches the retina (and insufficiencies of the storage format) that impact the result, that the observations should be taken with a grain of salt.

I noticed that you are using sRGB color space for the sample image. sRGB happens to have unusual tone response curve that includes gamma 1 and gamma 2.4 segments. Perhaps testing a color space with straightforward gamma or L* TRC would yield better results? Also, sRGB has a small color gamut. Does your source gradient only contain colors that are reproducible in sRGB or did the program that generated the file had to remap some colors to sRGB gamut? That would certainly result in effects like those we see in the example.

The other thing is the actual monitor and it's profile. If I use an L* TRC display profile, the problem areas in the image shift. That tells me that the TRC may have some effect here. Perhaps it would be best to test this while using L* TRC based profiles from end to end?

Edit: Take a look at dispcalcGUI or ArgyllCMS for tools to generate profiles with custom TRC and to profile display with L* TRC

  • "Also, sRGB has a small color gamut. Does your source gradient only contain colors that are reproducible in sRGB or did the program that generated the file had to remap some colors to sRGB gamut?" In this case, all the computations were done in the sRGB gamut (or at least, that is my understanding); this follows since the original "faulty" color scheme was designed in sRGB space, and the "fixed" version is simply the original curve through sRGB space with an altered velocity, so it is automatically embedded in sRGB. – DumpsterDoofus Dec 21 '14 at 0:24
  • I specifically made sure to do all computations in sRGB based on your answer to my previous question, where you pointed out that doing computations outside of sRGB and then mapping them into sRGB can be disastrous when the curve lies outside of the sRGB gamut. "sRGB happens to have unusual tone response curve that includes gamma 1 and gamma 2.4 segments. Perhaps testing a color space with straightforward gamma or L* TRC would yield better results?" While sRGB does have variable gamma definition (which I just learned about tonight!)... – DumpsterDoofus Dec 21 '14 at 0:25
  • ...I'm not sure this should be a problem, as the computation should (I think?) be independent of the color space in which the original "faulty" curve is embedded. This is because the computational correction is done by mapping the curve from sRGB space into CIELAB 1976 space, which to my understanding contains all other spaces (including sRGB), and doing the computation there. – DumpsterDoofus Dec 21 '14 at 0:26
  • Just to give a flavor of how the computation goes, the L* derivative at each point along the curve is measured in CIELAB 1976 space, and if it's too high, it tells the curve to go slower there, and vice versa, giving a parametric curve embedded in sRGB space with a constant L*-derivative when viewed in CIELAB 1976 space. Could you explain what "L* TRC" is? I was unable to find out what it means with Google search. I will try viewing my post with other devices to see if my monitor display settings are just tricking me. – DumpsterDoofus Dec 21 '14 at 0:26
  • Re sRGB gamut: What I meant is that you are working with scale of integers from 0 to 255. If you take that and recalculate the values, depending on your formula, you might get over 255 or under 0 and you will have rounding errors which may result in artifact similar to what you see on your screen. I would tend to do it in a color space with large gamut and in a file with larger bit depth than 8 or on floating point values to avoid rounding. If you did the calculations in Lab with good bit depth, I suppose it should be fine. The new Lab values must be valid colors in sRGB though... – MirekE Dec 21 '14 at 1:26

Not the answer you're looking for? Browse other questions tagged or ask your own question.